-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Conversation
.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), |
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.
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
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.
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?
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
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