Epic: Rescope Nargo & NoirJS to exclude proving/verification/contract codegen

[TomAFrench]

Nargo is currently the "everything-box" for working with Noir. You can install various proving backends, generate proofs in a single command, verify these, generate smart contract verifiers, etc. This has a few downsides:

• Once we take on most of the Noir workflow there's an expectation that we handle all of it. These leads to expectations such as
  • Handling inconsistencies with backends and external tools to solve QOL issues such as Place verifier contract to contracts folder instead of contract #1009, Add option to specify output directory path when running nargo codegen-verifier  #4476, When executing codegen-verifier, the name used for the generated Solidity contracts is currently fixed #4477
  • creating a "one-click" solution for generating recursive proof artifacts: Add #[recursive] proof artifact generation to nargo prove #4336
• As nargo is at once the compiler and proving interface, this pushes us towards a "source-code first" workflow where nargo verify will compile a circuit from scratch rather than just working on a verification key and a proof. Why should I need the original source code to verify a proof?

All this while providing a generic interface which can handle the peculiarities of many different proving backends.

Ideally Noir/Nargo should:

• Specify the ACIR standard.
• Specify a standard structure of a Noir project (so backends can make reasonable defaults for where to look for compiled artifacts)
• Compile Noir source code down to artifacts compliant with these two standards.
• Provide tools for execution/testing/debugging of Noir source code.

As part of the tasks set out below we should:

• Ensure that the equivalent bb workflow works
• Make any necessary changes to bb such that the UX is still high.
• Add an equivalent test in CI using the bb workflow as an example

Write a spec for ACIR backends to specify handling of

Beta Give feedback

1. ACIR Program artifacts

Nargo

Beta Give feedback

1. Remove nargo codegen_verifier command
2. Remove nargo verify command
3. Remove nargo prove command
4. Remove nargo info command #4962
   +0
   
5. Create replacement for nargo info to allow generation of reports similar to now.
6. Remove nargo backend command
7. Add default expression-width field to Nargo.toml #4961
   +0
   

NoirJS

Beta Give feedback

1. Remove concept of backends from noir_js
2. Push noir_js_backend_barretenberg into bb.js #5079
   backend enhancement js +3

Barretenberg feature parity tasks

Beta Give feedback

1. feat!: switch bb over to read ACIR from nargo artifacts AztecProtocol/aztec-packages#6283
   +0
   
2. chore!: remove backend interactions from nargo AztecProtocol/aztec-packages#6320
   +0
3. chore!: remove nargo prove and nargo verify AztecProtocol/aztec-packages#6321
   +0

[Savio-Sou]

From AztecProtocol/aztec-packages#6320 (comment):

we should also expect that users should install their proving backend of choice rather than nargo acting as an installer for bb

@TomAFrench we shouldn't go that far as to remove default proving backend installation if that was what you were considering. That drives up onboarding frictions and support requests, with arguably little benefit in simplifying Noir 1.0's audit.

[TomAFrench]

Nargo is not going to be speaking to barretenberg and so there's no reason for it to install bb

[TomAFrench]

If we want bb to be a user facing component then it needs to have its own install method.

[Savio-Sou]

Oh I didn't mean Nargo specifically.

Goal is to preserve our current DevEx where users could get started / updated with 1 command.
If e.g. noirup automatically fetches the right version of bb that's a win.

[TomAFrench]

noirup is installation tooling for Nargo so it shouldn't install bb

[Savio-Sou]

Is there a good way to avoid / warn about nargo and bb version mismatches if they aren't pre-matched and installed as a batch?

[charlielye]

Is there a good way to avoid / warn about nargo and bb version mismatches if they aren't pre-matched and installed as a batch?

The output artefacts of nargo could have a "backend api" version number associated with them.
If nargo bumps this number, it should bump it's major version number (breaking change), as it's changing the artefacts that it outputs such that they become incompatible with consumers of those artefacts.
bb can detect the mismatch and ask the user to upgrade, (knowing an upgrade will exist as there should always be a compatible bb). This bb release would also have a bumped major version number, as it's a breaking change regarding the artefacts it consumes.

In this model, noirs docs (which I think should at least give the 1-liner to install a compatible version of bb) can always provide, e.g. knowing compatibility with major version 3:

npm install --global bb.js@3

Also, I'm not totally against e.g. the noirup script offering to run the 1-liner or whatever is needed to upgrade a detected incompatible backend. As long as it's just scoped to a bit of bash in order to simplify...

[Savio-Sou]

"backend api" version number

Including an ACIR version in Noir artifacts should do the trick 👍

[TomAFrench]

I'm going to close this epic and break out any remaining issues to be standalone or under a new documentation epic.

[Savio-Sou]

@TomAFrench SGTM 👍 would be great if you could remove unresolved Issues from the Epic body while recreating them separately for more accurate communications 🙌