-
Notifications
You must be signed in to change notification settings - Fork 22
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 monomial form when computing the quotient #98
base: master
Are you sure you want to change the base?
Conversation
@@ -62,8 +63,11 @@ func (c *Context) ComputeBlobKZGProof(blob *Blob, blobCommitment KZGCommitment, | |||
// 2. Compute Fiat-Shamir challenge | |||
evaluationChallenge := computeChallenge(blob, blobCommitment) | |||
|
|||
domain.BitReverse(polynomial) | |||
polyCoeff := c.domain.IfftFr(polynomial) |
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.
This additional IFFT costs 1ms which is not that much compared to the MSM
// 2. Create opening proof | ||
openingProof, err := kzg.Open(c.domain, polynomial, inputPoint, c.commitKeyLagrange, numGoRoutines) |
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.
We should be able to get rid of commitKeyLagrange entirely, if we can stomach the 1ms ifft
|
||
outputPoint := poly.PolyEval(polyCoeff, evaluationPoint) | ||
|
||
quotient := poly.DividePolyByXminusA(polyCoeff, evaluationPoint) | ||
|
||
comm, err := ck.Commit(quotient, 0) | ||
if err != nil { | ||
return OpeningProof{}, nil | ||
} | ||
|
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 have not deleted the code, we no longer need but this is comparatively simpler than what we were doing before
Need to take benchmarks to compute what the difference is before moving forward |
Currently on master I get:
On this branch, I get:
So its about 10% slower though the allocations have grown |
I created another branch that merges the iterative IFFT code into these changes, see #99 -- we get:
|
So that branch has essentially the same performance, with the newer branch having a slighter better memory profile, but nothing significant |
Note to self: local branch is named kw/simple-kzg-code |
No description provided.