ZKProof Proposal: Interoperability of zero-knowledge tools

2nd ZKProof Workshop
1

We’re starting to see more and better software that implements various zero-knowledge techniques, which is great.

There are different types of code out there:

  1. Proving systems that generate and verify proofs.

  2. Frameworks that let us express the statements to prove.

  3. Collections of helper routines and gadgets.

  4. Applications that implement specific statements and are distributed to end-users.

There’s a parallel with classical software engineering to make:

  1. Machine architectures, 2. Languages and compilers, 3. Functions and libraries, 4. Executable programs.

Today, these layers tend to be tightly coupled, and we find multiple stacks, written in different languages, with their own approach to each issue. This does make sense for now, as a team of experts can produce multiple layers together and deliver a specific product.

But zero-knowledge proving has potential for a variety of applications; not just in specialised products, but as a new technique engineers can use in larger systems, as they do today with encryption, signatures, etc. Meanwhile, complexity and requirements will increase, and there will be more teams throughout the world working on zero-knowledge software. We might even see some kind of equivalent to JavaScript, included in many products to execute on many clients. If any of this is to happen, the ecosystem will exhibit more and more software engineering practices. A particular impact may come from thinking in terms of systems, components, and interfaces, which is generally beneficial in multiple ways:

  • Less effort required to build and review complex applications if it is made of components.

  • The ability to coordinate the efforts of multiple teams who agree on the interfaces between components.

  • More effective systems, as the most appropriate component can be chosen for each layer.

  • Quicker deployment of innovations, when a new technique can be implemented in one layer and integrated with existing tools.

  • Familiarity of concepts for non-specialists.

Some elements of system engineering do appear naturally in individual projects. Libsnark separates the proving systems from the gadgets through C++ interfaces. The implementation of Zcash Sapling looks a lot like a set of layers and components. In ZoKrates, the developer is exposed to the familiar concepts of programs being compiled and functions returning outputs from inputs; this independently of third-party proving systems and gadget libraries the compiler might support.

In this spirit, we put a lot of thoughts into how interoperability across today’s and tomorrow’s projects could work. We present a step in this direction as a proposal in the 2nd ZKProof standards workshop, which you can find at https://github.com/QED-it/zkinterface. Many thanks to all who did or will review and comment this proposal. Feel free to discuss here.

5 Likes
2

The above is one of the proposals, the second one, on JSON R1CS format, can be found here

Here are the notes of the discussion - feel free to comment and use them.

Here are the specific action points that were discussed (in this case to be part of improving the respective proposals and generate further discussion and a summary of the discussion for the reference document.

  • @aurel and authors will update their proposal to include comments on dependencies, types, wasm comments.
  • @Guillaume is there any specific update to the proposal you aim to do?
  • @str4d, Sean Bowe, @jbaylina and myself will write up a summary for the reference document on the following topics:
  1. Platform issue (browser vs native)
  2. Calling convention issue (need protocol for calling gadgets between each other)
  3. Interactivity and semantics
  4. Dependency of libraries / languages - not try to reinvent (talk to people who have thought about this)

Please point out if there is anything I am missing or something more you think we should do / add.

Shoot the comments.