How STARK Proofs Actually Work and Why StarkNet Uses Them Instead of SNARKs

Most guides explain StarkNet as "a Layer 2 that uses STARK proofs for scalability." That's true and useless. It doesn't tell you what a STARK proof actually contains, why StarkNet chose STARKs over the SNARKs that most other rollups use, or where the current trust assumptions sit that the marketing doesn't highlight. This article closes those gaps.

A STARK — Scalable Transparent ARgument of Knowledge — is a cryptographic proof that lets a prover demonstrate they executed a computation correctly without the verifier re-running that computation. The verifier checks the proof instead of the work, and the proof is exponentially smaller than the original computation.

The standard explanation says STARKs "prove computation." What's actually happening is more specific: the prover converts the computation into a polynomial, evaluates that polynomial at many points, then uses a protocol called FRI (Fast Reed-Solomon Interactive Oracle Proofs of Proximity) to prove the evaluations are consistent with a low-degree polynomial. The verifier only checks a small random sample of those evaluations. If the polynomial is low-degree and matches the evaluations, the computation was correct — any error in execution would spike the polynomial's degree, which FRI would catch.

The key property: this entire process uses hash functions (typically Pedersen or Poseidon hashes within StarkNet's prover, with Keccak for Ethereum verification). No elliptic curve pairings, no trusted setup ceremony. The security rests on collision-resistant hashing, which is considered quantum-resistant — unlike the elliptic curve assumptions that SNARKs depend on.

⚠ Common mistake: Assuming "no trusted setup" means "no trust assumptions." STARKs eliminate the toxic waste problem of SNARK ceremonies, but you still trust the prover software implementation, the hash function's collision resistance, and — in StarkNet's current state — the sequencer operator. Transparent ≠ trustless.

Rollups like zkSync Era and Scroll use SNARKs (specifically, variants like PLONK or Groth16). StarkNet uses STARKs. The difference isn't philosophical — it's engineering trade-offs with measurable consequences.

STARK proofs are larger than SNARK proofs. A typical SNARK proof is around 200-300 bytes. A raw STARK proof can be tens of kilobytes. StarkNet mitigates this by using a technique called SHARP (SHARed Prover): it aggregates proofs from multiple programs (and even multiple chains — StarkNet and StarkEx dApps like dYdX v3 historically shared the same prover) into a single proof submitted to Ethereum. Additionally, StarkNet wraps the STARK proof in a final step that generates a smaller proof optimized for on-chain verification, reducing L1 gas costs.

SNARKs are cheaper to verify on-chain per proof but require a structured reference string (trusted setup). STARKs are more expensive to verify but scale better as computation grows — the proof size grows quasi-logarithmically (polylog) with computation size, while many SNARK schemes grow linearly or require recursive composition earlier. For a rollup batching thousands of transactions, this scaling property matters.

• STARK proof generation: slower per-proof but parallelizable across commodity hardware
• SNARK proof generation: faster per-proof but often requires specialized hardware or high-memory machines
• STARK verification gas cost on Ethereum: roughly 300,000–500,000 gas per aggregated proof via SHARP
• SNARK verification gas cost: roughly 200,000–300,000 gas per proof

⚠ Common mistake: Thinking STARKs are "better" than SNARKs in absolute terms. They're better for StarkNet's specific design — large-batch proving with hash-based security. For a rollup optimizing per-transaction L1 cost with smaller batches, SNARKs can be more efficient.

When you submit a transaction on StarkNet, it doesn't touch Ethereum immediately. The sequencer (currently operated solely by StarkWare) orders transactions, executes them against the current state, and produces a new state root. This execution happens off-chain in the Cairo VM, StarkNet's custom virtual machine.

The sequencer sends the batch of executed transactions to the prover (SHARP). The prover generates an execution trace — a record of every step the Cairo VM took — converts it into a polynomial commitment, runs the FRI protocol, and produces a STARK proof. This proof asserts: "Starting from state root A, applying these N transactions, the correct resulting state root is B."

This proof is submitted to the StarkNet Core Contract on Ethereum (address: 0xc662c410C0ECf747543f5bA90660f6ABeBD9C8c4). The contract's verifier checks the proof on-chain. If valid, it updates the accepted state root. At this point, the transactions have L1 finality — the same security as any Ethereum transaction.

• Batch size varies: StarkNet typically proves batches covering minutes to hours of activity depending on throughput
• State diffs (not full transaction data) are posted to Ethereum as calldata or blobs, enabling anyone to reconstruct the state
• The proving step takes minutes — this is the main source of latency between L2 execution and L1 finality

⚠ Common mistake: Thinking your transaction is "final" when the sequencer confirms it. That's a soft confirmation — the sequencer could theoretically reorder or censor. True finality comes only after the proof is verified on L1. The gap between these two moments is currently measured in hours, not seconds.

StarkNet runs on the Cairo VM, not the EVM. This is a direct consequence of using STARKs. The EVM wasn't designed to be "provable" — its instruction set creates awkward, expensive constraints when converted to polynomials. Cairo's instruction set was purpose-built so that every operation maps cleanly to algebraic constraints that the STARK prover can handle efficiently.

The practical impact: you can't deploy Solidity contracts on StarkNet. Contracts are written in Cairo (the language), which compiles to Sierra (Safe Intermediate Representation) and then to CASM (Cairo Assembly). This is a genuine barrier to composability with EVM chains but gives StarkNet a proving efficiency advantage. Operations that would be expensive to prove in a zkEVM — like Keccak hashing or certain bitwise operations — are handled natively in Cairo's algebraic framework using field arithmetic over a 251-bit prime field.

This also means StarkNet's account model differs from Ethereum. Every account on StarkNet is a smart contract — there are no externally owned accounts (EOAs). This native account abstraction means every wallet can implement custom signature verification, session keys, or social recovery at the protocol level, not as a wrapper.

⚠ Common mistake: Assuming StarkNet is "EVM-compatible" or that you can use the same contract addresses across Ethereum and StarkNet. Addresses, transaction formats, and the execution environment are entirely different. A StarkNet address is a 251-bit field element, not a 160-bit Ethereum address.

StarkNet's proof system is sound — if the math checks out, the state transition is valid. But the infrastructure around the proofs has centralization points that matter for your risk assessment.

The sequencer is currently a single operator run by StarkWare. This means StarkWare controls transaction ordering (MEV extraction potential), can censor specific transactions, and is a single point of liveness failure — if the sequencer goes down, no new transactions are processed. StarkNet's roadmap includes decentralizing the sequencer, but as of mid-2025, this hasn't shipped to mainnet.

The upgradeability of StarkNet's core contracts on Ethereum is controlled by a multisig with a time delay. This means the bridge contract — holding all assets deposited from L1 — can be upgraded. If the multisig signers are compromised or collude, the upgrade could theoretically redirect funds. The implementation delay gives users a window to exit, but only if they're monitoring. The StarkNet governance model has been evolving, with STRK token holders gaining more influence, but the upgrade keys remain a practical trust assumption.

• Forced transaction inclusion: StarkNet supports L1→L2 messages that the sequencer must eventually include, providing a censorship escape hatch
• Withdrawal delay: after proving, withdrawals from StarkNet to Ethereum require interacting with the L1 contract to claim funds
• Data availability: state diffs posted on L1 mean anyone can reconstruct state even if StarkWare disappears — but running an independent full node to do this is non-trivial

⚠ Common mistake: Equating "validity proof" with "fully decentralized." The proof guarantees computation correctness. It does not guarantee liveness, censorship resistance, or immutability of the bridge contract. These are separate properties with separate trust models.

• StarkNet state on Ethereum: Look up the StarkNet Core Contract on Etherscan. The updateState transactions contain the new state root and the proof verification results.
• Proof verification: Each state update calls verifyProofAndRegister on the SHARP verifier contracts. You can trace these calls to confirm proofs were checked.
• StarkNet Explorer: Voyager (voyager.online) and Starkscan (starkscan.co) show transaction status, including whether a batch has been proven and accepted on L1.
• DeFiLlama: Track StarkNet's TVL (defillama.com/chain/Starknet) to gauge how much value currently depends on these trust assumptions.
• L2BEAT: l2beat.com/scaling/projects/starknet provides an independent risk assessment covering data availability, state validation, sequencer status, and upgrade permissions — updated regularly.

• Read the STARK paper directly: The original 2018 paper by Ben-Sasson et al. is dense but the first 15 pages give the intuition behind FRI and polynomial commitment. Search "Scalable, transparent, and post-quantum secure computational integrity" on IACR.
• Deploy a Cairo contract on testnet: StarkNet's Sepolia testnet lets you write and deploy Cairo contracts using the Scarb toolchain. This makes the execution model concrete rather than abstract.
• Compare L2 risk profiles on L2BEAT: Look at StarkNet alongside Optimism, Arbitrum, and zkSync. Compare the specific centralization vectors — sequencer, prover, upgrade keys — rather than just TPS claims.
• Monitor proof costs: Watch the gas spent by the StarkNet operator address on Ethereum to understand how much proof verification actually costs per batch and how that cost is amortized across users.