feat(acvm)!: Encapsulate internal state of ACVM within a struct

[TomAFrench]

Description

Problem*

Resolves #383

Summary*

This PR creates an struct to track the internal state of the ACVM execution.

Testing with full noir test suite here

Additional Context

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[TomAFrench]

This can be simplified significantly with #368 and #385. We will then also be able to remove all cloning of opcodes.

[kevaundray]

Is this aiming to encapsulate ACVM or just the PWG? Seems its just the solver from the linked issue -- Not sure if that struct should be called ACVM then, since ACVM involves both a solver and a backend. Where the backend does proving and verifying

[TomAFrench]

ACVM involves both a solver and a backend. Where the backend does proving and verifying

Is that the correct way to think about it? I mean, yes if we're talking about "ACVM the repository" then this naming is suboptimal but if we're thinking about "ACVM the virtual machine" then the struct naming is accurate.

If we were talking about a zkEVM, I don't think we'd include the prover/verifier in the definition of the zkEVM but accompanying components. The zkEVM is just the circuits which take initial state and generate the output state which is similar to what the ACVM struct is doing here.

Is this aiming to encapsulate ACVM or just the PWG? Seems its just the solver from the linked issue.

Yes, I'm planning on just having this cover the solver for the foreseeable future. Proving/verifying has zero internal state so we don't need to place it on this struct.

[kevaundray]

Is that the correct way to think about it? I mean, yes if we're talking about "ACVM the repository" then this naming is suboptimal but if we're thinking about "ACVM the virtual machine" then the struct naming is accurate.

I've always thought of it as ACVM being instantiated with a backend but I can see where you are coming from. If thats the case, then wouldn't proving and verifying being in this repository be an abstraction leak?

(This is not blocking for me)

[TomAFrench]

If thats the case, then wouldn't proving and verifying being in this repository be an abstraction leak?

Potentially, yes. The SmartContract and ProofSystemCompiler traits depend on ACIR rather than the ACVM itself. These interfaces could be defined elsewhere as some for of "surrounding tooling" for the ACVM.

[TomAFrench]

I don't think this will be the final state of the ACVM struct but its in a mergeable condition.