Security Model
OpenVM targets 100 bits of provable security.
The proving pipeline produces two kinds of proofs: STARK proofs for the core VM execution and aggregation, and a final EVM proof for on-chain verification.
STARK Proofs
OpenVM uses SWIRL, a sumcheck-based proof system with WHIR as the polynomial commitment scheme, over the BabyBear field. The interaction argument uses GKR LogUp; see Improving logarithmic derivative lookups using GKR.
Assumptions
- The Fiat-Shamir transformation uses a duplex sponge and is secure in the ideal permutation model. We instantiate the permutation with Poseidon2.
- Soundness is based on provable proximity gaps theorems. It does not rely on the ethSTARK toy problem conjecture or any proximity gaps conjectures.
- We use proof-of-work grinding to increase the prover work required to bias
Fiat-Shamir challenges. In our security accounting, a
w-bit grinding condition contributeswbits of security to the round in which it is applied, and costs about2^wadditional Fiat-Shamir permutation invocations in expectation; the concrete cost depends on the instantiated permutation (here, Poseidon2). In our parameter choices,w <= 20.
Proof Types
The Continuations Design uses the following STARK proof types:
app— one proof per execution segmentleaf— aggregates app proofsinternal-for-leaf— aggregates leaf proofsinternal-recursive— recursively aggregates internal proofsroot— final STARK proof, input to EVM wrapping
Parameters
The WHIR protocol parameters that determine the security level are:
| Parameter | Description |
|---|---|
log_blowup | Base-2 log of the inverse rate of the code used in WHIR |
num_rounds | Number of WHIR rounds |
k_whir | Binary fold factor (number of sumcheck steps per WHIR round) |
num_queries | Per-round query schedule; each WHIR round has its own number of in-domain queries |
mu_pow_bits | Number of proof-of-work grinding bits for the mu sampling phase |
folding_pow_bits | Number of proof-of-work grinding bits for folding challenges |
query_phase_pow_bits | Number of proof-of-work grinding bits for the query phase |
log_final_poly_len | Base-2 log of the final polynomial coefficient count |
Under the default OpenVM settings, the concrete production parameters are shown
below. The table also includes protocol-shape parameters that are not direct
security knobs. Using Gruen's univariate skip technique from
Some Improvements for the PIOP for ZeroCheck,
the first univariate round uses a domain of size 2^{l_skip}, effectively
collapsing l_skip sumcheck rounds into one.
n_stack is the number of remaining multilinear sumcheck rounds, so each stacked
trace has height 2^{l_skip + n_stack}. w_stack bounds the number of stacked
columns, so each stacked trace has width at most w_stack and therefore contains at
most 2^{l_skip + n_stack} * w_stack cells.
| Proof | log_blowup | l_skip | n_stack | w_stack | k_whir | num_rounds | num_queries by round | mu_pow_bits | folding_pow_bits | query_phase_pow_bits | log_final_poly_len | Proximity regime |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
app | 1 | 4 | 20 | 2048 | 3 | 5 | [193, 97, 84, 81, 81] | 15 | 5 | 20 | 9 | unique decoding |
leaf | 2 | 4 | 17 | 2048 | 3 | 4 | [118, 88, 82, 81] | 13 | 4 | 20 | 9 | unique decoding |
internal-for-leaf | 3 | 2 | 17 | 512 | 3 | 3 | [67, 37, 25] | 20 | 18 | 20 | 10 | list decoding, m = 2 |
internal-recursive | 3 | 2 | 17 | 512 | 3 | 3 | [67, 37, 25] | 20 | 18 | 20 | 10 | list decoding, m = 2 |
root | 4 | 2 | 19 | 9 | 3 | 4 | [47, 30, 22, 17] | 20 | 20 | 20 | 9 | list decoding, m = 2 |
Additional shared defaults:
log_up_pow_bits = 18(number of proof-of-work grinding bits in LogUp)log_max_message_length = 7(base-2 log)max_interaction_count = 2^31 - 2^27 + 1(the BabyBear field modulus)max_constraint_degree = 4
The app row above is the default SDK configuration, which uses
MAX_APP_LOG_STACKED_HEIGHT = 24, so n_stack = 24 - l_skip = 20. The
internal-for-leaf and internal-recursive layers intentionally share the same
default production parameter set.
These values are the default production settings configured in stark-backend, which also includes a soundness calculator that computes the provable security level from a given set of parameters.
EVM Proofs
The root STARK proof is wrapped into an EVM-verifiable proof (static_verifier)
using halo2 with a KZG backend, as originally designed by
ZCash and forked by
PSE and
Axiom. This step relies on a one-time
universal trusted setup.
Trusted Setup
We use the Perpetual Powers of Tau setup run by the Ethereum Foundation, specifically this challenge.
The challenge file challenge_0085 was converted from its original format compatible
with snarkjs and the Groth16 proof
system to a format usable by halo2 using the following
open-source code.
To verify the conversion of the file challenge_0085, download it and run:
git clone https://github.com/axiom-crypto/phase2-bn254.git
cd phase2-bn254
git switch halo2
# https://github.com/axiom-crypto/phase2-bn254/commit/0bd58f1311bdb54329686e4d0914006d602e0082
cd powersoftau
wget https://pse-trusted-setup-ppot.s3.eu-central-1.amazonaws.com/challenge_0085
cargo build --release --bin convert_to_halo2
time cargo run --release --bin convert_to_halo2 -- challenge_0085 28 2097152To reduce the time of conversion, only the the first 2^25 powers were converted. For convenience, the resulting
halo2-compatible trusted setup files are hosted below by Axiom (k means 2^k powers of tau):