zk-STARKs: Scalable Zero-Knowledge Proofs

• zk-STARKs are cryptographic proof systems that offer scalable, transparent, and post-quantum secure zero-knowledge proofs without relying on a trusted setup.
• They use the Interactive Oracle Proof framework with low-degree testing (FRI) and hash-based commitments to achieve succinct verification with polylogarithmic complexity.
• Applied in blockchain rollups, decentralized identity, and verifiable computation, zk-STARKs benefit from parallelizable implementations for enhanced performance.

Zero-Knowledge Scalable Transparent ARguments of Knowledge (zk-STARKs) are a class of cryptographic proof systems supporting succinct, non-interactive zero-knowledge (ZK) proofs without trusted setup. Developed within the Interactive Oracle Proof (IOP) framework, zk-STARKs achieve scalability for NP statements, maintain transparency through hash-based commitments, and are conjectured to be post-quantum secure since their soundness relies only on the collision resistance of hash functions rather than hardness assumptions underlying elliptic curve cryptography. STARKs have been adopted as building blocks in privacy-preserving computation and scalable verification for rollups, decentralized identity, and verifiable computation in blockchain environments (Nainwal et al., 10 Dec 2025, Yuan, 10 Oct 2025).

1. Theoretical Foundations

zk-STARKs instantiate the IOP model, where the prover produces messages encoded as oracles—typically evaluations of low-degree polynomials—accessible by the verifier through a limited number of queries. The reduction of an NP statement to a STARK proceeds through the following stages:

1. Arithmetization: Encode the execution trace of the computation as a low-degree polynomial $P$ over a finite field $\mathbb{F}_q$. This typically involves mapping the original circuit or constraint system to a set of polynomial relations (see Section 4.1 in (Yuan, 10 Oct 2025) for circuit encoding strategies).
2. Commitment: Commit to all evaluations $\{P(x)\}_{x\in G}$ via a Merkle tree, where $G$ is a suitably chosen evaluation domain.
3. Low-Degree Testing (FRI): Using public-coin challenges via Fiat–Shamir, the verifier directs the prover to perform probabilistic checks (notably, the Fast Reed–Solomon IOP of Proximity, FRI) to demonstrate that $P$ is of low degree. Only a polylogarithmic number of queries to the oracle are necessary for sublinear verification.

The protocol’s soundness error is governed by the number of FRI rounds and the field size. Let $n = |G|$ denote the domain size, $d$ the polynomial degree ($d < n$), and $\lambda$ the security parameter. The typical complexities are:

• Prover time: $O(n\log n)$, dominated by FFT-based low-degree extension, Merkle tree construction, and FRI folding.
• Verifier time: $O(\log n\log d)$, since only $O(\log d)$ FRI queries and Merkle-path verifications are needed.
• Proof size: $$\mathrm{ProofSize}(\lambda, d) \approx O(\kappa\log d + \lambda\log d\log n)$$, with $\kappa$ the Merkle digest size.

These complexities are realized by hashing and polynomial arithmetic (interpolation, evaluation, multiplication).

2. Security and Trust Assumptions

zk-STARKs employ a fully transparent setup. All system parameters are generated deterministically, and no trusted party or multi-party computation (MPC) is required, contrasting sharply with structured reference string (SRS) requirements for zk-SNARKs (Nainwal et al., 10 Dec 2025).

• Soundness: Relies exclusively on the collision resistance of the hash function used in Merkle commitments and Fiat–Shamir challenges (e.g., SHA-256 or SHA3-256).
• Zero-Knowledge: Leveraging randomness derived from the Fiat–Shamir transform, the protocol is made non-interactive while retaining the ZK property.
• Post-Quantum Security: Security analysis assumes only that the hash function remains collision-resistant in a post-quantum setting.

Field choice and soundness error are parametrized to ensure negligible adversarial advantage even in large-scale deployments (e.g., Cairo’s 250-bit field achieves per-round soundness $\leq 2^{-250}$, further reduced across FRI repetitions) (Yuan, 10 Oct 2025).

3. Implementation-Level Performance and Bottlenecks

Empirical measurements on contemporary hardware quantify the computational requirements of practical STARK implementations. For a Go reference STARK system executed on an Apple M1 (ARM64):

• Proof generation: 3809.64 ms
• Proof verification: 472.25 ms
• Proof size: 68,564 bytes

Profiling reveals the principal computational hotspots:

