EIP-6110 Onchain supply of validator deposits (Supply validator deposits on chain)
Final · Consensus & staking · EIP status Final · created 2022-12-09
Validator deposit records are included as a list in execution layer blocks and passed directly to the consensus layer. The existing block proposer voting method (Eth1Data) is deprecated.
Why it is needed
To become a validator, a user must send ether (ETH) to the deposit contract on the execution layer. Until now the consensus layer could not see these deposit records directly, so block proposers used a workaround: they voted on how far deposits were valid (the Eth1Data vote). This approach takes about 12 hours for a deposit to be reflected on the beacon chain, and it relies on a safety assumption that an attacker holding more than two thirds of the stake could make honest nodes accept a fake deposit. It also had many fragile parts: consensus clients depended on JSON-RPC queries and had to maintain a deposit contract snapshot (EIP-4881). This EIP removes these problems by placing deposit data directly in execution layer blocks so that the protocol itself verifies it.
What changes
Today
- It takes about 12 hours for a deposit to be reflected on the beacon chain
- Deposits are finalized by a block proposer vote (Eth1Data), so if more than 2/3 of the stake is malicious, even honest nodes can accept a fake deposit
- Consensus clients fetch deposit records separately through JSON-RPC queries
- The deposit contract snapshot (EIP-4881) must be maintained and distributed
After EIP-6110
- The time until a deposit is reflected drops to about 13 minutes
- The execution layer verifies deposits directly while executing the block, so honest online nodes are not fooled by fake deposits
- The deposit list is included in the block, so no separate query is needed
- The requirement to maintain and distribute snapshots disappears
Who is affected
- Validators and stakers: About 13 minutes after a deposit is submitted, it is reflected on the consensus layer, which greatly shortens the wait.
- Consensus client teams: They can remove the Eth1Data vote and JSON-RPC dependency code, but validator indexes can differ across forks, so they must change how the (pubkey, index) cache is handled.
- Execution client teams: They implement new block validity rules that parse deposit logs, include them as EIP-7685 requests, and validate them.
- Ordinary users: The block structure and validation rules change, but user activity and experience are not affected.
In depth
Deposit request structure and EIP-7685 encoding
The new deposit request consists of five fields: pubkey: Bytes48, withdrawal_credentials: Bytes32, amount: uint64, signature: Bytes96, index: uint64. A deposit is treated as one kind of generic request defined by EIP-7685, and the request type byte is DEPOSIT_REQUEST_TYPE = b'0'. request_data is the byte string formed by concatenating the deposit requests extracted from the block receipts with get_deposit_request_data. amount and index are read from the log data as 8-byte little-endian uint64 values.
Block validity check: extracting deposits from logs
From FORK_BLOCK (the first block after this EIP is activated), every deposit that occurs in a block must be placed in the EIP-7685 request list in the same order it appears in the logs. The execution client selects only the receipt logs whose address is DEPOSIT_CONTRACT_ADDRESS (0x00000000219ab540356cbb839cbe05303d7705fa) and whose first topic is DEPOSIT_EVENT_SIGNATURE_HASH. This filtering is necessary because some deposit contracts, such as the Sepolia one, emit other events like Transfer in addition to DepositEvent. is_valid_deposit_event_data checks that the log data is 576 bytes long in total, that the offsets of the five fields are 160, 256, 320, 384, and 512, and that their sizes are 48, 32, 8, 96, and 8. If anything does not match, the log is treated as a malformed deposit log with an unsupported layout. Both constants must be included in the client software binary distribution.
Consensus layer changes and deprecation of the Eth1Data vote
On the consensus layer, a deposit_requests field is added to ExecutionRequests, and deposit_requests_start_index is added to BeaconState. A new process_deposit_request function is added to the block processing routine, along with a block validity condition that restricts use of the Eth1Data vote during the transition period. The index value carried in each deposit is used to deterministically initialize deposit_requests_start_index, which prevents the same deposit from being applied twice during the transition. The transition is considered complete when state.eth1_deposit_index == state.deposit_requests_start_index. After that, each consensus client can remove its Eth1Data vote code on its own, without coordination. The detailed specification is in the consensus-specs documents electra/beacon-chain.md, electra/validator.md, and electra/fork.md.
Validator indexes differ across forks
In the old approach, thanks to the long follow distance of the Eth1Data vote, a new validator's index was the same on every branch of the block tree, and the consensus client's (pubkey, index) cache was unaffected by reorgs. The new mechanism breaks this invariant, so a validator with the same pubkey can have a different index on different branches of the block tree. According to the analysis attached to the original text, the process_deposit function is the only place that needs a fork-dependent (pubkey, index) cache.
Data complexity and DoS analysis
As of the last update of the document, cumulative deposits total 1,899,120 entries and 348MB. At the same rate this grows by about 84MB a year, which it judges negligible compared with other historical data. Even on June 1, 2023, the biggest spike, there were more than 12,000 deposits in 24 hours, an average of fewer than 2 deposits (384 bytes) per block. The cheapest execution of the deposit contract costs 15,650 gas, and under current rules a 30M gas block can hold fewer than 1,271 deposits, but for future robustness the beacon chain must be able to handle up to 1,916. The heaviest operation is signature verification: about 1,271 deposits take about 1.2 seconds without optimization, and delaying block processing by 1 second would cost an attacker 1,000 ETH, so this is not a sustainable attack. A node doing optimistic sync can receive a block with up to 8,192 deposits (1.5MB, about 8 seconds of processing), but the attacker would have to build an alternative chain and make economically valid signatures, so it judges that sync cannot be slowed significantly. Because the minimum deposit is 1 ETH, one byte of deposit data costs about 5,208,333 Gwei, tens of times more expensive than ordinary calldata, so the execution layer DoS surface does not grow either.
Weak subjectivity period and final state
This EIP removes the fixed cap on deposits per epoch and leaves only the block gas limit. The limit changes from MAX_DEPOSITS * SLOTS_PER_EPOCH = 512 deposits to max_deposits_per_30m_gas_block * SLOTS_PER_EPOCH ~ 32,768 deposits for a 30M gas block (simplified to 1,024 per block). The number of top-ups is one input to the weak subjectivity period calculation, but the analysis attached to the original text finds that the period does not shrink meaningfully. It judges such an attack invalid because it presupposes burning a substantial amount of stake. The status of this EIP is Final, and the consensus layer specification is reflected in the Electra documents.