When a startup commits to one proving scheme over another, it is selecting which classes of systemic risk it is willing to absorb and which it intends to delegate to a future, possibly quantum-capable, adversary.
StarkWare, the company whose co-founders are credited as authors on the original STARK paper published on March 6, 2018, made its selection explicit: zk-STARKs were deployed first in its StarkEx scaling solution and remain the proving layer beneath Starknet. The rationale, as it appears in the company's own documentation and in Ethereum's developer materials, is anchored in three properties — transparency without a trusted setup, favorable scaling for large computations, and hash-based post-quantum security — and one acknowledged liability: larger proofs and correspondingly higher on-chain verification overhead.
A proof system is not trustless or trusted; it is a precise map of where trust must be deposited.
The Architectural Rationale for zk-STARKs
The decision to anchor a scaling product on a particular proof family is constrained by four primary vectors: the size of the computation being proven, the cost of verifying the resulting proof on the settlement layer, the trust assumptions embedded in the proving system, and the cryptographic hardness floor under which the system is expected to remain secure.
For computations at the scale required by a general-purpose rollup — where batches can contain thousands of transactions, each composed of arbitrary Cairo logic — the asymptotic behavior of the prover and verifier becomes a first-order architectural concern. Ethereum's developer documentation frames this directly: for zk-STARKs, proving and verification time grow quasilinearly with computational complexity, while for zk-SNARKs, the corresponding times grow linearly with the underlying computation size.
The distinction is not academic. A linear verifier penalizes the largest computations disproportionately; a system optimized for SNARK verification therefore benefits from bounded circuit sizes and aggressive recursion. A system built on STARKs, by contrast, is structurally tolerant of large computational traces because prover and verifier costs degrade more gracefully as batch size increases. For a rollup whose economic model depends on amortizing a single proof over thousands of user transactions, this asymptotic profile is decisive rather than incidental.
Transparency and the Elimination of Trusted Setups
The trust model embedded in a proof system is not a configuration option; it is a property of the underlying construction and it persists for the lifetime of the deployment. A zk-SNARK constructed over elliptic curves, in its classical Groth16 form, requires a Common Reference String (CRS) generated through a multi-party trusted setup ceremony. If the toxic waste — the secret parameters used to construct that CRS — is ever reconstructed by a participant or by an attacker who compromises one, a malicious actor can forge validity proofs.
Ethereum's developer documentation describes this risk in operational terms: if the information used to create CRS public parameters becomes available to malicious actors, they may be able to generate false validity proofs. The standard mitigation is operational rather than structural — multi-party ceremonies with public verifiability and cryptographic contributions from independent participants — but the mitigation does not eliminate the trust assumption; it distributes it across the ceremony's participants.
A zk-STARK removes the ceremony entirely. The original STARK paper states that setup requires no external trusted party and that the construction relies on publicly verifiable randomness. Proving and verification keys are derived from public hash evaluations, not from secret toxic waste, and there is no parameter-generation event whose compromise would compromise soundness. This property — transparency — is what made STARKs attractive for deployments whose security model must remain structurally inspectable and whose long-tail risk surface cannot include a forgotten ceremony secret.
The trade-off is that transparency is purchased at the cost of larger proofs and more expensive on-chain verification. The choice is therefore not "trusted versus trustless" in any abstract sense; it is a concrete engineering decision to relocate trust from a one-time ceremony into the cryptographic hardness assumptions themselves, and to absorb the resulting data and gas footprint.
Scaling Computational Complexity: STARKs vs. SNARKs
The properties most relevant to a rollup designer evaluating SNARKs against STARKs at the time of StarkWare's deployment decisions are summarized below. The numerical anchors are taken from Ethereum's own illustrative examples and are not universal constants; production costs depend on the specific proving system, the circuit, the recursion strategy, and prevailing gas conditions.
| Property | zk-SNARK (classical) | zk-STARK |
|---|---|---|
| Trusted setup required | Yes — CRS via multi-party ceremony | No — publicly verifiable randomness |
| Prover scaling vs. computation | Linear | Quasilinear |
| Verifier scaling vs. computation | Linear | Quasilinear |
| Proof size | Smaller — order of hundreds of bytes | Larger — tens to hundreds of kilobytes |
| On-chain verification cost (Ethereum) | Lower — illustrative ~500,000 gas per proof | Higher — documentation describes STARK verification as more expensive |
| Cryptographic assumptions | Elliptic-curve pairings | Collision-resistant hash functions |
| Post-quantum status | Not considered resistant under current understanding | Considered post-quantum secure under stated assumptions |
| Setup auditability | Operational — ceremony transcripts | Structural — no secret parameters exist |
For StarkWare, the architectural question was not whether STARK verification was cheaper than SNARK verification on a particular block but whether the asymptotic profile of the proof system permitted the amortization model a rollup requires. The answer, for the scale of computations StarkEx was designed to batch, was yes.
Post-Quantum Security and Hash-Based Cryptography
The original STARK paper frames its construction as post-quantum secure under collision-resistant hash-function assumptions and the random-oracle model for non-interactivity. This framing is narrower than "quantum-proof" in the colloquial sense and broader than "currently certified quantum resistance." It asserts that, if a sufficiently large quantum computer is constructed, the soundness of the proof system does not collapse with it, provided the underlying hash function remains collision-resistant.
This is a non-trivial claim. Classical SNARKs rely on elliptic-curve pairings, and the discrete-log problem underpinning those pairings is known to be efficiently solvable by Shor's algorithm on a cryptographically relevant quantum computer. A zk-SNARK system whose security rests on these assumptions therefore carries a quantified, if uncertain, exposure to a future quantum adversary. A zk-STARK, by contrast, derives its soundness from the hardness of finding collisions in a hash function — a problem for which no efficient quantum algorithm is currently known.
The qualification matters. Hash-based security is not absolute. It is conditional on the continued hardness of the underlying primitive, and the field of post-quantum cryptography continues to evolve. What the STARK construction provides is a credible hedge: a proof system whose security assumptions are not on the published list of problems known to be efficiently solvable by quantum algorithms. For an infrastructure provider whose deployed systems are intended to persist across decades, this hedge is architecturally material, not cosmetic.
The Reality of On-Chain Verification Overhead
The deployment decision does not eliminate verification cost; it concentrates it. In Starknet's documented architecture, Cairo executions generate STARK proofs that are then submitted for on-chain verification. To reduce the marginal cost per proof, the company operates SHARP — a Shared Prover and Verifier — which aggregates multiple Cairo programs into a single unified STARK proof before that proof is verified on Ethereum.
The mechanics matter for any reader evaluating the cost model. SHARP's dispatcher is reported to send a typical range of 3 to 5 Merkle statements to its MerkleStatementContract and a general range of 5 to 15 FRI statements to its FriStatementContract. These numbers describe the volume of low-level proof components that must be re-encoded and re-submitted per aggregated batch; they do not represent user-facing gas estimates, but they do constrain the size of the proof payload that ultimately crosses the consensus boundary.
A second lever is calldata compression. Ethereum's documentation describes a rollup optimization in which accounts are represented by an index rather than a full 20-byte address, yielding an illustrative calldata saving of 28 bytes per reference. Combined with the aggregation performed by SHARP, this is the operational machinery by which a proof system with materially larger proofs than its SNARK counterparts remains economically viable on Ethereum at scale.
The structural picture, then, is the following. STARK verification is more expensive per unit of computation proven, but the cost is amortized across very large batches through aggregation and calldata optimization. For workloads where this amortization is possible — high-throughput rollups with frequent batch settlement — the model holds. For low-volume deployments where batches are small and infrequent, the same trade-off can render STARKs uneconomical.
A STARK proves correct execution; it does not prove that the executed program was operating on data that reflected external reality.
Distinguishing Proof Validity from Oracle Data Integrity
A zero knowledge proof protocol attests that a computation was executed correctly over a given set of inputs. It does not, by itself, attest that those inputs were truthful, fresh, or resistant to manipulation. This distinction is the structural reason STARKs cannot be treated as an oracle-security solution, and it is the reason the underlying protocol must be paired with independent oracle-layer hardening.
OWASP's Smart Contract Weakness Classification treats price-oracle manipulation as exploitation of an oracle to alter smart-contract logic. Its worked example identifies a flash-loan-mediated sequence in which an attacker manipulates a price feed before calling a withdrawal function — a scenario in which the proof system, if any, has already validated correct execution of the contract's withdrawal code over an attacker-supplied price.
The mitigation strategies documented by OWASP are not cryptographic-proof-related. They are operational: multiple decentralized oracle sources, input validation at the contract boundary, and circuit breakers such as a maximum price-deviation guard. In OWASP's illustrative hardened-oracle code, this guard is set at 5% — a figure OWASP presents as an example, not a universal threshold, and one which should not be lifted from context into a protocol-wide specification.
The audit implication is direct. A security review of a STARK-based rollup that consumes oracle feeds must evaluate the proof system and the oracle layer as distinct attack surfaces. Soundness of the STARK does not propagate to soundness of the data on which the proven Cairo program operates. Any attempt to collapse these into a single "verified by STARK" claim is a category error.
What a Security Review of a STARK-Based Deployment Must Cover
A pre-deployment audit checklist for a system anchored on a STARK-based prover should include, at minimum, the following:
- Verification of the proving system's soundness parameters under the specific hash-function instantiation in use, with attention to the field size and the FRI parameters
- Confirmation that SHARP aggregation does not introduce cross-program interference that compromises individual program soundness
- Validation of the calldata encoding, particularly the use of index-based account references and the resulting compression guarantees
- Independent assessment of the oracle feeds feeding into the proven Cairo programs, including source diversity, freshness, and deviation-circuit parameters
- Adversarial modeling of flash-loan-mediated oracle manipulation sequences against the system's withdrawal and liquidation paths
- Stress testing of the verifier gas consumption under batch-size extremes, because the asymptotic behavior of the verifier only amortizes at scale
This list is not a substitute for OWASP's recommendations or for the specific testing methodology of an audit engagement. It is a structural outline of the surfaces a review must touch if it is to produce findings that reflect the architecture's actual risk profile.
Viability and the Limits of the Trade-Off
StarkWare's choice of zk-STARKs is structurally coherent for the workload it was designed to support: large-batch, high-throughput rollups where the amortization model can absorb the per-proof verification overhead. The trade-off purchased is real — the proof system is transparent, the cryptography is hash-based, and the security assumptions are credibly post-quantum — but it is paid for in larger proofs and higher on-chain gas, two liabilities that smaller or lower-volume deployments may not be able to absorb.
The protocol is not a substitute for oracle security, a mitigation for flash-loan attacks, or a general-purpose defense against smart-contract logic errors. A STARK proves correct execution; it does not prove that the executed program was operating on data that reflected external reality. Auditors and integrators must therefore evaluate the system on two axes simultaneously: the soundness of the proof system itself, and the integrity of the inputs on which the proven computations operate. Failure to do so produces a deployment that is provably correct and operationally wrong.
For an organization whose architecture demands verifiable execution over large computational traces, whose threat model extends to a future quantum adversary, and whose economic model supports proof aggregation, zk-STARKs remain a defensible selection. For any other workload profile, the same trade-off becomes a liability. The choice, as with all proof-system decisions, is not which scheme is best in the abstract; it is which failure mode the deploying organization is structurally incapable of recovering from.
