Skip to content

chore: update bb commands in beta2 and beta3 versioned docs #7888

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
TomAFrench merged 1 commit into from
Apr 2, 2025
Merged

chore: update bb commands in beta2 and beta3 versioned docs #7888

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 5 additions & 14 deletions docs/versioned_docs/version-v1.0.0-beta.2/getting_started/quick_start.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -94,7 +94,7 @@ With circuit compiled and witness generated, we're ready to prove.
Different proving backends may provide different tools and commands to work with Noir programs. Here Barretenberg's `bb` CLI tool is used as an example:

```sh
bb prove -b ./target/hello_world.json -w ./target/hello_world.gz -o ./target/proof
bb prove -b ./target/hello_world.json -w ./target/hello_world.gz -o ./target
```

:::tip
Expand All @@ -106,22 +106,13 @@ Naming can be confusing, specially as you pass them to the `bb` commands. If uns
The proof is now generated in the `target` folder. To verify it we first need to compute the verification key from the compiled circuit, and use it to verify:

```sh
bb write_vk -b ./target/hello_world.json -o ./target/vk
bb verify -k ./target/vk -p ./target/proof
```

:::info

Notice that in order to verify a proof, the verifier knows nothing but the circuit, which is compiled and used to generate the verification key. This is obviously quite important: private inputs remain private.

As for the public inputs, you may have noticed they haven't been specified. This behavior varies with each particular backend, but barretenberg typically attaches them to the proof. You can see them by parsing and splitting it. For example if your public inputs are 32 bytes:
# Generate the verification key and save to ./target/vk
bb write_vk -b ./target/hello_world.json -o ./target

```bash
head -c 32 ./target/proof | od -An -v -t x1 | tr -d $' \n'
# Verify the proof
bb verify -k ./target/vk -p ./target/proof
```

:::

Congratulations, you have now created and verified a proof for your very first Noir program!

In the [next section](./project_breakdown.md), we will go into more detail on each step performed.
71 changes: 15 additions & 56 deletions docs/versioned_docs/version-v1.0.0-beta.2/how_to/how-to-solidity-verifier.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,25 +61,15 @@ nargo compile

This will compile your source code into a Noir build artifact to be stored in the `./target` directory. From here on, it's Barretenberg's work. You can generate the smart contract using the commands:

<Tabs>
<TabItem value="UltraHonk">

```sh
bb write_vk_ultra_keccak_honk -b ./target/<noir_artifact_name>.json
bb contract_ultra_honk
```

</TabItem>
<TabItem value="UltraPlonk">
# Generate the verification key. You need to pass the `--oracle_hash keccak` flag when generating vkey and proving
# to instruct bb to use keccak as the hash function, which is more optimal in Solidity
bb write_vk -b ./target/<noir_artifact_name>.json -o ./target --oracle_hash keccak

```sh
bb write_vk -b ./target/<noir_artifact_name>.json
bb contract
# Generate the Solidity verifier from the vkey
bb write_solidity_verifier -k ./target/vk -o ../target/Verifier.sol
```

</TabItem>
</Tabs>

replacing `<noir_artifact_name>` with the name of your Noir project. A `Verifier.sol` contract is now in the target folder and can be deployed to any EVM blockchain acting as a verifier smart contract.

