EIP-4736: Consensus Layer Withdrawal Protection

Abstract #

If a consensus layer mnemonic phrase is compromised, it is impossible for the consensus layer network to differentiate the "legitimate" holder of the key from an "illegitimate" holder. However, there are signals that can be considered in a wider sense without changing core Ethereum consensus. This proposal outlines ways in which the execution layer deposit address, a consensus layer rebroadcast delay, and list of signed messages could create a social consensus that would significantly favor but not guarantee legitimate mnemonic holders would win a race condition against an attacker, while not changing core Ethereum consensus.

Motivation #

The consensus layer set withdrawal address proposal is secure for a single user who has certainty their keys and mnemonic have not been compromised. However, as validator withdrawals on the consensus layer are not yet possible, no user can have absolute certainty that their keys are not compromised until the set withdrawal address is on chain, and by then too late to change. All legitimate mnemonic phrase holders were originally in control of the execution layer deposit address. Beacon node clients and node operators may optionally load a list of verifiable deposit addresses, a list of verifiable set withdrawal address messages to broadcasts, and specify a rebroadcast delay that may create a social consensus for legitimate holders to successfully win a race condition against an attacker. If attackers compromise a significant number of consensus layer nodes, it would pose risks to the entire Ethereum community.

Setting a withdrawal address to an execution layer address was not supported by the eth2.0-deposit-cli until v1.1.1 on March 23, 2021, leaving early adopters wishing they could force set their execution layer address earlier. Forcing this change is not something that can be enforced in-protocol, partly due to lack of information on the beacon chain about the execution layer deposit address and partly due to the fact that this was never listed as a requirement. It is also possible that the execution layer deposit address is no longer under the control of the legitimate holder of the withdrawal private key.

However, it is possible for individual nodes to locally restrict the changes they wish to include in blocks they propose, and which they propagate around the network, in a way that does not change consensus. It is also possible for client nodes to help broadcast signed set withdrawal address requests to ensure as many nodes witness this message as soon as possible in a fair manner. Further, such set withdrawal address signed messages can be preloaded into clients in advance to further help nodes filter attacking requests.

This proposal provides purely optional additional protection. It aims to request nodes set a priority on withdrawal credential claims that favour a verifiable execution layer deposit address in the event of two conflicting set withdrawal credentials. It also establishes a list of set withdrawal address signed messages to help broadcast "as soon as possible" when the network supports it, and encourage client teams to help use these lists to honour filter and prioritize accepting requests by REST and transmitting them via P2P. This will not change consensus, but may help prevent propagating an attack where a withdrawal key has been knowingly or unknowingly compromised.

It is critical to understand that this proposal is not a consensus change. Nothing in this proposal restricts the validity of withdrawal credential operations within the protocol. It is a voluntary change by client teams to build this functionality in to their beacon nodes, and a voluntary change by node operators to accept any or all of the restrictions and broadcasting capabilities suggested by end users.

Because of the above, even if fully implemented, it will be down to chance as to which validators propose blocks, and which voluntary restrictions those validators’ beacon nodes are running. Node operators can do what they will to help the community prevent attacks on any compromised consensus layer keys, but there are no guarantees of success this will prevent a successful attack.

Specification #

The Consensus Layer set withdrawal credentials operation MUST have at least the following fields:

• Validator index
• Current withdrawal BLS public key
• Proposed execution layer withdrawal address
• Signature by withdrawal private key over the prior fields

This proposal describes three OPTIONAL and RECOMMENDED mechanisms which a client beacon node MAY implement, and end users are RECOMMENDED to use in their beacon node operation.

1. Set Withdrawal Address Broadcast File #

Beacon node clients MAY support an OPTIONAL file of lines specifying "validator index" , "current withdrawal BLS public key" , "proposed execution layer withdrawal address", and "signature" which, if implemented and if provided, SHALL instruct nodes to automatically submit a one-time set withdrawal address broadcast message for each valid signature at the block height the network supports a "set withdrawal address" operation. This file SHALL give all node operators an OPTIONAL opportunity to ensure any valid set withdrawal address messages are broadcast, heard, and shared by nodes during the first epoch supporting the set withdrawal address operation. This OPTIONAL file SHALL also instruct nodes to perpetually prefer accepting and repeating signatures matching the signature in the file, and SHALL reject accepting or rebroadcasting messages which do not match a signature for a given withdrawal credential.

