Translating Ideas into Zero-Knowledge Proofs: A Comparative Study of Circom, Arkworks, and ZoKrates

Lecture 3.2 and 3.3

Structure:

1. Introduction
2. Library Approach
3. HDLs & Circuit Libraries
4. Compiling Programming Languages to Circuits
5. Comparative Analysis of ZKP Toolchains
6. Future of ZKP Toolchains
7. Conclusion

Introduction:

In the increasingly privacy-focused era of digital transactions, Zero-Knowledge Proofs (ZKPs) have emerged as a potent tool to ensure security and confidentiality. Three distinct methodologies to translate high-level ideas into ZKPs - Hardware Description Language (HDL), Library, and Programming Language - have come to the forefront, each with its unique features, benefits, and limitations. This article explores these three approaches, with a particular focus on three widely used tools: Circom, Arkworks, and ZoKrates. By comparing and contrasting these tools and examining how they leverage the potential of ZKPs, this study aims to shed light on the evolution of ZKP toolchains and the potential for future development in this sphere.

Library approach

The library approach to programming ZKPs provides direct control over constraint systems. In this method, a library is implemented in a popular high-level programming language such as Rust, OCaml, C++, or Go. This library is key in implementing this approach as it contains one crucial type – the constraint system. This object is tasked with maintaining state about the R1CS constraint system as it develops, as well as the variables and values assigned to the variables during constraint system generation. The constraint system internally contains the representation of the three constrained matrices A, B, and C, as well as the values assigned to the variables, if any. There are key operations you can perform on the constraint system object, such as creating a new variable, creating a linear combination of variables, and adding a constraint.

Constraint system Operations

In pseudo Rust for variable creation, you would have an add_var function that takes the constraint system as input, which it can mutate and add a new entry, the visibility of the variable (public or private), a value assigned to the variable (for proving), and the result is a variable ID. Once you have variables created, you can construct linear combinations. You can use cs.0 to create an empty linear combination and then add a term to it by giving the coefficient and the variable handle as input. Finally, the most important operation in a constraint system object is adding constraints, which happens via the API CS dot constraint. This API enforces that the LC_A times LC_B equals LC_C once you substitute the values of the variables in place of their handles.

Boolean example

Let's consider an example where we want to perform a Boolean operation. First, we define a new Rust function that takes a constraint system and two variables representing the inputs to the Boolean operation. We then construct a new variable, the result, which is a witness variable. We then enforce that the result is the "and" of A and B using linear combinations and the constrain method. This operation is valid because if A or B has a value of 0 or 1, the "and" of these corresponds exactly to the multiplication of these variables seen as field elements.

Idea: leverage language abstraction

To avoid the repetition and potential for errors, we can leverage the power of the host language, Rust, to abstract away these low-level operations. By using language abstractions like structs, enums, operator overloading methods, and others, we can improve the developer's user experience. For example, by wrapping our variable in a dedicated type and using the operator overloading feature of Rust, we can perform the "and" operation between two Boolean variables with a simple command.

Does it work? Yes!

Yes, this approach works well. It allows us to declare our variables neatly and perform operations on them using high-level syntax, reducing the need for manual calls to constrain and new_var, and manual LC generation.

Enabling Witness Computation

By embedding our program in a host language, we can perform arbitrary computations to generate our witnesses. For example, instead of providing a simple true or false value, we can input an expression that will be evaluated to true or false, and this logic is executed only when needed, saving computational resources.

HDLs & Circuit Libraries

In comparison to the previous two approaches, HDLs (Hardware Description Languages) and circuit libraries differ in that circuit libraries utilize their host language, a full-featured programming language, whereas HDLs are limited to a custom language. However, they both involve creating wires or variables and writing down constraints that enforce conditions on these variables.

Compiling PLs to Circuits (Idea)

