Open arthurpaulino opened 8 months ago
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
@arthurpaulino is this still active post #799, #756 et al?
Yes, this issue is specific to the Circom coprocessor itself, which wasn't changed when adapted to LEM
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.
@tchataigner we mean the arguments we pass in a Lurk program like foo
in (sha256 foo)
Alright so arguments is a lurk term. And, deducing that those arguments are then what we use as inputs in Circom.
@tchataigner yes
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.
The PoC implementation of the Circom coprocessor doesn't take arguments, but we'd want it to.