2. Set Withdrawal Address Rebroadcast Delay #

Beacon node clients MAY implement an OPTIONAL time measurement parameter "set withdrawal address rebroadcast delay" that, if implemented and if provided, SHALL create a delay in rebroadcasting set withdrawal addresses (RECOMMENDED to default to 2000 seconds (>5 epochs), or OPTIONAL set to 0 seconds for no delay, or MAY set to -1 to strictly only rebroadcast requests matching a "Set Withdrawal Address Broadcast" entry). This setting SHALL allow set withdrawal address requests time for peer replication of client accepted valid requests that are preferred by the community. This MAY prevent a "first to arrive" critical race condition for a conflicting set withdraw address.

Set Withdrawal Address Handling #

Beacon node clients are RECOMMENDED to first rely on a "Set Withdrawal Address Broadcast" file of verifiable signatures, and then MAY fallback to accept a "first request" but delay in rebroadcasting it via P2P. All of this proposal is OPTIONAL for beacon nodes to implement or use, but all client teams are RECOMMENDED to include a copy or link to the uncontested verification file and RECOMMENDED enable it by default to protect the entire Ethereum community. This OPTIONAL protection will prove the user was both in control of the consensus layer and execution layer address, while making sure their intended set withdrawal address message is ready to broadcast as soon as the network supports it.

If a node is presented with a set withdrawal address operation via the REST API or P2P, they are RECOMMENDED to follow this process:

A) Withdrawal credential found in "Set Withdrawal Address Broadcast" file:

1. Signature Match: If a valid set withdrawal request signature is received for a withdrawal credential that matches the first signature found in the "Set Withdrawal Address Broadcast" file, accept it via REST API, rebroadcast it via P2P, and drop any pending “first preferred” if existing.
2. Signature Mismatch: If a valid set withdrawal request is received for a withdrawal credential that does not match the first signature found in the "Set Withdrawal Address Broadcast" file, reject it via REST API, and drop it to prevent rebroadcasting it via P2P.

B) Withdrawal credential not found in or no "Set Withdrawal Address Broadcast" file provided, or capability not implemented in the client:

1. Matching withdraw credential and withdraw address in "Set Withdrawal Address Broadcast" file: If a valid set withdrawal address request is received for a withdrawal credential that matches the first found withdrawal address provided in the "Set Withdrawal Address Broadcast" file, accept it via REST API, rebroadcast it via P2P, and drop any pending “first preferred” if existing.

2. Mismatching withdraw credential and withdraw address in "Set Withdrawal Address Broadcast" file: If a valid set withdrawal request is received for a withdrawal credential that does not match the first found withdrawal address provided in the "withdrawal address" file, reject it via REST API, and drop it to prevent rebroadcasting it via P2P.

3. Missing withdraw address in or no "Set Withdrawal Address Broadcast" file:

   i. First Preferred: If first valid set withdrawal address request is received for a not finalized withdrawal credential that does not have any listed withdrawal credential entry in the "Set Withdrawal Address Broadcast" file, accept it via REST API, but do not yet rebroadcast it via P2P (“grace period”) and do not yet propose any local blocks with this message. Once the client “Set Withdrawal Address Grace Period” has expired and no other messages have invalidated this message, rebroadcast the request via P2P and include in locally built blocks if not already present.

   ii. Subsequent Rejected: If an existing valid "First Preferred" request exists for a not finalized withdrawal credential, reject it via REST API, and drop it to prevent rebroadcasting via P2P.

Note that these restrictions SHALL NOT apply to set withdrawal credential operations found in blocks. If any operation has been included on-chain, it MUST by definition be valid regardless of its contents or protective mechanisms described above.

Rationale #

This proposal is intended to protect legitimate mnemonic phrase holders where the phrase was knowingly or unknowingly compromised. As there is no safe way to transfer ownership of a validator without exiting, it can safely be assumed that all current validator holders intend to set to a withdrawal address they specify. Using the deposit address in the execution layer to determine the legitimate holder is not possible to consider in consensus as it may be far back in history and place an overwhelming burden to maintain such a list. As such, this proposal outlines optional mechanism which protect legitimate original mnemonic holders and does so in a way that does not place any mandatory burden on client node software or operators.

