Repository navigation
perf(challenges): use signed accumulation for sparse evaluation - #268
Open
Acentelles wants to merge 2 commits into
Open
Acentelles wants to merge 2 commits into
Acentelles wants to merge 2 commits into
Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
SparseChallengeevaluation at a point now accumulates coefficients of magnitude one or two by signed addition in the extension field. Other coefficients are still embedded into the base field and multiplied in with a mixed base-field operation, and the ordinary base-field case isE = F.Magnitude two is handled by repeating the term, which preserves the polynomial over every field. Inputs are validated as before: mismatched term counts, zero coefficients and out-of-range positions return an error.
There is no change to the proof, the transcript or the setup; only the verifier's arithmetic changes.
Changes
akita-challenges,challenge.rs: a signed-accumulation evaluator and its validation.Measured effect (stacked; standalone not measured)
Standalone rows on this base are not measured. The figures below are total trace rows (real plus virtual) of Jolt's recursion example, whose guest verifies one Akita proof of an inner Jolt proof. Each was measured without and with this change, on two recursion integration builds that also carry the factored compression-weight evaluation and the terminal quotient certificate.
Build 1 was measured in two runs, on an AMD Ryzen 9 7950X host and an AMD EPYC 7B13 host; rows and guest ELFs are identical across the runs.
Build 2 adds further verifier changes and was measured in one run, on an AMD EPYC 7B13 host:
On build 2, the honest proof is accepted and a tampered proof is rejected, and the proof and tampered-proof bytes are identical with and without the change.
Reproduce
Run the a16z/jolt#1911 recursion example ($2^{12}$ and $2^{20}$ with the Akita dependency on this branch, then on
--features akita,field-inline,ntt-inline,trace --embed) at inneree03aa30, and compare the total rows.Base
This PR targets
markos/recursion-integration(ee03aa30), the recursion integration branch where this change was measured. It merges intomainwith the rest of that branch.Current integration figures (whole stack, not this PR alone)
These are figures for the whole recursion integration stack: Jolt's recursion example with this PR's Akita changes together with the other changes on this branch, the Jolt-side verifier changes and the guest build settings. They are not a measurement of this PR alone.
The Akita proof is 72,672 bytes at$2^{12}$ and 75,817 bytes at $2^{20}$ in both stacks, unchanged.
Receipt hashes (whole / closing):
02a12d07/72c63ef2;d23b9ab4/16ca914c;ea4ddf32/f069836d.