Security Model
This section describes the security model, security parameters, and cryptographic assumptions for OpenVM. For a technical overview of the OpenVM design, see the whitepaper.
Cryptographic Security
OpenVM targets 100 bits of provable security and relies upon a FRI-based backend for STARK proofs and a halo2-based backend for EVM proofs.
Cryptographic Assumptions
The STARKs for OpenVM use FRI over the BabyBear field as implemented in Plonky3 with LogUp for lookup arguments. We use the following assumptions in our soundness analysis:
- We use proof-of-work grinding to increase bits of security as described in Section 3.11.3 of the ethSTARK paper.
- We use proof-of-work grinding to boost LogUp soundness as described in Section 4 of our analysis.
- We analyze STARK soundness using theorems on batched FRI and DEEP-ALI with correlated agreement in the unique decoding regime (UDR).
The EVM proofs for OpenVM use halo2 with a KZG backend as originally designed by ZCash and forked by PSE and Axiom. It relies on a one-time universal trusted setup, for which we use the Perpetual Powers of Tau setup run by the Ethereum Foundation, specifically this challenge. To learn more about this trusted setup, see the Details on Universal Trusted Setup section.
Security Parameters
We now specify security parameters used in the proofs:
- STARK proofs:
app,leaf,internal,root - EVM proofs:
static_verifier
involved in the Continuations Design under default settings. These parameters are of three types:
- FRI parameters:
log_blowup,num_queries,query_proof_of_work_bits, andcommit_proof_of_work_bitsto control the soundness of the FRI argument used to generate proofs for the STARKs. - LogUp parameters:
max_interaction_count,log_max_message_length, andlog_up_pow_bitsare parameters controlling the soundness of the LogUp argument as described in our soundness analysis. - DEEP-ALI parameters:
deep_pow_bitsto control the soundness of the DEEP algebraic linking (DEEP-ALI) argument used in the STARK protocol.
The concrete parameter values used by OpenVM are specified in the table below.
| Proof | Type | Security Bits | log_blowup | num_queries | query_proof_of_work_bits | commit_proof_of_work_bits | max_interaction_count | log_max_message_length | log_up_pow_bits | deep_pow_bits |
|---|---|---|---|---|---|---|---|---|---|---|
app | STARK | 100 | 1 | 193 | 20 | 20 | 15 * 2^27 + 1 | 7 | 18 | 5 |
leaf | STARK | 100 | 1 | 193 | 20 | 20 | 15 * 2^27 + 1 | 7 | 18 | 5 |
internal | STARK | 100 | 2 | 118 | 20 | 16 | 15 * 2^27 + 1 | 7 | 18 | 5 |
root | STARK | 100 | 3 | 97 | 20 | 16 | 15 * 2^27 + 1 | 7 | 18 | 5 |
static_verifier | Halo2 | 100+ | -- | -- | -- | -- | -- | -- | -- | -- |
Details on Universal Trusted Setup
The challenge file for our universal trusted setup
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 the file 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):