Add a new crate with the implementation of BlackBoxFunctionSolver trait from acvm-backend-barretenberg

[TomAFrench]

Problem

noir-lang/acvm#492 describes how we want to separate the solving of black box functions from the interactions with the proving backend.

Happy Case

noir-lang/acvm-backend-barretenberg#239 implements the ProofSystemCompiler and SmartContract traits using a prebuilt bb binary while the BlackBoxFunctionSolver trait remains using the static-lib/wasm.

We should bring this implementation up to this repository so that acvm-backend-barretenberg is only responsible for interacting with the bb binary.

Alternatives Considered

No response

Additional Context

This is required for #2164 as we need to maintain a BlackBoxFunctionSolver implementation even once we have deprecated acvm-backend-barretenberg.

Would you like to submit a PR for this Issue?

Yes

Support Needs

No response

[vezenovm]

implements the ProofSystemCompiler and SmartContract traits using a prebuilt bb binary while the BlackBoxFunctionSolver trait remains using the static-lib/wasm.

Is there a reason that the bb binary cannot be used for also implementing the BlackBoxFunctionSolver?

This is required for #2164 as we need to maintain a BlackBoxFunctionSolver implementation even once we have deprecated acvm-backend-barretenberg.

Is the plan to maintain these BlackBoxFunctionSolver's (bb and future ones) inside of Noir?

[TomAFrench]

Is there a reason that the bb binary cannot be used for also implementing the BlackBoxFunctionSolver?

bb doesn't expose these currently plus we need to maintain the wasm solver for acvm_js anyway so I don't see much benefit of adding this at the minute.

Is the plan to maintain these BlackBoxFunctionSolver's (bb and future ones) inside of Noir?

Zac's currently reworking pedersen opcodes so that we can have rust implementations of them or implement them inside Noir. I'm planning on this crate being a temporary measure until this is done.

[vezenovm]

bb doesn't expose these currently plus we need to maintain the wasm solver for acvm_js anyway so I don't see much benefit of adding this at the minute.

There are bindings setup for both pedersen and schnorr we would just need to expose them in bb.js. But if this complicates things for acvm_js we can leave it.

I'm planning on this crate being a temporary measure until this is done.

Was mainly curious if this was temporary measure

[TomAFrench]

Also looking at just using the wasm solver in all cases as described in noir-lang/acvm#494. Main trouble now is start-up time on the wasm binary which is being addressed by stripping it down to only contain the 3 functions necessary.

[TomAFrench]

This can be closed as we are handling this down in ACVM now as the wasm has been stripped down enough to be the default solver.