Go to Home
Web3 security pattern.
Pectra Competition
Web3 security pattern.
EIP-6110
EIP-6110 moves validator deposits to Execution Layer blocks, removing Consensus Layer voting to improve security and processing speed.EIP-6110 shifts validator deposits to the Execution Layer, simplifying client design, reducing delays, and enhancing security.

EIP-6110

Table of Contents

Heading 2
Heading 3
Heading 4

What is this EIP about?

EIP-6110 proposes integrating validator deposits directly into the Ethereum Execution Layer blocks. It eliminates the need for deposit voting by the Consensus Layer, shifting the responsibility for deposit inclusion and validation to the Execution Layer. The aim is to enhance security, simplify client software design, and reduce delays in processing validator deposits.

Why is this EIP needed?

Validator deposits are essential to Ethereum's Proof-of-Stake consensus. The current mechanism relies on a complex and brittle deposit voting process in the Consensus Layer, which introduces several limitations:

  • Security Risks: Proposer voting can potentially allow adversarial behavior to disrupt deposits.
  • Delays: Processing deposits through the Consensus Layer can take up to 12 hours, causing inefficiencies.
  • Complexity: Client software must handle JSON-RPC API inconsistencies and maintain deposit snapshots, increasing the engineering overhead.

This EIP addresses these challenges by offering a more streamlined and secure mechanism for deposit processing.‍

What does this EIP propose, and how does it function?

Key Proposals:

  • Append validator deposit operations to the Execution Layer block structure.
  • Parse deposits directly from DEPOSIT_CONTRACT_ADDRESS log events in the Execution Layer.
  • Eliminate the Consensus Layer’s reliance on Eth1Data polling for deposits.

How It Works:

  1. Deposit Processing:
    • Validator deposits are parsed from DepositContract.DepositEvent logs in the Execution Layer.
    • These deposits include key data fields like pubkey, withdrawal_credentials, amount, signature, and index.
  2. Execution Layer Integration:
    • Each deposit operation is appended to the block’s EIP-7685 requests list.
    • Deposit inclusion and validation are performed in the Execution Layer, ensuring order and correctness.
  3. Consensus Layer Adjustments:
    • The Consensus Layer introduces a new deposit_requests field in its state and updates block validity conditions.
    • The Eth1Data polling mechanism is deprecated, simplifying client software.

What are the security implications of this EIP?

Potential Risks:

  • Data Complexity: Deposit data growth is minimal, but the system must handle spikes in deposit submissions, as seen in June 2023.
  • Denial-of-Service (DoS) Vectors: While deposits consume gas, the execution layer's gas pricing prevents viable large-scale DoS attacks.
  • Optimistic Sync Vulnerability: Nodes syncing optimistically may be susceptible to adversarial chains, but this risk aligns with existing security assumptions.

Mitigation Measures:

  • Gas constraints limit the number of deposits per block, ensuring manageable computational overhead.
  • Signature verification costs are capped at 1,271 operations per block, minimizing performance impact.
  • The proposed mechanism aligns with Ethereum’s current security model, maintaining consistency with established defenses.

This proposal offers a robust solution to improve the efficiency and security of validator deposits, streamlining Ethereum’s Proof-of-Stake operations.