EIP-7684: Return deposits for distinct credentials
Automatically withdraw deposits for existing validator records but with distinct execution withdrawal credentials
| Authors | Lion (@dapplion) |
|---|---|
| Created | 2024-04-12 |
| Discussion Link | https://ethereum-magicians.org/t/eip-7684-return-deposits-for-distinct-credentials/19632 |
Table of Contents
Abstract
Automatically withdraw deposits for existing validator records, but where the deposit includes a distinct execution withdrawal credential.
Motivation
Some staking operations feature two distinct entities, one operating the validating key, and one funding the deposit. The funding entity delegates control of the stake operation but must retain ultimate control of funds. If the funding entity naively submits a single deposit with the full stake amount and the other entity’s validating key, it is subject to a front-run attack. The validating entity can front-run the bigger deposit with a second deposit with its own set of withdrawal credentials. The full stake amount deposit becomes a top-up, in control of the validating entity.
There exist workarounds to the front-run attack. Using some distributed key generation protocol between the funding and validating entity, such that a deposit must be made with the consent of both entities. Submit a 1 ETH deposit first wait for its inclusion then send the full stake amount as a top-up, to bind the maximum loss under the attack to 1 ETH. While these workarounds, work; they difficult the operation of trustless autonomous staking protocols.
This specification reduces the total loss on a naive deposit submission from the full deposit amount to RETURN_DEPOSIT_PENALTY.
Specification
Consensus Layer
The configuration values and mechanics of the specification can be found in the Consensus Layer specs.
A sketch of the resulting changes to the consensus layer is included below.
- Modify
apply_depositto queue for withdrawal deposits with distinct execution withdrawal credentials - Modify
get_expected_withdrawalsto return pending withdrawals first - Modify
process_withdrawalsto clear the pending withdrawals queue
Execution Layer
This specification does not require any changes to the Execution Layer.
Rationale
Persist pending withdrawals
Rejected deposits from block at slot N can not be withdrawn in block N due to a cyclic dependency. An execution client must know the full list of withdrawals before constructing a payload for slot N. After EIP-6110, a consensus client must know the full execution payload for slot N before constructing the beacon block for slot N. Therefore, rejected deposits must be withdrawn in some future slot. All pending withdrawals are processed at once in the very next slot for simplicity but could be queued and processed progressively if there are DOS concerns.
Backwards Compatibility
This is a backward incompatible change to the Consensus Layer of Ethereum and must be scheduled with a hard fork.
There are no forwards / backwards compatibility issues with the Execution Layer
Test Cases
Test cases are work-in-progress within the standard Consensus Layer tests.
Security Considerations
The worst-case number of withdrawals is raised from a fixed 16 to 1,271 under current gas rules and a 30M gas block. Citing EIP-6110, future gas efficiencies can increase the number to 1,916 withdrawals in a 30M gas block. Each withdrawal results in a single address balance change. There is no explicit pricing for such an operation, but under the worst case, it results in a notable increase in the total block gas (30% assuming 6,900 gas per withdrawal and current gas rules).
RETURN_DEPOSIT_PENALTY disincentivizes rejected deposits, and imposes a gas cost of 144,927 Gwei / gas, assuming 6,900 gas per withdrawal.
Copyright
Copyright and related rights waived via CC0.
Citation
Please cite this document as:
Lion (@dapplion), "EIP-7684: Return deposits for distinct credentials [DRAFT]," Ethereum Improvement Proposals, no. 7684, April 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7684.