feat: Implement basic contracts

[jfecher]

Related issue(s)

Resolves #943

Description

Adds support for a basic contract structure in Noir. Contracts are currently very similar to submodules in that they can contain imports, globals, and functions, although currently these function exactly like normal noir constructs.

This PR also adds a nargo compile --contracts command for compiling all functions declared in a contract as if they were a separate main function.

Test additions / changes

Adds a contracts test

Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt with default settings.
• I have linked this PR to the issue(s) that it resolves.
• I have reviewed the changes on GitHub, line by line.
• I have ensured all changes are covered in the description.
• This PR requires documentation updates when merged.

[jfecher]

Example output of nargo compile --contracts mycircuit in the nargo/tests/test_data/contracts directory:

Proving key saved to /Users/jakefecher/Code/Noir/noir/crates/nargo/tests/test_data/contracts/target/mycircuit-Foo-double.pk
Verification key saved to /Users/jakefecher/Code/Noir/noir/crates/nargo/tests/test_data/contracts/target/mycircuit-Foo-double.vk
Generated ACIR code into /Users/jakefecher/Code/Noir/noir/crates/nargo/tests/test_data/contracts/target/mycircuit-Foo-double.json.checksum
Proving key saved to /Users/jakefecher/Code/Noir/noir/crates/nargo/tests/test_data/contracts/target/mycircuit-Foo-triple.pk
Verification key saved to /Users/jakefecher/Code/Noir/noir/crates/nargo/tests/test_data/contracts/target/mycircuit-Foo-triple.vk
Generated ACIR code into /Users/jakefecher/Code/Noir/noir/crates/nargo/tests/test_data/contracts/target/mycircuit-Foo-triple.json.checksum

[kevaundray]

Nice! We can combine these ABIs with method names in a separate PR

[TomAFrench]

This isn't necessary for this PR but do we potentially want to create a new CrateType for contracts? I wouldn't exactly say that contracts fall neatly into the "binary" classification. Currently we only find contracts which are reachable through main.nr but for a solidity-like dev experience I would expect to have a bunch of .nr files for a multi-contract system and just have the contracts be found automagically when compiling.

We would then have something like

enum CrateType {
  Binary, // Enter through main.nr looking for `main()`. Used for generic stateless ZK proofs.
  Library, // Enter through lib.nr
  Contract // Search every file for contracts.
}

[TomAFrench]

Sidenote: our nargo contract command is going to get confusing at some point.

[jfecher]

I would expect to have a bunch of .nr files for a multi-contract system and just have the contracts be found automagically when compiling

I'd rather users just referenced the additional modules in their program via mod foo; as normal. There's no reason to support module autodiscovery for contracts but not when compiling normal programs, or vice-versa. I don't think it is too burdensome to maintain, but I would support it if we wanted to make all mod foo; declarations unnecessary.

[kevaundray]

Sidenote: our nargo contract command is going to get confusing at some point.

Yeah I'm not yet sure how to disambiguate. Probably better to do it sooner than later.

Maybe something along the lines of 'nargo verify --Ethereum' spits out an eth contract?

[TomAFrench]

I'd rather users just...

Ah yes that's true, I'd need to think about how this would work in a rust-like import scheme. In solidity each file has explicit path-based imports when pulling in other files so you can enter through any file and just follow the paths to find all of its dependencies whereas it's a little more complex here.

That said, I can foresee this being a big point of friction for new devs coming into the discord asking why nargo won't compile their new contract.

[TomAFrench]

Maybe something along the lines of 'nargo verify --Ethereum' spits out an eth contract?

I'm not a fan of overloading the verify command like that, a call to nargo verify should always verify the proof no matter what extra flags you pass.

nargo generate-verifier --solidity perhaps? We could then extend it to other languages, etc.

(Sorry for derailing this PR Jake, we should probably open an issue for this)

[kevaundray]

Maybe something along the lines of 'nargo verify --Ethereum' spits out an eth contract?

I'm not a fan of overloading the verify command like that, a call to nargo verify should always verify the proof no matter what extra flags you pass.

nargo generate-verifier --solidity perhaps? We could then extend it to other languages, etc.

(Sorry for derailing this PR Jake, we should probably open an issue for this)

generate-verifier is much better!

[kevaundray]

What happens if I run nargo compile intending to compile a main function, but I have contracts in my code?

[kevaundray]

Looks good -- some small questions re exclusivity of contracts and regular noir programs.

It may be confusing to allow them to be called just like modules -- I'm not sure. This is not a blocker for this PR and something which may require experience/time

[jfecher]

What happens if I run nargo compile intending to compile a main function, but I have contracts in my code?

It will try to compile the main function as normal then, and fail if it is not present.

[kevaundray]

LGTM

[kevaundray]

Not sure if @TomAFrench had any comments on this, if not we can merge

[TomAFrench]

Nothing blocking!

[kevaundray]

@jfecher we merged another PR which created merge conflicts -- could you resolve these please?