-
Notifications
You must be signed in to change notification settings - Fork 153
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
chore: use non-zero start and end blocks for proof generation #1336
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
f7e3c10
to
7f6f059
Compare
- [x] Update maci-contracts task - [x] Update maci-cli task - [x] Add indexed params for poll events - [x] Change deploy config example maci public key
7f6f059
to
59887e7
Compare
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.
Great stuff, thank you
@0xmad I think we missed something here, and surprised tests did not catch it. We should be counting the start block as the block where the MACI contract was deployed. This is because we add the first leaf to the state tree inside the constructor, so if we start fetching logs from either the first signup, or when the first poll is deployed, then we will have a mismatch here: https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/ts/genMaciState.ts#L362 |
nope actually what I just said is not true haha it's fine to fetch from the first signup or first poll deployment because anyways we are not emitting an event for the first leaf and replicating the same logic off chain - my bad |
Description
Additional Notes
Now you don't need to specify start and end blocks. By default start block is a first signup event block; end - last merge aq event block.
Related issue(s)
MACI rpgf feedback discussion
Confirmation