EIP-7044 Making voluntary exit signatures permanently valid (Perpetually Valid Signed Voluntary Exits)
Final · Consensus & staking · EIP status Final · created 2023-05-18
Pins the signature verification of a validator's voluntary exit to the Capella fork domain. An exit message signed once stays valid through any later upgrade.
Why it is needed
To end staking, a validator must send the network a voluntary exit message signed with the active key. However, the beacon chain only accepts the current and previous fork versions when verifying a signature, so a signed exit message was valid for only two upgrades. The problem arises when the operator who actually runs the validator (the active key holder) and the owner of the funds (the withdrawal credential holder) are different. An exit can only be signed with the active key, so the fund owner has to obtain a signed exit from the operator in advance, but it became invalid at every fork and had to be obtained again endlessly. This restriction was originally meant to prevent an exit message from being reused on both sides when a hard fork splits the chain in two. But even if it is reused, funds are not at risk and stakers can simply stake again on one or both chains, so it was judged not worth the usability cost.
What changes
Today
- A signed voluntary exit is valid only under the current and previous fork versions, that is, for at most two upgrades
- In staking where the operator and the fund owner differ, exit signatures must be exchanged again at every fork
- Exit-related tooling must keep updating fork version information
After EIP-7044
- An exit signed with the Capella fork domain is permanently valid across all later forks
- The exit signature only needs to be obtained once in advance
- It gives the same usability as deposits and BLS withdrawal address changes (BLSToExecutionChanges), so tooling does not need to know the fork version
Who is affected
- Institutional and delegated staking operators: In a setup where operator and fund owner are separate, the exit signature only needs to be exchanged once, which simplifies operational design
- Solo stakers: An exit pre-signed with the Deneb domain is no longer valid, so it must be signed again with the Capella domain
- Client teams: process_voluntary_exit and the gossip validation conditions must be modified in the Deneb upgrade
- Staking tool developers: Exit handling tools no longer need to update fork version information
In depth
Pin the signing domain to Capella
One thing changes in the state transition function. process_voluntary_exit is modified to compute the signing domain and signing root pinned to CAPELLA_FORK_VERSION. This change is included in the Deneb upgrade of the consensus specs. The voluntary_exit gossip validation conditions are also implicitly modified to support this change. For backward compatibility, the domain is pinned to the Capella fork rather than Deneb.
Why exits were valid for only two upgrades
The beacon chain state considers only the current fork version and the previous fork version when verifying a signature. As a result, a signed voluntary exit was valid for at most two upgrades, counted by block inclusion. In staking setups where the operator holding the active key and the fund owner holding the withdrawal credential are different, the number of future forks is not fixed, so signed exits had to be exchanged in advance for every fork, which was a burden.
Why replay protection was given up
The validity window was originally meant for a situation where a hard fork leaves both chain A and chain B alive. If a validator is active on both chains and then sends an exit, that message could be reused on both. But even if a reuse happens, funds are not at risk and stakers can stake again on one or both chains, so this possibility alone was judged not enough to justify the usability cost described above.
Invalid if pre-signed with the Deneb domain
This change is backward compatible with the consensus layer's block processing logic. However, expectations about the future validity of exits are not forward compatible. Users who expected an exit pre-signed with the Deneb fork domain to remain valid should know that such a signature is no longer accepted as valid. To remain valid in Deneb and later forks, it must be signed with the Capella fork domain. There are no changes to the execution layer and no compatibility issues.
Security impact
Previously, the signing domain differed for each forked network, so after two hard forks the replay of a voluntary exit was prevented. This change removes that replay protection. A replay could affect individual stakers on both sides of a fork, but funds are not at risk and chain security is not affected.
Design intent and current status
Permanently valid exit signatures simplify staking operational design. The usability of these objects is also aligned with BLSToExecutionChanges and deposits, so downstream tooling no longer needs to update fork version information. This EIP is in Final status, and its test cases are in the deneb test suite of the consensus-specs repository.