Skip to main content
Version: 0.7.1 / 0.8.0

Project Breakdown

This section breaks down our hello world program in section 1.2. We elaborate on the project structure and what the prove and verify commands did in the previous section.

Anatomy of a Nargo Project

Upon creating a new project with nargo new and building the in/output files with nargo check commands, you would get a minimal Nargo project of the following structure:

- src
- Prover.toml
- Verifier.toml
- Nargo.toml

The source directory src holds the source code for your Noir program. By default only a main.nr file will be generated within it.

Prover.toml is used for specifying the input values for executing and proving the program. You can specify toml files with different names by using the --prover-name or -p flags, see the Prover section below. Optionally you may specify expected output values for prove-time checking as well.

Verifier.toml contains public in/output values computed when executing the Noir program.

Nargo.toml contains the environmental options of your project.

proofs and contract directories will not be immediately visible until you create a proof or verifier contract respectively.

main.nr

The main.nr file contains a main method, this method is the entry point into your Noir program.

In our sample program, main.nr looks like this:

fn main(x : Field, y : Field) {
assert(x != y);
}

The parameters x and y can be seen as the API for the program and must be supplied by the prover. Since neither x nor y is marked as public, the verifier does not supply any inputs, when verifying the proof.

The prover supplies the values for x and y in the Prover.toml file.

As for the program body, assert ensures the satisfaction of the condition (e.g. x != y) is constrained by the proof of the execution of said program (i.e. if the condition was not met, the verifier would reject the proof as an invalid proof).

Prover.toml

The Prover.toml file is a file which the prover uses to supply his witness values(both private and public).

In our hello world program the Prover.toml file looks like this:

x = "1"
y = "2"

When the command nargo prove my_proof is executed, two processes happen:

  1. Noir creates a proof that x which holds the value of 1 and y which holds the value of 2 is not equal. This not equal constraint is due to the line assert(x != y).

  2. Noir creates and stores the proof of this statement in the proofs directory and names the proof file my_proof. Opening this file will display the proof in hex format.

Custom toml files

You can specify a toml file with a different name to use for proving by using the --prover-name or -p flags.

This command looks for proof inputs in the default Prover.toml and generates proof p:

nargo prove p

This command looks for proof inputs in the custom OtherProver.toml and generates proof pp:

nargo prove -p OtherProver pp 

Verifying a Proof

When the command nargo verify my_proof is executed, two processes happen:

  1. Noir checks in the proofs directory for a file called my_proof

  2. If that file is found, the proof's validity is checked

Note: The validity of the proof is linked to the current Noir program; if the program is changed and the verifier verifies the proof, it will fail because the proof is not valid for the modified Noir program.

In production, the prover and the verifier are usually two separate entities. A prover would retrieve the necessary inputs, execute the Noir program, generate a proof and pass it to the verifier. The verifier would then retrieve the public inputs from usually external sources and verifies the validity of the proof against it.

Take a private asset transfer as an example:

A user on browser as the prover would retrieve private inputs (e.g. the user's private key) and public inputs (e.g. the user's encrypted balance on-chain), compute the transfer, generate a proof and submit it to the verifier smart contract.

The verifier contract would then draw the user's encrypted balance directly from the blockchain and verify the proof submitted against it. If the verification passes, additional functions in the verifier contract could trigger (e.g. approve the asset transfer).

Now that you understand the concepts, you'll probably want some editor feedback while you are writing more complex code.

In the next section, we will explain how to utilize the Noir Language Server.