Introducing the ZK Catalog
Introducing the ZK Catalog, a place to aggregate information about source code verification of onchain ZK verifiers.
Background
Unverified contracts should be treated as potentially malicious and shouldn’t be trusted.
Etherscan has provided for years an amazing service for hosting Solidity source codes that are remotely verified and easily reproducible, but in the era of ZK this is not enough. For comparison, this is what the Polygon zkEVM verifier’s source code looks like:
How can we check that Polygon zkEVM is indeed verifying a zkEVM and not some dummy, or worse, malicious program? If you want to find out all the ways ZK projects can fool users, check out this amazing thread by Kobi Gurkan:
ZK verifiers regeneration
ZK verifiers have an onchain representation of the program being proven in the form of “verification keys” or a “program hash”. In the same way a Solidity contract gets verified by generating its bytecode and having it matched with the one onchain, a ZK source code is checked against a verifier by regenerating the verification keys or its program hash.
The procedure is not as standard though: different proof systems require different tools and different steps, for example depending on whether there is a trusted setup or not to be verified. Additionally, there might be multiple nested ZK verifiers in case of recursive proof aggregation or in case of “proof wrapping” of one proof system into another. For complex circuits, a powerful machine might be required: in the case of Polygon zkEVM, one needs at least a 256GB RAM machine with 16 cores to run for 5–6 hours. Since the space is still in its early days, many projects decide to build their own languages, compilers and tools, which adds significant complexity and therefore trust in the codebase, even if successfully checked against the verifier.
Our experience: the Semaphore and SMTB case
We started this effort as part of a grant funded by Worldcoin. Worldcoin uses two types of relatively simple ZK circuits: Semaphore, used to check whether an address is contained in the anonymity set in a privacy-preserving way, and the Semaphore Merkle Tree Batcher (SMTB), used to update such anonymity set.
Semaphore circuits are independently developed by the Ethereum Foundation’s PSE team. Since Semaphore uses Groth16 as its proving system, it requires a circuit-specific trusted setup (as opposed to a universal one, like in KZG-based proof systems).
To make the connection between the source code and the onchain verifier, one needs to first generate the *.r1cs file from the *.circom file, then check the trusted setup contributions (***.zkey), generate the keys and finally the verifier contract.
While it is possible to make the connection between the (claimed) *.r1cs file and the onchain verifier, we were not able to compile the *.circom source code to it since the compiler version used at the time of the trusted setup appears to be non-deterministic: even after compiling the file thousands of times, we were not able to regenerate the same compiled file. The issue appears to be in the order in which the constraints are written, and a solution is currently under investigation.
Another obstacle that we encountered during the verification of the SMTB circuits is verification guides not specifying the tools’ versions and specific repo commits used at the time of the verifier generation which made debugging extremely difficult. Special thanks to dcbuilder, Marcin Kostrzewa, Eric Woolsey and Jakub Trad for spending a lot of time going through the process with me to successfully verify one of the SMTB circuits.
The ZK Catalog: present & future
We introduce the ZK Catalog as a place to aggregate the information about source code verification of ZK programs and standardize practices where possible to make it easy for everyone to go through the process with the minimum trust and effort involved. The Catalog also aims to provide detailed information on the proof system architecture of the listed projects.
Since most projects make use of custom tooling, processes and need specific hardware, it’s not currently possible to have an automated backend that performs verifications like Etherscan in the general case. As a temporary solution, L2BEAT will provide attestations on the verification status of projects for which we’ve performed the regeneration procedure in the form of badges, with the goal to create a decentralized system where everyone can publish attestations and automate processes where possible.
We invite everyone to contribute to this effort by submitting onchain verifiers (of any type!) to the Catalog and help provide more transparency and more (than zero) knowledge to the space!
