EIP-7685 creates a general-purpose framework for execution layer requests to the consensus layer. Each request has a type byte and opaque data. A requests_hash in block headers commits to all requests. Individual request types (like validator withdrawals) define their own data formats.
As smart contract validators proliferate, more operations need to flow from EL to CL - exits, consolidations, deposits. Instead of adding new block fields for each, this unified framework handles any request type. Adding new requests becomes a matter of defining the type, not changing block structure.
This proposal defines a general purpose framework for storing contract-triggered requests. It extends the execution header with a single field to store the request information. Requests are later on exposed to the consensus layer, which then processes each one.
The proliferation of smart contract controlled validators has caused there to be a demand for additional EL triggered behaviors. By allowing these systems to delegate administrative operations to their governing smart contracts, they can avoid intermediaries needing to step in and ensure certain operations occur. This creates a safer system for end users. By abstracting each individual request details from the EL, adding new request types is simpler and does not require an update on the execution block structure.
A requests object consists of a request_type byte prepended to an opaque byte array
request_data. The request_data contains zero or more encoded request objects.
Each request type will define its own requests object with its own request_data format.
Extend the header with a new 32 byte commitment value requests_hash.
While processing a block, multiple requests objects with different request_types will
be produced by the system, and accumulated in the block requests list.
In order to compute the commitment, an intermediate hash list is first built by hashing
all non-empty requests elements of the block requests list. Items with empty
request_data are excluded, i.e. the intermediate list skips requests items which
contain only the request_type (1 byte) and nothing else.
Within the intermediate list, requests items must be ordered by request_type ascending.
The final commitment is computed as the sha256 hash of the intermediate element hashes.
Each proposal may choose how to extend the beacon chain types to include new EL request types.
By having the bytes of request_data array from second byte on be opaque bytes, rather
than an RLP (or other encoding) list, we can support different encoding formats for the
request payload in the future such as SSZ, LEB128, or a fixed width format.
This EIP makes no strict requirement where a request may come from nor when/how a request must be validated. This is to provide future protocol designers maximum flexibility.
The authors' recommendations on source and validity of requests are:
The ordering across types is ascending by type. This is to simplify the process
of verifying that all requests which were committed to in requests_hash match.
An alternative could be to order by when the request was generated within the block. Since it's expected that many requests will be accumulated at the end of the block via system calls, this would be difficult to enforce. Therefore, ordering by type is the most straightforward ordering which ensures integrity.
Within the same type, order is not defined. This is because the data of the request is opaque as far as this EIP is concerned. Therefore, it is to be determined by each request type individually.
We exclude empty requests elements from the requests_hash commitment in order to get a
stable 'empty' hash value that is independent of the blockchain fork. For a block with no
requests data, the requests_hash is simply sha256("").
No backward compatibility issues found.
TODO
Needs discussion.
Copyright and related rights waived via CC0.