Proposed mitigation against a malicious staking pool refusing to exit a validator

[zah]

The security of stakers who trust the services of staking pools has been greatly enhanced with the introduction Eth1 withdrawal credentials that allow an arbitrary smart contract to govern the funding process and the withdrawal rights of potentially multiple stakers.

One possible problem though is that nothing guarantees that the node operator who holds the signing key for the validator will perform an exit at an agreed upon exit date. The operator can decide to keep validating forever with the goal of extracting MEV value from proposed execution layer blocks.

One simple mitigation for this problem is to require the operator to share a pre-signed exit message specifying the exit epoch for the created validator before the stakers have deposited their funds ("require" in the sense that potential stakers will seek out the services of operators that offer this). The stakers will be then able to broadcast the message on their own to trigger the exit. The current problem with this approach is that the exit message features a validator index instead of a validator public key and the stakers cannot know the final validator index before the deposit is submitted to the deposit contract. To facillitate the practice of pre-sharing an exit message, we can define the following new form of an exit message:

class KeyedVoluntaryExit(Container):
    epoch: Epoch  # Earliest epoch when voluntary exit can be processed
    validator_pubkey: BLSPubkey
    
class SignedKeyedVoluntaryExit(Container):
    message: KeyedVoluntaryExit
    signature: BLSSignature

Furthermore, in order to make the new exit messages portable across forks, the domain of their signature can always use the GENESIS_FORK_VERSION (just like deposit signatures).

It would be enough to introduce a new gossip topic for broadcasting such messages and a new List field in the BeaconBlockBody container that will have zero cost when not used. Alternatively, the new definition can just replace the previous one, assuming it is introduced in a fork that changes the gossip topic names.

[potuz]

Why not just change the existing message instead of having two separate messages for exits? Are there any contracts controlling validators that would break?

[mcdee]

@potuz because there will already be signed voluntary exit transactions out there that would then break.

@zah is there any proper use case for this? Given that there are staking services that have been running for nearly a year, I would assume that their customers accept the current situation.

[zah]

@mcdee, I think this concern is going to become more relevant once the staking pools start migrating from "terms of services" style of legal contracts (which are hard to enforce around the globe) to smart contracts and 0x01 withdrawal credentials. The tighter the guarantees that can be expressed in such a contract, the better.

[mcdee]

Not sure about that. If the withdrawal address is a smart contract then who should hold the pre-signed exit transaction?

[zah]

It will be generated by the operator and shared with all stakers upfront. It's possible to design the smart contract in such a way that the operator commits to a validator public key before it starts collecting deposits from potential stakers. If the public key is known upfront, it can be used to verify the pre-signed exit message as well. The stakers will then be confident that they are entering a fixed-term contract ending at a specific date (the exit epoch in the shared exit message).

[mcdee]

Sounds like this issue could be solved outside the protocol by the staking service putting up a bond on a smart contract that can be reclaimed by the staking service on presentation of the signed data for a voluntary exit, or by the staker(s) after a certain time period.

In general I'd like to see the beacon chain protocol kept as lean as possible. If this could be solved outside the protocol then it seems to make sense to do so.

[zah]

While it's true that the proposed bond can be an alternative mitigation, it does increase the capital requirements for providing staking services and it's not clear what is the appropriate size of the bond considering that the operator can continue extracting MEV value indefinitely.

[zah]

@potuz because there will already be signed voluntary exit transactions out there that would then break.

Currently, beacon chain hard-forks already invalidate previously signed exit messages which makes it difficult to reason about exit messages targetting epochs in the distant future. The proposed SignedKeyedVoluntaryExit signature treatment addresses this problem as well.

[mcdee]

Surely the bond is 32 ETH for each validator, as it allows the stakers to retrieve the funds and go elsewhere. It would only be short-term, as it would not be needed once the pre-signed exit transaction was made available.

But these are details. If we can do this outside of the protocol, I'd very much prefer it to loading the protocol wit point interest

[mcdee]

Currently, beacon chain hard-forks already invalidate previously signed exit messages which makes it difficult to reason about exit messages targetting epochs in the distant future. The proposed SignedKeyedVoluntaryExit signature treatment addresses this problem as well.

Danny stated that using the current fork version rather than the genesis one was to avoid a potential replay attack on forks. I don't remember the details, however.

[zilm13]

Special fork rules for one kind of message looks like a really bad idea

[zah]

This issue is largely resolved by the introduction of https://eips.ethereum.org/EIPS/eip-7002 and https://eips.ethereum.org/EIPS/eip-7044