Repository navigation
perf(verifier): batch reduced setup rows sharing one functional - #271
Open
Acentelles wants to merge 3 commits into
Open
Acentelles wants to merge 3 commits into
Acentelles wants to merge 3 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
When every reduced setup row in a scan job shares one base-ring functional (one functional class with ratio 1), the verifier now collects the rows and their scalars and evaluates them with one
weighted_dot_base_rowscall, instead of onedot_baseand oneadd_productper row. This uses the same shared-functional kernel the lifted scans already use.Mixed ring dimensions or distinct functionals keep the existing per-class path. The value computed is the same field sum. There is no change to the proof, the transcript or the setup.
Changes
akita-verifier,setup_contribution/scan/reduced.rs: the shared-functional fast path, with checked allocations (InvalidSetupon failure).setup_contribution/tests/reduced_shared.rscompares the batched path against the per-row path, including the mixed and distinct-functional fallbacks.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 pointed at this branch, then at its base
--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.