Nodes send new signed beacon blocks on the fork-specific beacon_block topic.
Req/Resp recovers missed blocks and supplies range, root, or head backfill. The
topic digest and each successful response context select the SSZ fork type.
Wire surfaces
beacon_block carries a complete SignedBeaconBlock. The request IDs are:
/eth2/beacon_chain/req/beacon_blocks_by_range/1/ # deprecated v1
/eth2/beacon_chain/req/beacon_blocks_by_root/1/ # deprecated v1
BlocksByRange requests (start_slot, count, step) in v1. step is
deprecated and must be one. BlocksByRoot requests a list of roots.
The block request bound is 1,024 items.
The method set also includes:
/eth2/beacon_chain/req/beacon_blocks_by_range/2/
/eth2/beacon_chain/req/beacon_blocks_by_root/2/
The v2 methods carry a fork-digest context on successful chunks. A v1 method
must return InvalidRequest for an Altair payload.
The block request bound is MAX_REQUEST_BLOCKS_DENEB = 128.
The method set also includes:
/eth2/beacon_chain/req/beacon_blocks_by_head/1/
BlocksByHead requests (beacon_root, count) and walks the ancestry in
descending slot order.
Fork payloads
The block type changes by validity range, while the wire name stays the same.
SignedBeaconBlock has no execution payload.
The beacon block carries the fork-specific execution payload. Each fork selects
its SignedBeaconBlock SSZ type through the response's four-byte fork context,
and the block checks its fork-specific body limits.
The block carries a signed execution-payload bid instead of the full execution payload. The block checks the bid's parent root and payload commitment limit. The payload envelope is a separate gossip and Req/Resp object.
Gossip validation
A receiver ignores a future block, a block at or before the finalized slot, a
duplicate (slot, proposer_index), or a block whose parent is not known. It
may queue an ignored block while it retrieves the parent. It rejects an out of
range proposer index, invalid proposer signature, non-increasing parent slot,
non-ancestor finalized checkpoint, unexpected proposer, or fork-specific body
operation-limit failure.
The block validates the execution-payload timestamp and the payload status of the parent. A parent with an unvalidated payload is a reject; a parent whose payload is invalid makes the child an ignore.
The block also rejects a KZG commitment count above MAX_BLOBS_PER_BLOCK.
The block rejects a KZG commitment count above MAX_BLOBS_PER_BLOCK_ELECTRA.
The node checks the bid and requires a verified parent payload when the parent block is full.
Only an accepted block enters the seen (slot, proposer_index) cache and the
forwarding path. A malformed or invalid block is a peer application fault;
missing state or parent data is not.
Serving ranges and roots
BlocksByRange returns blocks from one fork-choice chain in ascending slot
order. Empty slots produce no chunk. After the first block, each returned
parent root must match the previous block, and the peer may stop if fork choice
changes. A server returns at least the first block it has and no more than the
requested count or method bound.
BlocksByRoot returns at most one block per requested root and may omit an
unknown root. It SHOULD include a block as soon as it passes gossip validation
and SHOULD NOT serve a block that fails the beacon-chain transition. The v1
and v2 methods support the recent range defined by
compute_min_epochs_for_block_requests(); older roots may receive
ResourceUnavailable.
Fulu's BlocksByHead walks ancestors until it reaches the requested count or
the required serving range. It returns at least the head block when available.
All successful chunks carry the fork digest derived from that block's slot.
Failure handling
Response code 0 carries a block chunk. Codes 1, 2, and 3 report an
invalid request, server error, or unavailable resource. A requester verifies
the fork context, SSZ bounds, proposer signature, root, parent, and transition
for every chunk. A partial stream advances only the verified prefix. An omitted
slot is not proof that the slot was empty unless chain data establishes it.
Scope and status
This page defines block gossip, block requests, fork-selected payloads, and serving behavior. Payload-envelope behavior is a separate in-progress surface until its fork activates.