EIP-7685 : General purpose execution layer requests

This is a foundational EIP that will serve as a basis for future EIPs, enabling further standardization of request_type.

Why this EIP neeeded?

• Currently, communication between the Execution Layer (EL) and Consensus Layer (CL) is limited to block creation and attestation.

One problem is, to become a validator in the Proof-of-Stake (PoS) system, a node operator must send 32 ETH to the smart contract 0x00000000219ab540356cBB839Cbe05303d7705Fa. This transaction is processed like a regular transaction, and the CL continuously monitors the contract's state to update the validator list whenever a new entry appears. However, exiting as a validator requires a manual request sent directly to the CL.

This EIP aims to standardize requests from the Execution Layer (EL) to the Consensus Layer (CL) using smart contract events, eliminating intermediaries and manual processes.

EIP Proposal and Functioning

A request object consists of:

• request_type – Defines the type of request.
• request_data – A raw bytes array ( opaque byte data because this allows request_data to be formatted into different encoding schemes in the future, such as SSZ or LEB128. ).

The request structure is represented as:
request = request_type ++ request_data

A new 32-byte value called requests_hash is added to the block header. This represents the hash of all requests in that block.

Request Hash Calculation

1. A list of all requests is created.
2. Requests with empty request_data are excluded to prevent identical hashes that could cause collisions in block with same request_type and empty request_data.
3. The remaining request_type values are sorted in ascending order.
4. A SHA-256 hash of the ordered list is computed to generate the requests_hash.

Note: Within the same request_type, the order of requests is not defined in this EIP.

Request Generation and Validation

Source of Requests

Requests originate from transactions executed on the EL smart contract i.e. an EOA. The contract:

• Stores the request object.
• Emits an event to propagate the request.

Validation Process

• Full validation is not possible on the Execution Layer (EL).
• The EL contract performs possible validations before emitting the request event.
• Complete validation occurs on the Consensus Layer (CL) when processing the request.

Risks & Mitigations

Risks

1. There is no standardized method for handling requests within the same type, which may result in unintended behavior.
2. Since the Execution Layer (EL) lacks proper validation, an attacker could flood the Consensus Layer (CL) with invalid requests, potentially causing network congestion.

Mitigations

1. Establish a standardized approach for handling intra-type requests.
2. Implement validation on the Execution Layer (EL) to filter out faulty requests before they reach the Consensus Layer (CL).