Main downsides of existing Eth1Data
poll are as follows:
These features are dictated by necessity of maintaining a bridge between two disjoint blockchains which is no longer the case post-Merge. This opens up an opportunity to improve on deposit processing flow.
EL is responsible for surfacing receipts of deposit transactions and including them into an execution block. In particular, EL is collecting DepositEvents
from transactions calling to deposit contract deployed in the network after transaction execution and either adds them to the block structure (when building a block) or runs necessery validations over the list of events. Computational cost of this addition should be marginal as EL does already make a pass over receipts to obtain receipts_root
.
Execution block header is equipped with deposits_root
field (a root of a list of deposit operations, akin to withdrawals_root
in the EIP-4895). Execution block body is equipped with the new deposits
list containing elements of the following type:
When validating a block, EL runs two additional checks over deposits_root
:
deposits_root
value in a block header must be equal to the root of deposits list obtained from the the block executiondeposits_root
must be consistent with deposits
list of the corresponding block bodyAddress of the deposit contract becomes a network configuration parameter on EL side.
The following structures, methods and fields become deprecated:
Eth1Data
Deposit
process_eth1_data
process_eth1_data_reset
process_deposit
BeaconBlockBody.deposits
BeaconState.eth1_deposit_index
ExecutionPayload
BeaconState
process_pending_deposit
process_block
During the period of transition from the old Eth1Data
poll mechanism to the new one clients will have to run two machineries in parallel until the moment in time when Eth1Data
poll period overlaps with the a span of blocks containing the new deposits
list.
process_eth1_data
process_pending_deposits
Given that no more merkle proof is required to process a deposit, data complexity per deposit is reduced roughly by 1Kb
.
With a cost of deposit transaction roughly equal to 60k gas and gas limit at 30m gas, a block may have 500 deposit operations at max. This is 192*500 = ~94Kb
(~47Kb
at a target block size) per block vs 1240*16 = ~19Kb
per block today.
Alternatively, deposit queue may be moved from CL state to EL state to rate limit a number of deposits per block.
There are ~410k deposits made until today. The size of overall deposit data would be ~75Mb
.
The cache is used by all CL clients to optimise deposit processing flow and in other places. Recent entries of the pubkey cache will have to be invalidated upon re-org as a validator (index, pubkey)
pair is fork dependent.
Eth1Data
and votingAnother path was explored to reuse the eth1data
machinery as much as possible. In this path, the block's eth1data
vote would be passed to EL in the engine API as part of the EL validations. A goal of this path is also to reduce to voting period and follow distance.
In this investigation we realized that although this would work in theory, in practice it no allow us to reduce the follow distance from the current amount. This is because CL clients maintain a deposit-cache for block production, and this deposit-cache, today, assumes no re-orgs at the depth of the cache. If we reduced the follow distance significantly (e.g. to 1 slot), it would put the deposit-cache in the zone of re-orgs and require significant reengineering on an already error prone component of CL client.