Discussion topic for EIP-7800 Add EIP: Withdrawal Credential Update Request by lucassaldanha · Pull Request #9005 · ethereum/EIPs · GitHub
This proposal defines a mechanism to allow validators to update their withdrawal credentials using a new execution request type (0x3). The request allows for changing the execution address and the withdrawal credential prefix (0x01 or 0x02).
Hello! How will the proposed mechanism in EIP-7804 ensure the security and integrity of updated withdrawal credentials for Ethereum validators, and are there any potential risks associated with changing execution addresses and credential prefixes?
How will the proposed mechanism in EIP-7804 ensure the security and integrity of updated withdrawal credentials for Ethereum validators
The mechanism proposed is similar to other execution layer requests (e.g., withdrawal requests). When the function to create an update request is called, the smart contract uses the msg.caller address as old_address when creating the request. Therefore, on the CL side, the protocol can verify that old_address matches the current validator withdrawal credential address and only update it if they match. This way, we ensure that only the current validator.withdrawal_credentials owner can update the address.
are there any potential risks associated with changing execution addresses and credential prefixes?
I don’t think there are any extra security considerations for execution addresses. As long as we guarantee that the address can only be updated by the “owner” of the previous address, this is all that is needed.
In terms of changing credential prefixes, there are two possible scenarios: changing from 0x01 to 0x02 and from 0x02 to 0x01.
The first scenario (0x01 → 0x02) is straightforward and does not need any extra consideration and we can re-use the rules from is_valid_switch_to_compounding_request .
The second scenario (0x02 → 0x01) is a bit more complicated. Any excess balance needs to go through the churn to prevent sudden changes in staked eth. We are still researching what would be the best way to accomplish this safely.
Hi. Will the solution require validators to go through the exit queue (or any other time delaying mechanism) in the same way that validator consolidations will and therefore be subject to churn limits? Also will the effective balance have an impact on time it takes to update the withdrawal address, eg a validator with EB of 32 vs EB of 2048?
The short answer is yes. We need a mechanism to ensure the excess balance when changing from 0x02 to 0x01 goes through the exit queue. It would probably be something similar to what is done in Pectra (next fork) for partial withdrawals with some extra logic around only effectively changing the credentials upon the balance being completely withdrawn or something like that. I haven’t spent a lot of time defining those mechanisms yet because I wanted to gauge if this EIP will get enough support/traction before spending too much time on the details.
The challenge with this is to create a mechanism that does not bring a lot of extra complexity to the protocol. One possible solution would be to require a validator that wants to change from compounding (0x02) to execution (0x01) to use a partial withdrawal (introduced in Electra) to bring their balance “close” to 32 ETH. The partial withdrawal mechanism already takes into account the churn and everything. Later, when processing the credential update, as long as the balance is within a certain tolerance of 32 ETH (e.g. < 32.5 ETH).
Using this approach, we can limit the amount of balance that will “leave” the stake per slot (MAX_UPDATES_PER_SLOT * tolerance).
I don’t think changing the address requires any special treatment. The consideration is related to changing creds type.