-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Send only blocks at missing heights #5206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
+61
−7
Conversation
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
c9cafde to
75a8dd9
Compare
75a8dd9 to
d0b36e3
Compare
bart-linera
approved these changes
Jan 6, 2026
Contributor
bart-linera
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
afck
reviewed
Jan 7, 2026
afck
approved these changes
Jan 7, 2026
deuszx
added a commit
that referenced
this pull request
Jan 7, 2026
When syncing chain information for blobs between validators, we were sending more data than necessary. The previous implementation would send **all blocks up to the height** where a blob was published, even when only the specific block containing that blob was needed. For sparse chains (chains with gaps in block heights), this meant sending many unnecessary blocks, wasting network bandwidth and validator processing time. Addresses #5205 (comment) ## Proposal This PR changes the blob synchronization strategy from "send all blocks up to height N" to "send only blocks at specific heights": 1. **Modified `send_chain_info_for_blobs`**: Instead of tracking the maximum height per chain, now collects a `BTreeSet` of all specific heights where blobs exist 2. **New method `send_chain_info_at_heights`**: Sends chain information only for the exact block heights specified, not all blocks leading up to those heights 3. **Updated documentation**: Clarifies that this optimization specifically benefits sparse chains ### Example Impact Previously, if blobs existed at heights [5, 10, 15] on a chain: - Sent blocks 0-5, 0-10, 0-15 (up to 30 blocks sent, with significant duplication) Now: - Sends only blocks at heights 5, 10, 15 (exactly 3 blocks) ## Test Plan - CI ## Release Plan - Nothing to do / These changes follow the usual release cycle. - Backport to `main`. ## Links - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jan 7, 2026
Backport of #5206 ## Motivation When syncing chain information for blobs between validators, we were sending more data than necessary. The previous implementation would send **all blocks up to the height** where a blob was published, even when only the specific block containing that blob was needed. For sparse chains (chains with gaps in block heights), this meant sending many unnecessary blocks, wasting network bandwidth and validator processing time. Addresses #5205 (comment) ## Proposal This PR changes the blob synchronization strategy from "send all blocks up to height N" to "send only blocks at specific heights": 1. **Modified `send_chain_info_for_blobs`**: Instead of tracking the maximum height per chain, now collects a `BTreeSet` of all specific heights where blobs exist 2. **New method `send_chain_info_at_heights`**: Sends chain information only for the exact block heights specified, not all blocks leading up to those heights 3. **Updated documentation**: Clarifies that this optimization specifically benefits sparse chains ### Example Impact Previously, if blobs existed at heights [5, 10, 15] on a chain: - Sent blocks 0-5, 0-10, 0-15 (up to 30 blocks sent, with significant duplication) Now: - Sends only blocks at heights 5, 10, 15 (exactly 3 blocks) ## Test Plan - CI ## Release Plan - Nothing to do / These changes follow the usual release cycle. ## Links - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist) Backport of #5206
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Motivation
When syncing chain information for blobs between validators, we were sending more data than necessary. The previous implementation would send all blocks up to the height where a blob was published, even when only the specific block containing that blob was needed.
For sparse chains (chains with gaps in block heights), this meant sending many unnecessary blocks, wasting network bandwidth and validator processing time.
Addresses #5205 (comment)
Proposal
This PR changes the blob synchronization strategy from "send all blocks up to height N" to "send only blocks at specific heights":
send_chain_info_for_blobs: Instead of tracking the maximum height per chain, now collects aBTreeSetof all specific heights where blobs existsend_chain_info_at_heights: Sends chain information only for the exact block heights specified, not all blocks leading up to those heightsExample Impact
Previously, if blobs existed at heights [5, 10, 15] on a chain:
Now:
Test Plan
Release Plan
main.Links