BCH native Groth16 verifier contract
Earlier this week I launched a new initiative to build optimized Groth16 verifier contracts for Bitcoin Cash called Verifier.cash.
It’s a collaborative, open research project and competition to build the smallest Groth16 zero-knowledge proof verifier that runs on Bitcoin Cash. The initiative is inspired by ecdsa.fail which has seen great success and participation but uses it to try and break crypto. This mirror-image initiative is instead to build up and strengthen crypto.
Benchmarking
I started the leaderboards with the sCrypt BN254 verifier they built in 2022 and the nChain BLS12-381 verifier built in 2024 but neither of these verifiers fit within BCH’s VM limits or leverage the new BCH primitives like bounded loops and reusable functions.
First I built a verifier benchmark using Libauth to test against the BCH VM (with and without VM limits/contract limits enforced). then I used Opus 4.8 to build the first BCH Groth16 verifiers which leverage the new upgrades.
Categories
The leaderboard has 3 categories: a “single-input” version which is the most optimized ideal but does not fit in the contract or VM limits, a “single non-standard transaction” version which uses many contract inputs and only disregard the maximum transaction size limit, and thirdly a “standard transaction” version which ends up needing to split/chunk the verifier over 3 separate transactions, each with many contract inputs.
Results
From the website (as of writing), the smallest BN254 verifier built in BCH is the following size for each category
- ~16 KB single input for the category ignoring VM and contract limits
- ~288 KB single transaction, 33 inputs for category ignoring transaction size standardness
- ~288 KB 3 transactions, 33 inputs for category with standard BCH transactions
The same Groth16 verifier shows up as two very different numbers. On BN254, as one input it is just 16 KB , the smallest and simplest form, but it busts Bitcoin Cash’s per-input limits and can’t run on chain. To actually fit, the work is split across 33 inputs, which brings the total to 258 KB .
That ~16× difference is the chunking overhead : the price of splitting one computation across many inputs, not extra cryptographic work. Entries are scored on total on-chain bytes, since bytes are what a user pays in fees.
Upgrades in action
The initiative highlights how Bitcoin Cash’s recent upgrades unlocked the power to run a Groth16 verifier on chain. BCH is entering the space age, and I don’t think people are realizing it.