Backwards Compatibility #

As there is currently no existing "set withdrawal address" operation, there is no documented backwards compatibility. As all of the proposal is OPTIONAL in both implementation and operation, it is expected that client beacon nodes that do not implement this functionality would still remain fully backwards compatible with any or all clients that do implement part or all of the functionality described in this proposal. Additionally, while users are RECOMMENDED to enable these OPTIONAL features, if they decide to either disable or ignore some or all of the features, or even purposefully load content contrary to the intended purpose, the beacon node client will continue to execute fully compatible with the rest of the network as none of the proposal will change core Ethereum consensus.

Reference Implementation #

Set Withdrawal Address Broadcast File #

A "change-operations.json" file intended to be preloaded with all consensus layer withdrawal credential signatures and verifiable execution layer deposit addresses. This file may be generated by a script and able to be independently verified by community members using the consensus layer node, and intended to be included by all clients, enabled by default. Client nodes are encouraged to enable packaging this independently verifiable list with the client software, and enable it by default to help further protect the community from unsuspected attacks.

The change-operations.json format is the "Set Withdrawal Address File - Claim" combined into a single JSON array.

Set Withdrawal Address Broadcast File - Claim #

A community collected and independently verifiable list of "Set Withdrawal Address Broadcasts" containing verifiable claims will be collected. Client teams and node operators may verify these claims independently and are suggested to include "Uncontested and Verified" claims enabled by default in their package.

To make a verifiable claim, users MAY upload using their GitHub ID with the following contents to the CLWP repository in a text file "[chain]/validatorIndex.json" such as "mainnet/123456.json" or MAY construct a repository of their own.

123456.json:

[{"message":{"validator_index":"123456","from_bls_pubkey":"0x977cc21a067003e848eb3924bcf41bd0e820fbbce026a0ff8e9c3b6b92f1fea968ca2e73b55b3908507b4df89eae6bfb","to_execution_address":"0x08f2e9Ce74d5e787428d261E01b437dC579a5164"},"signature":"0x872935e0724b31b2f0209ac408b673e6fe2f35b640971eb2e3b429a8d46be007c005431ef46e9eb11a3937f920cafe610c797820ca088543c6baa0b33797f0a38f6db3ac68ffc4fd03290e35ffa085f0bfd56b571d7b2f13c03f7b6ce141c283"}]

Claim Acceptance #

In order for a submission to be merged into CLWP GitHub repository, the submission must have:

1. Valid filename in the format validatorIndex.json
2. Valid validator index which is active on the consensus layer
3. Verifiable signature
4. A single change operation for a single validator, with all required fields in the file with no other content present

All merge requests that fail will be provided a reason from above which must be addressed prior to merge. Any future verifiable amendments to accepted claims must be proposed by the same GitHub user, or it will be treated as a contention.

Set Withdrawal Address Broadcast #

Anyone in the community will be able to independently verify the files from the claims provided using the Capella spec and command line clients such as "ethdo" which support the specification.

A claim will be considered contested if a claim arrives where the verifiable consensus layer signatures differ between two or more GitHub submissions, where neither party has proven ownership of the execution layer deposit address. If a contested but verified "Set Withdrawal Address Broadcast" request arrives to the GitHub community, all parties will be notified via GitHub, and may try to convince the wider community by providing any publicly verifiable on chain evidence or off chain evidence supporting their claim to then include their claim in nodes. Node operators may decide which verifiable claims they wish to include based on social consensus.

Security Considerations #

1: Attacker lacks EL deposit key, uncontested claim #

• User A: Controls the CL keys and the EL key used for the deposit
• User B: Controls the CL keys, but does not control the EL key for the deposit

