Skip to main content
netspecsEthereum networking

4.4.7.Block access list sidecars

Stage
Future
Validity
Future proposal; not yet reconstructed.
Sources
4 pinned sources
Content
Pending reconstruction — no completeness claim is made.

Draft EIP-8146 moves the block access list out of the ePBS execution payload envelope. The signed execution payload bid commits to the exact RLP bytes:

block_access_list_hash = keccak256(rlp(block_access_list))

The consensus client treats the list as opaque bytes. The execution client owns RLP decoding, state prefetch, and execution checks. This proposal has no assigned activation claim and is not part of the pinned Gloas or Amsterdam specifications.

Wire object and gossip

MAX_BLOCK_ACCESS_LIST_SIZE is 8 MiB.

BlockAccessListSidecar:
  beacon_block_root: Root
  slot: Slot
  block_access_list: ByteList[8 MiB]

The global block_access_list_sidecar topic carries one BlockAccessListSidecar. The selected bid in the named beacon block supplies the commitment. The sidecar needs no separate signature because the builder already signed that bid.

A receiver ignores a sidecar while its beacon block is unknown and may queue it. It also ignores a duplicate for the same block root and a sidecar before the finalized slot boundary.

After it has the block, the receiver rejects the sidecar when:

  • the beacon block failed consensus validation;
  • sidecar.slot differs from the block slot; or
  • keccak256(sidecar.block_access_list) differs from the bid's block_access_list_hash.

Consensus does not RLP-decode the bytes during gossip validation. A successful hash check proves only that the sidecar matches the bid. Execution still checks the access list and payload.

Req/Resp recovery

BlockAccessListSidecarsByRange requests (start_slot, count). The server returns sidecars in slot order and sends at most MAX_REQUEST_PAYLOADS = 128 response items.

BlockAccessListSidecarsByRoot requests at most 128 beacon block roots and returns the sidecars that the server has for those roots.

Both methods use the consensus Req/Resp response codes, context bytes, and SSZ-Snappy chunk framing. A requester checks the block root, slot, size, and commitment before it stores a response.

Payload bid and envelope

The proposal adds block_access_list_hash to ExecutionPayloadBid and removes the access-list bytes from ExecutionPayload. The execution payload envelope therefore carries the payload without the list. Payload processing waits until the local node has both the access-list sidecar and the required blob data.

The three availability signals remain separate:

  • payload_present reports timely payload-envelope receipt;
  • blob_data_available reports the data-availability result; and
  • block_access_list_present reports timely sidecar receipt.

A payload-timeliness committee member sets block_access_list_present = true only after it receives and verifies the sidecar at least one second before its payload-attestation deadline. A vote does not replace local sidecar validation and cannot make an invalid execution payload valid.

Engine API delivery

engine_notifyBlockAccessListV1 sends two values to the execution client:

blockAccessList: DATA
blockHash: DATA32

The consensus client calls it as soon as the sidecar passes the commitment check. It does not wait for the payload envelope. The execution client stores the bytes by block hash and can start state prefetch or parallel post-state work.

The proposed engine_newPayloadV5 does not carry the list. If the payload arrives first, the execution client may queue it until the matching notify call arrives. engine_getPayloadV6 returns blockAccessList beside the payload so a builder can compute the bid commitment and publish the sidecar.

The pinned Amsterdam Engine API assigns the same method versions to a different contract. Its engine_newPayloadV5 requires an ExecutionPayloadV4 that contains blockAccessList, and its engine_getPayloadV6 returns that inline payload field. An EIP-8146 implementation cannot negotiate compatibility from the method number alone. The owning Engine API specification must replace or version those schemas.

Transport failure is not a payload-validity result. The consensus client must retry or fail its local delivery path without changing the sidecar commitment or interpreting the payload as valid.

Withholding and retention

A builder can withhold the sidecar. Committee members then report that it was not present, and local payload processing remains blocked until recovery succeeds. The bid prevents the builder from substituting different bytes after selection.

Servers must retain sidecars for the proposal's required serving window and may prune them later. The pinned EIP names MIN_EPOCHS_FOR_BAL_SIDECARS_REQUESTS but does not define its value. It also does not add the topic, methods, containers, or Engine call to the pinned consensus and Engine API specifications.

Completion gap

This page records the Draft EIP wire surface but does not claim deployment. The proposal needs:

  • an assigned fork or independent rollout state;
  • a defined sidecar-retention constant;
  • integrated consensus SSZ types and topic validation;
  • integrated Req/Resp method framing and serving rules; and
  • final Engine API schemas, errors, capability negotiation, and resolution of the conflicting Amsterdam method shapes.

Until those points exist in the owning specifications, implementations must not advertise these identifiers as an interoperable production protocol.