-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
[zk-token-sdk] Add range proof generation error types #34065
[zk-token-sdk] Add range proof generation error types #34065
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #34065 +/- ##
=======================================
Coverage 81.9% 81.9%
=======================================
Files 819 819
Lines 219145 219162 +17
=======================================
+ Hits 179529 179561 +32
+ Misses 39616 39601 -15 |
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.
Looks good for the most part! For backporting, we should just focus on the bits required by the runtime, ie. the new checks on the verification functions. We can probably leave off all the client-side bits
#[derive(Error, Clone, Debug, Eq, PartialEq)] | ||
pub enum RangeProofGeneratorError { | ||
#[error("maximum generator length exceeded")] | ||
MaximumGeneratorLengthExceeded, |
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.
What's the purpose of this error over RangeProofGenerationError
? They both have MaximumGeneratorLengthExceeded
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.
Yeah, both proof generation and verification uses a subroutine to generate "group generators" that could return an if the generator length is too large. I made it so that if the subroutine errors during proof generation, it returns RangeProofGenerationError::Maximum...Exceeded
(here) and if it errors during verification, it returns RangeProofVerificationError::Maximum...Exceeded
(here).
// `j` is guaranteed to be at most `u64::BITS` (a 6-bit number) and therefore, | ||
// casting is lossless and right shift can be safely unwrapped |
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.
❤️
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.
Looks great!
Problem
#33507, #33509, #33510, and #33525.
Summary of Changes
RangeProofGenerationError::VectorLengthMismatch
.RangeProofGenerationError::GeneratorLengthMismatch
.gens_capcity
for the bulletproof generators become too large (ottersec #6) #33509.RangeProofGenerationError::InnerProductLengthMismatch
when invoked on vectors of different lengths. Addresses [zk-token-sdk] Range proof scalar inner product panics if input lengths are different (ottersec #8) #33510.MAX_COMMITMENTS
. Addresses [zk-token-sdk] Potential for a malicious prover to generate proofs overMAX_COMMITEMNTS
(ottersec #7) #33525.Fixes #