A more ergonomic way to work with ZKPs is to design and specify a high-level language that doesn't require us to explicitly program R1CS or reason about individual variables. This language would include features like functions, loops, variables, arrays, and structs. We would then input this high-level code into a compiler, which would output R1CS, consisting of wires, constraints, and variables. This approach is exemplified by the popular ZK programming language, ZoKrates.

ZoKrates: Syntax

ZoKrates is a domain-specific language designed for zk-SNARKs on Ethereum. It uses a syntax similar to popular languages and allows the definition of custom types such as structs or type aliases. Each ZoKrates program has a main entry point, known as the main function, where variables can be declared. These variables hold values used during execution or proving.

Visibility of the inputs can be annotated within the main function. For instance, if a variable 'x' is public, it is known to the verifier. Constraints on variables can be enforced through the 'assert' keyword, which accepts any boolean expression as input, not limited to linear combinations. Therefore, the syntax allows for a high-level coding experience.

Zokrates: Language Features

ZoKrates provides advanced features for more complex programs. It supports generic type parameters for functions, allowing more flexibility. Arrays can be declared and mutated, particularly within for-loops, as long as their length is known at compile-time. The language also supports if expressions and compile-time known array accesses. Together, these features make up a rich programming environment that's easier to use from a user experience perspective.

What about Witness Computation?

One limitation of ZoKrates is with respect to witness computation. There is no way to compute a witness during the execution of a program in ZoKrates. All private inputs or witnesses must be provided as arguments to the main function. Therefore, we cannot declare a private variable during the execution. It must be declared at the beginning of the main function.

ZKP Toolchains: A Quick Tour

After understanding how to use Circom, Arkworks, and ZoKrates, it's important to note their differences and similarities, and the benefits and costs of using them. These tools can be categorized into three types: Hardware Description Languages (HDLs), Circuit Synthesis Libraries, and Programming Languages. They vary based on whether they describe circuit synthesis or a program, and whether they have their own syntax or are embedded within a host language.

Toolchain Type

Circom is a standalone HDL for describing circuit synthesis. Arkworks is an example of an embedded language for describing circuit synthesis, embedded within the Rust language. ZoKrates, on the other hand, is a programming language with its own syntax and a compiler that translates it into a circuit. These three tools differ based on the type of language and whether they have their own syntax.

Other toolchains

Apart from Circom, Arkworks, and ZoKrates, there are other tools and languages available for implementing zero-knowledge proofs. Libraries such as Gadgetlib, Bellman, Snarky, and Plonkish are alternatives to Arkworks, while Noir, Leo, and Cairo are programming languages that serve as alternatives to ZoKrates. Each has its unique features and constraints.

Shared Compiler Infrastructure?

Given the many languages and tools for ZKP, it's conceivable that a shared compiler infrastructure could simplify the development of new ZKP languages. This could include common techniques for representing booleans, fixed-width integers, variable semantics, user-defined structures, control flow, circuit optimization, and array interactions. A shared infrastructure like this could help standardize and simplify the development of new ZKP languages.

Conclusion:

The field of Zero-Knowledge Proofs is fast-evolving, with new tools and languages like Circom, Arkworks, and ZoKrates emerging to simplify the process of creating ZKPs. Each tool has its unique strengths, offering different approaches to translating high-level ideas into ZKPs, be it through a Hardware Description Language, a Library, or a Programming Language. However, despite the progress made so far, there remains room for improvement and innovation. One such potential area is the development of a shared compiler infrastructure that could standardize the creation of ZKP languages, thereby simplifying the development process. As we move forward, it will be crucial to continue exploring and refining these tools and methodologies to harness the full potential of ZKPs in ensuring secure and private digital transactions.

P.S.

I believe that constructive feedback is essential for personal and professional growth, and I welcome any comments or thoughts you may have regarding my article. Your feedback will help me improve my writing and provide better content for you in the future.

If you found this article valuable, I encourage you to follow me on LinkedIn to stay updated on my latest posts. Your support and engagement mean a lot to me, and I am grateful for every like, comment, and share.

Thank you for your time, and I look forward to connecting with you.