feat: biggroup handles points at infinity #6391
Merged
Conversation
This file contains 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
…inity, and have +/- methods that correctly handle points at infinity
codygunton
force-pushed
the
zw/biggroup-infinity
branch
from
9f6b4ef to
175a9b2
Compare
codygunton
changed the title
codygunton
force-pushed
the
zw/biggroup-infinity
branch
from
6245aa9 to
08edd99
Compare
Changes to circuit sizes
🧾 Summary (100% most significant diffs)
Full diff report 👇
|
Benchmark resultsMetrics with a significant change:
Detailed resultsAll benchmarks are run on txs on the This benchmark source data is available in JSON format on S3 here. Proof generationEach column represents the number of threads used in proof generation.
L2 block published to L1Each column represents the number of txs on an L2 block published to L1.
L2 chain processingEach column represents the number of blocks on the L2 chain where each block has 16 txs.
Circuits statsStats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.
Stats on running time collected for app circuits
Tree insertion statsThe duration to insert a fixed batch of leaves into each tree type.
MiscellaneousTransaction sizes based on how many contract classes are registered in the tx.
Transaction size based on fee payment method | Metric | | |
ludamad
pushed a commit
that referenced
this pull request
May 21, 2024
This was referenced May 24, 2024
codygunton
approved these changes
May 25, 2024
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.
This PR introdues a stdlib boolean flag into biggroup to track whether an element is the point at infinity. This is uses to handle edge cases around the point at infinity in biggroup operations. We now correctly handle points at infinity under addition and subtraction. The
batch_mulmethod correctly handles points at infinity (at least in three tested cases) under the Mega arithmetization (though this is not all that meaningful without a full Goblin proof!). Thewnaf_batch_mulmethod correctly handles points at infinity (at least in three tested cases) under the Ultra arithmetization, which is the only arithmetization for which it's implemented.The PR adds constraints that increase the cost of biggroup operations. This cases the UltraPlonk recursive verifier circuit size to grow, crossing a power-of-two boundary. This means that we can no longer execute two UltraPlonk recursive verifications in WASM due to an out-of-memory error during provcing key creation. (cf the$2^{19}$ . In response to these two issues, we have disabled tests. We did this in consulation with @TomAFrench and @vezenovm. Related issues: noir-lang/noir#5106, #6672.
double_verify_prooftests; note thatdouble_verify_nested_proofwas already not available in WASM). Moreover, the PR exposed that noir.js is not capable of executing proof construction for a circuit of sizeChanges to benchmarks
Note that this PR disrupted the ClientIVC benchmarks by shrinking the mock circuits considerably. This will be fixed in a follow-on.
MockKernelTest.PinFoldingKernelSizes before
MockKernelTest.PinFoldingKernelSizes after
MegaMockCircuitsPinning Before
MegaMockCircuitsPinning After
Client IVC Before
ClientIVC After