Over the last few years, the popularity of proving systems based on zkSNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) has risen, typically due to real-world use cases such as private authentication, private set membership, proofs of correct execution by a non-trusted entity and more.

There are different proving systems that have been proposed in the last 5-7 years (Groth16, Marlin, PLONK, TurboPLONK, etc.), with their primary objectives being reducing the size of the proof, reducing the proving/verifying time and minimizing the need for a trusted setup. Further, there are different ways to implement zkSNARKs, but the common idea behind all of them is that the construction has to be represented in an arithmetic circuit on top of a finite field. This is possible using domain-specific languages (DSLs) such as Circom or Leo, or using a library such as gnark, Halo2 or arkworks-rs.

In the aforementioned applications, typically, encryption and hashing operations are needed. However, the performance of traditional designs such as AES or BLAKE2 is not optimal in circuits. This has led to the apparition of arithmetization-oriented constructions for hashing and encryption. Moreover, the Sponge API for Field Elements (SAFE API) has been recently proposed, which can be used to create different cryptographic primitives for zkSNARK circuits using the sponge construction. In many cases, the performance of this type of constructions and the difficulty of implementing them using modern libraries for creating circuits has not been evaluated.

In this talk, we present zekrom, an open-source library of arithmetization-oriented constructions for zkSNARK circuits. The goal of zekrom is to analyze the performance of novel constructions for circuits using modern libraries such as arkworks-rs and Halo2 and frameworks such as the SAFE API. Other goals of zekrom are: 1) to provide recently proposed arithmetization-oriented constructions for creating privacy-friendly applications based on zero-knowledge proofs, 2) to help developers by providing tools to generate the type of parameters that this type of constructions require, and 3) to provide a reusable implementation of the SAFE API that can be easily adapted to new proposed permutations for circuits. Finally, in our talk, we'll describe the obstacles we have found when implementing this type of construction.