Make Circom coprocessor use arguments

[arthurpaulino]

The PoC implementation of the Circom coprocessor doesn't take arguments, but we'd want it to.

[huitseeker]

See https://github.com/lurk-lab/lurk-rs/blob/3292852ce90722ebe263a0de6d0cc7cb6589de37/examples/circom.rs#L76-L81 https://github.com/lurk-lab/lurk-rs/blob/3292852ce90722ebe263a0de6d0cc7cb6589de37/examples/circom.rs#L83-L92 https://github.com/lurk-lab/lurk-rs/blob/3292852ce90722ebe263a0de6d0cc7cb6589de37/examples/circom.rs#L94-L103

[huitseeker]

@arthurpaulino is this still active post #799, #756 et al?

[arthurpaulino]

Yes, this issue is specific to the Circom coprocessor itself, which wasn't changed when adapted to LEM

[tchataigner]

I was about to tackle this but it seems that I got confused in lexical terms. When referring to arguments do we mean inputs or parameters?

As the main entrypoint does not allow for parameters I'm guessing we refer to inputs, but I just want to make sure.

[arthurpaulino]

@tchataigner we mean the arguments we pass in a Lurk program like foo in (sha256 foo)

[tchataigner]

Alright so arguments is a lurk term. And, deducing that those arguments are then what we use as inputs in Circom.

[huitseeker]

@tchataigner yes

[tchataigner]

Hey everyone! Quick follow-up on this. After some consideration, it seems that we can not really create a 1 to 1 relationship between the awaited circom signals and our lurk arguments. So the information about the arity of a CircomGadget and how to handle them will have to be declarative on the developer side.

#997 will show off how that works for now. I have an update to push by EOD.