-
Notifications
You must be signed in to change notification settings - Fork 11.3k
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
[consensus] Get highest accepted rounds from RoundProber and use in ancestor selection #20336
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
3 Skipped Deployments
|
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.
The second commit using the high quorum round of the high quorum round is going to be tested but I can also move it to another PR if you want to review the changes separately.
|
||
// Probe accepted rounds in round prober. | ||
#[serde(skip_serializing_if = "is_false")] | ||
consensus_round_prober_probe_accepted_rounds: bool, |
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.
nit: probably just consensus_round_probe_accepted_rounds
would do
…d anemo is unused
9b30953
to
24de64c
Compare
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, with just a few comments.
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.
Looks good @arun-koshy ! I am approving but I would suggest for waiting for @mwtian to approve as well.
// When probe_accepted_rounds is false, should use received rounds | ||
let network_high_quorum_round = | ||
ancestor_state_manager.calculate_network_high_quorum_round(); | ||
assert_eq!(network_high_quorum_round, 300); |
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.
Why does 300 passes here? I would expect the quorum between the received quorum rounds (100, 229), (225, 229), (229, 300), (229, 300)
to be 299
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.
We are calculating the high quorum round of the high quorum rounds. So based on the values of 229, 229, 300, 300 when we iterate (ascending) the value & stake that is >= the quorum_threshold
is 300 and that is essentially the highest round seen by f+1 (2 authorities).
Description
For ancestor selection we want to ensure the highest quality ancestors are included in the proposal, therefore if an authority is excluded we should start including them once they have caught up to the network with their accepted blocks not just received as its possible for blocks to be received but suspended on many hosts which can cause performance degradation
Additionally switched to using high quorum round of the high quorum round of accepted rounds for inclusion metric.
Also bumped protocol version to 70 to include the new feature.
Test plan
How did you test the new or updated feature?
Injected Latency Test - https://metrics.sui.io/goto/Jowh4F7Hg?orgId=1
Hoarded Block Test - Pending
Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.