feat(nargo)!: define preprocessed artifacts for programs/contracts

[TomAFrench]

Related issue(s)

Related to #1102

Description

Summary of changes

This PR defines generic preprocessed artifacts for Noir programs and contracts as defined in #1102 ("Backend-specific Artifact").

Rather than the current json/pk/vk/checksum files we now have a single json file which we can use. This means that we don't need to be concerned about the keys and the acir being in sync as they're stored together.

This does mean that we now need to load the proving key when verifying a proof however my preference for solving this is to derive specialized "verifier artifacts" which just contain the information required for verifying the circuit. Nargo would then accept the full or verifier artifact when verifying a circuit but that's OOS for this PR.

Note: PreprocessedContract does NOT match the desired spec for A3 contracts, these can be derived from this artifact however. I don't think that Nargo is the right place for performing this translation so the A3 team may need to maintain a small tool to translate between them. Thoughts @kevaundray?

Dependency additions / changes

Test additions / changes

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.

Documentation needs

• This PR requires documentation updates when merged.

Nargo compilation outputs have been changed. This shouldn't affect any actions which the user has to take but discussion about files created needs to be update.

nargo preprocess command has been removed as it's not meaningful until we have backend-agnostic artifacts. The nargo preprocess command would then create the artifacts made in this PR.

Additional context

[phated]

This does mean that we now need to load the proving key when verifying a proof however my preference for solving this is to derive specialized "verifier artifacts" which just contain the information required for verifying the circuit. Nargo would then accept the full or verifier artifact when verifying a circuit but that's OOS for this PR.

Why would we have specialized artifacts instead of just switching to a serialization protocol that can read individual pieces of data out of the artifact?

[TomAFrench]

Why would we have specialized artifacts instead of just switching to a serialization protocol that can read individual pieces of data out of the artifact?

Both are options. Choosing a serialisation format which allows us to read subsets of the artifact is obviously better when you're storing the full artifact anyway but only need a portion of it for the action you're performing. However, if we know that we're never going to prove against the circuit (e.g. we want to verify proofs on a mobile device but it doesn't have the resources to create proofs) then we can save bandwidth/disk space using specialised artifacts.

[TomAFrench]

Removing generic from the title as this causes some confusion in relation to #1102. For clarity these artifacts aren't generic wrt to backends but are "generic" in the sense that they're not tailored to any particular usecase.

[kevaundray]

Left some questions I had

[kevaundray]

LGTM -- one more comment on creating an issue for the hardcoded backend name