Draft EIP-8237 adds partial_header_hash, a SHA-256 commitment to fields that
both layers must agree on. It lets the consensus client range-sync beacon
blocks without downloading every payload envelope at the same time. The draft
has no activation claim.
Status and wire changes
The proposal changes the ExecutionPayloadBid, BeaconBlockBody,
ExecutionPayload, and execution block-header containers. The beacon body and
execution payload carry partial_header_hash; the execution header includes it
so the block hash commits to the value. The proposal removes
execution_requests_root from ExecutionPayloadBid and does not define a
deployed Engine API method for reading the accumulator.
Sync process
The consensus block and execution payload carry the same commitment. Each layer
computes it as SHA-256 over the concatenation of the parent block hash,
prev_randao, little-endian gas_limit and timestamp, serialized
withdrawals, little-endian slot_number, and serialized execution requests.
The execution header commits to the result through the block hash; that block
hash links the value to the prior chain.
During range sync, the consensus client advances the accumulator from beacon blocks while the execution client syncs payloads on its own path. Once both reach a common point, they compare commitments. A mismatch proves that some cross-layer input diverged.
Failure and recovery
The draft requires an Engine API lookup by block hash so the consensus client can find the first divergent accumulator. It then obtains and validates the needed payload range. Deferred checking does not remove eventual execution validation.
Status and open points
The pinned draft states the need for the lookup but does not name or fully specify the Engine API method, its request, its response encoding, its errors, or its activation. This page therefore remains a reconstruction gap for that wire surface.