Adopt noir-rs v1.0.0-beta.19 (barretenberg-rs migration)#705
Conversation
Deploying mopro with
|
| Latest commit: |
e8f1b4f
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://e96d117a.mopro.pages.dev |
| Branch Preview URL: | https://noir-rs-upgrade-beta19.mopro.pages.dev |
moven0831
force-pushed
the
noir-rs/upgrade-beta19
branch
from
86f746f to
d2d3fc8
Compare
- Bump the CLI noir-rs pin to the immutable v1.0.0-beta.19 tag and drop the obsolete android-compat feature. - Regenerate noir_multiplier2 fixtures (.json, .srs, .vk) under nargo 1.0.0-beta.19 so a fresh `mopro init --adapter noir` build is green end-to-end. - Add a Poseidon-flavored VK fixture (`noir_multiplier2_poseidon.vk`). Ultra-Honk verification keys encode the oracle hash since beta.19, so the same .vk file can no longer drive both Poseidon and Keccak prove paths; the two `_with_vk` Poseidon tests now read it. - Capture the regeneration recipe as `scripts/regen-noir-fixtures.sh` with a small Rust helper, and check in the multiplier2 circuit source under `test-vectors/noir/multiplier2/`. - Refresh adapter docs, rust-setup snippet, and the May 2025 noir blog post to match (drops x86_64-apple-ios from the noir support matrix and points users at crates.io/barretenberg-rs instead of the no-longer load-bearing aztec-packages releases). Closes #704. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The official barretenberg-rs prebuilt for x86_64-linux-android references __libc_single_threaded, which bionic only exposes from API 30 onwards. The previous custom bb binaries from zkmopro/aztec-packages didn't, so the emulator could stay on API 29. Without this bump, cli_build_android fails with `dlopen failed: cannot locate symbol "__libc_single_threaded"` on the noir adapter, but cross-compilation succeeds, so the regression slipped past the upstream noir-rs CI matrix (which never runs an emulator). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Added the -p argument with value 30 to the Android build configuration to enforce a minimum API level of 30, ensuring compatibility with the required symbols in the barretenberg-rs prebuilt for x86_64-linux-android.
cargo-ndk 4.x parses -p as cargo's --package, so the previous attempt panicked with `unknown package: 30`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Noir's barretenberg compile hits ~14m on its own, leaving the emulator instrumented test ~1m before the 15m timeout cancels it. Other adapters finish in 8-9m so the bump is just slack for noir. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
moven0831
force-pushed
the
noir-rs/upgrade-beta19
branch
from
6b93ddf to
19fe340
Compare
The Aztec barretenberg prebuilt linked via barretenberg-rs references
__libc_single_threaded, a libc++ atomics hint symbol that bionic does
not export on any current Android API. dlopen of the generated .so
fails on every emulator and device. cargo-ndk --platform N cannot
remove the reference since it is baked into the upstream static
archive. Define the symbol locally in the noir template so the
dynamic linker resolves it inside our own .so; value 0 ("multi-
threaded") is the correct default since libc++ only reads it.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…IB_DIR Root cause of the noir Android dlopen failures: barretenberg-rs's build.rs selects its prebuilt archive by substring-matching the target triple with "linux" checked before "android". The triple x86_64-linux-android contains "linux", so it downloads barretenberg-static-amd64-linux.tar.gz (a glibc / libstdc++ build) instead of the x86_64-android (libc++) one. The resulting .so references symbols Android has no provider for (__libc_single_threaded from glibc, std::__cxx11::* from libstdc++), so dlopen fails at runtime. The bug exists in every published barretenberg-rs (4.2.0-aztecnr-rc.2 pinned by noir-rs, through 4.4.0-nightly); it is only fixed on aztec-packages next/master, which are unpublished. A version bump cannot fix it. barretenberg-rs honours BB_LIB_DIR ahead of its own download, so in the Android build path we now detect a barretenberg-rs dependency (via the project's resolved Cargo.lock), pre-fetch the correct barretenberg-static-<arch>-android.tar.gz for the matching version, and point BB_LIB_DIR at it before invoking cargo ndk. No-op for adapters that do not use barretenberg-rs. Verified: a noir example built for x86_64-linux-android now produces a .so with zero undefined __libc_single_threaded / __cxx11 / _ZTTNSt7__cxx1119basic_ostringstream symbols (only libc++ std::__1 refs, met by the bundled libc++_shared.so). Also reverts the __libc_single_threaded shim from 55ac32a, which treated a symptom of the wrong-library download and is unnecessary with the correct lib. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The BB_LIB_DIR commit hand-edited the build_for_arch(...) call and left it unformatted, failing `cargo fmt --all -- --check` in the lint gate. That blocked every downstream cli_build_* job from running. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `--platform 30` floor was annotated `// API 30 minimum` and justified in 69977f9/11cd70b by the __libc_single_threaded symbol — which the root-cause fix (04a2f51) showed was an artifact of the wrong glibc archive, not a real requirement. Symbol inspection (llvm-nm/llvm-readelf) of the correct libc++ prebuilt `libbb-external.a` shows the actual driver of the floor: GLOBAL undefined imports `__tls_get_addr` (bionic libc.so, API 29 on x86_64) and `getifaddrs`/`freeifaddrs` (API 24), absent from cargo-ndk's default API 21. A floor is therefore genuinely required (true minimum 29 x86_64 / 24 arm64); the value 30 is kept as a small margin. Also tightens the BB_LIB_DIR note. Comment-only; no behavior change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…++ ABI The beta.19 barretenberg Android prebuilt is Zig-built against upstream libc++ (std::__1); the NDK's std::__ndk1 can't satisfy its symbols, so dlopen fails at runtime (e.g. the basic_ostringstream VTT). Route the final link through a `zig cc` wrapper so Zig's __1 libc++ is baked in, keeping the NDK's libc++_shared.so for other C++. Adds a noir-only Zig setup step to CI. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
beta.19 barretenberg proving on loaded CI simulators exceeds the 5s the other adapters use, making testNoirProveVerify flaky (passed at 55ac32a, failed at 0e559a1 with no functional change between). Raise prove to 120s, verify to 60s; the proof itself is valid (native Rust tests pass). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The shipped noir lib is Zig-linked (to resolve barretenberg's std::__1 libc++), but zig cc drops the static .symtab that uniffi-bindgen reads, so binding generation produced nothing and reformat_kotlin_package panicked. Build a separate NDK-linked debug lib for metadata only (identical metadata, keeps .symtab; it can't run, but bindgen never runs it) and generate bindings from it, while still shipping the Zig-linked .so. Bump the noir Android CI timeout to cover the extra build. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
testNoirProveVerify is flaky: barretenberg beta.19 proving of multiplier2 is milliseconds natively (19 tests in 1.41s) but bimodal on the CI simulator — usually <5s, occasionally stalling past the 120s timeout. The stall is a ~100,000x outlier (an upstream barretenberg-on-simulator issue, not a bad proof): same code+timeout passed at 8dd403c, and the only change since is Android-only. Retry noir up to 3x via -retry-tests-on-failure so one stalled roll doesn't fail the build; other adapters stay strict to keep real regressions visible. Bump noir's step timeout to 25m for retry headroom. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The bindgen call-site repeated the .symtab/Zig rationale already documented on build_bindgen_lib; drop one test comment that restated its test name. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…rebuilt per version Two robustness fixes to the noir Android build path from pre-landing review: - barretenberg_rs_version now bails on a failed generate-lockfile and propagates Cargo.lock read errors instead of returning Ok(None). A real failure no longer silently relinks barretenberg-rs's wrong glibc prebuilt and ships a lib that fails dlopen at runtime; Ok(None) means only "crate absent". - The BB prebuilt cache key now includes the version (bb-android-prebuilt/ <arch>-<version>). build/ survives cleanup_tmp_local, so an arch-only key would relink a stale .a after a noir-rs bump. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…oir fixtures nargo bakes the absolute source path into the circuit JSON's file_map, so the committed fixture leaked a local home-dir path to every mopro init user and regenerating on another machine produced a spurious diff. Clear file_map in the committed JSON (proving only reads bytecode) and add a normalize step to regen-noir-fixtures.sh so the recipe is host-independent. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThe PR pins Noir-rs to v1.0.0-beta.19 across configs and docs, regenerates Noir test fixtures, increases CI/workflow timeouts and adds a Zig setup for Noir Android, and introduces structured Android binding parameters with android_noir logic to fetch prebuilts and produce a Zig-based linker flag. ChangesNoir-rs v1.0.0-beta.19 Migration with Android Build Flow Updates
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
mopro-ffi/src/app_config/android.rs (2)
146-153:⚠️ Potential issue | 🟠 Major | ⚡ Quick winMissing exit status check for cargo ndk build.
The code spawns the cargo ndk command and waits for it, but doesn't verify the command succeeded. If the build fails, execution continues and later operations (like
fs::copyon line 177) fail with a confusing "file not found" error rather than a clear build failure.Proposed fix
- build_cmd + let status = build_cmd .env("CARGO_BUILD_TARGET_DIR", build_dir) .env("CARGO_BUILD_TARGET", arch_str) .env("CARGO_NDK_OUTPUT_PATH", cpp_lib_dest) .spawn() .expect("Failed to spawn cargo build") .wait() .expect("cargo build errored"); + if !status.success() { + anyhow::bail!("cargo ndk build failed for {}", arch_str); + }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@mopro-ffi/src/app_config/android.rs` around lines 146 - 153, The spawn()/wait() chain for the cargo NDK build (build_cmd.spawn().expect(...).wait().expect(...)) doesn't check the process exit status; change it to capture the ExitStatus from build_cmd.spawn() -> child.wait(), then verify status.success() and return or panic with a clear error including the exit code or status if it failed (so callers won't hit later fs::copy file-not-found errors). Update the block that creates and runs build_cmd (the cargo ndk invocation) to check the ExitStatus and produce a descriptive error message on non-successful exit.
162-168:⚠️ Potential issue | 🟠 Major | ⚡ Quick winPath construction duplicates
build_dirwhen it's a relative path.When
build_diris relative (e.g.,build),build_dir.join(format!("{}/...", build_dir.display(), ...))producesbuild/build/arch/mode/lib.so. This works correctly only whenbuild_diris absolute (becausePathBuf::joinreplaces the base for absolute arguments).Line 218 in
build_bindgen_libuses the correct pattern.Proposed fix
- let out_lib_path = build_dir.join(format!( - "{}/{}/{}/{}", - build_dir.display(), - arch_str, - mode.as_str(), - lib_name - )); + let out_lib_path = build_dir + .join(arch_str) + .join(mode.as_str()) + .join(lib_name);🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@mopro-ffi/src/app_config/android.rs` around lines 162 - 168, The out_lib_path construction duplicates build_dir when build_dir is relative; update the expression that builds out_lib_path in android.rs (the assignment using build_dir.join(format!( ... ))) to join only the arch_str, mode.as_str(), and lib_name components (or chain build_dir.join(arch_str).join(mode.as_str()).join(lib_name)) instead of including build_dir.display() in the format; this mirrors the correct approach used in build_bindgen_lib and ensures relative build_dir yields build/arch/mode/lib rather than build/build/arch/....cli/src/template/init/src/noir.rs (1)
79-79:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix typo: "fotr" should be "for".
The comment contains a typo: "Poseidon hash fotr better performance" should be "Poseidon hash for better performance".
📝 Proposed fix
-/// - `on_chain = false`: Uses Poseidon hash fotr better performance +/// - `on_chain = false`: Uses Poseidon hash for better performance🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@cli/src/template/init/src/noir.rs` at line 79, Fix the typo in the doc comment that reads "`on_chain = false`: Uses Poseidon hash fotr better performance" by changing "fotr" to "for" so it reads "`on_chain = false`: Uses Poseidon hash for better performance"; locate this exact comment fragment in noir.rs and update the comment text accordingly.docs/blog/2025-05-12-noir-integration.md (1)
106-117:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winPlatform support table may need updating.
The newly added migration note (lines 121-125) states that
x86_64-apple-ioswas dropped in v1.0.0-beta.19 because barretenberg-rs doesn't ship prebuilt binaries for Intel iOS simulator. However, line 110 in the platform support table still showsx86_64-apple-ioswith a ✅ status.Please update the table to reflect the current state after the upgrade, or clarify if this table represents historical support rather than current support.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/blog/2025-05-12-noir-integration.md` around lines 106 - 117, The platform support table is inconsistent with the migration note: update the `x86_64-apple-ios` row in the table (the `x86_64-apple-ios` platform entry) to reflect the dropped support (change the ✅ to ❌) or explicitly mark the table as "historical support" and add a clarifying footnote; ensure the change aligns with the migration note about v1.0.0-beta.19 and barretenberg-rs not shipping Intel iOS simulator binaries so readers are not misled.
🧹 Nitpick comments (1)
scripts/regen-noir-fixtures/Cargo.toml (1)
8-10: ⚡ Quick winPrefer pinning
noir-rsby immutablerevfor deterministic fixture tooling.Using only
tagleaves room for non-determinism if a tag is moved; this helper is explicitly about reproducible artifacts.#!/usr/bin/env bash set -euo pipefail git ls-remote https://github.com/zkmopro/noir-rs refs/tags/v1.0.0-beta.19Use the returned commit SHA as
rev = "<sha>"(optionally keeptagas documentation).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@scripts/regen-noir-fixtures/Cargo.toml` around lines 8 - 10, The noir crate dependency in the Cargo.toml (the noir = { package = "noir", git = "https://github.com/zkmopro/noir-rs", ... tag = "v1.0.0-beta.19" } entry) should be pinned to an immutable commit for deterministic fixture generation: run git ls-remote on the repository to get the commit SHA for tag v1.0.0-beta.19 and replace or add rev = "<sha>" in the dependency table (you may optionally keep tag = "v1.0.0-beta.19" for documentation), ensuring the dependency uses rev = "<sha>" so the fixture tooling is reproducible.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/docs/adapters/noir.md`:
- Around line 30-32: Update the Noir adapter docs to stop implying that
"=4.2.0-aztecnr-rc.2" is a crates.io version of the barretenberg-rs crate:
clarify that Noir v1.0.0-beta.19 uses the official barretenberg-rs crate from
crates.io for the Rust bindings but requires Barretenberg binaries/CLI aligned
to the Aztec compatibility tag "4.2.0-aztecnr-rc.2" (i.e., a binaries/tooling
compatibility identifier), and remove or rephrase the exact crates.io version
assertion so the text instead states the adapter fetches prebuilt FFI binaries
that must match that Barretenberg tag.
In `@mopro-ffi/src/app_config/android.rs`:
- Around line 209-216: The cargo build for the bindgen lib spawns build_cmd with
envs (bindgen_target, arch_str) but never checks the child process' exit status;
change the chain to capture the ExitStatus (e.g., let status =
build_cmd...spawn()?.wait()?), then assert status.success() and return/log a
clear error including arch_str and the status/code if it failed (so failures are
distinguished from spawn errors), similar to the fix used in build_for_arch;
keep the existing out_lib_path.exists() check as a secondary validation.
In `@scripts/regen-noir-fixtures.sh`:
- Around line 17-18: The script currently only prints the installed nargo
version before running ( cd "$CIRCUIT_DIR" && nargo compile ); add a strict
version check that runs nargo --version, compares it to a defined
REQUIRED_NARGO_VERSION (or expected string), and exits non-zero with a clear
error if they differ so the compile step is skipped on mismatched versions;
update the top of the script to define REQUIRED_NARGO_VERSION and perform the
check before invoking ( cd "$CIRCUIT_DIR" && nargo compile ), emitting a helpful
message that shows both required and installed versions on mismatch.
---
Outside diff comments:
In `@cli/src/template/init/src/noir.rs`:
- Line 79: Fix the typo in the doc comment that reads "`on_chain = false`: Uses
Poseidon hash fotr better performance" by changing "fotr" to "for" so it reads
"`on_chain = false`: Uses Poseidon hash for better performance"; locate this
exact comment fragment in noir.rs and update the comment text accordingly.
In `@docs/blog/2025-05-12-noir-integration.md`:
- Around line 106-117: The platform support table is inconsistent with the
migration note: update the `x86_64-apple-ios` row in the table (the
`x86_64-apple-ios` platform entry) to reflect the dropped support (change the ✅
to ❌) or explicitly mark the table as "historical support" and add a clarifying
footnote; ensure the change aligns with the migration note about v1.0.0-beta.19
and barretenberg-rs not shipping Intel iOS simulator binaries so readers are not
misled.
In `@mopro-ffi/src/app_config/android.rs`:
- Around line 146-153: The spawn()/wait() chain for the cargo NDK build
(build_cmd.spawn().expect(...).wait().expect(...)) doesn't check the process
exit status; change it to capture the ExitStatus from build_cmd.spawn() ->
child.wait(), then verify status.success() and return or panic with a clear
error including the exit code or status if it failed (so callers won't hit later
fs::copy file-not-found errors). Update the block that creates and runs
build_cmd (the cargo ndk invocation) to check the ExitStatus and produce a
descriptive error message on non-successful exit.
- Around line 162-168: The out_lib_path construction duplicates build_dir when
build_dir is relative; update the expression that builds out_lib_path in
android.rs (the assignment using build_dir.join(format!( ... ))) to join only
the arch_str, mode.as_str(), and lib_name components (or chain
build_dir.join(arch_str).join(mode.as_str()).join(lib_name)) instead of
including build_dir.display() in the format; this mirrors the correct approach
used in build_bindgen_lib and ensures relative build_dir yields
build/arch/mode/lib rather than build/build/arch/....
---
Nitpick comments:
In `@scripts/regen-noir-fixtures/Cargo.toml`:
- Around line 8-10: The noir crate dependency in the Cargo.toml (the noir = {
package = "noir", git = "https://github.com/zkmopro/noir-rs", ... tag =
"v1.0.0-beta.19" } entry) should be pinned to an immutable commit for
deterministic fixture generation: run git ls-remote on the repository to get the
commit SHA for tag v1.0.0-beta.19 and replace or add rev = "<sha>" in the
dependency table (you may optionally keep tag = "v1.0.0-beta.19" for
documentation), ensuring the dependency uses rev = "<sha>" so the fixture
tooling is reproducible.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: ff819cfd-04fa-4379-97c6-b9e1738a2d63
⛔ Files ignored due to path filters (1)
scripts/regen-noir-fixtures/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (18)
.github/workflows/build-and-test.ymlcli/src/init/noir.rscli/src/template/init/src/noir.rscli/src/template/init/test-vectors/noir/noir_multiplier2.jsoncli/src/template/init/test-vectors/noir/noir_multiplier2.srscli/src/template/init/test-vectors/noir/noir_multiplier2.vkcli/src/template/init/test-vectors/noir/noir_multiplier2_poseidon.vkcli/src/template/ios/MoproAppUITests/MoproAppUITests.swiftdocs/blog/2025-05-12-noir-integration.mddocs/docs/adapters/noir.mddocs/docs/setup/rust-setup.mdmopro-ffi/src/app_config/android.rsscripts/regen-noir-fixtures.shscripts/regen-noir-fixtures/Cargo.tomlscripts/regen-noir-fixtures/src/main.rstest-vectors/noir/multiplier2/Nargo.tomltest-vectors/noir/multiplier2/src/main.nrtest-vectors/noir/noir_multiplier2.vk
| **Current version**: Supports Noir `v1.0.0-beta.19` via the official [`barretenberg-rs`](https://crates.io/crates/barretenberg-rs) crate (`=4.2.0-aztecnr-rc.2`). | ||
|
|
||
| **Backend**: The adapter uses the Barretenberg backend, which is automatically downloaded from the released GitHub artifacts at [zkmopro/aztec-packages](https://github.com/zkmopro/aztec-packages/releases). | ||
| **Backend**: The adapter uses the Barretenberg backend via the official [`barretenberg-rs`](https://crates.io/crates/barretenberg-rs) crate from crates.io. Prebuilt FFI binaries are fetched automatically at build time — no separate download script required. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if barretenberg-rs 4.2.0-aztecnr-rc.2 exists on crates.io
curl -s https://crates.io/api/v1/crates/barretenberg-rs | jq -r '.versions[] | select(.num == "4.2.0-aztecnr-rc.2") | .num'Repository: zkmopro/mopro
Length of output: 1893
🌐 Web query:
crates.io barretenberg-rs 4.2.0-aztecnr-rc.2
💡 Result:
The identifier 4.2.0-aztecnr-rc.2 refers to a specific version of the Aztec developer SDK and associated tools, rather than a standalone crate hosted on crates.io [1][2]. Barretenberg-rs is a Rust crate that provides bindings to Barretenberg, the cryptographic proving engine used by the Aztec protocol [3][4]. While barretenberg-rs is available on crates.io [3], the specific version 4.2.0-aztecnr-rc.2 is a release tag for the Aztec developer ecosystem [5][2], not a version published to the crates.io registry. In the context of Aztec development, 4.2.0-aztecnr-rc.2 is used to version developer documentation, SDK components, and contract development environments [1][6][2]. The Aztec protocol maintains its own versioning system for its release candidates and mainnet-compatible tools, which may differ from the versioning of individual crates like barretenberg-rs [2]. Developers are typically advised to use the version specified in the documentation for the network they are targeting (e.g., mainnet, testnet) rather than looking for a matching crate version on crates.io [2].
Citations:
- 1: AztecProtocol/aztec-packages@b3f4a7e
- 2: AztecProtocol/aztec-packages@c6042dd
- 3: https://crates.io/crates/barretenberg-rs
- 4: https://deepwiki.com/AztecProtocol/aztec-packages/4.1-barretenberg-proving-engine
- 5: https://github.com/AztecProtocol/aztec-starter/releases/tag/v4.2.0-aztecnr-rc.2
- 6: AztecProtocol/aztec-packages@d4198ec
🌐 Web query:
noir-rs v1.0.0-beta.19 barretenberg-rs dependency 4.2.0-aztecnr-rc.2
💡 Result:
In the context of the Noir ecosystem, the version noir-rs v1.0.0-beta.19 is associated with a migration to the barretenberg-rs library [1][2][3]. Specifically, projects such as the zkmopro/noir-rs crate underwent updates to integrate this version of Noir and adopt the official barretenberg-rs dependency [4][2]. Evidence from technical repositories indicates that for certain implementations utilizing this toolchain, the Barretenberg CLI (and the associated barretenberg-rs build) is expected to match the version 4.2.0-aztecnr-rc.2 [5]. This version mapping is managed in various monorepos and developer environments, often requiring manual synchronization, such as using bbup (a tool for managing Barretenberg binaries) or installation scripts that target this specific rc version [5][6]. In summary: - noir-rs v1.0.0-beta.19 was released around February 2026 [7]. - The transition to barretenberg-rs was a key part of the upgrade path for that release [2][3]. - 4.2.0-aztecnr-rc.2 is a documented version requirement for the Barretenberg CLI components used alongside these builds to ensure compatibility with the proving backend [5][6].
Citations:
- 1: Adopt noir-rs v1.0.0-beta.19 (barretenberg-rs migration) across mopro #704
- 2: https://github.com/zkmopro/noir-rs
- 3: rust-witness fails to compile for iOS targets if using both Circom and Noir #551
- 4: https://github.com/zkmopro/noir-rs?tab=readme-ov-file
- 5: https://github.com/zksigil/sigil-monorepo/blob/master/README.md
- 6: AztecProtocol/aztec-packages@3bf4f63
- 7: https://github.com/noir-lang/noir/releases/tag/v1.0.0-beta.19
Correct the barretenberg-rs version mapping in noir adapter docs
The docs claim that Noir v1.0.0-beta.19 uses barretenberg-rs with the exact version =4.2.0-aztecnr-rc.2 “via the official barretenberg-rs crate” as if that RC tag is a crates.io crate version. The identifier 4.2.0-aztecnr-rc.2 matches an Aztec developer ecosystem/Barretenberg CLI compatibility tag (binaries/tooling), not clearly a published barretenberg-rs crates.io version. Update the wording to clarify whether 4.2.0-aztecnr-rc.2 refers to the Barretenberg binaries/CLI alignment requirement (rather than the barretenberg-rs crate version constraint) and remove/adjust the exact crates.io version assertion accordingly.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/docs/adapters/noir.md` around lines 30 - 32, Update the Noir adapter
docs to stop implying that "=4.2.0-aztecnr-rc.2" is a crates.io version of the
barretenberg-rs crate: clarify that Noir v1.0.0-beta.19 uses the official
barretenberg-rs crate from crates.io for the Rust bindings but requires
Barretenberg binaries/CLI aligned to the Aztec compatibility tag
"4.2.0-aztecnr-rc.2" (i.e., a binaries/tooling compatibility identifier), and
remove or rephrase the exact crates.io version assertion so the text instead
states the adapter fetches prebuilt FFI binaries that must match that
Barretenberg tag.
There was a problem hiding this comment.
Verified — keeping as written. noir-rs v1.0.0-beta.19 declares the dependency as barretenberg-rs = { version = "=4.2.0-aztecnr-rc.2", default-features = false, features = ["ffi"] } in its noir/Cargo.toml, i.e. an exact crates.io version constraint, not just an Aztec tooling tag. So "via the official barretenberg-rs crate (=4.2.0-aztecnr-rc.2)" is accurate. Happy to add a sentence distinguishing the crate version from the Barretenberg binary alignment if you'd still like that called out.
There was a problem hiding this comment.
@moven0831, thanks for the verification — that's exactly the confirmation I needed. Since noir-rs v1.0.0-beta.19 pins barretenberg-rs with an exact crates.io version constraint (= "=4.2.0-aztecnr-rc.2"), the current wording in the docs is accurate and no change is required. I'll withdraw the suggestion.
（ˇεˇ）
✏️ Learnings added
Learnt from: moven0831
Repo: zkmopro/mopro PR: 705
File: docs/docs/adapters/noir.md:30-32
Timestamp: 2026-06-08T15:37:46.590Z
Learning: In the `zkmopro/mopro` repository, `noir-rs` `v1.0.0-beta.19` declares its Barretenberg dependency in `noir/Cargo.toml` as `barretenberg-rs = { version = "=4.2.0-aztecnr-rc.2", default-features = false, features = ["ffi"] }`. The identifier `4.2.0-aztecnr-rc.2` is a valid, published crates.io version of the `barretenberg-rs` crate — not merely an Aztec tooling/CLI compatibility tag. Documentation referencing "via the official `barretenberg-rs` crate (`=4.2.0-aztecnr-rc.2`)" is therefore accurate.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
|
|
||
| // barretenberg-rs's build.rs matches "linux" before "android" and fetches a | ||
| // glibc prebuilt Android can't dlopen; BB_LIB_DIR overrides it with the right one. | ||
| let bb_lib_dir = setup_barretenberg_android_lib(arch, project_dir, build_dir)?; |
There was a problem hiding this comment.
In this version of mopro-ffi, I hope it can be adpater-free
it should not be built for any adapter (e.g. circom or noir)
if there is adapter related change, it should be in cli cli/src/template/init/build.rs
There was a problem hiding this comment.
Agreed that mopro-ffi should stay adapter-free. I looked into hosting this in the generated cli/src/template/init/build.rs specifically, but a build script there structurally can't carry the core mechanics:
BB_LIB_DIRhas to be in thecargo ndkprocess env before it starts —barretenberg-rs's ownbuild.rsruns (and picks its prebuilt) before the user crate'sbuild.rs, and a build script can't set env for another crate's build script.- The Zig linker can't be selected from a build script — there's no
cargo::rustc-linkerdirective; onlyRUSTFLAGS -Clinker/CARGO_TARGET_<triple>_LINKER/.cargo/config.tomlcan, and cargo-ndk overrides the latter two. --platformand the second NDK-linked bindgen build arecargo ndkorchestration, not something a templated project file can express.
So I kept the intent but moved it to the CLI build driver, mirroring the existing IosBindingsParams { using_noir } pattern:
mopro-ffi/src/app_config/android.rsis adapter-free again (323 lines, was 217 onmain).AndroidBindingsParamsis now a generic struct —arch_overrides(per-arch env + RUSTFLAGS),min_sdk_version,relink_with_ndk_for_bindgen— with no barretenberg/noir/Aztec strings.- All the noir/barretenberg logic (prebuilt download, version parsing, Zig wrapper, NDK discovery) moved to a new
cli/src/build/android_noir.rs, called fromcli/src/build.rsonly when the Noir adapter is selected.
Since mopro build drives the Android build in-process via the CLI, this needs no mopro-ffi release — the generated project still compiles against the published =0.3.6 untouched. Side effect: non-noir Android builds no longer inherit the --platform 30 bump this PR had applied to every adapter.
Does this direction work for you?
Keep mopro-ffi's Android builder adapter-free (per review). AndroidBindingsParams is now a generic struct (arch_overrides / min_sdk_version / relink_with_ndk_for_bindgen) and android.rs carries no barretenberg/noir/Aztec knowledge. All noir-specific logic (prebuilt download, Cargo.lock version parse, Zig linker wrapper, NDK discovery) moves to cli/src/build/android_noir.rs, driven from cli/src/build.rs only when Noir is selected, mirroring IosBindingsParams. `mopro build` drives the build in-process via the CLI, so no mopro-ffi release is needed; generated projects still build against the published =0.3.6. Restores cargo-ndk's default min API for non-noir Android builds (--platform 30 is now noir-only), and adds cargo-ndk exit-status checks plus a relative-build_dir join fix in the generic builder. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- blog: mark x86_64-apple-ios unsupported (dropped in noir-rs beta.19) - noir.rs template: fix "fotr" -> "for" typo - regen-noir-fixtures.sh: enforce nargo v1.0.0-beta.19 instead of only printing it - regen-noir-fixtures: pin noir-rs by immutable rev for reproducible fixtures Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… tests Per review, remove the manual fixture-regeneration apparatus (scripts/regen-noir-fixtures.sh, its helper crate, and the now-orphaned test-vectors/noir/multiplier2 circuit source) to revisit after the circuit compile/reuse refactor. The committed .json/.srs/.vk fixtures the tests consume are untouched. Also trim the barretenberg-rs version parser tests to the one meaningful case (distinguishing a dependency mention from the package entry); the other two just re-derived their mocked input. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/build-and-test.yml (1)
285-289:⚠️ Potential issue | 🟠 Major | ⚡ Quick winExpand Noir Android toolchain setup to the React Native job too.
Line 285 adds Zig only for
cli_build_android, but Line 417 still builds Android foradapter: noirincli_create_react_nativewithout Zig/NDK setup. Withandroid_noirnow failing fast when Zig is unavailable (and using NDK paths for linker wrapper generation), this can break the Noir React Native matrix leg. Add equivalent Noir-conditional Zig (and required Android toolchain) setup in that job before the build step.Also applies to: 417-424
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/build-and-test.yml around lines 285 - 289, The Noir Android Zig/NDK setup is only added in the cli_build_android job (matrix.adapter == 'noir') but missing from the cli_create_react_native job where adapter: noir is also built; add the same conditional setup there: insert the mlugg/setup-zig@v2 step (version 0.16.0) guarded by if: matrix.adapter == 'noir' and also include the corresponding Android toolchain/NDK setup steps used in cli_build_android (the NDK/SDK export and any linker-wrapper generation used by android_noir) before the build step so the android_noir path in cli_create_react_native can find Zig/NDK. Ensure you reference the same step names/inputs as in the cli_build_android block to keep behavior identical.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In @.github/workflows/build-and-test.yml:
- Around line 285-289: The Noir Android Zig/NDK setup is only added in the
cli_build_android job (matrix.adapter == 'noir') but missing from the
cli_create_react_native job where adapter: noir is also built; add the same
conditional setup there: insert the mlugg/setup-zig@v2 step (version 0.16.0)
guarded by if: matrix.adapter == 'noir' and also include the corresponding
Android toolchain/NDK setup steps used in cli_build_android (the NDK/SDK export
and any linker-wrapper generation used by android_noir) before the build step so
the android_noir path in cli_create_react_native can find Zig/NDK. Ensure you
reference the same step names/inputs as in the cli_build_android block to keep
behavior identical.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 2fc52a36-eef5-48c6-a033-ac91cad835ce
📒 Files selected for processing (2)
.github/workflows/build-and-test.ymlcli/src/template/ios/MoproAppUITests/MoproAppUITests.swift
🚧 Files skipped from review as they are similar to previous changes (1)
- cli/src/template/ios/MoproAppUITests/MoproAppUITests.swift
2 participants
Closes #704. The mopro side of the noir-rs beta.19 migration (zkmopro/noir-rs#37).
What changes
cli/src/init/noir.rs: noir-rs →tag = "v1.0.0-beta.19", and drop the obsoleteandroid-compatfeature so fresh projects build out of the box.mopro-ffi/src/app_config/android.rs:AndroidBindingsParamsis now a real struct (arch_overrides,min_sdk_version,relink_with_ndk_for_bindgen) instead of(). mopro-ffi stays adapter-free — it just applies whatever per-arch env/RUSTFLAGS, min SDK, and separate bindgen build the caller passes.dlopenfix —cli/src/build/android_noir.rs(new): all noir/barretenberg knowledge lives here, driven fromcli/src/build.rsonly when the Noir adapter is selected (mirrorsIosBindingsParams). It fetches the correct barretenberg prebuilt and links it with Zig (root cause below).noir_multiplier2.{json,srs,vk}, plus a newnoir_multiplier2_poseidon.vk. beta.19 bakes the oracle hash into the VK, so the two Poseidon_with_vktests read the new file; the Keccak tests and the sample apps keep usingnoir_multiplier2.vk.barretenberg-rscrate on crates.io and dropx86_64-apple-ios.build-and-test.yml: install Zig for the noir leg, raise the Android emulator to API 30, and give the Android job more timeout headroom (slower proving + the extra bindgen build).Android
dlopenfix (root cause for previous CI failure)barretenberg-rs'sbuild.rspicks its prebuilt by substring-matching the target triple, with thelinuxarm beforeandroid:x86_64-linux-androidcontainslinux, so it downloads the glibc / libstdc++ build and links it into the Android.so. Android has neither, sodlopenfails at runtime (__libc_single_threaded,std::__cxx11::*). It's fixed upstream (PR #20759) but that commit is unpublished, so a version bump can't pull it in.barretenberg-rshonorsBB_LIB_DIRahead of its own download, so the Noir Android path (cli/src/build/android_noir.rs) now:barretenberg-rsversion from the project'sCargo.lock— and bails loudly if it can't resolve it, rather than silently linking the wrong prebuilt.barretenberg-static-<arch>-android.tar.gzand pointsBB_LIB_DIRat it (cached per version underbuild/).std::__1, and the NDK'sstd::__ndk1is ABI-incompatible..symtabbindgen reads.This is a no-op for adapters that don't use barretenberg-rs. It needs Zig and the NDK on
PATH; the builder errors clearly if either is missing.Min API 30: the correct prebuilt imports
__tls_get_addr(API 29) andgetifaddrs(API 24), above cargo-ndk's default of 21. The builder passes--platform 30(noir-only) and CI runs the emulator on API 30.Test plan
mopro init --adapter noiragainst this CLI pins beta.19 with noandroid-compatwarning.cargo test --all --all-features→ 19/19 noir tests pass, all four_with_vkvariants included.cargo check --workspace;cargo test -p mopro-cli(covers thebarretenberg-rsversion parser).x86_64-linux-androidbuild: the shipped.sohas no undefined__libc_single_threaded/__cxx11symbols, andBB_LIB_DIRwas used.noirButtonClick) and iOS simulator E2E — handled by CI.Out of scope (tracked under #704)
docs/docs/performance.mdbenchmarks still cite beta.3; re-running them is separate.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes
Documentation