In-Protocol Deposits breakout

• In-Protocol Deposits breakout
  • Next steps
  • Agenda/Goals
  • Specification
  • Design overview
    • Transition
  • Motivation

Next steps

• Explore design space without pending_queue in the beacon state
  • Transition: process block.body.deposits and block.body.execution_payload.deposits in parallel instead of queuing the latter and waiting for the former to fill the gap (proposed by Peter Davies)
  • WS period: confirm that a significant increase of a number of top ups per epoch is fine
  • (pubkey, index) cache: confirm that CL client devs are fine with taking this engineering complexity in favour of complexity related to pending_queue
    • data complexity of two queues is higher than of one because of top ups, each top up would take a separate record in the pending_queue while all top ups for the same validator are accumulated in a single record in the validator registry
  • sig verification complexity: limited by a size of EL block, worth re-evaluating
• Evaluate a number of deposits per 30M gas block that advanced attacker can induce by making multiple deposits in one transaction (reduced cost by removing base tx fee and re-using warmed up state slot reads/writes) – Peter Davies to do the evaluation
  • one deposit per transaction consumes 50-60k gas and results in 500-600 deposits per 30M gas block at max; this number can be doubled with the tricks
• It might be better to couple this change with introduction of re-usable validator indexes as the latter would break existing way of caching validator indexes – think on that and discuss

Agenda/Goals

• Go over proposed design
• Address questions and conserns
• Discuss Transition and pending_deposits queue in the beacon state

Specification

• Execution Layer EIP-6110
• Conensus Layer #3177
• Engine API eip6110.md

Design overview

EL looks for transaction receipts supplied by the deposit contract to get a list of deposits made in a given block. The list is included into execution payload and then verified by EL clients.

CL processes a list of deposit operations supplied by EL in a way similar to existing process_deposit functionality except for merkle proof verification. The verification is no longer required as EL takes this responsibility.

Note: Number of deposits per block is limited by EL block's gas limit. See analysis of potential DoS vectors in security considerations of EIP-6110 and description to PR#3177.

Transition

Once the fork is activated EL starts to surface deposits on chain and checking their validity with respect to transaction execution. Transition period doesn't affect EL anyhow.

The reason for transition period to exist is Eth1Data poll lagging behind the head by several hours. Thus, there will be a gap between deposits processed with existing machinery and the first deposit included on chain upon the fork activation.

The proposed solution for filling the gap is pending_deposits queue which keeps on chain deposits in the beacon state unprocessed until the old deposits flow (based on Eth1Data poll) starts overlapping with the beginning of the queue.

Once this happens, CL may start to process on chain deposits instantly with no fallback to pending_deposits queue. At this point Eth1Data poll has no longer an impact on deposit processing and can be removed by CL clients without coordination. The queue can be removed in the next hard fork.

Reasons to keep using the queue outside of transition window:

• Limits a number of validator balance top ups per epoch which reduces the size of WS period on some edge cases. Detailed analysis is in
• Allows to finalize the order of deposits before creating validator records. CL don't have to re-compute (pubkey, index) cache entries on chain re-orgs.
• Detailed analysis of the above points is in the description to PR#3177.

Motivation

• Significant increase of deposits security by supplanting proposer voting. With the proposed in-protocol mechanism, an honest online node can’t be convinced to process fake deposits even when more than 2/3 portion of stake is adversarial.
• Decrease of delay between submitting deposit transaction on Execution Layer and its processing on Consensus Layer. That is, ~13 minutes with in-protocol deposit processing compared to ~12 hours with the existing mechanism.
• Eliminate beacon block proposal dependency on JSON-RPC API data polling that suffers from failures caused by inconsistencies between JSON-RPC API implementations and dependency of API calls processing on the inner state (e.g. syncing) of client software.
• Eliminate requirement to maintain and distribute deposit contract snapshots (EIP-4881).
• Reduction of design and engineering complexity of Consensus Layer client software on a component that has proven to be brittle.

For more details and analysis see rationale and security considerations of EIP-6110 and description to consensus-specs#3177.