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 v1BlocksByRange requests (start_slot, count, step) in v1. step is
deprecated and must be one. BlocksByRoot requests a list of roots.
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.
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 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.