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] Calculate committed sub dag digest #17765

Merged
merged 8 commits into from
May 23, 2024

Conversation

akichidis
Copy link
Contributor

Description

Currently the default digest is being used on the mysticeti committed subdag making the fork detection in checkpoints weaker as included in the ConsensusCommitInfo. This PR is calculating the committed sub dag digest and enabling it behind a feature flag. It has to be noted that the reputation scores are not included in the sub dag digest as during crash recovery we don't restore the actual scores for every committed sub dag, but only restoring the last ones and sent as part of the last committed sub dag.

Test plan

CI


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.

  • Protocol:
  • Nodes (Validators and Full nodes):
  • Indexer:
  • JSON-RPC:
  • GraphQL:
  • CLI:
  • Rust SDK:

Copy link

vercel bot commented May 15, 2024

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

Name Status Preview Comments Updated (UTC)
sui-docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback May 23, 2024 7:55pm
3 Ignored Deployments
Name Status Preview Comments Updated (UTC)
multisig-toolkit ⬜️ Ignored (Inspect) Visit Preview May 23, 2024 7:55pm
sui-kiosk ⬜️ Ignored (Inspect) Visit Preview May 23, 2024 7:55pm
sui-typescript-docs ⬜️ Ignored (Inspect) Visit Preview May 23, 2024 7:55pm

Copy link
Member

@mwtian mwtian left a comment

Choose a reason for hiding this comment

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

Great work figuring out why prologue transaction digest was not changing with forked consensus commits!

For the commit digest without reputation score, my suggestion is to use CommitRef in place of CommitIndex in CommittedSubDag, and take the digest from the ref. Then we don't need to maintain the separate digest computation, and there is one less type of digest. If we ever want to use checkpoint to certify consensus commit, this is the digest to use as well.

@akichidis
Copy link
Contributor Author

Great work figuring out why prologue transaction digest was not changing with forked consensus commits!

For the commit digest without reputation score, my suggestion is to use CommitRef in place of CommitIndex in CommittedSubDag, and take the digest from the ref. Then we don't need to maintain the separate digest computation, and there is one less type of digest. If we ever want to use checkpoint to certify consensus commit, this is the digest to use as well.

Thanks @mwtian . Yes I’ve considered using CommitRef, it was actually my first attempt , but we kind of have a cyclic dependency here. We first construct the sub dag and then the Commit - which calculates its digest . In this case we would have to go back and update the sub dag commit ref which is not ideal. Let me try again and see if there is an elegant way, but those two structs they kind of seem a bit independent and related in the same time.

@akichidis
Copy link
Contributor Author

@mwtian @arun-koshy please take another look after the latest changes

Copy link
Contributor

@arun-koshy arun-koshy left a comment

Choose a reason for hiding this comment

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

Thanks for taking care of this and the cleanups!

}

impl Display for CommittedSubDag {
fn fmt(&self, f: &mut Formatter<'_>) -> fmt::Result {
write!(
f,
"CommittedSubDag(leader={}, index={}, blocks=[",
self.leader, self.commit_index
self.leader, self.commit_ref
Copy link
Member

Choose a reason for hiding this comment

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

Update the message above to ref={}?

)?;
for (idx, block) in self.blocks.iter().enumerate() {
if idx > 0 {
write!(f, ", ")?;
}
write!(f, "{}", block.digest())?;
}
write!(f, "])")
write!(f, "], digest={})", self.commit_ref.digest)
Copy link
Member

Choose a reason for hiding this comment

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

Revert this?

) -> CommittedSubDag {
) -> (CommittedSubDag, TrustedCommit) {
// Grab latest commit state from dag state
let dag_state = self.dag_state.read();
Copy link
Member

Choose a reason for hiding this comment

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

Eventually I hope we can place where the current commit state is read from DagState, and where commits are buffered in DagState, inside the same function. It give readers of the code more confidence that commit state gets updated by the last commit. We can follow up with another PR after the score refactor. In the short term, maybe we can just add an assertion that the last commit index is current index - 1.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Eventually I hope we can place where the current commit state is read from DagState, and where commits are buffered in DagState, inside the same function. It give readers of the code more confidence that commit state gets updated by the last commit

Hhm I am not sure I understand the above comment. Could you please elaborate a bit more?

Copy link
Member

Choose a reason for hiding this comment

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

This does not block the PR. But when reading last commit from DagState, it is unintuitive which exact commit is being read unless pushing commits to DagState also happened in the same function, or there is verification that the last commit from DagState indeed has index - 1.

Copy link
Contributor

@mystenmark mystenmark left a comment

Choose a reason for hiding this comment

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

sui-core changes are good, but we should enable it in a new proto version for devnet at least.

having this disabled is actually as big a risk as having it disabled. if we enable it and it causes a fork, that just means that we caught the fork as early as possible

// When disabled the default digest is used instead. It's important to have this guarded behind
// a flag as it will lead to checkpoint forks.
#[serde(skip_serializing_if = "is_false")]
mysticeti_use_committed_subdag_digest: bool,
Copy link
Contributor

Choose a reason for hiding this comment

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

don't we want to enable this, at least for ChainId::Unknown?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oh sure, was just planning to do as separate PR

@mystenmark
Copy link
Contributor

In fact I would even go further and say I'd really like to see this enabled before we launch on mainnet

… the blocks in construction. There shouldn't be any other rule sorting them differently
…t. User the Commit digest into the CommittedSubdag. Use the Commit digest for the checkpoint commit info
@akichidis akichidis force-pushed the akichidis/consensus-mysticeti-subdag-digest branch from f516e8d to 0c4f61f Compare May 23, 2024 19:53
@akichidis akichidis merged commit 2dc5a07 into main May 23, 2024
48 checks passed
@akichidis akichidis deleted the akichidis/consensus-mysticeti-subdag-digest branch May 23, 2024 22:49
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.

None yet

4 participants