🔎 Reports: summary · individual zkVMs
A universal soundness calculator across hash-based zkEVM proof systems and security regimes.
It aims to answer questions like:
- "What if RISC0 moves from Babybear⁴ to Goldilocks³?"
- "What if OpenVM moves from the Toy Problem heuristic to the provable Johnson Bound Regime?"
- "What if ZisK moves from the Toy Problem heuristic to the provable Unique Decoding Regime?"
You can run the calculator by doing python3 -m soundcalc.
As a result, the calculator generates / updates reports in reports/.
Tests can be run with pytest.
We currently support the following zkEVMs:
We support the following security regimes (see below for explanation of regimes):
- Unique Decoding Regime (UDR)
- Johnson Bound Regime (JBR)
Consider a fixed set of parameters describing the prover and verifier of a FRI-based zkEVM.
To evaluate the concrete soundness level of such a system, we introduce a parameter θ in the range (0, 1).
The soundness level is then determined as a function of θ and the zkEVM parameters (e.g., field size, code rate).
Depending on the value of θ, the analysis falls into different regimes:
-
UDR (Unique Decoding Regime):
$\theta \leq (1 - \rho)/2$ , where$\rho$ is the code rate. -
JBR (Johnson Bound Regime):
$(1 - \rho)/2 < \theta < 1 - \sqrt{\rho}$ .
Crucially, θ is not an input to the prover or verifier code—it is only used in the soundness analysis.
All regimes therefore apply to the same zkEVM instance without any change.
The soundcalc proof size estimate is based on counting Merkle proofs and their sizes. It is only an estimate and should be treated as such. To get the actual proof size you need to run the actual prover.
Reports show two estimates:
- Expected: Accounts for Merkle path sharing when random queries overlap in the tree (path pruning optimization)
- Worst case: Assumes no overlap: each query contributes a full independent path.
In practice, actual proof sizes tend to be closer to the expected estimate.
A flurry of new results on proximity gaps were published in November 2025 (see Nico's summary).
In soundcalc we have incorporated:
- The improved JBR security bounds of BCHKS25
- The removal of the CBR regime, following the results of DG25 and CS25
soundcalc/main.py: Entry pointsoundcalc/zkvms/: One directory per supported zkVMsoundcalc/proxgaps/: Proximity gaps related functionalitysoundcalc/pcs/: Polynomial commitment schemes functionalitysoundcalc/common/: Common utilities used by the entire codebasesoundcalc/report.py: Markdown report generator (ugly!)
Inspiration:
Based on papers (links point to specific versions where possible):