Skip to content
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

Merged
merged 4 commits into from
Mar 18, 2024

Conversation

akichidis
Copy link
Contributor

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

Copy link

vercel bot commented Mar 15, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
explorer ✅ Ready (Inspect) Visit Preview 💬 Add feedback Mar 18, 2024 10:51am
multisig-toolkit ✅ Ready (Inspect) Visit Preview 💬 Add feedback Mar 18, 2024 10:51am
mysten-ui ✅ Ready (Inspect) Visit Preview 💬 Add feedback Mar 18, 2024 10:51am
sui-core ✅ Ready (Inspect) Visit Preview 💬 Add feedback Mar 18, 2024 10:51am
sui-kiosk ✅ Ready (Inspect) Visit Preview 💬 Add feedback Mar 18, 2024 10:51am
sui-typescript-docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Mar 18, 2024 10:51am

@@ -110,10 +110,10 @@ impl ConsensusManagerTrait for MysticetiManager {

let name: AuthorityName = self.keypair.public().into();

let sui_committee = system_state.get_sui_committee();
Copy link
Contributor

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?

Copy link
Contributor Author

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.


// 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));
Copy link
Contributor

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion.

Copy link
Contributor Author

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

@akichidis akichidis merged commit 67b4c83 into main Mar 18, 2024
41 checks passed
@akichidis akichidis deleted the akichidis/akichidis-19 branch March 18, 2024 11:14
tx-tomcat pushed a commit to tx-tomcat/sui-network that referenced this pull request May 30, 2024
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants