|1.1.2||Jun 30, 2020|
|1.1.1||Jun 17, 2020|
|1.0.6||Jun 16, 2019|
|1.0.2||May 10, 2019|
#62 in Cryptography
176 downloads per month
Used in 4 crates
zkInterface is a standard tool for zero-knowledge interoperability between different ZK DSLs, gadget libraries, and proving systems. The zkInterface project was born in the ZKProof community.
See a live demo.
zkInterface is specification and associated tools for enabling interoperability between implementations of general-purpose zero-knowledge proof systems. It aims to facilitate interoperability between zero knowledge proof implementations, at the level of the low-constraint systems that represent the statements to be proven. Such constraint systems are generated by frontends (e.g., by compilation from higher-level specifications), and are consumed by cryptographic backends which generate and verify the proofs. The goal is to enable decoupling of frontends from backends, allowing application writers to choose the frontend most convenient for their functional and development needs and combine it with the backend that best matches their performance and security needs.
The standard specifies the protocol for communicating constraint systems, for communicating variable assignments (for production of proofs), and for constructing constraint systems out of smaller building blocks (gadgets). These are specified using language-agnostic calling conventions and formats, to enable interoperability between different authors, frameworks and languages.
A simple special case is monolithic representation of a whole constraint system and its variable assignments. However, there are a need for more richer and more nuanced forms of interoperability:
- Precisely-specified statement semantics, variable representation and variable mapping
- Witness reduction, from high-level witnesses to variable assignments
- Gadgets interoperability, allowing components of constraint systems to be packaged in reusable and interoperable form
- Procedural interoperability, allowing execution of complex code to facilitate the above
|Circuit Type||Export Circuits||Import Circuits|
|Proving System||Export Circuits||Import Circuits|
| ||The interface specification|
| ||The gadget interface definition using FlatBuffers|
| ||An example circuit in binary and JSON|
| ||Cargo package |
| ||Generated Rust code|
| ||Rust helpers to read messages|
| ||Rust helpers to write messages|
| ||Rust helpers to interact with C++|
| ||Example messages for a simple test circuit|
| ||Example gadget call in Rust|
| ||Generated C++ code|
| ||Example gadget in C++|
| ||NPM package |
| ||Generate Rust and C++ code from zkinterface.fbs, and compile the C++ example|
| ||Libsnark support|
| ||Libsnark gadget example|
rust directory, run unit tests:
The following commands will generate and print a file containing the messages Circuit, R1CSConstraints, and Witness for a toy circuit in
cargo run --bin example > example.zkif cargo run --bin print < example.zkif
This command will generate and compile Rust and C++ code, and run a test of both sides communicating through the standard interface:
cargo test --features cpp
Generated C++ and Rust code is included.
For other languages, install the FlatBuffers code generator (
flatc). One way is to compile it with the following:
git clone https://github.com/google/flatbuffers.git cd flatbuffers cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release make
flatc --LANGUAGE zkinterface.fbs
- In a frontend, implement a feature to export the circuits or gadgets to zkInterface format.
- In a proving system, support loading circuits from zkInterface buffers or files.
See the implementation guide section in the spec above for more details, and check out the existing implementations below.
The zkInterface specification document providers further context on the above, and defines the communication protocol and calling convention between frontends and backends:
- The logical content of messages being exchange.
- The serialization format of the messages (which is based on FlatBuffers and may be used in-memory, saved or streamed).
- A protocol for building a constraint system from gadget composition.
- Technical recommendations for implementation.
This first revision focuses on non-interactive proof systems (NIZKs) for general statements (i.e., NP relations) represented in the R1CS/QAP-style constraint system representation. Extension to other forms of constraint systems is planned.
The associated code is experimental.
See the specification document for more information about limitations and scope.