chore(v3): release 3.0.1 (#19011)

This release is too large to preview in the pull request body. View the
full release notes here:
https://github.com/AztecProtocol/aztec-packages/blob/release-please--branches--v3--release-notes/release-notes.md

---------

Co-authored-by: AztecBot <tech@aztecprotocol.com>

Author: AztecBot

.release-please-manifest.json

@@ -1,3 +1,3 @@
 {
-  ".": "3.0.0"
+  ".": "3.0.1"
 }

CHANGELOG.md

@@ -0,0 +1,6 @@
+{
+    "label": "Advanced",
+    "position": 2,
+    "collapsible": true,
+    "collapsed": true
+}

barretenberg/docs/versioned_docs/version-v3.0.1/explainers/advanced/_category_.json

@@ -0,0 +1,49 @@
+---
+title: CHONK - Client-side Highly Optimized ploNK
+description: Learn about CHONK, Aztec's specialized proving system designed for client-side proving with low memory requirements and efficient recursion for private smart contract execution.
+keywords: [chonk, plonk, proving system, recursive proofs, hypernova, goblin plonk, zero knowledge, aztec, client-side proving, hyperplonk, sumcheck]
+image: https://hackmd.io/_uploads/BkpsblXEgg.jpg
+sidebar_position: 1
+---
+
+![CHONK Overview](https://hackmd.io/_uploads/BkpsblXEgg.jpg)
+
+Aztec's goal is to enable private verifiable execution of smart contracts. This motivates a proving system design where:
+
+- Proofs can be generated with relatively low memory, so that the prover can be run on a phone or browser.
+- Proofs can efficiently incorporate many layers of recursion - as the claims being proven are of a recursive nature - one contract function calls another which calls another etc.
+
+The second goal indirectly supports the first - efficient recursion goes hand in hand with low memory proving, as statements can be decomposed via recursion into smaller statements that require less prover memory.
+
+We call the proving system **CHONK - Client-side Highly Optimized ploNK**. As the name suggests, its starting point is the [PlonK proving system](https://eprint.iacr.org/2019/953).
+
+As in the original PlonK system:
+
+- It is based on elliptic curves and pairings.
+- Circuit constraints are expressed via selector polynomials and copy constraints.
+
+Its deviations from PlonK, detailed below, are motivated by the above goals.
+
+## Key Deviations from PlonK
+
+### 1. Proving statements about a sequence of circuits
+
+A statement about contract execution will translate to multiple circuits - representing the different contract functions called during the execution. Between each two of these circuits we need to run an Aztec constructed *Kernel circuit* to do "bookkeeping" - like making sure the correct arguments are passed from function to function. More details on this approach can be found in the [Aztec documentation](https://docs.aztec.network) and the [Stackproofs paper](https://eprint.iacr.org/2024/1281).
+
+### 2. Replacing univariate quotienting by sumcheck
+
+This eliminates FFT's and reduces prover time and memory at the expense of proof length. This approach is the main theme of the [hyperplonk paper](https://eprint.iacr.org/2022/1355).
+
+### 3. Using the Hypernova (HN) folding scheme
+
+Folding schemes enable cheaper recursion than standard recursive proofs. They work most smoothly with elliptic-curve based proofs systems like CHONK. We specifically work with [HyperNova](https://eprint.iacr.org/2023/573) which is convenient and efficient for folding non-uniform PlonK circuits (i.e. not a fixed repeating circuit).
+
+### 4. Enhancing HN with "Goblin plonk"
+
+Though HN (as do other folding schemes) already facilitates efficient recursion, it can still be a bit heavy client-side due to the non-native elliptic curve scalar multiplications performed by the folding verifier. For this reason, we use a "lazy" version of HN where the verifier doesn't perform these operations, but rather simply adds them to a queue of EC operations that need to be performed at the final proving stage. We call this deferral mechanism [*Goblin Plonk*](https://hackmd.io/@aztec-network/BkGNaHUJn/%2FdUsu57SOTBiQ4tS9KJMkMQ) (GP) (see also [this paper](https://eprint.iacr.org/2024/1651)).
+
+The advantage of GP is that at this final stage we transition to another elliptic curve called Grumpkin where these operations are more efficient. This curve-switch approach was initiated by [BCTV](https://eprint.iacr.org/2014/595.pdf), and a good example of it in the modern folding context is [CycleFold](https://eprint.iacr.org/2023/1192). GP is arguably simpler than CycleFold where we switch back and forth between the curves at every iteration of the IVC. The approaches are however incomparable, and for example, CycleFold has the advantage of the final IPA verifier size not growing with the number of iterations. (Although this verifier can be run server-side once for all client proofs using the [Halo](https://eprint.iacr.org/2019/1021)/[BCMS](https://eprint.iacr.org/2020/499) accumulation mechanism.)
+
+## Learn More
+
+*For a more colorful video presentation of the above check out [this talk](https://www.youtube.com/watch?v=j6wlamEPKlE).*

barretenberg/docs/versioned_docs/version-v3.0.1/explainers/advanced/chonk.md

@@ -0,0 +1,173 @@
+---
+title: Recursive proofs
+description: Explore the concept of recursive proofs in Zero-Knowledge programming. Understand how recursion works in Noir, a language for writing smart contracts on the EVM blockchain. Learn through practical examples like Alice and Bob's guessing game, Charlie's recursive merkle tree, and Daniel's reusable components. Discover how to use recursive proofs to optimize computational resources and improve efficiency.
+
+keywords:
+  [
+    "Recursive Proofs",
+    "Zero-Knowledge Programming",
+    "Noir",
+    "EVM Blockchain",
+    "Smart Contracts",
+    "Recursion in Noir",
+    "Alice and Bob Guessing Game",
+    "Recursive Merkle Tree",
+    "Reusable Components",
+    "Optimizing Computational Resources",
+    "Improving Efficiency",
+    "Verification Key",
+    "Aggregation",
+    "Recursive zkSNARK schemes",
+    "PLONK",
+    "Proving and Verification Keys"
+  ]
+---
+
+In programming, we tend to think of recursion as something calling itself. A classic example would be the calculation of the factorial of a number:
+
+```js
+function factorial(n) {
+    if (n === 0 || n === 1) {
+        return 1;
+    } else {
+        return n * factorial(n - 1);
+    }
+}
+```
+
+In this case, while `n` is not `1`, this function will keep calling itself until it hits the base case, bubbling up the result on the call stack:
+
+```md
+        Is `n` 1?  <---------
+           /\               /
+          /  \         n = n -1
+         /    \           /
+       Yes     No --------
+```
+
+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 onchain, or simply to make business logic less dependent on a consensus mechanism.
+
+## Examples
+
+Let us look at some of these examples
+
+### Alice and Bob - Guessing game
+
+Alice and Bob are friends, and they like guessing games. They want to play a guessing game online, but for that, they need a trusted third-party that knows both of their secrets and finishes the game once someone wins.
+
+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 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 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.
+
+```md
+      Did you fail?  <--------------------------
+           / \                                  /
+          /   \                             n = n -1
+         /     \                              /
+       Yes      No                           /
+        |        |                          /
+        |        |                         /
+        |      You win                    /
+        |                                /
+        |                               /
+Generate proof of that                 /
+        +                             /
+    my own guess     ----------------
+```
+
+### Charlie - Recursive merkle tree
+
+Charlie is a concerned citizen, and wants to be sure his vote in an election is accounted for. He votes with a ZK proof, but he has no way of knowing that his ZK proof was included in the total vote count!
+
+If the vote collector puts all of the votes into a [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree), everyone can prove the verification of two proofs within one proof, as such:
+
+```md
+                    abcd
+           __________|______________
+          |                         |
+         ab                         cd
+     _____|_____              ______|______
+    |           |            |             |
+  alice        bob        charlie        daniel
+```
+
+Doing this recursively allows us to arrive on a final proof `abcd` which if true, verifies the correctness of all the votes.
+
+### Daniel - Reusable components
+
+Daniel has a big circuit and a big headache. A part of his circuit is a setup phase that finishes with some assertions that need to be made. But that section alone takes most of the proving time, and is largely independent of the rest of the circuit.
+
+He might find it more efficient to generate a proof for that setup phase separately, and verify that proof recursively in the actual business logic section of his circuit. This will allow for parallelization of both proofs, which results in a considerable speedup.
+
+## What params do I need
+
+As you can see in the [recursion reference](https://noir-lang.org/docs/noir/standard_library/recursion), a simple recursive proof requires:
+
+- The proof to verify
+- The Verification Key of the circuit that generated the proof
+- The public inputs for the proof
+
+:::info
+
+Recursive zkSNARK schemes do not necessarily "verify a proof" in the sense that you expect a true or false to be spit out by the verifier. Rather an aggregation object is built over the public inputs.
+
+So, taking the example of Alice and Bob and their guessing game:
+
+- Alice makes her guess. Her proof is *not* recursive: it doesn't verify any proof within it! It's just a standard `assert(x != y)` circuit
+- Bob verifies Alice's proof and makes his own guess. In this circuit, he doesn't exactly *prove* the verification of Alice's proof. Instead, he *aggregates* his proof to Alice's proof. The actual verification is done when the full proof is verified, for example when using `nargo verify` or through the verifier smart contract.
+
+We can imagine recursive proofs a [relay race](https://en.wikipedia.org/wiki/Relay_race). The first runner doesn't have to receive the baton from anyone else, as he/she already starts with it. But when his/her turn is over, the next runner needs to receive it, run a bit more, and pass it along. Even though every runner could theoretically verify the baton mid-run (why not? 🏃🔍), only at the end of the race does the referee verify that the whole race is valid.
+
+:::
+
+## Some architecture
+
+As with everything in computer science, there's no one-size-fits all. But there are some patterns that could help understanding and implementing them. To give three examples:
+
+### Adding some logic to a proof verification
+
+This would be an approach for something like our guessing game, where proofs are sent back and forth and are verified by each opponent. This circuit would be divided in two sections:
+
+- A `recursive verification` section, which would be just the call to `std::verify_proof`, and that would be skipped on the first move (since there's no proof to verify)
+- A `guessing` section, which is basically the logic part where the actual guessing happens
+
+In such a situation, and assuming Alice is first, she would skip the first part and try to guess Bob's number. Bob would then verify her proof on the first section of his run, and try to guess Alice's number on the second part, and so on.
+
+### Aggregating proofs
+
+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" 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 onchain (or elsewhere) at the end of the day.
+
+### Recursively verifying different circuits
+
+Nothing prevents you from verifying different circuits in a recursive proof, for example:
+
+- A `circuit1` circuit
+- A `circuit2` circuit
+- A `recursive` circuit
+
+In this example, a regulator could verify that taxes were paid for a specific purchase by aggregating both a `payer` circuit (proving that a purchase was made and taxes were paid), and a `receipt` circuit (proving that the payment was received)
+
+## How fast is it
+
+At the time of writing, verifying recursive proofs is surprisingly fast. This is because most of the time is spent on generating the verification key that will be used to generate the next proof. So you are able to cache the verification key and reuse it later.
+
+Currently, Noir JS packages don't expose the functionality of loading proving and verification keys, but that feature exists in the underlying `bb.js` package.
+
+## How can I try it
+
+Learn more about using recursion in Nargo and NoirJS in the [how-to guide](../how_to_guides/recursive_aggregation.md) and see a full example in [noir-examples](https://github.com/noir-lang/noir-examples).

barretenberg/docs/versioned_docs/version-v3.0.1/explainers/recursive_aggregation.md

@@ -0,0 +1,56 @@
+---
+title: Getting Started
+hide_title: true
+description: Barretenberg is a high-performance zero-knowledge proof system implementation written in C++. It serves as the cryptographic engine powering Aztec's privacy-focused blockchain solutions. The system includes efficient implementations of key cryptographic primitives, constraint system construction, and proof generation optimized for modern hardware.
+keywords:
+    [zero-knowledge proofs, ZK proofs, cryptography, blockchain, privacy, Aztec, C++, PLONK, arithmetic circuits, constraint systems, elliptic curves, performance optimization, zkSNARKs, zero-knowledge]
+sidebar_position: 1
+---
+
+# Barretenberg
+
+Barretenberg (or `bb` for short) is an optimized elliptic curve library for the bn128 curve, and a PLONK SNARK prover.
+
+Although it is a standandalone prover, Barretenberg is designed to be used with [Noir](https://noir-lang.org). It is highly recommended to start by creating a Noir project with the [Noir guickstart guide](https://noir-lang.org/docs/getting_started/quick_start) before this guide!
+
+## Installation
+
+Inspired by `rustup`, `noirup` and similar tools, you can use the `bbup` installation script to quickly install and update Barretenberg's CLI tool:
+
+```bash
+curl -L https://raw.githubusercontent.com/AztecProtocol/aztec-packages/refs/heads/next/barretenberg/bbup/install | bash
+bbup
+```
+
+Following these prompts, you should be able to see `bb` binary in `$HOME/.bb/bb`.
+
+## Usage
+
+Assuming you have a Noir project, you can use `bb` straight-away to prove by giving it the compiled circuit and the witness (the outputs of `nargo execute`). Since we want to verify the proof later, we also want to write the verification key to a file. Let's do it:
+
+```bash
+bb prove -b ./target/hello_world.json -w ./target/hello_world.gz --write_vk -o target
+```
+
+This will prove your program and write both a `proof` and a `vk` file to the `target` folder. To verify the proof, you don't need the witness (that would defeat the purpose, wouldn't it?), just the proof and the `vk`:
+
+```bash
+bb verify -p ./target/proof -k ./target/vk
+```
+
+Congratulations! Using Noir and Barretenberg, your verifier could verify the correctness of a proof, without knowing the private inputs!
+
+:::info
+
+You may be asking yourself what happened to the **public inputs**? Barretenberg proofs usually append them to the beginning of the proof. This may or may not be useful, and the next guides will provide you with handy commands to split the proof and the public inputs whenever needed
+
+:::
+
+## Next steps
+
+As cool as it is, proving and verifying on the same machine is not incredibly useful. You may want to do things like:
+
+- Generating programs that verify proofs in immutable, decentralized ledgers like blockchains
+- Verifying proofs within other proofs
+
+Check out those specific guides in the sidebar.

barretenberg/docs/versioned_docs/version-v3.0.1/getting_started.md

@@ -0,0 +1,6 @@
+{
+    "label": "How to Guides",
+    "position": 2,
+    "collapsible": true,
+    "collapsed": true
+}