feat: merge-train/barretenberg#23137
Merged
Merged
Conversation
Two cleanups in trace-to-polynomials land. Originally motivated by small perf wins but is attractive for the code simplification: **1. Simpler permutation polynomial construction.** The old code built a large intermediate table and walked it to produce the sigma/id polynomials. The new code writes those polynomials directly in three steps: identity init, cycle linkages, public-input update. **2. Each block has only the non-gate selectors plus (at most) one gate selector.** Previously every block declared all eight or nine possible gate selectors using the hacky `ZeroSelector`. `ZeroSelector` class is gone plus lots of simplification in the block classes.
Collaborator
Author
|
🤖 Auto-merge enabled after 4 hours of inactivity. This PR will be merged automatically once all checks pass. |
Adds safety mechanisms to protect against two currently unreachable cycle_group footguns: - In-circuit rejection of point-at-infinity operands in `cycle_group::_unconditional_add_or_subtract`: the `ecc_add_gate` is degenerate at (0, 0) and admits forged outputs. Replaces builder-only BB_ASSERT(!is_constant_point_at_infinity) with in-circuit is_point_at_infinity().assert_equal(false). No additional gates and no VK change for existing circuits. Unreachable from noir. - Clarify offset-generator collision-avoidance contract in MSM helpers: adds a BB_ASSERT(base_point != offset_generator) in `straus_lookup_table` to catch the (highly improbably) honest-dev mistake of these two coinciding (and makes it clear that they must not).
Integrates init/inner kernels that process up to 3 apps into the PXE --------- Co-authored-by: federicobarbacovi <171914500+federicobarbacovi@users.noreply.github.com> Co-authored-by: AztecBot <tech@aztec-labs.com>
Collaborator
Author
|
🤖 Auto-merge enabled after 4 hours of inactivity. This PR will be merged automatically once all checks pass. |
Collaborator
Author
|
🤖 Auto-merge enabled after 4 hours of inactivity. This PR will be merged automatically once all checks pass. |
## Summary - `acir_format::MemOp.index` and `MemOp.value` become plain `uint32_t` witness indices instead of `WitnessOrConstant<bb::fr>`. - The deserializer in `acir_to_constraint_buf.cpp` now asserts the Noir-side `Acir::Expression` is a single unscaled witness, matching what Noir actually emits (see `MemOp::read_at_mem_index` / `write_to_mem_index` in `acvm-repo/acir/src/circuit/opcodes/memory_operation.rs` — both take `Witness`, not `Expression`). - Drops the `add_constant_ops` helper and `perform_constant_ops` parameterization from ROM/RAM/CallData tests, since the path being exercised never came up in production. ## Test plan - [ ] `ninja dsl_tests` passes (note: my local build hits a pre-existing gtest cxx11-ABI link error; the affected `.cpp.o` objects compile cleanly) - [ ] CI green
After the multi app PR landed, there were conflicts in the private kernel execution prover. This PR resolves them. The conflicts came from this PR: 66d7308
Merge next into merge-train/barretenberg to resolve conflicts --------- Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar> Co-authored-by: AztecBot <tech@aztecprotocol.com> Co-authored-by: Maxim Vezenov <mvezenov@gmail.com> Co-authored-by: Aztec Bot <49558828+AztecBot@users.noreply.github.com> Co-authored-by: AztecBot <tech@aztec-labs.com> Co-authored-by: Alex Gherghisan <alexghr@users.noreply.github.com> Co-authored-by: charlielye <5764343+charlielye@users.noreply.github.com> Co-authored-by: Tom French <15848336+TomAFrench@users.noreply.github.com>
Addressing the follow-on comments [here](https://github.com/Cyfrin/audit-2026-04-aztec-polynomial/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22Report%20Status%3A%20Open%22).
This was referenced May 13, 2026
federicobarbacovi
added a commit
that referenced
this pull request
May 14, 2026
…g build (#23229) ## Why The nightly Barretenberg debug build (`Nightly Debug Build` workflow, run [25781836067](https://github.com/AztecProtocol/aztec-packages/actions/runs/25781836067)) on `next` @ `2b1d9cf22d` failed in `circuit_checker_tests`: ``` [ RUN ] UltraCircuitBuilderArithmetic.QArith3Gate C++ exception with description "Assertion failed: (block_selectors[idx].size() == nominal_size) Actual : 1 Expected: 2" thrown in the test body. [ FAILED ] UltraCircuitBuilderArithmetic.QArith3Gate ``` CI log: http://ci.aztec-labs.com/e0ba10c734d2dd7b The assertion fires inside `UltraCircuitBuilder_::check_selector_length_consistency` (`stdlib_circuit_builders/ultra_circuit_builder.hpp`), which is gated by `#if NDEBUG ... #else` and so runs only in debug builds — that's why no other CI mode caught it. `QArith3Gate` builds two arithmetic gates manually by pushing each selector individually. Every in-tree gate constructor (`create_arithmetic_gate`, `fix_witness`, `create_add_gate`, etc.) follows `q_4().emplace_back(...)` with `q_5().emplace_back(0)`; this test was the only manual-construction site that omitted the `q_5` push. Pre-merge-train, the consistency check used a per-flavour curated `get_selectors()` for `UltraTraceArithmeticBlock` that did not include `q_5`, so the omission was invisible. PR #23137 (`feat: merge-train/barretenberg`) refactored `ExecutionTraceBlock` so `get_selectors()` returns `non_gate_selectors` (7 entries including `q_5`) concatenated with `gate_selectors`, expanding the consistency check to cover `q_5`. The test has been silently broken w.r.t. the new check ever since that landed last night. ## What Add the missing `builder.blocks.arithmetic.q_5().emplace_back(0)` to both manually-constructed gates in `QArith3Gate`, matching the existing convention. ## Verification ``` cd barretenberg/cpp rm -rf build-debug AVM=0 AVM_TRANSPILER=0 cmake --preset debug -DAVM=OFF cmake --build build-debug --target circuit_checker_tests ./build-debug/bin/circuit_checker_tests --gtest_filter='UltraCircuitBuilderArithmetic.QArith3Gate' # -> [ OK ] UltraCircuitBuilderArithmetic.QArith3Gate ``` Full `circuit_checker_tests` (79 tests) and a sanity-run of `polynomials_tests`, `common_tests`, `relations_tests` all pass after the fix. Full analysis: https://gist.github.com/AztecBot/74d9233cda80ad6c3108d670a019afea ClaudeBox log: https://claudebox.work/s/3064b2e43c917621?run=1 ClaudeBox log: https://claudebox.work/s/3064b2e43c917621?run=1 Co-authored-by: sergei iakovenko <105737703+iakovenkos@users.noreply.github.com> Co-authored-by: federicobarbacovi <171914500+federicobarbacovi@users.noreply.github.com>
rangozd
pushed a commit
to rangozd/aztec-packages
that referenced
this pull request
May 16, 2026
…AztecProtocol#23223) ## What Bumps the hard chunk-size cap on the playground's main entrypoint chunk (`assets/index-*.js`) in `playground/vite.config.ts` from **1800 KB → 1850 KB**, plus a bump-log entry. ## Why The `merge-train/barretenberg` PR (AztecProtocol#23137) is repeatedly failing in the merge queue on a **deterministic** `yarn build` failure in `playground/`: ``` ❌ Chunk size validation failed: ❌ assets/index-Bc65D_YP.js: 1801.31 KB exceeds limit of 1800 KB (Main entrypoint, hard limit) error during build: Error: Build failed: chunk size limits exceeded ``` (merge-queue log: `ci.aztec-labs.com/a34536031aaca0b9`) The 1800 KB limit was only raised four days ago (AztecProtocol#23107, 1750 → 1800). The merge train bundles further bb-side changes on top of `next` — notably `feat: multi-app kernel circuits (AztecProtocol#23076)` — which nudged bb.js ~1.3 KB past the just-raised ceiling. It will fail on every queue attempt until the cap is raised. 1850 KB restores a small amount of headroom. ## Note This lands the bump on `next`. To unblock AztecProtocol#23137 immediately, `next` needs to be re-merged into `merge-train/barretenberg` once this merges (or the same one-liner can be applied directly on that branch — note that branch's earlier conflict resolution dropped one of the two `=> 1800` bump-log comment lines, so expect a trivial conflict on the comment block when re-merging). No behavior change; CI build only. --- *Created by [claudebox](https://claudebox.work/v2/sessions/7ad309a3cd56537a) · group: `slackbot`*
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.
BEGIN_COMMIT_OVERRIDE
chore: circuit to polys cleanup (#23013)
chore: translator fixes (#22983)
chore: cycle group defense in depth (#23118)
chore: add a shplemini failure test (#23147)
feat: multi-app kernel circuits (#23076)
chore(dsl): require MemOp index and value to be witnesses (#23171)
chore: Fix merge-train conflicts (#23173)
chore: Merge next into merge-train/barretenberg (#23191)
fix: Fix conflicts next vs merge-train/barretenberg (#23194)
chore: poly audit followup (#23053)
chore: shrink msm test size while maintaining coverage (#23226)
END_COMMIT_OVERRIDE