You can find more information about `bb` and the default Noir proving backend on [this page](../getting_started/quick_start.md#proving-backend).
Expand Down Expand Up @@ -119,19 +109,8 @@ At this point we should have a compiled contract ready to deploy. If we navigate

Looking closely, we will notice that our "Solidity Verifier" is composed on multiple contracts working together. Remix will take care of the dependencies for us so we can simply deploy the Verifier contract by selecting it and hitting "deploy":

<Tabs>
<TabItem value="UltraHonk">

![Deploying HonkVerifier](@site/static/img/how-tos/solidity_verifier_7.png)

</TabItem>
<TabItem value="UltraPlonk">

![Deploying PlonkVerifier](@site/static/img/how-tos/solidity_verifier_9.png)

</TabItem>
</Tabs>

A contract will show up in the "Deployed Contracts" section.

## Step 4 - Verifying
Expand All @@ -150,50 +129,30 @@ nargo check

This will generate a `Prover.toml` you can fill with the values you want to prove. We can now execute the circuit with `nargo` and then use the proving backend to prove:

<Tabs>
<TabItem value="UltraHonk">

```bash
nargo execute <witness-name>
bb prove_ultra_keccak_honk -b ./target/<circuit-name>.json -w ./target/<witness-name> -o ./target/proof
bb prove -b ./target/<circuit-name>.json -w ./target/<witness-name> -o ./target --oracle_hash keccak
```

:::tip[Public inputs]
Barretenberg attaches the public inputs to the proof, which in this case it's not very useful. If you're up for some JS, `bb.js` has [a method for it](https://github.com/AztecProtocol/aztec-packages/blob/master/barretenberg/ts/src/proof/index.ts), but in the CLI you can use this ugly snippet:

```bash
cat ./target/proof | od -An -v -t x1 | tr -d $' \n' | sed 's/^.\{8\}//' | (read hex; echo "${hex:0:192}${hex:256}")
```

Beautiful. This assumes a circuit with one public input (32 bytes, for Barretenberg). For more inputs, you can just increment `hex:256` with 32 more bytes for each public input.

:::

</TabItem>
<TabItem value="UltraPlonk">
Barretenberg attaches the public inputs to the proof, which in this case it's not very useful. If you're up for some JS, `bb.js` has [a method for it](https://github.com/AztecProtocol/aztec-packages/blob/master/barretenberg/ts/src/proof/index.ts), but in the CLI you can use this ugly snippet for now:

```bash
nargo execute <witness-name>
bb prove -b ./target/<circuit-name>.json -w ./target/<witness-name> -o ./target/proof
```
PROOF_HEX=$(cat ./target/proof | od -An -v -t x1 | tr -d $' \n' | sed 's/^.\{8\}//')

NUM_PUBLIC_INPUTS=2
HEX_PUBLIC_INPUTS=${PROOF_HEX:192:$((32 * $NUM_PUBLIC_INPUTS * 2))}
SPLIT_HEX_PUBLIC_INPUTS=$(sed -e 's/.\{64\}/0x&,/g' <<<$HEX_PUBLIC_INPUTS)

:::tip[Public inputs]
Barretenberg attaches the public inputs to the proof, which in this case it's not very useful. If you're up for some JS, `bb.js` has [a method for it](https://github.com/AztecProtocol/aztec-packages/blob/master/barretenberg/ts/src/proof/index.ts), but in the CLI you can use this ugly snippet:
PROOF_WITHOUT_PUBLIC_INPUTS="${PROOF_HEX:0:192}${PROOF_HEX:$((192 + $NUM_PUBLIC_INPUTS * 32 * 2))}"

```bash
tail -c +33 ./target/proof | od -An -v -t x1 | tr -d $' \n'
echo 0x$PROOF_WITHOUT_PUBLIC_INPUTS
echo [$SPLIT_HEX_PUBLIC_INPUTS]
```

Beautiful. This assumes a circuit with one public input (32 bytes, for Barretenberg). For more inputs, you can just add 32 more bytes for each public input to the `tail` command.
You can pass the proof and public inputs from above to the `verify` function in Remix.

:::

</TabItem>
</Tabs>

Remix expects that the public inputs will be split into an array of `bytes32` values so `HEX_PUBLIC_INPUTS` needs to be split up into 32 byte chunks which are prefixed with `0x` accordingly.

A programmatic example of how the `verify` function is called can be seen in the example zk voting application [here](https://github.com/noir-lang/noir-examples/blob/33e598c257e2402ea3a6b68dd4c5ad492bce1b0a/foundry-voting/src/zkVote.sol#L35):

```solidity
Expand Down
19 changes: 5 additions & 14 deletions docs/versioned_docs/version-v1.0.0-beta.3/getting_started/quick_start.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -94,7 +94,7 @@ With circuit compiled and witness generated, we're ready to prove.
Different proving backends may provide different tools and commands to work with Noir programs. Here Barretenberg's `bb` CLI tool is used as an example:

```sh
bb prove -b ./target/hello_world.json -w ./target/hello_world.gz -o ./target/proof
bb prove -b ./target/hello_world.json -w ./target/hello_world.gz -o ./target
```

:::tip
Expand All @@ -106,22 +106,13 @@ Naming can be confusing, specially as you pass them to the `bb` commands. If uns
The proof is now generated in the `target` folder. To verify it we first need to compute the verification key from the compiled circuit, and use it to verify:

```sh
bb write_vk -b ./target/hello_world.json -o ./target/vk
bb verify -k ./target/vk -p ./target/proof
```

:::info

Notice that in order to verify a proof, the verifier knows nothing but the circuit, which is compiled and used to generate the verification key. This is obviously quite important: private inputs remain private.

As for the public inputs, you may have noticed they haven't been specified. This behavior varies with each particular backend, but barretenberg typically attaches them to the proof. You can see them by parsing and splitting it. For example if your public inputs are 32 bytes:
# Generate the verification key and save to ./target/vk
bb write_vk -b ./target/hello_world.json -o ./target

```bash
head -c 32 ./target/proof | od -An -v -t x1 | tr -d $' \n'
# Verify the proof
bb verify -k ./target/vk -p ./target/proof
```

:::

Congratulations, you have now created and verified a proof for your very first Noir program!

In the [next section](./project_breakdown.md), we will go into more detail on each step performed.
71 changes: 15 additions & 56 deletions docs/versioned_docs/version-v1.0.0-beta.3/how_to/how-to-solidity-verifier.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,25 +61,15 @@ nargo compile

This will compile your source code into a Noir build artifact to be stored in the `./target` directory. From here on, it's Barretenberg's work. You can generate the smart contract using the commands:

<Tabs>
<TabItem value="UltraHonk">

```sh
bb write_vk_ultra_keccak_honk -b ./target/<noir_artifact_name>.json
bb contract_ultra_honk
```

</TabItem>
<TabItem value="UltraPlonk">
# Generate the verification key. You need to pass the `--oracle_hash keccak` flag when generating vkey and proving
# to instruct bb to use keccak as the hash function, which is more optimal in Solidity
bb write_vk -b ./target/<noir_artifact_name>.json -o ./target --oracle_hash keccak

```sh
bb write_vk -b ./target/<noir_artifact_name>.json
bb contract
# Generate the Solidity verifier from the vkey
bb write_solidity_verifier -k ./target/vk -o ../target/Verifier.sol
```

</TabItem>
</Tabs>

replacing `<noir_artifact_name>` with the name of your Noir project. A `Verifier.sol` contract is now in the target folder and can be deployed to any EVM blockchain acting as a verifier smart contract.

You can find more information about `bb` and the default Noir proving backend on [this page](../getting_started/quick_start.md#proving-backend).
Expand Down Expand Up @@ -119,19 +109,8 @@ At this point we should have a compiled contract ready to deploy. If we navigate

Looking closely, we will notice that our "Solidity Verifier" is composed on multiple contracts working together. Remix will take care of the dependencies for us so we can simply deploy the Verifier contract by selecting it and hitting "deploy":

<Tabs>
<TabItem value="UltraHonk">

![Deploying HonkVerifier](@site/static/img/how-tos/solidity_verifier_7.png)

</TabItem>
<TabItem value="UltraPlonk">

![Deploying PlonkVerifier](@site/static/img/how-tos/solidity_verifier_9.png)

</TabItem>
</Tabs>

A contract will show up in the "Deployed Contracts" section.

## Step 4 - Verifying
Expand All @@ -150,50 +129,30 @@ nargo check

This will generate a `Prover.toml` you can fill with the values you want to prove. We can now execute the circuit with `nargo` and then use the proving backend to prove:

<Tabs>
<TabItem value="UltraHonk">

```bash
nargo execute <witness-name>
bb prove_ultra_keccak_honk -b ./target/<circuit-name>.json -w ./target/<witness-name> -o ./target/proof
bb prove -b ./target/<circuit-name>.json -w ./target/<witness-name> -o ./target --oracle_hash keccak
```

:::tip[Public inputs]
Barretenberg attaches the public inputs to the proof, which in this case it's not very useful. If you're up for some JS, `bb.js` has [a method for it](https://github.com/AztecProtocol/aztec-packages/blob/master/barretenberg/ts/src/proof/index.ts), but in the CLI you can use this ugly snippet:

```bash
cat ./target/proof | od -An -v -t x1 | tr -d $' \n' | sed 's/^.\{8\}//' | (read hex; echo "${hex:0:192}${hex:256}")
```

Beautiful. This assumes a circuit with one public input (32 bytes, for Barretenberg). For more inputs, you can just increment `hex:256` with 32 more bytes for each public input.

:::

</TabItem>
<TabItem value="UltraPlonk">
Barretenberg attaches the public inputs to the proof, which in this case it's not very useful. If you're up for some JS, `bb.js` has [a method for it](https://github.com/AztecProtocol/aztec-packages/blob/master/barretenberg/ts/src/proof/index.ts), but in the CLI you can use this ugly snippet for now:

```bash
nargo execute <witness-name>
bb prove -b ./target/<circuit-name>.json -w ./target/<witness-name> -o ./target/proof
```
PROOF_HEX=$(cat ./target/proof | od -An -v -t x1 | tr -d $' \n' | sed 's/^.\{8\}//')

NUM_PUBLIC_INPUTS=2
HEX_PUBLIC_INPUTS=${PROOF_HEX:192:$((32 * $NUM_PUBLIC_INPUTS * 2))}
SPLIT_HEX_PUBLIC_INPUTS=$(sed -e 's/.\{64\}/0x&,/g' <<<$HEX_PUBLIC_INPUTS)

:::tip[Public inputs]
Barretenberg attaches the public inputs to the proof, which in this case it's not very useful. If you're up for some JS, `bb.js` has [a method for it](https://github.com/AztecProtocol/aztec-packages/blob/master/barretenberg/ts/src/proof/index.ts), but in the CLI you can use this ugly snippet:
PROOF_WITHOUT_PUBLIC_INPUTS="${PROOF_HEX:0:192}${PROOF_HEX:$((192 + $NUM_PUBLIC_INPUTS * 32 * 2))}"

```bash
tail -c +33 ./target/proof | od -An -v -t x1 | tr -d $' \n'
echo 0x$PROOF_WITHOUT_PUBLIC_INPUTS
echo [$SPLIT_HEX_PUBLIC_INPUTS]
```

Beautiful. This assumes a circuit with one public input (32 bytes, for Barretenberg). For more inputs, you can just add 32 more bytes for each public input to the `tail` command.
You can pass the proof and public inputs from above to the `verify` function in Remix.

:::

</TabItem>
</Tabs>

Remix expects that the public inputs will be split into an array of `bytes32` values so `HEX_PUBLIC_INPUTS` needs to be split up into 32 byte chunks which are prefixed with `0x` accordingly.

A programmatic example of how the `verify` function is called can be seen in the example zk voting application [here](https://github.com/noir-lang/noir-examples/blob/33e598c257e2402ea3a6b68dd4c5ad492bce1b0a/foundry-voting/src/zkVote.sol#L35):

```solidity
Expand Down
Loading