Nargo proofs should be specified in the Nargo.toml

[phated]

Problem

Currently, creating multiple proofs with different inputs requires changing the Prover.toml file or creating many files and using the --prover-name flag. The latter leads to a proliferation of toml files in a project.

Instead of separate toml files, we should think about "proofs" the same way that cargo thinks about "examples" in that you specify zero or more [[examples]] in your Cargo.toml and you can run a specific example with cargo run --example [NAME]. We should allow zero or more [[proofs]] to be specified in the Nargo.toml and then allow --proof on the appropriate commands to select one proof by name.

The above also pairs nicely with workspaces, such that you could do nargo prove --package foobar --proof first-proof without needing to worry about resolving a filepath from inside a workspace package.

Happy Case

Proofs are specified in the Nargo.toml, reducing proliferation of toml files in projects.

Alternatives Considered

We also considered taking proof data from stdin, but that doesn't work well with the concept of workspaces.

And we considered an interactive session to take inputs, but that doesn't fit with the mental model of these being examples with inputs that the user might not have easily (e.g. the result of some hashing function).

Additional Context

No response

Would you like to submit a PR for this Issue?

Yes

Support Needs

No response

[kevaundray]

I don't really understand this sentence "Proofs are specified in the Nargo.toml," -- from the rest of the paragraph, I think this means that the inputs to a Noir program should now be specified in the Nargo.toml with a particular name for each group of inputs.

• Perhaps you could show a pseudo structure and pseudo Nargo.toml to help me understand?
• Can you speak to how this idea meshes with adding the ability for users to provide inputs to a Noir program via the CLI?

[Savio-Sou]

I think this means that the inputs to a Noir program should now be specified in the Nargo.toml
That'd be my interpretation as well.

Assigning P-LOW for now as this seems to be a file structuring nice to have that is not blocking any works.

Guessing E-LOW.