Repository navigation
Range-check multiplicities wherever needed for soundness #1017
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,21 @@ | ||
| #import "../meta.typ": todo | ||
| // TODO: | ||
| // - sigma protocol, layout the various steps | ||
| // - Fiat Shamir transformation into non-interactive protocol. | ||
| // | ||
|
|
||
| = Auxiliary verification steps | ||
| #todo[ | ||
| *Verify that the number of tables used by the prover in an epoch/proof is | ||
| lower than some bound.* | ||
| Without this restriction, a prover can construct an interaction multiplicity | ||
| of $-1$ by repeating a table row a large number of times. | ||
| While this strategy this would result in a large increase of | ||
| proof size, the excess can be purged during recursion. | ||
| This could e.g. be used to bypass range checks. | ||
|
|
||
| TODO: determine the right bound. The `IS_WH` chip with its multiplicity of type | ||
| `B20` induces an upper bound: it requires $approx 2^43$ rows | ||
| (or $approx 2^23$ tables) to achieve a multiplicity sum of $-1$. | ||
| This can then be used to forge an `IS_HALF` check. | ||
| ] |
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This Given that we're working with a 64-bit prime, this IS_B20 lookup allows this to be achieved with 2^44 rows, which fit in 2^24 tables of 2^20 rows each. 2^24 tables is a lot, but, given that (with the exception of one, maybe) all of these tables are identical, the prover overhead is negligible (right?). Sure, the proof would be large, but that is something you can reduce through recursion. So: the verifier will have to ensure the number of tables being used during proving are not excessively large.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, fair point, we may need some bound on total number of tables (or tables per epoch)
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. added it as a note |
Uh oh!
There was an error while loading. Please reload this page.