EIP-7685 Generalized execution layer requests (General purpose execution layer requests)
Final · Networking & nodes · EIP status Final · created 2024-04-14
Creates a general-purpose channel that bundles requests made by smart contracts into a single hash in the block header (requests_hash) and delivers it to the consensus layer. The block structure does not need to change when a new request type appears.
Why it is needed
Ethereum is split into an execution layer (EL) that processes transactions and a consensus layer (CL) that finalizes blocks. As validators operated by smart contracts have grown in number, demand has grown for contracts to make administrative requests such as deposits and withdrawals directly to the consensus layer, instead of going through people or intermediary services. But if the execution layer's block structure had to be reworked every time such a request type appeared, each new feature would be a major undertaking. This EIP abstracts the contents of a request into generic data that the execution layer does not interpret, so that adding just one commitment to the block header lets it carry any request type. Since no intermediary needs to get involved, the structure is safer for end users.
What changes
Today
- When a new type of request from the execution layer to the consensus layer appears, the block structure itself has to change
- Some administrative tasks of contract-operated validators require an intermediary to get involved
- A delivery method has to be designed separately for each request type
After EIP-7685
- A single requests_hash field added to the block header commits to multiple types of requests at once
- A common channel is created in which the consensus layer receives and processes requests made by contracts
- A new request type only needs a type number defined and layered on, and the block structure stays the same
Who is affected
- Client teams: Execution clients must add requests_hash to the block header and, while processing a block, collect requests and compute the commitment hash. Consensus clients process the delivered requests by type.
- Staking services and validator operators: This creates a foundation for smart contracts that manage validators to make administrative requests directly. Because it works without an intermediary, it is safer.
- Protocol designers: Execution-layer-originated requests proposed later (deposits, withdrawals, and so on) only need their type defined and placed on top of this framework.
- Ordinary users: There is no change you will notice directly, but when using contract-based staking you benefit from a structure that guarantees operations without an intermediary getting involved.
In depth
Structure of the requests object
A single requests object is the 1-byte request_type followed by the opaque byte array request_data (requests = request_type ++ request_data). request_data holds zero or more encoded request objects, and each request type defines their format itself. At the level of this EIP, the contents of request_data are not interpreted.
Block header extension and requests_hash computation
A 32-byte commitment value, requests_hash, is added to the header. During block processing, requests objects of different request_types are produced and accumulated in the block's request list. The commitment is computed in two steps. First, only elements whose request_data is non-empty (longer than 1 byte) are selected and each is hashed with sha256 to build an intermediate list. This intermediate list must be sorted in ascending order of request_type. The final commitment is the result of feeding the intermediate hashes into sha256 in order. The compute_requests_hash pseudocode in the source shows this process exactly.
Excluding empty requests and a fork-independent empty hash
Elements whose request_data is empty, that is, entries consisting only of the 1-byte request_type, are excluded from the commitment computation. This way, the requests_hash of a block with no requests is sha256("") in every fork. The design yields a stable "empty" hash value regardless of how many request types are active.
Ordering rule: ascending across types, undefined within a type
The order across types is ascending by request_type. This keeps the procedure for verifying that all requests committed to in requests_hash match simple. An alternative was to order by the time of creation within the block, but many requests are expected to accumulate at once in the system call at the end of the block, so enforcing chronological order was judged difficult. The order within the same type is not defined by this EIP. Because request_data is opaque, it is left for each request type to decide individually.
Why an opaque byte array instead of an RLP list
request_data is not fixed as a list in a specific encoding such as RLP and is left as opaque bytes. This lets future request payloads use any encoding, whether SSZ, LEB128, or a fixed-width format. The execution layer only carries the content without knowing what it is, so the choice of encoding does not affect the block structure.
Request source and validity: a recommendation, not a requirement
This EIP does not enforce where requests must come from or when and how they must be validated. The aim is to give future protocol designers maximum flexibility. The authors recommend the following. The source of a request should be transaction execution, specifically a transaction that calls a designated system contract and accumulates the request in account storage, and the request is best retrieved from storage by a system call after block processing. If rate limiting is not needed, emitting events and parsing them after block processing is also possible. Also, the validity of a request often cannot be fully verified on the execution layer, so it is called a "request" that has no authority on its own to trigger any action. The expected structure is that the system contract performs the validation possible on the execution layer and then passes the request to the consensus layer for additional validation.
Consensus layer handling and current status
The consensus layer side of the specification is left open. How a new execution layer request type is reflected in the beacon chain types is decided by each proposal. The source states that no backwards compatibility issues were found, and this EIP has Final status, so the specification is settled.