chore!: remove backend interactions from nargo

[TomAFrench]

This PR removes the nargo codegen-verifier command and replaces it with an example bash script showing how to use nargo in conjunction with bb to generate a smart contract verifier.

cc @AztecProtocol/devrel

Closes noir-lang/noir#4447
Closes noir-lang/noir#1138
Closes noir-lang/noir#2222
Closes noir-lang/noir#1159
Closes noir-lang/noir#1009
Closes noir-lang/noir#3837
Closes noir-lang/noir#2667

[signorecello]

Reached out on slack, this will make 90% of Noir devs install a new package (+node if they don't have it already). Let's see if we can find a middle ground solution 👍

[TomAFrench]

As discussed on slack, the solution is for us to have good interop between nargo artifacts and bb as done in #6283, we should also expect that users should install their proving backend of choice rather than nargo acting as an installer for bb.

[TomAFrench]

Note that the UX from this change goes from

nargo codegen-verifier

to

nargo compile
bb write_vk -b ./target/hello_world.json
bb contract -v ./target/vk

which after some UX changes to bb could become

nargo compile
bb contract

[Savio-Sou]

which after some UX changes to bb could become

nargo compile
bb contract

This nargo codegen-verifier PR should aim for this as the goal rather than something in between.

A requirement to noir-lang/noir#4960 is we do our best attempts at minimizing additional DevEx frictions coming out of it. If that means more engineering time, we allocate the time 🤝

[TomAFrench]

Happy to discuss audit timelines if we're taking Noir development resources to rewrite all of Noir's workspace logic in C++.

[Savio-Sou]

Good point.

To clarify I was thinking of an aim to add default behaviors (if they don't already exist):

1. Update bb write_vk (flagless) to operate on ./target/main.json by default
2. Update bb contract (flagless) to operate on ./target/vk by default
3. Update bb contract (flagless) to call bb write_vk (flagless) automatically if ./target/vk doesn't already exist

While maintaining flag options for users that need them to operate on multiple / renamed files.

---

I don't think there are a lot of user demand for:

• Generate multiple Solidity verifiers
• For multiple Noir programs
• Within one single workspace

at least not today (@AztecProtocol/devrel to confirm).

On that assumption, offering a reference bash script and kicking the bb workspace can down the road until we see growing demand is acceptable.

[signorecello]

I do lack full context on the end goal here, but I understand there is a significant engineering reason for burning this nargo-bb bridge. So I won't say we shouldn't do it, but I do care about the devex since that's the biggest Noir strength.

For context, every single Noir workshop we do starts with generating a proof and a smart contract, and verifying it on Remix IDE. Literally every one of the 60+ Noir submissions at the Scroll hackathon generated a smart contract with Nargo.

Downgrading the devex introducing more packages and commands to something so ubiquitous seems like something we want to avoid, if possible.

I proposed a solution, which I reckon is not ideal: to have DevRel maintain a CLI tool that that could encapsulate Nargo and BB, essentially delivering the same execution + proving devex. I told @critesjosh I could take on that task, but I think it's worth exploring if there's any other way

[TomAFrench]

I proposed a solution, which I reckon is not ideal: to have DevRel maintain a CLI tool that that could encapsulate Nargo and BB, essentially delivering the same execution + proving devex. I told @critesjosh I could take on that task, but I think it's worth exploring if there's any other way

This is going to be way more work than I think you're intending to take on. On top of that, unless we're fully deprecating nargo as a user-facing component (which we aren't) we've just backed ourselves into needing to support two separate tools instead of one.

[Savio-Sou]

@signorecello we surely don't want to build and maintain a new wrapper. That would undermine the whole point of noir-lang/noir#4960 for cleaner engineering scope (hence simpler auditing) and improved DevEd (hence DevEx).

DevEx: aiming for net positive

The initiative aims at cleanly separating Noir and Backend tooling from a user perspective, which helps familiarize users with the Noir <> Backend concept as clear and as soon during their onboarding as possible. This in turn helps users to more accurately debug issues they run into, as well as paves way for users to more easily work between different backends.

there is a significant engineering reason for burning this nargo-bb bridge

This hence is a tradeoff between different verticals of DevEx, rather than a net DevEx negative in exchange for some obscure internal engineering goals.

DevEx Change: Single Solidity Verifier

To clarify on effects, with my suggestion above the DevEx for generating one Solidity verifier would change from:

nargo codegen-verifier

to:

nargo compile
bb contract

We would already be at the ceiling of intuitiveness on separating the two toolings.

DevEx Change: Multiple Solidity Verifier

The intermediate DevEx deterioration (until workspace support is introduced in barretenberg tooling) lies with generating multiple Solidity verifiers, which would change from:

nargo codegen-verifier

to:

(create / edit bash script)
bash codegen_verifier.sh

This was assumed acceptable as little to none user demand was assumed for frequently generating multiple Solidity verifiers. Do comment below if that isn't accurate 🙏

[signorecello]

DevEx Change: Single Solidity Verifier

To clarify on effects, with my suggestion above the DevEx for generating one Solidity verifier would change from:

nargo codegen-verifier

to:

nargo compile
bb contract

We would already be at the ceiling of intuitiveness on separating the two toolings.

I agree we mostly care about 80% of users, who would be generating one Solidity verifier only.

But the proposed change is not as easy as just using two commands instead of one. Some problems come to mind:

1. noirup installs nargo and according to Tom it won't install bb. Will there be a similar, easy script for bb? bbup? And in that case, will there be a script that runs both noirup and bbup? Doesn't that essentially mean the proposal above that, I agree, will take too much effort?
2. Nargo documentation lives in Noir docs. Where will the documentation for bb live? I talked with @codygunton some time ago on practicing a bit with the Doxygen config they have, but decided to spare them from our incessant requests and docusaurus stuff.
3. Related to the above, who exactly will own BB? If the solidity verifier breaks, I usually just reach out to the Noir team... Burning this bridge, we risk putting BB even more on the outside. There's no BB team.

I don't think the proposed separation on itself would mean net positive DevEx. Net positive DevEd, yes, as the user understands the clear separation between compiler and prover. But strictly speaking, this means more packages and more commands. That's not net positive DevEx. Even if we have an all-in-on noirbbup package as suggested above, the user still needs to install two packages, ensure their versions are compatible, use two commands, probably looking at two different websites for their documentation, etc.

I'm just concerned about throwing away some of the biggest assets we have: the all-mighty Nargo. People are delighted when they see it and realize "wait this thing compiles, tests, executes, proves, generates smart contract, all in one?"

[Savio-Sou]

@signorecello happy to talk through (1), (2) and (3), but maybe somewhere else to keep the thread focused on this PR.

we mostly care about 80% of users

I was thinking more >95% of users aren't frequently generating multiple Solidity verifiers. Were you simply speaking idiomatically, or are there projects that you know of that rely heavily on it?

[TomAFrench]

Will there be a similar, easy script for bb? bbup?

Yeah, you could create a bbup script from noirup pretty easily. Just need to delete all of the code related to building from source.

Nargo documentation lives in Noir docs. Where will the documentation for bb live?

We should have examples of usage in the Noir docs for the time being. There should eventually be docs in the barretenberg repository for how to install/use bb at some point though imo, no need for a full docusaurus setup. At that point we can just link to that. Having decent output for bb --help would help greatly also.

[TomAFrench]

Opened issues.

[TomAFrench]

Closes noir-lang/noir#4447
Closes noir-lang/noir#1138
Closes noir-lang/noir#2222
Closes noir-lang/noir#1159
Closes noir-lang/noir#1009
Closes noir-lang/noir#3837
Closes noir-lang/noir#2667

[github-actions]

Changes to circuit sizes

Generated at commit: 8726f99aa94bce84baa287de1c9a0c88ac719678, compared to commit: 1fa59637a0829208d382d1dded36df33f4d61582

🧾 Summary (100% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
public_kernel_setup	+132,792 ❌	+152.17%	+329,851 ❌	+99.61%
public_kernel_teardown	+132,792 ❌	+151.80%	+329,851 ❌	+99.52%
public_kernel_app_logic	+133,092 ❌	+116.18%	+363,656 ❌	+85.42%
public_kernel_tail	+378,895 ❌	+58.26%	+1,650,753 ❌	+80.18%
private_kernel_reset	+84,515 ❌	+51.11%	+744,823 ❌	+42.77%
private_kernel_init_simulated	0 ➖	0.00%	+720 ❌	+38.24%
private_kernel_inner_simulated	0 ➖	0.00%	+720 ❌	+38.24%
private_kernel_reset_simulated	0 ➖	0.00%	+720 ❌	+38.24%
private_kernel_tail_to_public_simulated	0 ➖	0.00%	+720 ❌	+25.95%
public_kernel_app_logic_simulated	0 ➖	0.00%	+720 ❌	+25.95%
public_kernel_setup_simulated	0 ➖	0.00%	+720 ❌	+25.95%
public_kernel_teardown_simulated	0 ➖	0.00%	+720 ❌	+25.95%
private_kernel_init	+62,040 ❌	+37.97%	+147,387 ❌	+21.68%
private_kernel_inner	+67,920 ❌	+35.45%	+289,939 ❌	+20.70%
private_kernel_tail	+2,880 ❌	+1.50%	+117,367 ❌	+9.85%
private_kernel_tail_to_public	+3,600 ❌	+0.59%	+118,809 ❌	+5.94%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
public_kernel_setup	220,059 (+132,792)	+152.17%	661,008 (+329,851)	+99.61%
public_kernel_teardown	220,273 (+132,792)	+151.80%	661,309 (+329,851)	+99.52%
public_kernel_app_logic	247,647 (+133,092)	+116.18%	789,364 (+363,656)	+85.42%
public_kernel_tail	1,029,192 (+378,895)	+58.26%	3,709,601 (+1,650,753)	+80.18%
private_kernel_reset	249,885 (+84,515)	+51.11%	2,486,261 (+744,823)	+42.77%
private_kernel_init_simulated	1 (0)	0.00%	2,603 (+720)	+38.24%
private_kernel_inner_simulated	1 (0)	0.00%	2,603 (+720)	+38.24%
private_kernel_reset_simulated	1 (0)	0.00%	2,603 (+720)	+38.24%
private_kernel_tail_to_public_simulated	1 (0)	0.00%	3,495 (+720)	+25.95%
public_kernel_app_logic_simulated	1 (0)	0.00%	3,495 (+720)	+25.95%
public_kernel_setup_simulated	1 (0)	0.00%	3,495 (+720)	+25.95%
public_kernel_teardown_simulated	1 (0)	0.00%	3,495 (+720)	+25.95%
private_kernel_init	225,424 (+62,040)	+37.97%	827,164 (+147,387)	+21.68%
private_kernel_inner	259,525 (+67,920)	+35.45%	1,690,457 (+289,939)	+20.70%
private_kernel_tail	194,412 (+2,880)	+1.50%	1,309,261 (+117,367)	+9.85%
private_kernel_tail_to_public	611,589 (+3,600)	+0.59%	2,119,608 (+118,809)	+5.94%