Project: Bringing (libsnark) gadgets to ZoKrates

[nicola]

Hello everyone, I finally wrapped my head around what is needed to make #2 happen :)

Current state: ZoKrates is really great - however, as soon as more complex primitives (SHA #2 and others) are required for designing a circuit, you either end up using libsnark or you will have to reimplement those carefully designed gadgets from libsnark again in ZoKrates (really prone to errors!)

There is hope: What if we could export gadgets from libsnark into R1CS that can be imported into ZoKrates? Then ZoKrates would be a really simple glue to combine gadgets and make circuts that Libsnark can then use. Once we have the ability of re-using circuits, then ZoKrates can really reach a wider audience which is not just "prototyping".

Note: This might even be a project where ZoKrates as a community could apply for grants (Zec? Protocol Labs? Eth?)

Ack: So talking to @JacobEberhardt @lgarron, I assembled this list of tasks/projects that we as a community should look into to make the leap with ZoKrates

---

Project: Gadgets to ZoKrates

• Aim: This project is to make it easy for developers to write and debug SNARK circuits.
• Conjecture: If the complexity of writing SNARKs is abstracted away by libraries such as libsnark, then what's left is the writing (and optimizing) of circuits. If can have gadgets and a high level language to combine gadgets, then it is easy to write and debug SNARK circuits.

Objectives

There are three objectives, and they can be run in parallel:

• Objective 1: Get R1CS gadgets from libsnark
  • Use amiller's code from zcash to extract circuits from libsnark
  • flatten all the gadgets
• Objective 2: Make libsnark use R1CS(=flattened ZoK) as input
  • given an r1cs, use libsnark to generate proofs about it
  • (See code from ZoKrates on how they integrate with libsnark)
• Objective 3: Make ZoKrates use gadgets
  • add multireturn https://github.com/JacobEberhardt/ZoKrates/pull/18
  • improved flattening
  • add import statements (*)

---

/cc @amiller, @JacobEberhardt, @barryWhiteHat, @Schaeff

[nicola]

Update: @barryWhiteHat has done some progress towards Objective 1 here: https://github.com/howardwu/libsnark-tutorial/compare/master...barryWhiteHat:master

Also, implicitly has defined a new format for R1CS :)

[nicola]

For reference https://github.com/QED-it/r1cs_proto where @kobigurk is also working on a standard format for r1cs

[Schaeff]

A first version is being actively worked on here https://github.com/schaeff/ZoKrates/tree/bind-libsnark-sha256 with the approach of generating witnesses in libsnark. Stay tuned!

[JacobEberhardt]

Sha is available as libsnark import as well as as native ZoKrates implementation

[nicola]

wooow!

[daniben31]

Nice proposal @nicola, I definitely agree that this is a direction that different projects should be working towards to enable interoperability.

We published a proposal as part of the community standards of zkproof.org. It is a procedural method for generating constraints (both instance reduction and witness reduction) that can be used for all the front-ends and back-ends that are "R1CS friendly"

https://github.com/QED-it/gadget_standard

We are thinking of implementing the ZoKrates frontend and bellman backend