Profiling Component	% CPU Time	Role
stark.TestZKGen.func2	23.94%	Orchestration of interpolation and FRI steps
poly.Polynomial.Eval	12.42%	Polynomial evaluation in trace/FRI queries
math/big.(*Int).Mod	10.61%	Modular reduction in large prime field ops
stark.GenerateProgramConstraints	9.39%	Constraint system and boundary encoding
math/big.(*Int).QuoRem	9.09%	Division/remaindering for field arithmetic
poly.Polynomial.Mul	4.85%	Multiplication in constraint polynomials

Aggregate field arithmetic and polynomial I/O constitute over 60% of prover runtime (Nainwal et al., 10 Dec 2025).

In a Cairo-based implementation on an 8-core Intel Xeon (with ~5,000 constraints for age-verification and ~4,000 for non-revocation):

• Prover time: ~3.5 s (STARK) vs. ~5.0 s (Groth16 SNARK)
• Verifier time: ≤5 ms (off-chain)
• Proof size: ~45 KB
• Trusted setup: None required

STARK provers benefit considerably from parallelization during polynomial extension and Merkle hash computation (Yuan, 10 Oct 2025).

4. Low-Degree Testing and FRI

FRI, the central low-degree testing primitive in zk-STARKs, recursively folds the evaluation vector to halve its length per round. At each FRI step, the transformation

$$\text{FRI\_Layer}(\text{polyVals}, \beta)[i] = \text{polyVals}[2i] + \beta \cdot \text{polyVals}[2i+1]$$

is applied, followed by Merkle-committing to the new vector and sampling random positions for the next round. Proof soundness error is reduced exponentially with each fold, and the presenter opens a polylogarithmic number of commitments across rounds (Nainwal et al., 10 Dec 2025).

5. Practical Considerations and Tuning

The efficiency, soundness, and applicability of zk-STARKs are influenced by a variety of tunable parameters and engineering trade-offs:

• FRI Round Selection ($r$): Typically $r = \lceil\log_2 d\rceil$, reducing degree to 1. Each round adds Merkle roots and opening proofs but improves soundness exponentially.
• Domain Extension Factor ($\alpha$): Larger extension factors increase soundness at the expense of higher prover computation and proof size. Practical deployments choose $\alpha$ between 4 and 8 (Nainwal et al., 10 Dec 2025).
• Hash Function and Digest Size ($\kappa$): Standard choices are SHA3-256 or SHA-256, with digest size selected to meet or exceed the required security parameter ($\lambda$). Security levels can be tuned by employing larger/smaller digests if desired.
• Parallelism: The polynomial interpolation, FFTs, and Merkle hashing steps exhibit high parallelizability. Multi-core and GPU implementations achieve quasi-linear speedups (Yuan, 10 Oct 2025).
• Batch Verification/Proof Generation: When verifying multiple STARK proofs, common FRI rounds or Merkle path data can be deduplicated to amortize overhead.

6. Applied Use Cases and Integrations

zk-STARKs are increasingly deployed in general-purpose privacy-preserving protocols, decentralized identity, and scaling solutions:

• Decentralized Identity: STARK-powered frameworks allow selective disclosure of credential properties (e.g. “age ≥ 18”) without leaking sensitive underlying information. The protocols arithmetize policies as polynomial constraints and prove satisfaction as part of a unified STARK (Yuan, 10 Oct 2025).
• Credential Revocation: By integrating accumulator non-membership proofs into the same trace as other personal information checks, a single STARK proof can show both eligibility and non-revocation.
• Parallelized Proof Construction: Implementations employing Cairo and similar DSLs exploit threading for speedup, with batched FRI queries allowing reduced marginal amortization (Yuan, 10 Oct 2025).

Empirical comparisons indicate that zk-STARKs, while producing larger proofs (~45–69 KB vs. <1 KB for Groth16 SNARKs), offer faster or competitive proof generation for complex statements and avoid the need for trusted setup or per-circuit SRS generation (Nainwal et al., 10 Dec 2025).

7. Comparison with zk-SNARKs and Concluding Observations

A systematic comparison with Groth16 SNARKs highlights critical trade-offs:

Property	zk-STARKs	Groth16 SNARKs
Setup	Transparent (no SRS)	Trusted, per-circuit
Prover Time	$O(n \log n)$	$O(n)$
Verifier Time	$O(\log n)$	$O(1)$
Proof Size (KB)	$O(\log n)$, 45–69 KB	≲0.2
Post-Quantum Secure	Yes	No

zk-STARKs’ transparency and post-quantum security are achieved at the cost of greater proof size and slower prover time for small statements, but their practical performance on commodity hardware—when tuned and parallelized appropriately—renders them viable for scalable, trustless zero-knowledge applications (Nainwal et al., 10 Dec 2025, Yuan, 10 Oct 2025).