Return deposits for distinct credentials

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_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, 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.