Skip to content

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 contributes w bits of security to the round in which it is applied, and costs about 2^w additional 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 segment
  • leaf — aggregates app proofs
  • internal-for-leaf — aggregates leaf proofs
  • internal-recursive — recursively aggregates internal proofs
  • root — final STARK proof, input to EVM wrapping

Parameters

The WHIR protocol parameters that determine the security level are:

ParameterDescription
log_blowupBase-2 log of the inverse rate of the code used in WHIR
num_roundsNumber of WHIR rounds
k_whirBinary fold factor (number of sumcheck steps per WHIR round)
num_queriesPer-round query schedule; each WHIR round has its own number of in-domain queries
mu_pow_bitsNumber of proof-of-work grinding bits for the mu sampling phase
folding_pow_bitsNumber of proof-of-work grinding bits for folding challenges
query_phase_pow_bitsNumber of proof-of-work grinding bits for the query phase
log_final_poly_lenBase-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.

Prooflog_blowupl_skipn_stackw_stackk_whirnum_roundsnum_queries by roundmu_pow_bitsfolding_pow_bitsquery_phase_pow_bitslog_final_poly_lenProximity regime
app1420204835[193, 97, 84, 81, 81]155209unique decoding
leaf2417204834[118, 88, 82, 81]134209unique decoding
internal-for-leaf321751233[67, 37, 25]20182010list decoding, m = 2
internal-recursive321751233[67, 37, 25]20182010list decoding, m = 2
root4219934[47, 30, 22, 17]2020209list 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 2097152

To 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):

kLink
15https://axiom-crypto.s3.amazonaws.com/challenge_0085/kzg_bn254_15.srs
16https://axiom-crypto.s3.amazonaws.com/challenge_0085/kzg_bn254_16.srs
17https://axiom-crypto.s3.amazonaws.com/challenge_0085/kzg_bn254_17.srs
18https://axiom-crypto.s3.amazonaws.com/challenge_0085/kzg_bn254_18.srs
19https://axiom-crypto.s3.amazonaws.com/challenge_0085/kzg_bn254_19.srs
20https://axiom-crypto.s3.amazonaws.com/challenge_0085/kzg_bn254_20.srs
21https://axiom-crypto.s3.amazonaws.com/challenge_0085/kzg_bn254_21.srs
22https://axiom-crypto.s3.amazonaws.com/challenge_0085/kzg_bn254_22.srs
23https://axiom-crypto.s3.amazonaws.com/challenge_0085/kzg_bn254_23.srs
24https://axiom-crypto.s3.amazonaws.com/challenge_0085/kzg_bn254_24.srs
25https://axiom-crypto.s3.amazonaws.com/challenge_0085/kzg_bn254_25.srs