-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
adds rollout path for chained Merkle shreds #35076
adds rollout path for chained Merkle shreds #35076
Conversation
fd49d2a
to
bf98394
Compare
00dcb50
to
8a01eef
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #35076 +/- ##
=======================================
Coverage 81.6% 81.6%
=======================================
Files 832 831 -1
Lines 224856 224893 +37
=======================================
+ Hits 183538 183631 +93
+ Misses 41318 41262 -56 |
8a01eef
to
b06ec12
Compare
fn should_chain_merkle_shreds(_slot: Slot, _cluster_type: ClusterType) -> bool { | ||
false | ||
} |
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.
This function will be used to incrementally roll out chained Merkle shreds starting with a small % of slots on testnet etc.
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.
Is the idea that receiving nodes won't know if chained merkle shreds are present for this slot until they deserialize shreds and look?
Here's my strawman of the rollout plan - please correct:
Plumbing for generating and including chained merkle shredsStart including for "non-standard" broadcast methods- This PR to add single function to decide whether to chain merkle shreds for "standard" broadcast method based on slot/cluster type
- Logic to include for some small percentage of slots on testnet
- Receivers validating chained Merkle shreds when present
- Expand rollout to more slots/clusters
- Remove conditional logic
- Receivers unconditionally verify Merkle shreds (must be present)
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.
Yes, that is pretty much it.
We did a similar thing for the Merkle shreds rollout:
https://github.com/solana-labs/solana/pulls?q=is%3Apr+author%3Abehzadnouri+rolls+out+Merkle+is%3Aclosed+
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 but left a couple of questions
The commit adds should_chain_merkle_shreds to incrementally roll out chained Merkle shreds to clusters.
b06ec12
to
e9975a1
Compare
Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis. |
The commit adds should_chain_merkle_shreds to incrementally roll out chained Merkle shreds to clusters. (cherry picked from commit 0cfb06f)
Problem
Roll out chained Merkle shreds
Summary of Changes
The commit adds
should_chain_merkle_shreds
to incrementally roll out chained Merkle shreds to clusters.