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

[ZKS-02] Introduce Committee IDs #2374

Merged
merged 8 commits into from Mar 2, 2024
Merged

[ZKS-02] Introduce Committee IDs #2374

merged 8 commits into from Mar 2, 2024

Conversation

raychu86
Copy link
Contributor

Motivation

This PR introduces the concepts of committee IDs, which is a hash of the committee state: BHP(starting_round || members || total_stake).

This committee ID is used in batch headers to refer to a specific committee that was used to create the batch header. Other validators will then only sign batch headers/proposals if they see that the committee ID used refers to the committee that was expected. This will be an added safety guarantee when building the sudag/blocks, because validators will only certify batches if they are on the same committee state.

Audit Finding: [zksecurity 02] Dynamic Committee Feature is Not Safe

@howardwu howardwu merged commit cc68b0a into mainnet Mar 2, 2024
0 of 69 checks passed
@howardwu howardwu deleted the committee-id branch March 2, 2024 22:59
.map(|certificate| certificate.committee_id())
.ok_or(anyhow!("No certificates found for subdag round {round}"))?;
ensure!(
certificates.iter().skip(1).all(|certificate| certificate.committee_id() == expected_committee_id),
Copy link

Choose a reason for hiding this comment

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

OK so I think that makes sense to me, most of the DAG will likely be the same committee id, but any vertex that's on the same round (or previous round) as the last committed anchor will have a different committee id

Copy link
Member

Choose a reason for hiding this comment

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

I think the intent is to reject those out of date cases during the proposal phase.

Do you see any concern that an out of date vertex could get 2f+1 signatures, be included in block production here, and cause a halting concern?

Copy link

@mimoo mimoo left a comment

Choose a reason for hiding this comment

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

LGTM

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