Add beacon_block_headers_by_root req/resp on Gloas#5179
Open
dapplion wants to merge 2 commits into
Open
Conversation
dapplion
force-pushed
the
headers-by-root-gloas
branch
from
71d8922 to
3bdfe04
Compare
dapplion
force-pushed
the
headers-by-root-gloas
branch
from
3bdfe04 to
2a17293
Compare
dapplion
changed the title
headers_by_root req/resp on Gloasbeacon_block_headers_by_root req/resp on Gloas
|
this is great, will implement |
jtraglia
pushed a commit
that referenced
this pull request
May 11, 2026
Adds a new req/resp route `beacon_blocks_by_head` to Fulu. The request is `(beacon_root, count)`; the responder walks the parent chain of `beacon_root` (inclusive) and emits up to `count` blocks in descending slot order, one per `response_chunk` in the same shape as `BeaconBlocksByRange v2`. Capped at `MAX_REQUEST_BLOCKS_DENEB` (= 128). Same motivation as #5179 (header-tree forward sync, sigp/lighthouse#7678) — backfill a chain segment from a known head. The trade-off vs. #5179: - This route streams full blocks (~average ~150 KiB/slot post-Deneb), so it's heavier on the wire. - It reuses the existing blocks-by-root store. **No new DB index required** on the server side. #5179 is the bandwidth-optimal version (only headers, single chunk, 2,048 per request) but requires clients to maintain a new headers-by-root DB column. This PR is the lower-cost-to-ship alternative for clients that don't want to add storage. The two routes are not mutually exclusive — a client can serve either or both.
Contributor
Isn't the bandwidth benefit still there, the response side is just paying more in disk io? |
Member
|
Hey @dapplion, what's the status on this PR? Is this still relevant? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a new ReqResp route
beacon_block_headers_by_rootto support "tree sync", a forward-sync redesign described in sigp/lighthouse#7678. First backfill an in-memory header tree from peer status / unknown roots until it ties into a known block or conflicts with finality, then forward-sync with full knowledge of which roots belong at which slot.The request is
(beacon_root, count, min_slot). The responder walks the parent chain ofbeacon_root(inclusive), in descending slot order, and stops when any of:countheaders returned, next ancestor hasslot < min_slot, or next ancestor falls outside the standard block-serving range.The whole list is sent as a single SSZ list in one
response_chunkrather than one chunk per element — headers are 112 B each, so bundling them avoids per-chunk framing overhead.MAX_REQUEST_BLOCK_HEADERS = 2**11(= 2,048) caps a response at ~230 KiB and covers 64 epochs of backfill per round-trip.Implementation cost
Serving this route efficiently requires clients to maintain a new DB index:
BeaconBlockHeaderkeyed by block root. Without it, the responder must load fullSignedBeaconBlocks and extract headers.Trade-off: a new index over the block-serving range, in exchange for fast header sync at very low bandwidth and few round-trips per request — that's the core value-add.
A sibling route
beacon_blocks_by_head(#5181) avoids this index by reusing the existing blocks-by-root store, at the cost of full-block bandwidth.