diff --git a/docs/versioned_docs/version-v1.0.0-beta.2/getting_started/quick_start.md b/docs/versioned_docs/version-v1.0.0-beta.2/getting_started/quick_start.md index 7b4524f6b8e..377e774aeb4 100644 --- a/docs/versioned_docs/version-v1.0.0-beta.2/getting_started/quick_start.md +++ b/docs/versioned_docs/version-v1.0.0-beta.2/getting_started/quick_start.md @@ -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 @@ -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. diff --git a/docs/versioned_docs/version-v1.0.0-beta.2/how_to/how-to-solidity-verifier.mdx b/docs/versioned_docs/version-v1.0.0-beta.2/how_to/how-to-solidity-verifier.mdx index c8c7894ff91..1fe3c00fe58 100644 --- a/docs/versioned_docs/version-v1.0.0-beta.2/how_to/how-to-solidity-verifier.mdx +++ b/docs/versioned_docs/version-v1.0.0-beta.2/how_to/how-to-solidity-verifier.mdx @@ -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: - - - ```sh -bb write_vk_ultra_keccak_honk -b ./target/.json -bb contract_ultra_honk -``` - - - +# 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/.json -o ./target --oracle_hash keccak -```sh -bb write_vk -b ./target/.json -bb contract +# Generate the Solidity verifier from the vkey +bb write_solidity_verifier -k ./target/vk -o ../target/Verifier.sol ``` - - - replacing `` 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). @@ -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": - - - ![Deploying HonkVerifier](@site/static/img/how-tos/solidity_verifier_7.png) - - - -![Deploying PlonkVerifier](@site/static/img/how-tos/solidity_verifier_9.png) - - - - A contract will show up in the "Deployed Contracts" section. ## Step 4 - Verifying @@ -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: - - - ```bash nargo execute -bb prove_ultra_keccak_honk -b ./target/.json -w ./target/ -o ./target/proof +bb prove -b ./target/.json -w ./target/ -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. - -::: - - - +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 -bb prove -b ./target/.json -w ./target/ -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. ::: - - - -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 diff --git a/docs/versioned_docs/version-v1.0.0-beta.3/getting_started/quick_start.md b/docs/versioned_docs/version-v1.0.0-beta.3/getting_started/quick_start.md index 7b4524f6b8e..377e774aeb4 100644 --- a/docs/versioned_docs/version-v1.0.0-beta.3/getting_started/quick_start.md +++ b/docs/versioned_docs/version-v1.0.0-beta.3/getting_started/quick_start.md @@ -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 @@ -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. diff --git a/docs/versioned_docs/version-v1.0.0-beta.3/how_to/how-to-solidity-verifier.mdx b/docs/versioned_docs/version-v1.0.0-beta.3/how_to/how-to-solidity-verifier.mdx index c8c7894ff91..1fe3c00fe58 100644 --- a/docs/versioned_docs/version-v1.0.0-beta.3/how_to/how-to-solidity-verifier.mdx +++ b/docs/versioned_docs/version-v1.0.0-beta.3/how_to/how-to-solidity-verifier.mdx @@ -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: - - - ```sh -bb write_vk_ultra_keccak_honk -b ./target/.json -bb contract_ultra_honk -``` - - - +# 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/.json -o ./target --oracle_hash keccak -```sh -bb write_vk -b ./target/.json -bb contract +# Generate the Solidity verifier from the vkey +bb write_solidity_verifier -k ./target/vk -o ../target/Verifier.sol ``` - - - replacing `` 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). @@ -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": - - - ![Deploying HonkVerifier](@site/static/img/how-tos/solidity_verifier_7.png) - - - -![Deploying PlonkVerifier](@site/static/img/how-tos/solidity_verifier_9.png) - - - - A contract will show up in the "Deployed Contracts" section. ## Step 4 - Verifying @@ -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: - - - ```bash nargo execute -bb prove_ultra_keccak_honk -b ./target/.json -w ./target/ -o ./target/proof +bb prove -b ./target/.json -w ./target/ -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. - -::: - - - +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 -bb prove -b ./target/.json -w ./target/ -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. ::: - - - -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