In the last years, blockchain technology is having an ever increasing spread both in research organizations and business companies. As a matter of fact, the introduction of smart contracts allowing to create Decentralised Applications (dApps) brought to the development of blockchain based solutions in many distinct application scenarios besides the cryptocurrency exchange one, such as: electronic voting, decentralized notary, supply chains management, identity management, access control, healthcare records management, and many others.
One of the main features that contributes to the success of the blockchain technology is transparency, i.e., the information (code and data) stored on a blockchain can be seen by all the participants. If, on the one hand, this feature allows all participants to potentially access and verify all the transactions on the blockchain, on the other hand it does not allow to preserve the privacy of the data stored on the blockchain and used for smart contracts execution, thus preventing the adoption of blockchain technology in many applications.
For instance, let us suppose that the University of Pisa wants to grant the right of executing a given smart contract π for conducting the experiments for the Distribute Ledger Technology course to the students who have paid a predefined fee or have a low income. To allow π to decide whether to grant the access to a student invoking it, the University of Pisa (or another trusted actor) could register the student's income or the fee payment on the blockchain, but this solution does not preserve student's privacy because it would disclose the student's income. Hence, a solution allowing π to evaluate conditions on secret values without disclosing them is required. This is where Zero Knowledge Succint Non-interactive Argument of Knowledge (zkSNARK) proofs [1,2] come into play. As a matter of fact, the zkSNARK technology allows to write smart contracts able to verify a known condition on secret data without revealing the latter. This opens the way to a large number of blockchain based applications where data privacy is a critical requirement. For instance, the authors of [3] exploit the zkSNARK technology to implement smart contracts evaluating Attribute Based Access Control (ABAC) policies [4] where the outcome of the policy evaluation is published on the blockchain (i.e., access granted/denied) without actually disclosing on the blockchain the values of the attributes used for the policy evaluation.
The easiest way for developing a smart contract based application exploiting the zkSNARK technology is exploiting an existing library, being Circom and Zokrates among the two most popular ones. This would relieve the developers from learning the mathematical foundations the zkSNARK technology is based on, since they should simply need to learn the specific languages used by the two libraries to express the conditions that will be evaluated on secret data. However, when choosing which of the two libraries to adopt for their dApps, developers should take into account the cost in terms of gas and storage space of the resulting code.
In the light of the previous considerations, the contribution of this paper is an evaluation and comparison between the two popular libraries implementing the zkSNARK protocol, Circom and Zokrates. In particular, such evaluation has been executed by implementing three well known problems where a privacy preserving condition involving secret inputs must be verified on the blockchain, namely the age verification, the Sudoku, and the Hamiltonian cycle problems, and by i) computing the gas cost of deploying and executing the corresponding smart contract, and ii) evaluating the size of the proofs, produced keys, and circuits varying the dimensions of the problems. These experimental results are then discussed to provide a kind of guideline for developers helping them to understand which library is more convenient to be used in their specific application scenarios.
The paper is structured as follows: Section 2 recalls the relevant background on blockchain and zero knowledge proofs, Section 3 briefly surveys relevant research in the area of zkSNARKs for blockchain, Section 4 introduces the Circom and ZoKrates libraries in more details. We perform an experimental comparison between the two libraries in Section 5 and discuss our findings in Section 6. We sum up the main insights and conclude our paper in Section 7.
A blockchain is a data structure made by data blocks, usually storing data in form of transactions, connected each other by hash pointers. This transaction ledger is shared among a peer-to-peer network, with every node holding a copy of the entire data structure. Users in the network execute transactions, which are grouped in a block and appended to the ledger after the block is validated. The block validation is performed through a consensus algorithm, with Proof-of-Work (PoW) [5] and Proof-of-Stake (PoS) [6] as the most used. After the validation, every node updates their copy of the ledger appending the new block.
Blockchains were popularized by Bitcoin [7], which built a decentralized network dedicated to digital currency trading and secured by cryptography, while newer projects such as Ethereum [8] focused on blockchain based application execution introducing smart contracts, blocks of code executed automatically executed on the blockchain as a transaction execution.
Zero Knowledge proofs (ZKPs) are a broad class of cryptographical constructs first introduced by Goldwasser et al. in [9]. A Zero Knowledge Proof involves two actors: a prover and a verifier. The former aims to prove the validity of a statement to the latter, without leaking additional information besides the validity of the statement being proved. Hence, ZKPs on the one hand allow to keep some data secret, while, on the other hand, allow to demonstrate that a statement based on such data is verified. For ZKP systems, three properties hold:
β’ Completeness: if the statement is true, a honest prover will always be able to convince the verifier except with negligible probability; β’ Soundness: if the statement is false, a malicious prover will be able to convince a verifier at most with negligible probability; β’ Zero Knowledge: if the statement is true, the verifier (even if malicious) will not learn anything about the statement from the proof besides the fact that the statement is true.
One common example to understand ZKPs is the well known Alibaba cave [10]: in this scenario, there is a ring shaped cave with only one entrance and a magic door at the other side of the ring, which can only be opened using a magic word. A prover, named Peggy, knows the secret magic word and a verifier, named Victor, challenges Peggy to prove the knowledge of the magic word. Therefore, Peggy has to provide to Victor a proof about the knowledge of such word without revealing it. To provide such proof of knowledge, the two play a game: Peggy will enter the cave and picks a side to proceed, that could be left or right, say left. Victor, who do not know which side Peggy picked, will ask to Peggy to come out from the cave from a specific side. If Victor picks the left side as exit, Peggy will simply walks back. If Victor picks the right side instead, Peggy has to use the magic word to open the door and walk over the entire ring to come out from the right side. In both cases, Peggy will be able to pick the correct exit side. This single game could not be sufficient to convince Victor about the knowledge of the word: there is a 50% chance that Peggy simply entered the correct side from the start, not using the magic word at all. The game can be repeated multiple times, reducing game by game the possibility that Peggy is simply lucky, until Victor is convinced.
zkSNARKs (Zero Knowledge Succint Non-interactive Argument of Knowledge) [2] are a very popular class of ZKP protocols. In a zkSNARK setting, an efficient (i.e. polynomially bounded) prover wants to prove the knowledge of a witness for a statement to a verifier in a complete, knowledge-sound and zero-knowledge way. Knowledge soundness is a stronger notion of soundness which states that a (malicious) prover that does not know a witness for a given statement can not convince a verifier about the validity of the statement. To model this, a knowledge extractor is employed, i.e. an algorithm that can compute a witness whenever a (malicious) prover provides a valid argument. The notion of "Argument" refers to the fact that the knowledge-soundness property should be satisfied only for a poly-bounded prover, in contrast with the stricter notion of "Proof", in which the prover has unbounded computational resources, see [11,12] for details.
Besides the properties previously mentioned, a zkSNARK system guarantees two additional properties: succintness, meaning that the proof has a small size and can be verified efficiently, and non-interactivity, meaning that constructing and verifying a proof requires little interaction between the prover and the verifier or no interaction at all. zkSNARKs life cycle is made by two main phases: arithmetization and commitment. In the arithmetization phase, the statement to prove is modeled as an arithmetic circuit, that mathematically maps how input values produces output values. One or more constraints can be defined on the model, to guarantee the correctness of the proof. The final output of the arithmetization is a polynomial representation which accounts both the model and the constraints. On the other hand, in the commitment phase the prover uses cryptographical schemes to generate values (the commitments) that will be used in the verification process to guarantee the zero knowledge property. Usually, commitments are generated starting from the coefficients of the polynomial produced in the arithmetization phase applying hash functions to hide the real values.
zkSNARKs usually require a preliminary trusted setup phase between the prover and the verifier, in which they generates two keys: a proving key, which is known only to the prover and will be used to generate the proof, and a public verification key which can be used by the verifier to verify the proof. The setup phase produces some data, often refereed as "toxic waste", which has to be destroyed right after the key generation to maintain the security of the protocol. If the trusted setup phase is executed in a decentralized way, it is sufficient that one of the participants to the setup phase is honest and deletes their part of the toxic waste.
The integration of zkSNARKs in blockchain based applications is a very promising and active research line, both in literature and in enterprise applications. zkSNARKs are applied to blockchain to both Layer 1 blockchains and Layer 2 applications. As Layer 1 application, we mention ZCash [13,14], a blockchain platform that implements zkSNARKs to allow users to execute private transactions. In particular, a zkSNARK is generated to prove the validity of a private transaction to the network users not directly involved in it, in order to make it possible to validate the transaction without reveling any other information except of the transaction validity. On the other hand, there are several applications of zkSNARKs in the context of blockchain Layer 2 applications, aimed to provide scalability and/or privacy when required.
Simunic et al. in [15] survey the methods to verify computations, focusing on blockchain applications. The authors highlight how ZKPs in general can be a powerful tool to implement verifiable computing for Layer 2 applications, ensuring at the same time a high level of privacy.
Partala et al. [16] describe the applications of general non-interactive ZKPs to blockchain, with particular attention to how to obtain confidential transactions and privacy-preserving smart contracts through ZKPs. The authors describe numerous protocols and techniques for implementing ZKPs and present several blockchain based applications exploiting them.
Kosba et al. in [17] propose a framework to build privacy-preserving smart contracts, in which users inputs and application logic are executed off-chain and a zkSNARK, related to the off-chain result, is verified by the on-chain smart contract.
In terms of blockchain applications, zkSNARKs are used with success in ZK rollups [18], a class of Layer 2 applications in which zkSNARKs are used as validity proofs paired with an off-chain computation, to assess the validity of the result of the computation, committed on the Layer 1 blockchain.
Furthermore, there is also a growing interest in benchmarking of zkSNARKs libraries, similarly to what we will discuss in this paper. Ernstberg et al. in [19] present a framework to evaluate, in terms of memory consumption and execution time, several zkSNARK protocols. The benchmark of zkSNARK libraries was also studied by Baghery et al. [20], which benchmark the setup phase in a subset of updatable ZK protocols, and by Steidtmann et al. [21] which focus on benchmarking several Circom circuits, mostly involving hash functions. A similar work, not restricted to Circom circuits, can be found in [22]. However, our work proposes a different point of view on the challenge of benchmark zkSNARK libraries and protocols with respect to the mentioned related works. More specifically, our focus is related to the blockchain applications of such libraries, being then less general-purpose with respect of the cited works. Moreover, we focused on a wider range of evaluated scenarios, not limited to cryptographical operations. Finally, the metrics we evaluated in our experiments are not limited to the memory evaluations or the time consumption, but we provided the evaluation of several other metrics about the smart contract related to an on-chain proof verifier.
There are are several ways to implement zkSNARK protocols that produce proofs verifiable on Ethereum. Among them, in this paper we focus on two of the most popular zkSNARK libraries: Circom and Zokrates. The motivations behind this choice are multiple: first, the two libraries are widely used to generate zkSNARKs in a various range of different applications, including blockchain related ones.
The integration with blockchains is the main motivation driving our selection, since both libraries are capable to generate a verifier smart contract alongside each proof. Finally, the fact that the two libraries have several common traits but at the same time crucial differences, as explained in the rest of this section, make the comparison even more significant. The rest of this section describes the two libraries.
Circom [23] is a library composed by a domain-specific language, which can be used to code the statement to prove, and a compiler which transforms the code into an arithmetic representation known as Rank 1 Constraint System (R1CS). To execute the trusted setup, Circom integrates snarkJS as an external library. Also, the witness has to be computed externally, using the R1CS (plus some extra files produced compiling the circuit, according to the chosen compilation options) as input. This operation can be executed using NodeJS or C++ wrappers. Circom language allows developers to define the problem as a sequence of inputs (signals) and operations between them (wires), such that the transformation into an arithmetic circuit is optimized since the development stage. Furthermore, the language allows to distinguish between public and private inputs. Finally, the library supports the proof verification executed by a dedicated Solidity smart contracts. Figure 1 provides an overview about how Circom works. First, the Circom code is compiled into the corresponding R1CS representation. An R1CS is a system of polynomials with degree 1, which combines the arithmetic operations composing the circuit that are needed to prove the initial statement and the constraints defined on the circuit. In Circom, the trusted setup is delegated to snarkJS, which executes two phases: in the first phase, independent by the circuit, the CRS is generated executing the Power of Tau [24] ceremony. In the second phase, the CRS and the R1CS are used to generate the key pair needed to generate the proof (private key) and to verify it (public key). The R1CS is also used to generate the witness: this operation is executed by an external component as well, in particular using a NodeJS or a C++ dedicated module. The witness and the private key are used to generate the proof, while the public key is used as input to generate the Solidity smart contract. The smart contract can be deployed on any EVM based blockchain, since it is written in Solidity, to enable the on-chain verification process.
ZoKrates [25] is a zkSNARK library that provides a domain specific language to write programs defining the statement to prove and the necessary inputs, a compiler to compile the mentioned programs into arithmetic circuits, and a procedure to generate proofs and to verify them. The programming language is an high-level language, making easier for developers to define the statement logic. Also, the language allows the distinction of inputs into public and private. The compiler compiles ZoKrates programs into an arithmetic representation called ZoKrates Intermediate Representation (ZIR).
A trusted setup is required to generate the private and public keys which are used, respectively, to generate and verify the proofs. Finally, ZoKrates is able to generate tailor-made Solidity smart contracts to verify proofs on EVM based blockchains, such as Ethereum. Figure 2 illustrates the ZoKrates workflow. The ZoKrates code, written using the dedicated language, is compiled into a ZIR by the compiler. The ZIR is an extended and more abstracted version of the R1CS representation, which optimizes both the program execution and the proof generation. The ZIR contains constraints (conditions to generate the arithmetic representation) and directives (used by the interpreter). ZoKrates supports a locally executed trusted setup, which takes in input the ZIR file and outputs a long proving key and a short verification key. The ZIR is also used to define the witness, which includes all the data needed to generate the proof, both public and private. This witness, in combination with the private proving key, is used to generate the proof. On the other hand, the verification key is used to generate a Solidity smart contract, which is capable of verifying the proof generated by the corresponding program. Such smart contract can be deployed on any EVM based blockchain to enable on-chain proof verification.
Exploiting the Circom or the Zokrates library is an easy way for dApps developers for integrating the zkSNARK technology in their dApps to protect data privacy, because they simply have to use the specific constructs provided by the languages of the two libraries to express the conditions that needs to be evaluated on secret data. However, when choosing the library that best fits their dApps, developers must consider the cost in terms of gas and storage space of the resulting code.
For this reason, in this section, we consider how ZoKrates and Circom compare with each other in three different scenarios. We assume that a Layer-2 dApp executes off-chain computation and, after that, publishes on the blockchain a zkSNARK proof of the result so that a dedicated on-chain smart contract can verify it. For a comprehensive comparison, we implement every scenario with both libraries, evaluating both the prover and the verifier side.
Our goal is to provide both the research and the development communities with guidelines that could help in choosing the most suitable zkSNARK library when building privacy preserving dApps. We aim to show how the two libraries behave in different contexts highlightning their strenghts and weaknesses so that developers can make an informed choice, according to their needs. For each scenario we consider, we chose to evaluate the storage consumption by the proving setup (arithmetic circuit file size, proving and verification key size, proof size) and the verifier smart contract deploy and execution costs.
To conduct a thorough comparison, we evaluated the two libraries against a set of problems with increasing complexity with the goal of exploring the features offered by Circom and ZoKrates. We defined three simple scenarios such that we can exploit several features of the programming language provided by the two libraries and how the usage of the main syntactical contructs impact on metrics like the circuit complexity, keys and proof size and smart contract costs, in order to provide the most possible detailed insights about how the libraries handle problems of increasing complexity. Each scenario that we considered in the analysis explores the usage of chosen language features, as Table 1 summarizes. This way, we are able to isolate the impact that the language features have over the metrics we are considering. For each scenario, we developed the actual proof of knowledge and the corresponding smart contract that acts as the verifier both using Circom and ZoKrates. We used Groth16 [26,27], a proving scheme based on elliptic curve pairings, for both Circom and ZoKrates. The code of experiments, including both the circuit coding for the two libraries and smart contract codes, is publicly available on GitHub 1 . The experiments were performed on a commodity laptop with Intel Core i5 dual-core 1,6 GHz CPU and 8 GB RAM 2133 MHz LPDDR3. In the rest of this section, detailed descriptions and experimental evaluations for each of these scenarios will be presented and discussed.
In real world scenarios, the access to services is regulated by policies, mostly defined by laws and regulations. Such policies usually define the requirements that users need to satisfy to access the services, and they can be based on any parameter. For instance, the purchase of a wide range of services is limited by age: the access to sport bets, the possibility to vote, and many others. Therefore, users have to prove to be older than a certain age threshold, which is set according to the required service or the law, to access the service or to purchase the product.
In our tests, a prover wants to prove to be older than a certain threshold, set up by the verifier, without disclosing their real age. Therefore, the age of the prover is considered as the witness, while the age threshold represents the public input.
This first experiment, which is indeed very simple, aims to exploit the basic components of the programming languages provided by the two libraries, i.e., numeric variables and boolean conditions evaluation. Table 2 reports the size of the files produced by the proof generation process. As expected, since we are dealing with a simple problem, the file sizes are overall very small, with Circom files being even smaller than the ZoKrates ones. No file exceeds the size of few KB, with the circuit file size registering the biggest difference between the two libraries, with 4 KB for the Circom circuit and 139 KB for the ZoKrates circuit. The other files, instead, have a similar size for the two libraries.
Sudoku [28] is a popular puzzle game structured as a square π Γ π grid, with π = 9 in the most common configuration of the game. The objective of the puzzle is to fill the grid using numbers from 1 to π, such that every number is present only once in every every row, column and
The starting grid is filled only partially.
In our tests, the prover wants to generate a proof assessing the knowledge of a valid solution for a certain Sudoku grid, maintaining such solution hidden to the verifier. Hence, the witness is the Sudoku solution, while the public input is the starting grid.
The goal of this experiment was to evaluate how the libraries implement the most used syntactic constructs common to programming languages, i.e., conditional blocks (ππ /πππ π) and cycles (π ππ/π€βπππ).
For our experiments, we evaluated 5 different instances of the Sudoku grid, progressively increasing the grid size. More specifically, we considered π = 4, 9, 16, 25, 36.
Table 3 summarizes our results about the size of the files produces by the proof generation process for the different Sudoku grids by both libraries. As shown by the table, the circuit files sizes and the proving keys sizes are the metrics where Circom and Zokrates differ the most. For instance, in case of a grid of 36 Γ 36, Circom's Circuit file (R1CS file) has a size of 17,3 MB, while the ZoKrates file has size 1,59 GB. The difference is also very pronounced on the proving key size, where the Circom proving key is 57 MB while the corresponding ZoKrates proving key occupies 2,64 GB. Figure 4 shows the cost to deploy the verifier smart contracts generated by Circom and ZoKrates. The first thing to notice is that for big grids the libraries have issues in generating a smart contract to verify the proof of knowledge. This is because Ethereum imposes 24.576 bytes as a maximum size for a smart contract file; a limit that is exceeded by the Circom smart contracts for the 25 Γ 25 and 36 Γ 36 grids and by ZoKrates contracts for the 36 Γ 36 grid, resulting in an exception during the smart contract generation thus making not possible to deploy the corresponding smart contract. For instance, the 36 Γ 36 Sudoku configuration requires two 36 Γ 36 grids (one for the starting grid and one as the solution) in input, namely 2.592 integers. When the smart contracts were deployable for both Circom and Zokrates, the deployment cost of the ones generated by Circom is always considerably cheaper.
The same trend is confirmed on the execution costs, i.e., the costs for executing the smart contract to verify the proof on the blockchain, as shown in Figure 5. Hence, the execution of the Circom-produced code results cheaper than the execution of the Zokrates one.
Given a(n undirected) graph, an Hamiltonian cycle [29] is a closed path in the graph that visit every node only once. Hamiltonian cycles are applied in several disciplines, such as computer graphics, genomic mapping, electronic circuit design and more others.
In our tests, a prover generates a proof to convince a verifier that they know a valid Hamiltonian cycle (which will be the witness) for a given graph (which is instead the public input). We defined this final scenario to test the two libraries in a more realistic setting, where both the primitives constructions of the language and the calls to external libraries are executed in the same program, making it possible to evaluate the two libraries in their entirety.
The graphs for this experiment were built in such a way that, for any two nodes π and π, the edge (π, π) exists with probability π = 0, 5 (then, the produced graphs were adapted accordingly, so that an Hamiltonian cycle always exists). We considered graphs consisting of 5, 8, 10, 15 and 50 nodes. For conducting our experiments, we passed as inputs the adjacency matrices of the graphs (for an π-node graph, its adjacency matrix has π Γ π entries) and the (solution) hamiltonian cycles as arrays of π elements.
Table 4 illustrates the storage occupation resulting from the implementation of the proving workflow for each of the mentioned scenarios. This results follows the trend observed by in the previous experiments, with Circom implementation producing smaller circuit files and proving keys for every scenario instance. More specifically, the size of the Circom circuits increases with the size of the graph, and for 50 nodes, the Circom circuit file size is 401 KB, while for ZoKrates the file is about 100 MB. Regarding proving key, its size increases with the dimension of the graph as well, and we have that, for a graph of 50 nodes, the Circom implementation proving key size is 3,2 MB, against the 106 MB of the ZoKrates one. Also Proofs and Verification Keys sizes increase with the graph dimension, and the former are lower in the Circom implementation, while the latter are slightly lower in the Zokrates implementation. However, the differences in size for Proofs and Verification Keys are considerably less significant than the ones for Circuit Files and Proving Keys. for Circom, smart contract deployment and execution costs are smaller than Zokrates' ones. Also, there is a deployment failure for the 50-node graph verifier contract: it would require to process a total of 2.550 inputs (2.500 for the 50 Γ 50 adjacency matrix and 50 for the solution), and the contract size would exceed the maximum size supoported for a single smart contract (like in the 36 Γ 36 Sudoku scenario).
In this section, we discuss the insights provided by the experimental results presented in the previous section. From a quantitative point of view, the results show that the dimension of the circuit file and the proving key size grow with the size of the input instances considered. This growth is steady for both Circom and ZoKrates in the scenarios we considered; even though for small inputs Circom and ZoKrates achieve comparable performances (in terms of circuit file size and proving key size), for bigger inputs Circom outperforms ZoKrates since it manages to keep the files size lower. For instance, in our experiments the size of the Circuit files produced by Circom is in the order of tens of MB, while for ZoKrates the size of the Circuit files sometimes reach the order of GB. This suggests that the Circom library performs better when the input size grows significantly, making it more suitable for managing situations where off-chain storage occupation matters, for instance when IoT devices, that usually have limited storage capabilities, are used.
Regarding the actual Proof size and the Verification Key size, in our experiments both Circom and ZoKrates manage to keep the storage occupation low (under 1 MB) without a library that clearly outperforms the other: we argue that this would not have been relevant even if this was the case since the storage occupation of the proof and the verification key files is negligible compared with the storage occupation of the Circuit and the Proving Key files.
For what concerns the on-chain costs, we observe a similar behavior, with Circom smart contracts generally cheaper than the ZoKrates ones. However, as highlighted by the Sudoku solution scenario, ZoKrates optimizes better the smart contract generation, since it managed to compile the contract to handle 25 Γ 25 Sudoku grids while Circom did not.
Although the quantitative experimental results show that Circom performs better than ZoKrates, the latter turns out to be more developer friendly, having a higher-level programming language if we compare it with the Circom one. We argue that a higher-level (and thus, easier to use) programming language not only provides a (non-negligible) advantage in terms of development experience, but helps to prevent bugs and inefficiencies that could possibly come up when implementing dApps that perform non-trivial tasks.
Figure 8 gives a view about the coding experience using the Circom and ZoKrates languages, considering only the lines of code needed to define the circuits. We did not take into account the smart contracts code because it is generated automatically, and then not coded by the developer. Considering the implementation of the three analyzed scenarios, the figures shows that coding in ZoKrates requires a number of effective lines of code sensibly lower than coding in Circom. This is particularly appreciable on the Sudoku solution case, where ZoKrates requires less than half lines of code with respect of the counterpart Circom program to achieve the same result (80 for the ZoKrates program, 193 for the Circom one). Furthermore, we noticed that Circom codes need of import several external modules to perform operations, such as comparisons between values. On the other hand, ZoKrates appears to be Additionally, ZoKrates manages the entire proof generation workflow without any crucial external dependency (such as snarkJS, that is necessary for Circom's workflow instead), and that could lead to an easier adoption of the tool. In the light of these considerations, the choice of one library instead of the other has to be weighted to several factors, such as developer comfort and skills, available off-chain storage, problem complexity.
In this paper we propose a comparative study to benchmark the performances of Circom and ZoKrates, two among the major libraries used to generate zkSNARK proofs in blockchain related applications and to verify them on-chain. The comparison was performed considering several scenarios of increasing complexity, in which a prover holds a secret witness and aims to prove the knowledge about such witness without disclosing it to the verifier. We have evaluated the entire workflow, from the proof generation to its verification. The proofs are verified by a smart contract generated by the libraries. The witnesses to prove the knowledge of were: i) to be older than a certain age threshold, ii) a valid solution for a Sudoku grid, iii) a valid hamiltonian cycle for a graph. We implemented several instances for each of these scenarios, increasing the input size, and consequently the computational charge, at each stage. Finally, we evaluated the performances of the two libraries against the mentioned scenario implementations, collecting measurements about several parameters, in particular the verifier smart contract gas costs and the storage costs at Layer 2.
Our findings highlight that the proving workflows produced by Circom appears cheaper in both Layer 2 storage occupation and smart contract costs on every tested scenario. However, even if Circom appears more performing than ZoKrates on the evaluated scenarios, the coding experience provided by the ZoKrates language was overall more fluid and produced more readable and compact code, as showed for example by our analysis of the effective lines of code needed to code the scenarios.
As future works, we plan to enrich the study defining more scenarios involving blockchain related problem, such as the transaction anonymization or the privacy preserving proof of ownership, or scenarios in which features like witness succintness is more crucial. We also plan to evaluate more parameters, such as the time to execute the various workflow steps (proof generation, proof verification, trusted setup...) and the scalability in terms of gas with respect of executing the same statements on a classic Layer 1 Ethereum smart contract. Finally, we will consider to include more libraries in the comparison.
This work was partially supported by project SERICS (PE00000014) under the MUR National Recovery and Resilience Plan funded by the European Union -NextGenerationEU. Additionally, it was partially funded by Ministero dell'UniversitΓ e della Ricerca (MUR), issue D.M. 352/2022 "Borse di Dottorato" -Dottorato di Ricerca di Interesse Nazionale in "Blockchain & Distributed Ledger Technology", under the National Recovery and Resilience Plan (NRRP).