forked from ethereum/EIPs
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add EIP: Return deposits for distinct credentials
Merged by EIP-Bot.
- Loading branch information
Showing
1 changed file
with
67 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,67 @@ | ||
--- | ||
eip: 7684 | ||
title: Return deposits for distinct credentials | ||
description: Automatically withdraw deposits for existing validator records but with distinct execution withdrawal credentials | ||
author: Lion (@dapplion) | ||
discussions-to: https://ethereum-magicians.org/t/eip-7684-return-deposits-for-distinct-credentials/19632 | ||
status: Draft | ||
type: Standards Track | ||
category: Core | ||
created: 2024-04-12 | ||
--- | ||
|
||
## 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](https://github.com/ethereum/consensus-specs/blob/2360756c8c19c0f7b0e91135f5bbcddecdf0a835/specs/_features/eip9999/beacon_chain.md). | ||
|
||
A sketch of the resulting changes to the consensus layer is included below. | ||
|
||
- Modify `apply_deposit` to queue for withdrawal deposits with distinct execution withdrawal credentials | ||
- Modify `get_expected_withdrawals` to return pending withdrawals first | ||
- Modify `process_withdrawals` to 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](./eip-6110.md), 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](./eip-6110.md), 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](../LICENSE.md). | ||
|
||
|