Benchmarking ZK-Friendly Hash Functions and SNARK Proving Systems for EVM-compatible Blockchains

TL;DR

This work provides a benchmark for ZK-friendly hash functions and ZK tools, while also exploring cost efficiency and compliance in ZKP-based privacy-preserving transaction protocols.

Abstract

With the rapid development of Zero-Knowledge Proofs (ZKPs), particularly Succinct Non-Interactive Arguments of Knowledge (SNARKs), benchmarking various ZK tools has become a valuable task. ZK-friendly hash functions, as key algorithms in blockchain, have garnered significant attention. Therefore, comprehensive benchmarking and evaluations of these evolving algorithms in ZK circuits present both promising opportunities and challenges. Additionally, we focus on a popular ZKP application, privacy-preserving transaction protocols, aiming to leverage SNARKs' cost-efficiency through "batch processing" to address high on-chain costs and compliance issues. To this end, we benchmarked three SNARK proving systems and five ZK-friendly hash functions, including our self-developed circuit templates for Poseidon2, Neptune, and GMiMC, on the bn254 curve within the circom-snarkjs framework. We also introduced the role of "sequencer" in our SNARK-based privacy-preserving transaction scheme to enhance efficiency and enable flexible auditing. We conducted privacy and security analyses, as well as implementation and evaluation on Ethereum Virtual Machine (EVM)-compatible chains. The results indicate that Poseidon and Poseidon2 demonstrate superior memory usage and runtime during proof generation under Groth16. Moreover, compared to the baseline, Poseidon2 not only generates proofs faster but also reduces on-chain costs by 73% on EVM chains and nearly 26% on Hedera. Our work provides a benchmark for ZK-friendly hash functions and ZK tools, while also exploring cost efficiency and compliance in ZKP-based privacy-preserving transaction protocols.

Figures (10)

• Figure 1: The arithmetic circuit $C(x_1, x_2, x_3, x_4) = (x_1 + x_2) \cdot (x_3 \cdot x_4)$ over $\mathbb{F}_q$ in different representations. Fig. \ref{['dag']} shows Graph representation. Fig. \ref{['r1cs']} shows R1CS representation. Fig. \ref{['plonkish']} shows Plonkish representation.
• Figure 2: Implementing ZK-SNARKs protocols in WASM and JavaScript (snarkjs) snarkjs. The solid rectangle represents user-defined parameters or circuit templates, while the dashed rectangle represents files generated by snarkjs.
• Figure 3: \ref{['fig:c1']} and \ref{['fig:c2']} respectively show the relationship between the circuit power of templates containing five types of ZK-friendly hash functions and the depth of the Merkle tree in R1CS-based proof systems (groth16) and Plonkish-based proof systems (plonk, fflonk). In each template for different Merkle tree depths, the most efficient hash function's circuit power is highlighted.
• Figure 4: Figure \ref{['fig:run_hash']} shows the relationship between the runtime of the setup and prove phases in the groth16 proof system and the depth of the Merkle tree for circuit templates containing five types of ZK-friendly hash functions. In each template for different Merkle tree depths, the runtime of the most efficient hash function is highlighted. Figure \ref{['fig:ram_hash']} illustrates the ratio of memory consumption among these different hash function circuit templates at various Merkle tree depths. The memory consumption of a single MiMC at depth 0 is set as the baseline value of unit 1. In each pane, resource-intensive tests are shown in dark colors, while efficient ones are in light colors.
• Figure 5: Figure \ref{['fig:run_proof']} shows the relationship between the runtime of the setup and prove phases and the depth of the Merkle tree for MiMC hash function circuit templates across three proof systems. In each template for different Merkle tree depths, the runtime of the most efficient hash function is highlighted. Figure \ref{['fig:ram_proof']} illustrates the ratio of memory consumption among these test circuits running on different proof systems at various Merkle tree depths. The memory consumption of a single MiMC in groth16 at depth 0 is set as the baseline value of unit 1.