EIP-7685

What is this EIP about?

EIP-7685 introduces a general-purpose framework for handling contract-triggered requests between Ethereum’s Execution Layer (EL) and Consensus Layer (CL). It extends the execution block header to include a requests_hash field, enabling requests to be processed by the CL.

This proposal aims to create a standardized system for smart contract-controlled validators to delegate administrative operations securely and flexibly, reducing the need for intermediaries.

Why is this EIP needed?

‍Smart contract-controlled validators increasingly require specific administrative actions (e.g., validator management) triggered by on-chain events. Currently, these operations often depend on external intermediaries, which can introduce inefficiencies, risks, and complexity.By allowing smart contracts to directly send requests to the CL, this EIP streamlines such operations, improving safety and scalability for end-users.This EIP focuses on cross-layer communication and governance automation, addressing limitations in Ethereum's ability to handle EL-triggered CL requests efficiently.What does this EIP propose, and how does it function?

• Proposal details:
  • Requests format:
    • Requests consist of a request_type byte followed by an opaque request_data byte array. This format is flexible and future-proof, supporting different encodings (e.g., SSZ, RLP) for diverse use cases.

Example request:

requests = request_type ++ request_data

• Block header extension:
  • Adds a new requests_hash field to the execution block header, computed as the sha256 hash of valid requests in the block.

Example computation:

def compute_requests_hash(block_requests: Sequence[bytes]):
    m = sha256()
    for r in block_requests:
        if len(r) > 1:  # Exclude empty requests
            m.update(sha256(r).digest())
    return m.digest()

• Consensus layer integration:
  • Requests are exposed to the CL for validation and processing. The proposal allows flexibility for future implementations to define specific behaviors for each request type.
• Ordering and filtering:
  • Requests are ordered by request_type to simplify verification.
  • Empty requests are excluded to stabilize the requests_hash, ensuring consistency across forks.

What are the security implications of this EIP?

• Potential risks:
  • Validation challenges: Since requests are only partially validated at the EL, malicious or invalid requests could be passed to the CL, potentially straining the system.
  • Request ordering manipulation: Poorly defined intra-type ordering could lead to inconsistencies if different request types introduce conflicts.
  • Compatibility risks: Smart contracts emitting invalid requests might require updates.
• Mitigations:
  • Layered validation: Requests are validated at both the EL (for basic checks) and CL (for additional validation), reducing the risk of invalid actions being executed.
  • Ordering consistency: Requests are sorted by type, simplifying verification and ensuring integrity.
  • Protocol flexibility: The use of opaque byte arrays and type-specific definitions ensures future scalability without frequent updates to the EL block structure.

This EIP enhances Ethereum's governance and scalability by enabling secure, efficient cross-layer operations, setting the stage for broader adoption of smart contract-controlled validators.

‍