-
Notifications
You must be signed in to change notification settings - Fork 11.2k
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 2.0] fix mysticeti committee member ordering #16679
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
@@ -110,10 +110,10 @@ impl ConsensusManagerTrait for MysticetiManager { | |||
|
|||
let name: AuthorityName = self.keypair.public().into(); | |||
|
|||
let sui_committee = system_state.get_sui_committee(); |
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.
can you explain why you got the committee from the system state here instead of epoch store? What is the difference?
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.
There shouldn't be a difference (in theory & in practice) - nothing wrong reading from epoch store - but since we are getting the mysticeti committee via the system state then I've considered more straightforward to do the same for the SUI committee as well so we don't read relevant information from two different sources.
consensus/config/src/committee.rs
Outdated
|
||
// sort the authorities by their protocol (public) key in ascending order - critical to be | ||
// aligned with the SUI committee. | ||
authorities.sort_by(|a1, a2| a1.protocol_key.cmp(&a2.protocol_key)); |
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 order should be provided by the caller or SUI in this case right? That would make sure we are aligned if something changes in the future on the Sui side?
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.
Good suggestion.
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.
Agreed, I was very in between this approach and the one that I went with , but it seems it makes more sense. I'll refactor. Thanks @arun-koshy
…6679) ## Description Committee members should be ordered in the same order as the SUI committee (protocol public key order ascending). ## Test Plan CI --- If your changes are not user-facing and do not break anything, you can skip the following section. Otherwise, please briefly describe what has changed under the Release Notes section. ### Type of Change (Check all that apply) - [ ] protocol change - [ ] user-visible impact - [ ] breaking change for a client SDKs - [ ] breaking change for FNs (FN binary must upgrade) - [ ] breaking change for validators or node operators (must upgrade binaries) - [ ] breaking change for on-chain data layout - [ ] necessitate either a data wipe or data migration ### Release notes
Description
Committee members should be ordered in the same order as the SUI committee (protocol public key order ascending).
Test Plan
CI
If your changes are not user-facing and do not break anything, you can skip the following section. Otherwise, please briefly describe what has changed under the Release Notes section.
Type of Change (Check all that apply)
Release notes