Repository navigation
refactor: consolidate Chonk VK generation and clarify polynomial consumption - #25653
Merged
Merged
Conversation
Remove Chonk prove --write_vk, whose retained-key export diverged from standalone bytecode-derived VK generation. Keep write_vk as the derivation path and verify pinned proofs against independently derived hiding keys. Remove the unused bulk proving API and its parsed-step container, and avoid copying the constraint system during VK derivation.
Keep the polynomial move, document consumption on both public accumulation methods, and assert that the first unshifted entity is absent from the to-be-shifted batch. Correct the batching comment: the batches overlap, but only the first entity is consumed by each in-place batch.
iakovenkos
added
port-to-v6
and removed
ci-barretenberg
fcarreiro
enabled auto-merge (squash)
October 14, 2026 22:51
fcarreiro
approved these changes
Oct 14, 2026
AztecBot
pushed a commit
that referenced
this pull request
Oct 14, 2026
…umption (#25653) The [memory PR #25638](#25638) changed `prove --write_vk` to reuse the input VK instead of deriving it from the circuit. We remove this redundant option and keep `write_vk` as the single way to generate Chonk VKs. Re the question on #25638: it is moot. Every Chonk verifier uses the hiding-kernel VK from the protocol VK tree. The node takes it from the protocol circuit artifacts, and the rollup checks the VK against the tree at the expected leaf index. Those VKs come from `bb write_vk --scheme chonk`, which derives them from bytecode. A VK written by `prove --write_vk` was never used anywhere, so we remove the option rather than fix it. The pinned-flow test now derives the hiding-kernel VK from bytecode, checks it against the input VK, and verifies the proof with the derived one. We also remove the unused `prove_and_verify` method, its `PrivateExecutionSteps` helper, and an unnecessary constraint-system copy during VK generation. For HyperNova, we keep the move and document that both accumulation methods consume the instance’s polynomials. The batches overlap, so an assertion checks that the first unshifted polynomial—the one consumed—is absent from the second batch. This makes the contract explicit and guards the layout assumption; no peak-memory improvement was measured for this move. Validation: 16 HyperNova tests and all 11 pinned flows passed; CLI and test targets rebuilt. (cherry picked from commit d1db3d1)
IlyasRidhuan
pushed a commit
that referenced
this pull request
Oct 15, 2026
Rolling port of `port-to-v6`-labelled PRs from `next` onto `v6`. Each source PR lands as its cherry-pick commit; conflicted picks are a raw pick (conflict markers as git produced them) followed by a `fix(port):` commit with the resolution. ## Ported - [x] [#25631](#25631) feat(kvdb): expose read-only lmdb transactions — **conflicted**. The fix commit maps the change onto v6's pre-split layout: the native code goes into `barretenberg/cpp/src/barretenberg/nodejs_module/lmdb_store` + `lmdblib` (v6's `SERIALIZATION_FIELDS`, `bb::nodejs` namespace, `barretenberg/` includes, unqualified `format`), the Makefile keeps v6's targets, and `native-packages/kvdb/*` is dropped (no kvdb package on v6). It also decides one behavioural point: barretenberg's msgpack-c fork rejects a missing map key where the upstream msgpack-c used by kvdb on `next` treats it as unset, and v6 clients never send `txId`. Requests carrying an optional `txId` therefore get a `convert` adaptor that reads a missing `txId` as nil. Without it every node fails to start with `Missing field txId`. The source PR's `read_tx.test.mjs` suite passes 8/8 against the v6 addon locally (6/8 fail without the adaptor). The lmdblib gtests pass. - [x] [#25638](#25638) chore: chonk memory improvements — clean pick. - [x] [#25653](#25653) refactor: consolidate Chonk VK generation and clarify polynomial consumption — clean pick. --- *Created by [claudebox](https://claudebox.work/v2/sessions/c367595c72de79d5/jobs/1) · group: `slackbot` · [Slack thread](https://aztecprotocol.slack.com/archives/C0AGN2WT3CP/p1791993763598479?thread_ts=1791993763.598479&cid=C0AGN2WT3CP)* --------- Co-authored-by: Santiago Palladino <santiago@aztec-labs.com> Co-authored-by: sergei iakovenko <105737703+iakovenkos@users.noreply.github.com> Co-authored-by: Oleh Misarosh <olehmisar@gmail.com> Co-authored-by: Facundo <facundo@aztec-labs.com>
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
2 participants
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.
The memory PR #25638 changed
prove --write_vkto reuse the input VK instead of deriving it from the circuit. We remove this redundant option and keepwrite_vkas the single way to generate Chonk VKs.Re the question on #25638: it is moot. Every Chonk verifier uses the hiding-kernel VK from the protocol VK tree. The node takes it from the protocol circuit artifacts, and the rollup checks the VK against the tree at the expected leaf index. Those VKs come from
bb write_vk --scheme chonk, which derives them from bytecode. A VK written byprove --write_vkwas never used anywhere, so we remove the option rather than fix it. The pinned-flow test now derives the hiding-kernel VK from bytecode, checks it against the input VK, and verifies the proof with the derived one.We also remove the unused
prove_and_verifymethod, itsPrivateExecutionStepshelper, and an unnecessary constraint-system copy during VK generation.For HyperNova, we keep the move and document that both accumulation methods consume the instance’s polynomials. The batches overlap, so an assertion checks that the first unshifted polynomial—the one consumed—is absent from the second batch. This makes the contract explicit and guards the layout assumption; no peak-memory improvement was measured for this move.
Validation: 16 HyperNova tests and all 11 pinned flows passed; CLI and test targets rebuilt.