chore: Accumulated backports to v4-next (#22060)

BEGIN_COMMIT_OVERRIDE
chore: rename pxe-side oracle implementations (#22044)
chore: rename pxe-side oracle implementations (#22044) (#22051)
docs: document AVM cryptographic compatibility for public vs private
(#21814)
END_COMMIT_OVERRIDE

Author: nventuro

barretenberg/cpp/src/barretenberg/api/file_io.hpp

@@ -69,7 +69,8 @@ inline void write_file(const std::string& filename, std::vector<uint8_t> const&
         size_t total_written = 0;
         size_t data_size = data.size();
         while (total_written < data_size) {
-            auto written = ::write(fd, data.data() + total_written, data_size - total_written);
+            auto written =
+                ::write(fd, data.data() + total_written, static_cast<unsigned int>(data_size - total_written));
             if (written == -1) {
                 close(fd);
                 THROW std::runtime_error("Failed to write to file descriptor: " + filename);

barretenberg/cpp/src/barretenberg/chonk/chonk_verifier.cpp

@@ -27,6 +27,12 @@ template <> ChonkVerifier<false>::Output ChonkVerifier<false>::verify(const Proo
     HidingKernelIO kernel_io;
     kernel_io.reconstruct_from_public(verifier.get_public_inputs());
 
+    // Check accumulated pairing points from the IVC chain (inner recursive verifications)
+    if (!kernel_io.pairing_inputs.check()) {
+        info("ChonkVerifier: verification failed at PI pairing points check");
+        return false;
+    }
+
     // Step 2: Perform databus consistency check
     const Commitment calldata_commitment = verifier.get_calldata_commitment();
     const Commitment return_data_commitment = kernel_io.kernel_return_data;

barretenberg/rust/bootstrap.sh

@@ -60,6 +60,12 @@ function release {
     (cd ../ts && yarn generate)
   fi
 
+  # Check if this version is already published on crates.io (idempotent re-runs).
+  if curl -sf -H "User-Agent: aztec-packages-ci (tech@aztec-labs.com)" "https://crates.io/api/v1/crates/barretenberg-rs/$version" | jq -e '.version.num' &>/dev/null; then
+    echo "barretenberg-rs@$version already published on crates.io. Skipping."
+    return 0
+  fi
+
   # Publish to crates.io (--allow-dirty because version was just set and generated files are gitignored)
   local extra_flags=""
   if ! gh release view "v$version" --repo AztecProtocol/aztec-packages &>/dev/null; then

docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/foundational-topics/advanced/authwit.md

@@ -120,6 +120,10 @@ sequenceDiagram
 
 The registry approach has a gas optimization: if authorization is set and consumed in the same transaction, the state changes cancel out, saving gas.
 
+:::tip Why use Auth Registry for signatures in public?
+ECDSA signature verification is not directly available in public functions due to AVM limitations. The public authwit flow above is the recommended pattern: verify signatures in private, store approvals in the Auth Registry, and consume them in public. See [AVM Cryptographic Compatibility](./circuits/avm_compatibility.md) for more details.
+:::
+
 ### Replay prevention
 
 Each authwit can only be used once. The consuming contract emits a nullifier for the action, preventing reuse. This is similar to how notes work.

docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/foundational-topics/advanced/circuits/avm_compatibility.md

@@ -0,0 +1,68 @@
+---
+title: AVM Cryptographic Compatibility
+sidebar_position: 3
+description: Which Noir cryptographic primitives work in public (AVM) functions vs private, and workarounds for unsupported operations.
+tags: [protocol, circuits]
+---
+
+Private and public functions in Aztec use different execution models. Private functions compile to ACIR circuits and have access to the full Noir standard library. Public functions compile to AVM bytecode via the transpiler, which supports only a specific set of cryptographic operations.
+
+## Compatibility Table
+
+The table below lists the low-level blackbox operations and whether they are available in the AVM. Higher-level Noir standard library functions (like `sha256::sha256_var`, `keccak256::keccak256`, `poseidon2::hash`, and `std::hash::pedersen_hash`) are built on these primitives and work in public functions when the underlying operations are supported.
+
+| Noir Primitive | Private (ACIR) | Public (AVM) | Notes |
+|---|---|---|---|
+| Poseidon2 Permutation | Supported | Supported | `POSEIDON2PERM` opcode |
+| Pedersen Hash / Commitment | Supported | Supported | Lowered to `ECADD` and `MSM` operations |
+| SHA-256 Compression | Supported | Supported | `SHA256COMPRESSION` opcode |
+| Keccak f1600 | Supported | Supported | `KECCAKF1600` opcode |
+| Embedded Curve Add | Supported | Supported | `ECADD` opcode (Grumpkin curve) |
+| Multi-Scalar Multiplication | Supported | Supported | Lowered to `TORADIXBE` + `ECADD` operations |
+| ToRadix | Supported | Supported | `TORADIXBE` opcode |
+| ECDSA secp256k1 | Supported | **Not supported** | Transpiler panics |
+| ECDSA secp256r1 | Supported | **Not supported** | Transpiler panics |
+| AES-128 Encrypt | Supported | **Not supported** | Transpiler panics |
+| Blake2s | Supported | **Not supported** | Transpiler panics |
+| Blake3 | Supported | **Not supported** | Transpiler panics |
+
+## Why the Difference
+
+Private functions are compiled to ACIR (Abstract Circuit Intermediate Representation), which supports the full set of Noir standard library blackbox functions. These are evaluated as part of the zk-SNARK proof generation on the user's device.
+
+Public functions are compiled to AVM bytecode via the transpiler. The AVM has a fixed instruction set, and each supported cryptographic operation must either have a dedicated opcode or be reducible to a sequence of supported opcodes. For example, multi-scalar multiplication has no dedicated opcode but is lowered to `TORADIXBE` and `ECADD` instructions. Operations that cannot be mapped to supported opcodes cannot be transpiled.
+
+## What Error Will I See?
+
+If you use an unsupported blackbox function in a `#[external("public")]` function, the transpiler will panic at compile time with a message like:
+
+```
+Transpiler doesn't know how to process EcdsaSecp256k1
+```
+
+where the final token is the name of the unsupported `BlackBoxOp` variant (e.g. `AES128Encrypt`, `Blake2s`, `Blake3`).
+
+## Signature Verification in Public: Workarounds
+
+Since ECDSA signature verification is not available in public functions, use the **Authentication Registry** pattern:
+
+1. Verify signatures in a **private** function (where all Noir primitives are available)
+2. Store approval hashes in the **Auth Registry** (a shared public contract)
+3. Consume the approvals in **public** functions
+
+This is exactly how public authwits work. See [Authentication Witnesses](../authwit.md) for the full pattern.
+
+:::tip Schnorr signatures
+The [`noir-lang/schnorr`](https://github.com/noir-lang/schnorr) library implements Schnorr verification in pure Noir using embedded curve operations (ECADD, MSM), which are supported in the AVM. This means Schnorr verification may work in public functions. However, the standard Aztec account contracts only use Schnorr in private functions, and the recommended pattern remains verifying signatures in private via the Auth Registry.
+:::
+
+## ISA Reference
+
+For the complete list of AVM opcodes, see the [AVM ISA Quick Reference](https://github.com/AztecProtocol/aztec-packages/blob/next/yarn-project/simulator/docs/avm/avm-isa-quick-reference.md).
+
+## Related Pages
+
+- [Public Execution (AVM)](./public_execution.md) – How the AVM executes public functions
+- [Authentication Witnesses](../authwit.md) – The Auth Registry pattern for public authorization
+- [Call Types](../../../foundational-topics/call_types.md) – How private and public functions interact
+- [Private Kernel](./private_kernel.md) – How private functions are processed

docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/foundational-topics/advanced/circuits/index.md

@@ -1,6 +1,6 @@
 ---
 title: Circuits
-sidebar_position: 2
+sidebar_position: 0
 tags: [protocol, circuits]
 description: Explore Aztec's core protocol circuits that enforce privacy rules and transaction validity through zero-knowledge proofs, enabling private state and function execution.
 ---

docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/foundational-topics/advanced/circuits/private_kernel.md

@@ -1,6 +1,6 @@
 ---
 title: Private Kernel Circuit
-sidebar_position: 0
+sidebar_position: 1
 tags: [protocol, circuits]
 description: Learn about the Private Kernel Circuit, the only zero-knowledge circuit in Aztec that handles private data and ensures transaction privacy by executing on user devices.
 ---

docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/foundational-topics/advanced/circuits/public_execution.md

@@ -1,6 +1,6 @@
 ---
 title: Public Execution (AVM)
-sidebar_position: 1
+sidebar_position: 2
 tags: [protocol, circuits]
 description: Learn how the Aztec Virtual Machine (AVM) executes public functions and manages public state transitions.
 ---
@@ -22,6 +22,14 @@ For transactions containing public functions, the execution flow is:
 3. **AVM** - Executes all public functions, produces accumulated data
 4. **Rollup Circuits** - Validates proofs and includes in block
 
+## Supported Cryptographic Operations
+
+The AVM supports Poseidon2, Pedersen, SHA-256, Keccak, and Grumpkin curve operations (embedded curve add, multi-scalar multiplication). ECDSA signature verification, AES-128, Blake2s, and Blake3 are not available in public functions.
+
+:::warning
+If your contract uses unsupported Noir blackbox functions in a public function, transpilation will fail at compile time. See [AVM Cryptographic Compatibility](./avm_compatibility.md) for the full compatibility table and workarounds.
+:::
+
 ## Execution Phases
 
 The AVM executes public functions in three distinct phases:
@@ -72,6 +80,7 @@ These snapshots are validated in the rollup circuits to ensure continuity across
 
 ## Related Pages
 
+- [AVM Cryptographic Compatibility](./avm_compatibility.md) – Which Noir primitives work in public functions
 - [Private Kernel](./private_kernel.md) – How private functions are processed
 - [Call Types](../../call_types.md) – How private and public functions interact
 - [State Management](../../state_management.md) – How public and private state works

docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/foundational-topics/advanced/circuits/rollup_circuits.md

@@ -1,6 +1,6 @@
 ---
 title: Rollup Circuits
-sidebar_position: 2
+sidebar_position: 4
 tags: [protocol, circuits]
 description: Learn how Rollup Circuits compress transactions into a single proof using a hierarchical tree topology for efficient verification on Ethereum.
 ---

docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/foundational-topics/call_types.md

@@ -220,6 +220,10 @@ For this reason it is encouraged to try to avoid public function calls and inste
 
 Contract functions marked with `#[external("public")]` can only be called publicly, and are executed by the sequencer. The computation model is very similar to the EVM: all state, parameters, etc. are known to the entire network, and no data is private. Static execution like the EVM's `STATICCALL` is possible too, with similar semantics (state can be accessed but not modified, etc.).
 
+:::note
+The AVM supports a subset of Noir's cryptographic operations. Signature verification (ECDSA) is not available in public functions. See [AVM Cryptographic Compatibility](./advanced/circuits/avm_compatibility.md) for details.
+:::
+
 Since private calls are always run in a user's device, it is not possible to perform any private execution from a public context. A reasonably good mental model for public execution is that of an EVM in which some work has already been done privately, and all that is known about it is its correctness and side-effects (new notes and nullifiers, enqueued public calls, etc.). A reverted public execution will also revert the private side-effects.
 
 Public functions in other contracts can be called both regularly and statically, just like on the EVM.