Merge branch 'next' into merge-train/avm

Author: AztecBot

barretenberg/cpp/src/barretenberg/bb/readme.md

@@ -79,7 +79,7 @@ Barretenberg UltraHonk comes with the capability to verify proofs in Solidity, i
    bb prove --scheme ultra_honk --oracle-hash keccak -b ./target/hello_world.json -w ./target/witness-name.gz -o ./target/proof
    ```
 
-   > **Note:** `--oracle-hash keccak` flag is used to generate UltraHonk proofs with Keccak hashes, as it is what the Solidity verifier is designed to be compatible with given the better gas efficiency when verifying on-chain; The default `--oracle-hash poseidon` in comparison generates proofs with Poseidon hashes, which is more efficient in recursions but not for on-chain verifications.
+   > **Note:** `--oracle-hash keccak` flag is used to generate UltraHonk proofs with Keccak hashes, as it is what the Solidity verifier is designed to be compatible with given the better gas efficiency when verifying onchain; The default `--oracle-hash poseidon` in comparison generates proofs with Poseidon hashes, which is more efficient in recursions but not for onchain verifications.
 
 2. Compute the verification key for your Noir program running:
 

barretenberg/docs/docs/explainers/recursive_aggregation.md

@@ -49,7 +49,7 @@ In Zero-Knowledge, recursion has some similarities.
 
 It is not a Noir function calling itself, but a proof being used as an input to another circuit. In short, you verify one proof *inside* another proof, returning the proof that both proofs are valid.
 
-This means that, given enough computational resources, you can prove the correctness of any arbitrary number of proofs in a single proof. This could be useful to design state channels (for which a common example would be [Bitcoin's Lightning Network](https://en.wikipedia.org/wiki/Lightning_Network)), to save on gas costs by settling one proof on-chain, or simply to make business logic less dependent on a consensus mechanism.
+This means that, given enough computational resources, you can prove the correctness of any arbitrary number of proofs in a single proof. This could be useful to design state channels (for which a common example would be [Bitcoin's Lightning Network](https://en.wikipedia.org/wiki/Lightning_Network)), to save on gas costs by settling one proof onchain, or simply to make business logic less dependent on a consensus mechanism.
 
 ## Examples
 
@@ -61,9 +61,9 @@ Alice and Bob are friends, and they like guessing games. They want to play a gue
 
 So, they use zero-knowledge proofs. Alice tries to guess Bob's number, and Bob will generate a ZK proof stating whether she succeeded or failed.
 
-This ZK proof can go on a smart contract, revealing the winner and even giving prizes. However, this means every turn needs to be verified on-chain. This incurs some cost and waiting time that may simply make the game too expensive or time-consuming to be worth it.
+This ZK proof can go on a smart contract, revealing the winner and even giving prizes. However, this means every turn needs to be verified onchain. This incurs some cost and waiting time that may simply make the game too expensive or time-consuming to be worth it.
 
-As a solution, Alice proposes the following: "what if Bob generates his proof, and instead of sending it on-chain, I verify it *within* my own proof before playing my own turn?".
+As a solution, Alice proposes the following: "what if Bob generates his proof, and instead of sending it onchain, I verify it *within* my own proof before playing my own turn?".
 
 She can then generate a proof that she verified his proof, and so on.
 
@@ -143,14 +143,14 @@ In such a situation, and assuming Alice is first, she would skip the first part
 
 ### Aggregating proofs
 
-In some one-way interaction situations, recursion would allow for aggregation of simple proofs that don't need to be immediately verified on-chain or elsewhere.
+In some one-way interaction situations, recursion would allow for aggregation of simple proofs that don't need to be immediately verified onchain or elsewhere.
 
-To give a practical example, a barman wouldn't need to verify a "proof-of-age" on-chain every time he serves alcohol to a customer. Instead, the architecture would comprise two circuits:
+To give a practical example, a barman wouldn't need to verify a "proof-of-age" onchain every time he serves alcohol to a customer. Instead, the architecture would comprise two circuits:
 
 - A `main`, non-recursive circuit with some logic
 - A `recursive` circuit meant to verify two proofs in one proof
 
-The customer's proofs would be intermediate, and made on their phones, and the barman could just verify them locally. He would then aggregate them into a final proof sent on-chain (or elsewhere) at the end of the day.
+The customer's proofs would be intermediate, and made on their phones, and the barman could just verify them locally. He would then aggregate them into a final proof sent onchain (or elsewhere) at the end of the day.
 
 ### Recursively verifying different circuits
 

barretenberg/docs/docs/how_to_guides/recursive_aggregation.md

@@ -96,7 +96,7 @@ Always keep in mind what is actually happening on your development process, othe
 
 In this case, you can imagine that Alice (running the `main` circuit) is proving something to Bob (running the `recursive` circuit), and Bob is verifying her proof within his proof.
 
-With this in mind, it becomes clear that our intermediate proof is the one *meant to be verified within another circuit*, so it must be Alice's. Actually, the only final proof in this theoretical scenario would be the last one, sent on-chain.
+With this in mind, it becomes clear that our intermediate proof is the one *meant to be verified within another circuit*, so it must be Alice's. Actually, the only final proof in this theoretical scenario would be the last one, sent onchain.
 
 :::
 

barretenberg/docs/docs/index.md

@@ -35,7 +35,7 @@ Barretenberg serves as the cryptographic backend for [Noir](https://noir-lang.or
 2. **ACIR Processing**: Barretenberg takes the ACIR instructions and converts them into a circuit representation
 3. **Witness Generation**: Based on actual input values, Barretenberg computes a witness for the circuit
 4. **Proof Generation**: Barretenberg creates a zero-knowledge proof that the computation was performed correctly
-5. **Verification**: The proof can be verified using Barretenberg's verification algorithms, including on-chain via Solidity verifiers
+5. **Verification**: The proof can be verified using Barretenberg's verification algorithms, including onchain via Solidity verifiers
 
 This integration allows Noir developers to focus on writing application logic while Barretenberg handles the complex cryptographic operations underneath.
 
@@ -51,7 +51,7 @@ The `bb` command line interface is the primary way to interact with Barretenberg
 
 - Proving and verifying circuits
 - Generating verification keys
-- Creating Solidity verifiers for on-chain verification
+- Creating Solidity verifiers for onchain verification
 - Executing and verifying recursive proofs
 
 ### bb.js
@@ -72,7 +72,7 @@ UltraHonk is an advanced proof system that offers improvements over the legacy U
 
 As the name implies, SNARKs are non-interactive, making them suitable to be verified in smart contracts. This enables applications where:
 
-1. Verification happens on-chain (ensuring trustlessness)
+1. Verification happens onchain (ensuring trustlessness)
 2. Private data remains hidden while correctness is verified
 
 Barretenberg produces Solidity smart contracts meant to be used on several EVM networks, as long as they implement the `ecMul`, `ecAdd`, `ecPairing`, and `modexp` EVM precompiles. For example:
@@ -110,7 +110,7 @@ Barretenberg is organized into several key modules:
 - **Commitment Schemes**: Polynomial commitment methods
 - **DSL (Domain Specific Language)**: Interfaces with ACIR from Noir
 - **Execution**: Witness generation and computation
-- **Verification**: Proof verification both native and on-chain
+- **Verification**: Proof verification both native and onchain
 
 ## Further Resources
 

barretenberg/docs/versioned_docs/version-v0.87.0/explainers/recursive_aggregation.md

@@ -49,7 +49,7 @@ In Zero-Knowledge, recursion has some similarities.
 
 It is not a Noir function calling itself, but a proof being used as an input to another circuit. In short, you verify one proof *inside* another proof, returning the proof that both proofs are valid.
 
-This means that, given enough computational resources, you can prove the correctness of any arbitrary number of proofs in a single proof. This could be useful to design state channels (for which a common example would be [Bitcoin's Lightning Network](https://en.wikipedia.org/wiki/Lightning_Network)), to save on gas costs by settling one proof on-chain, or simply to make business logic less dependent on a consensus mechanism.
+This means that, given enough computational resources, you can prove the correctness of any arbitrary number of proofs in a single proof. This could be useful to design state channels (for which a common example would be [Bitcoin's Lightning Network](https://en.wikipedia.org/wiki/Lightning_Network)), to save on gas costs by settling one proof onchain, or simply to make business logic less dependent on a consensus mechanism.
 
 ## Examples
 
@@ -61,9 +61,9 @@ Alice and Bob are friends, and they like guessing games. They want to play a gue
 
 So, they use zero-knowledge proofs. Alice tries to guess Bob's number, and Bob will generate a ZK proof stating whether she succeeded or failed.
 
-This ZK proof can go on a smart contract, revealing the winner and even giving prizes. However, this means every turn needs to be verified on-chain. This incurs some cost and waiting time that may simply make the game too expensive or time-consuming to be worth it.
+This ZK proof can go on a smart contract, revealing the winner and even giving prizes. However, this means every turn needs to be verified onchain. This incurs some cost and waiting time that may simply make the game too expensive or time-consuming to be worth it.
 
-As a solution, Alice proposes the following: "what if Bob generates his proof, and instead of sending it on-chain, I verify it *within* my own proof before playing my own turn?".
+As a solution, Alice proposes the following: "what if Bob generates his proof, and instead of sending it onchain, I verify it *within* my own proof before playing my own turn?".
 
 She can then generate a proof that she verified his proof, and so on.
 
@@ -143,14 +143,14 @@ In such a situation, and assuming Alice is first, she would skip the first part
 
 ### Aggregating proofs
 
-In some one-way interaction situations, recursion would allow for aggregation of simple proofs that don't need to be immediately verified on-chain or elsewhere.
+In some one-way interaction situations, recursion would allow for aggregation of simple proofs that don't need to be immediately verified onchain or elsewhere.
 
-To give a practical example, a barman wouldn't need to verify a "proof-of-age" on-chain every time he serves alcohol to a customer. Instead, the architecture would comprise two circuits:
+To give a practical example, a barman wouldn't need to verify a "proof-of-age" onchain every time he serves alcohol to a customer. Instead, the architecture would comprise two circuits:
 
 - A `main`, non-recursive circuit with some logic
 - A `recursive` circuit meant to verify two proofs in one proof
 
-The customer's proofs would be intermediate, and made on their phones, and the barman could just verify them locally. He would then aggregate them into a final proof sent on-chain (or elsewhere) at the end of the day.
+The customer's proofs would be intermediate, and made on their phones, and the barman could just verify them locally. He would then aggregate them into a final proof sent onchain (or elsewhere) at the end of the day.
 
 ### Recursively verifying different circuits
 

barretenberg/docs/versioned_docs/version-v0.87.0/how_to_guides/recursive_aggregation.md

@@ -122,7 +122,7 @@ Always keep in mind what is actually happening on your development process, othe
 
 In this case, you can imagine that Alice (running the `main` circuit) is proving something to Bob (running the `recursive` circuit), and Bob is verifying her proof within his proof.
 
-With this in mind, it becomes clear that our intermediate proof is the one *meant to be verified within another circuit*, so it must be Alice's. Actually, the only final proof in this theoretical scenario would be the last one, sent on-chain.
+With this in mind, it becomes clear that our intermediate proof is the one *meant to be verified within another circuit*, so it must be Alice's. Actually, the only final proof in this theoretical scenario would be the last one, sent onchain.
 
 :::
 

barretenberg/docs/versioned_docs/version-v0.87.0/index.md

@@ -36,7 +36,7 @@ Barretenberg serves as the cryptographic backend for [Noir](https://noir-lang.or
 2. **ACIR Processing**: Barretenberg takes the ACIR instructions and converts them into a circuit representation
 3. **Witness Generation**: Based on actual input values, Barretenberg computes a witness for the circuit
 4. **Proof Generation**: Barretenberg creates a zero-knowledge proof that the computation was performed correctly
-5. **Verification**: The proof can be verified using Barretenberg's verification algorithms, including on-chain via Solidity verifiers
+5. **Verification**: The proof can be verified using Barretenberg's verification algorithms, including onchain via Solidity verifiers
 
 This integration allows Noir developers to focus on writing application logic while Barretenberg handles the complex cryptographic operations underneath.
 
@@ -51,8 +51,8 @@ A versioning tool allowing to install arbitrary versions of Barretenberg, as wel
 The `bb` command line interface is the primary way to interact with Barretenberg directly. It provides commands for operations such as:
 
 - Proving and verifying circuits
-- Generating verification keys 
-- Creating Solidity verifiers for on-chain verification
+- Generating verification keys
+- Creating Solidity verifiers for onchain verification
 - Executing and verifying recursive proofs
 
 ### bb.js
@@ -74,7 +74,7 @@ UltraHonk is an advanced proof system that offers improvements over the legacy U
 
 As the name implies, SNARKs are non-interactive, making them suitable to be verified in smart contracts. This enables applications where:
 
-1. Verification happens on-chain (ensuring trustlessness)
+1. Verification happens onchain (ensuring trustlessness)
 2. Private data remains hidden while correctness is verified
 
 Barretenberg produces Solidity smart contracts meant to be used on several EVM networks, as long as they implement the `ecMul`, `ecAdd`, `ecPairing`, and `modexp` EVM precompiles. For example:
@@ -112,7 +112,7 @@ Barretenberg is organized into several key modules:
 - **Commitment Schemes**: Polynomial commitment methods
 - **DSL (Domain Specific Language)**: Interfaces with ACIR from Noir
 - **Execution**: Witness generation and computation
-- **Verification**: Proof verification both native and on-chain
+- **Verification**: Proof verification both native and onchain
 
 ## Further Resources
 

barretenberg/docs/versioned_docs/version-v3.0.0-nightly.20250908/explainers/recursive_aggregation.md

@@ -49,7 +49,7 @@ In Zero-Knowledge, recursion has some similarities.
 
 It is not a Noir function calling itself, but a proof being used as an input to another circuit. In short, you verify one proof *inside* another proof, returning the proof that both proofs are valid.
 
-This means that, given enough computational resources, you can prove the correctness of any arbitrary number of proofs in a single proof. This could be useful to design state channels (for which a common example would be [Bitcoin's Lightning Network](https://en.wikipedia.org/wiki/Lightning_Network)), to save on gas costs by settling one proof on-chain, or simply to make business logic less dependent on a consensus mechanism.
+This means that, given enough computational resources, you can prove the correctness of any arbitrary number of proofs in a single proof. This could be useful to design state channels (for which a common example would be [Bitcoin's Lightning Network](https://en.wikipedia.org/wiki/Lightning_Network)), to save on gas costs by settling one proof onchain, or simply to make business logic less dependent on a consensus mechanism.
 
 ## Examples
 
@@ -61,9 +61,9 @@ Alice and Bob are friends, and they like guessing games. They want to play a gue
 
 So, they use zero-knowledge proofs. Alice tries to guess Bob's number, and Bob will generate a ZK proof stating whether she succeeded or failed.
 
-This ZK proof can go on a smart contract, revealing the winner and even giving prizes. However, this means every turn needs to be verified on-chain. This incurs some cost and waiting time that may simply make the game too expensive or time-consuming to be worth it.
+This ZK proof can go on a smart contract, revealing the winner and even giving prizes. However, this means every turn needs to be verified onchain. This incurs some cost and waiting time that may simply make the game too expensive or time-consuming to be worth it.
 
-As a solution, Alice proposes the following: "what if Bob generates his proof, and instead of sending it on-chain, I verify it *within* my own proof before playing my own turn?".
+As a solution, Alice proposes the following: "what if Bob generates his proof, and instead of sending it onchain, I verify it *within* my own proof before playing my own turn?".
 
 She can then generate a proof that she verified his proof, and so on.
 
@@ -143,14 +143,14 @@ In such a situation, and assuming Alice is first, she would skip the first part
 
 ### Aggregating proofs
 
-In some one-way interaction situations, recursion would allow for aggregation of simple proofs that don't need to be immediately verified on-chain or elsewhere.
+In some one-way interaction situations, recursion would allow for aggregation of simple proofs that don't need to be immediately verified onchain or elsewhere.
 
-To give a practical example, a barman wouldn't need to verify a "proof-of-age" on-chain every time he serves alcohol to a customer. Instead, the architecture would comprise two circuits:
+To give a practical example, a barman wouldn't need to verify a "proof-of-age" onchain every time he serves alcohol to a customer. Instead, the architecture would comprise two circuits:
 
 - A `main`, non-recursive circuit with some logic
 - A `recursive` circuit meant to verify two proofs in one proof
 
-The customer's proofs would be intermediate, and made on their phones, and the barman could just verify them locally. He would then aggregate them into a final proof sent on-chain (or elsewhere) at the end of the day.
+The customer's proofs would be intermediate, and made on their phones, and the barman could just verify them locally. He would then aggregate them into a final proof sent onchain (or elsewhere) at the end of the day.
 
 ### Recursively verifying different circuits
 

barretenberg/docs/versioned_docs/version-v3.0.0-nightly.20250908/how_to_guides/recursive_aggregation.md

@@ -122,7 +122,7 @@ Always keep in mind what is actually happening on your development process, othe
 
 In this case, you can imagine that Alice (running the `main` circuit) is proving something to Bob (running the `recursive` circuit), and Bob is verifying her proof within his proof.
 
-With this in mind, it becomes clear that our intermediate proof is the one *meant to be verified within another circuit*, so it must be Alice's. Actually, the only final proof in this theoretical scenario would be the last one, sent on-chain.
+With this in mind, it becomes clear that our intermediate proof is the one *meant to be verified within another circuit*, so it must be Alice's. Actually, the only final proof in this theoretical scenario would be the last one, sent onchain.
 
 :::