User A signs and submits a claim to the CLWP repository, clients load User A message into the "Set Withdrawal Address Broadcast" file. At the time of the first epoch support Set Withdrawal Address, many (not all) nodes begin to broadcast the message. User B also tries to submit a different but valid Set Withdrawal Address to an address that does not match the signature in the claim. This message is successfully received via REST API, but some (not all) nodes begin to silently drop this message as the signature does not match the signature in the "Set Withdrawal Address Broadcast" file. As such, these nodes do not replicate this message via P2P. The nodes which do not have a Set Withdrawal Address Broadcast file loaded may still impose a "Set Withdrawal Address Rebroadcast Delay" to keep listening (for about 5 epochs) to see if there are any conflicts to this message. This delay may give User A an advantage in beating User B to consensus, but there is no certainty as it will depend on chance which validator and nodes are involved.

2: Attacker has both EL deposit key and CL keys, uncontested claim #

• User A: Controls the CL key/mnemonic and the EL key used for the deposit, and submits a claim to move to a new address
• User B: Controls the CL and EL key/mnemonic used for the EL deposit, but fails to submit a claim

It is possible/likely that User A would notice that all their funds in the EL deposit address had been stolen. This may signal that their CL key is compromised as well, so they decide to pick a new address for the withdrawal. The story will play out the same as Scenario 1 as the claim is uncontested.

3: Same as #2, but the attacker submits a contested claim #

• User A: Controls the CL keys/mnemonic and the EL key used for the deposit, and submits a claim to move to a new address
• User B: Controls the CL keys/mnemonic and the EL key used for the deposit, and submits a claim to move to a new address

This is a contested claim and as such there is no way to prove who is in control using on chain data. Instead, either user may try to persuade the community they are the rightful owner (identity verification, social media, etc.) in an attempt to get node operators to load their contested claim into their "Set Withdrawal Address Broadcast" file. However, there is no way to fully prove it.

4: A user has lost either their CL key and/or mnemonic (no withdrawal key) #

• User A: Lacks the CL keys and mnemonic

There is no way to recover this scenario with this proposal as we cannot prove a user has lost their keys, and the mnemonic is required to generate the withdrawal key.

5: End game - attacker #

• User A: Controls EL and CL key/mnemonic, successfully achieves a set address withdrawal
• User B: Controls CL key, decides to attack

Upon noticing User A has submitted a successful set address withdrawal, User B may run a validator and attempt to get User A slashed

6: Compromised key, but not vulnerable to withdrawal #

• User A: Controls EL and CL key/mnemonic, but has a vulnerability which leaks their CL key but NOT their CL mnemonic
• User B: Controls the CL key, but lacks the CL mnemonic

User A may generate the withdrawal key (requires the mnemonic). User B can attack User A by getting them slashed, but will be unable to generate the withdrawal key.

7: Attacker loads a malicious Set Withdrawal Address Broadcast file into one or multiple nodes, User A submits claim #

• User A: Submits a valid uncontested claim which is broadcast out as soon as possible by many nodes
• User B: Submits no claim, but broadcasts a valid malicious claim out through their Set Withdrawal Address Broadcast list, and blocks User A's claim from their node.

User B's claim will make it into many nodes, but when it hits nodes that have adopted User A's signature they will be dropped and not rebroadcast. Statistically, User B will have a harder time achieving consensus among the entire community, but it will be down to chance.

8: Same as #7, but User A submits no claim #

The attacker will statistically likely win as they will be first to have their message broadcast to many nodes and, unless User A submits a request exactly at the time of support, it is unlikely to be heard by enough nodes to gain consensus. All users are encouraged to submit claims for this reason because nobody can be certain their mnemonic has not been compromised until it is too late.

Second Order Effects #

1. A user who participates in the "Set Withdrawal Address Broadcast" may cause the attacker to give up early and instead start to slash. For some users, the thought of getting slashed is preferable to giving an adversary any funds. As the proposal is voluntary, users may choose not to participate if they fear this scenario.
2. The attacker may set up their own Set Withdrawal Address Broadcast to reject signatures not matching their attack. This is possible with or without this proposal.
3. The attacker may be the one collecting "Set Withdrawal Address Broadcast" claims for this proposal and may purposefully reject legitimate requests. Anyone is free to set up their own community claim collection and gather their own community support using the same mechanisms described in this proposal to form an alternative social consensus. Come at me bro.

Copyright #

Copyright and related rights waived via CC0.