This EIP redefines the field target_pubkey from consolidations requests into a general array of 48 bytes that can be interpreted separately by the consensus layer.
The current contract to send consolidation requests is not optimized in that the exact same contract, with the exact same calldata and engine API, can be used to transmit more general messages from the EL to the CL without changes on the EL side. In particular, avoiding any cross layer coordination in the event of an CL hard fork.
As a possible application, we could use the same contract to allow any existing validator to become a builder as in EIP-7732.
| NAME | Value | Comment |
|---|---|---|
MAGIC_PREFIX |
0xEF0A11 |
3 byte prefix to all generalized consolidation requests |
No changes are expected
This EIP does not establish any changes on the consensus layer, but rather standardizes how consolidation requests are to be treated in the future. When receiving a ConsolidationRequest type object on the consensus layer, the target_pubkey field is to be treated differently. If it coincides with the BLS publick key of an existing active validator in the beacon chain, then it is to be interpreted as such. Otherwise, the 48 bytes are to be interpreted as a concatenation of the following fields
|MAGIC_PREFIX | CALL_TYPE | ARG_NUMBER | ARG1 | ARG2 | ARG3 | ARG4 | ARG5 |
Where MAGIC_PREFIX is the 3 byte constant that prefixes all generalized consolidation requests. CALL_TYPE are 4 bytes to be interpretted as a little Endian uint32 and identifies the function type. ARG_NUMBER is a 1 byte to be interpretted as a uint8 that encodes the number of arguments that are being passed to the generalized consolidation request handler. And each ARG1, ARG2, ARG3, ARG4, ARG5 are all interpretted as little Endian uint64.
For each addition of a new CALL_TYPE, the consensus layer must add a handler appropriately called from within process_consolidation_requests.
No changes needed.
The proposed reinterpretation of the existing contract enables new implementations in the consensus layer without requireing a hard fork in the execution layer.
This EIP is fully backwards compatible.
No known security impacts.
Copyright and related rights waived via CC0.