Zero Knowledge Proofs Explained: How ZKPs Power Privacy, Scaling, and Modern Blockchain Infrastructure

Your L2 transaction confirms in under 2 seconds. But finality on Ethereum takes hours. Somewhere between that instant confirmation and the eventual on-chain settlement, a mathematical proof is being generated - one that convinces Ethereum's verifier contract that thousands of transactions executed correctly, without re-executing a single one of them. That proof is a zero knowledge proof, and it is quietly reshaping how blockchains scale, handle privacy, and verify computation.

Most developer-facing content on ZK proofs stops at the cryptography. It explains the math, maybe walks through a circuit, and calls it a day. But if you are building on zkSync Era, StarkNet, Scroll, or Linea, the questions that matter are more practical. How do ZK rollup nodes differ from standard Ethereum nodes? Why does starknet_getBlockWithTxs return different data than eth_getBlockByNumber? What does "soft confirmation" actually mean for your application's UX?

This guide covers ZK technology from the cryptographic foundations through to the infrastructure layer where it directly affects how you build.

What Are Zero Knowledge Proofs?

A zero knowledge proof (ZKP) is a cryptographic protocol that lets one party (the prover) convince another party (the verifier) that a statement is true, without revealing any information beyond the truth of the statement itself. In blockchain terms, a ZK proof demonstrates that 10,000 transactions executed correctly without forcing the verifier to re-run any of them.

ZK proofs satisfy three fundamental properties:

• Completeness - If the statement is true and both parties follow the protocol honestly, the verifier will always accept the proof. A valid batch of transactions will always produce a valid proof.
• Soundness - If the statement is false, no dishonest prover can convince the verifier to accept it (except with negligible probability). You cannot forge a proof for an invalid state transition.
• Zero-knowledge - The verifier learns nothing beyond the fact that the statement is true. The proof reveals no details about the underlying data, transactions, or witness values.

The classic illustration is the Ali Baba cave analogy. Imagine a circular cave with a locked door in the middle. You want to prove you know the secret word that opens the door without revealing the word itself.

The verifier waits at the entrance, you walk in, and the verifier randomly asks you to come out from one side or the other. If you know the word, you can always comply by unlocking the door when needed. After enough rounds, the verifier becomes statistically certain you know the secret, but never learns what it is.

That analogy captures the intuition, but real ZK systems are far more powerful. They prove arbitrary computational statements, not just secrets.

How ZK Proofs Work

At a high level, every ZK proof system follows the same flow: transform a computation into a mathematical structure, then prove properties of that structure without revealing its contents.

From Computation to Circuits

The first step is expressing the computation you want to prove as an arithmetic circuit - a directed acyclic graph of addition and multiplication gates over a finite field. If you want to prove that you computed a hash correctly, the hash function gets decomposed into thousands of field operations. Each gate enforces a constraint (e.g., a * b = c), and the full set of constraints forms a constraint system.

The most common constraint system is R1CS (Rank-1 Constraint System), where each constraint takes the form (A * s) . (B * s) = (C * s) with s being the witness vector containing all intermediate values. More recent systems use PLONKish arithmetization, which supports custom gates and lookup tables for more efficient circuit design.

Polynomial Commitments

The constraint system is then encoded as polynomials. The prover's job is to demonstrate that certain polynomial relationships hold, which corresponds to the original computation being correct.

Polynomial commitment schemes let the prover commit to a polynomial and later prove evaluations of it at specific points without revealing the full polynomial. Common schemes include KZG (Kate-Zaverucha-Goldberg) commitments, which rely on elliptic curve pairings, and FRI (Fast Reed-Solomon Interactive Oracle Proofs of Proximity), which use hash functions only.

Interactive to Non-Interactive

Early ZK proof systems required multiple rounds of interaction between prover and verifier. This is impractical for blockchains, where the "verifier" is a smart contract.

The Fiat-Shamir heuristic solves this by replacing the verifier's random challenges with hash function outputs derived from the prover's messages. The prover simulates the interaction by hashing its own commitments to generate challenges, producing a single proof that anyone can verify independently.

This is why modern ZK proofs are called non-interactive zero knowledge proofs (NIZKs) - they produce a single proof blob that a smart contract can verify in one transaction.

ZK-SNARKs vs ZK-STARKs

The two dominant proof system families are ZK-SNARKs and ZK-STARKs. The choice between them drives fundamental trade-offs in proof size, verification cost, security assumptions, and quantum resistance.

ZK-SNARKs (Succinct Non-interactive Arguments of Knowledge) produce small proofs that are fast to verify. The classic Groth16 scheme generates proofs of just 128 bytes with constant-time verification, but requires a per-circuit trusted setup ceremony. PLONK introduced a universal trusted setup that works for any circuit up to a fixed size, removing the per-circuit ceremony requirement while keeping verification efficient.

ZK-STARKs (Scalable Transparent Arguments of Knowledge) eliminate the trusted setup entirely by using hash-based cryptography instead of elliptic curves. This makes them transparent (no toxic waste from a setup ceremony) and quantum-resistant. The trade-off is larger proof sizes, typically 40-200 KB compared to SNARKs' sub-kilobyte proofs. StarkWare developed STARKs and uses them in StarkNet and StarkEx.

Bulletproofs are a third option worth mentioning. They require no trusted setup and produce relatively small proofs (under 1 KB), but verification time scales linearly with circuit size rather than being constant. Monero uses Bulletproofs for confidential transactions.

The trend in 2025-2026 is convergence. Proof systems increasingly combine SNARK-like succinctness with STARK-like transparency. Proof aggregation and recursive composition let teams wrap a STARK proof inside a SNARK for cheaper on-chain verification, which is exactly what StarkNet does when posting proofs to Ethereum.

ZK Rollups: How Zero Knowledge Proofs Scale Ethereum

ZK rollups are the highest-impact application of zero knowledge proofs today. They execute transactions off-chain, generate a validity proof that the execution was correct, and post that proof along with compressed transaction data to Ethereum L1. The L1 verifier contract checks the proof in a single transaction, securing thousands of L2 transactions with one verification.

How ZK Rollup Architecture Works

A ZK rollup consists of four core components:

1. Sequencer - Receives user transactions, orders them, and executes them against the current state. The sequencer produces blocks and state diffs.
2. Prover - Takes the sequencer's execution trace and generates a validity proof. This is the computationally expensive step, often requiring specialized hardware (GPUs, FPGAs, or high-memory machines).
3. L1 Verifier Contract - A smart contract on Ethereum that accepts proofs, verifies them, and updates the rollup's state root on L1. Verification is cheap (200-500k gas).
4. Data Availability Layer - Transaction data or state diffs are posted to L1 (or a DA layer like EIP-4844 blobs) so that anyone can reconstruct the L2 state independently.

Transaction Lifecycle

When you submit a transaction on a ZK rollup, it moves through distinct confirmation stages:

1. Soft confirmation - The sequencer includes your transaction in a block and returns a receipt. This happens in 1-3 seconds. Your frontend can show the transaction as "confirmed," but it is not yet proven on L1.
2. Proof generation - The prover batches multiple blocks together and generates a validity proof. Depending on the network, this takes minutes to hours.
3. L1 finality - The proof and state diff are submitted to Ethereum. Once the L1 transaction confirms, the state transition is final. No challenge period, no dispute window.

This is the key advantage over optimistic rollups. Optimistic rollups assume transactions are valid and allow a 7-day challenge window for fraud proofs. ZK rollups prove validity upfront, achieving finality as soon as the proof lands on L1.

ZK Rollups by the Numbers

ZK rollup growth in 2025 underscores the technology's momentum:

• Combined TVL exceeded $28 billion across major ZK rollups, up significantly from 2024
• 65% of new smart contracts deployed in 2025 went to L2 networks, with ZK rollups capturing a growing share
• Proving costs fell 45x during 2025, dropping from $1.69 to $0.0376 per proof through hardware optimization and better proving algorithms
• Transaction fees on ZK rollups consistently sit below $0.01 for standard transfers, often under $0.001

zkEVM Types: Vitalik's Classification

With ZK rollups proven in production, the next question is compatibility. Not all ZK rollups interpret Ethereum compatibility the same way. Vitalik Buterin defined a Type 1-4 classification system that maps the trade-off between Ethereum equivalence and proving efficiency.

Type 1 zkEVMs aim for perfect compatibility with Ethereum, including the same state tree and hash functions. This means existing Ethereum tools, clients, and block explorers work unchanged. The downside: proving Ethereum's keccak-heavy state transitions in ZK circuits is extremely expensive, making prover times impractical today.

Type 4 zkEVMs compile Solidity (or Vyper) to a custom VM rather than replicating the EVM instruction set. This allows much faster provers but sacrifices bytecode-level compatibility. Contracts must be recompiled, and some low-level EVM behavior may differ.

The sweet spot for most production networks in 2026 sits at Type 2-3, where EVM compatibility is high enough for standard tooling (Hardhat, Foundry, ethers.js) while keeping provers tractable.

For a deeper dive into zkEVM architectures and their implications, see zkEVM: Revolutionizing Ethereum Scalability and Privacy.

Major ZK Rollup Networks

These classification types map directly to the networks you can build on today. Four ZK rollup networks have established significant traction, each making different architectural choices that affect your development experience.

StarkNet

StarkNet uses STARK proofs and the Cairo programming language, a purpose-built language for provable computation. Rather than replicating the EVM, StarkNet runs the Cairo VM (CairoVM), designed from the ground up for efficient proof generation.

StarkNet grew from 4,000 to 60,000 daily active users during 2025, achieved 127 TPS sustained peak throughput, and maintains transaction fees below $0.001. The network uses its own JSON-RPC namespace (starknet_* methods like starknet_getBlockWithTxs, starknet_call) rather than standard eth_* methods.

zkSync Era

zkSync Era (by Matter Labs) takes the Type 4 approach. It compiles Solidity through zksolc to run on its custom zkEVM. This means you deploy using familiar Solidity code, but the compiled bytecode differs from standard EVM bytecode.

Daily transactions on zkSync Era grew 276% quarter-over-quarter in Q1 2025. The network features native account abstraction, meaning every account is a smart contract by default, simplifying gas abstraction and session key patterns.

Scroll

Scroll pursues Type 2 (approaching Type 2.5) zkEVM compatibility, aiming to be as close to Ethereum equivalence as possible. This means standard Ethereum development tools work with minimal modification.

Scroll reached $748 million in TVL, making it the largest zkEVM rollup by locked value. Its focus on compatibility means deploying existing Ethereum contracts requires no code changes in most cases.

Linea

Linea (by Consensys) is a Type 3 zkEVM that benefits from deep integration with the Consensys developer ecosystem, including MetaMask and Infura.

Linea supports standard eth_* JSON-RPC methods alongside some custom extensions, making it the most familiar environment for Ethereum developers among ZK rollups.

For infrastructure considerations on these networks, see the Best StarkNet RPC Providers and Best Linea RPC Providers comparisons.

Developer Tooling for ZK

Choosing a network is one decision. Choosing how to build ZK proofs is another. The ZK developer tooling landscape has matured significantly, and the most important shift is clear: zkVMs now let Rust developers write provable programs without learning circuit design.

Circom remains the most battle-tested tool for custom circuits, used extensively in Tornado Cash, Semaphore, and identity protocols. You write circuits in Circom's DSL, compile to R1CS, and generate proofs with snarkjs.

Cairo is mandatory for StarkNet development. Cairo 1.0 (now Cairo) brought a Rust-like syntax with strong typing, making it more approachable than the original Cairo 0 assembly-style language.

SP1 and RISC Zero represent the biggest paradigm shift. These zkVMs let you write standard Rust code and generate proofs of its execution. No circuit design, no constraint systems, no specialized DSLs.

SP1 compiles Rust to a custom RISC-V ISA and proves execution in a STARK, then wraps the proof in a SNARK for cheap on-chain verification. This dramatically lowers the barrier to building ZK applications.

// SP1 example: prove a computation in standard Rust
// No circuit knowledge required

// Program (runs inside the zkVM)
fn main() {
    let input: u64 = sp1_zkvm::io::read();
    let result = fibonacci(input);
    sp1_zkvm::io::commit(&result);
}

fn fibonacci(n: u64) -> u64 {
    if n <= 1 { return n; }
    let (mut a, mut b) = (0u64, 1u64);
    for _ in 2..=n {
        let temp = b;
        b = a + b;
        a = temp;
    }
    b
}

The key insight: if you can write Rust, you can now build ZK applications. The zkVM handles all the cryptography.

Real-World Applications Beyond Rollups

While scaling is the dominant use case, ZK proofs enable applications across several domains:

Privacy-preserving transactions - Zcash pioneered private cryptocurrency using ZK-SNARKs. The shielded pool hides sender, recipient, and amount while proving that no coins are created or destroyed. Tornado Cash used ZK proofs on Ethereum for transaction privacy before regulatory action.

Identity and credentials - Zero knowledge proofs let you prove attributes without revealing underlying data. World ID uses ZK proofs to verify personhood without exposing biometric data. zkEmail proves you received an email from a specific domain without revealing the contents. These systems enable selective disclosure for KYC, age verification, and credential protocols.

Cross-chain bridges - ZK-based bridges verify state transitions across chains with mathematical proofs rather than relying on multisig committees or optimistic assumptions. This eliminates the trusted intermediary that has been the failure point in bridge exploits totaling billions of dollars. For more on bridge architectures, see Cross-Chain Bridges Explained.

Voting and governance - ZK proofs enable verifiable anonymous voting where results are publicly auditable but individual votes remain private. MACI (Minimal Anti-Collusion Infrastructure) uses ZK proofs to prevent vote buying and coercion in on-chain governance.

Financial compliance - Institutions can prove regulatory compliance (KYC status, accreditation, sanctions screening) without sharing customer data across counterparties. This unlocks institutional DeFi participation where data privacy is a legal requirement.

Current Limitations and What Is Changing

ZK technology has advanced rapidly, but real constraints remain. Understanding them helps you make informed architecture decisions.

Proof Generation Costs

Generating ZK proofs is computationally intensive. A single proof for a batch of transactions can require minutes of GPU time. Costs are dropping fast - 45x in 2025 alone, from $1.69 to $0.0376 per proof - but proving remains the most expensive component of the ZK rollup stack. Hardware acceleration (GPUs, FPGAs, ASICs) and algorithmic improvements continue to push costs down.

Trusted Setup Ceremonies

SNARKs using Groth16 require a trusted setup that generates a structured reference string. If the randomness used in the setup is compromised, an attacker could forge proofs. Multi-party computation ceremonies mitigate this risk - Ethereum's KZG ceremony attracted over 141,000 contributors - but the concern remains for security-critical applications.

Universal setups (PLONK) and transparent systems (STARKs) eliminate this issue entirely. The industry is moving decisively toward setup-free systems.

Developer Complexity

Writing ZK circuits in Circom or Halo2 requires deep understanding of constraint systems, finite field arithmetic, and proof system internals. A single unconstrained variable can create a soundness bug that allows proof forgery.

zkVMs like SP1 and RISC Zero address this by letting developers write standard code, but custom circuits still offer better performance for specialized applications.

Quantum Resistance

SNARKs based on elliptic curves are vulnerable to quantum computers running Shor's algorithm. STARKs, which rely only on hash functions, are quantum-resistant by design.

Practical quantum computers capable of breaking elliptic curve cryptography remain years away. Still, networks with long time horizons like Ethereum are already planning migration paths to hash-based proof systems.

The Biggest Development: Ethereum's L1 zkEVM

The most significant development on the ZK roadmap is Ethereum's plan to integrate a Type 1 zkEVM directly into the L1 protocol. This would enable ZK verification of Ethereum's own state transitions, making light clients trustless and dramatically improving the network's verification properties.

The Ethereum Foundation has targeted 2026 for initial milestones, though full production deployment will take longer. If successful, this turns Ethereum itself into a ZK-proven chain.

What ZK Means for Infrastructure

ZK technology connects directly to how you choose, configure, and operate your infrastructure. Most ZK explainers skip this layer entirely, but architectural decisions here affect your application's reliability and performance in ways the cryptography sections never touch.

ZK Rollup Nodes Are Not Provers

A common misconception: running a ZK rollup node means running a prover. It does not. ZK rollup full nodes execute transactions and maintain state, similar to Ethereum full nodes. The prover is a separate, computationally intensive component typically run by the rollup operator or specialized proving services.

This distinction matters for infrastructure planning. Running a zkSync Era or Scroll full node requires hardware comparable to an Ethereum full node: 16-32 GB RAM, fast SSD, multi-core CPU. Running a prover requires high-end GPUs with 40+ GB VRAM or specialized hardware. Different infrastructure profiles, different cost structures.

Custom JSON-RPC Namespaces

ZK rollup networks do not all speak the same RPC language. StarkNet uses entirely custom methods:

// StarkNet uses starknet_* namespace
{
  "method": "starknet_getBlockWithTxs",
  "params": { "block_id": "latest" }
}

// vs. standard Ethereum RPC
{
  "method": "eth_getBlockByNumber",
  "params": ["latest", true]
}

zkSync Era extends the standard eth_* namespace with additional zks_* methods:

// zkSync-specific method for L1 batch details
{
  "method": "zks_getL1BatchDetails",
  "params": [12345]
}

Scroll and Linea hew closer to standard Ethereum RPC, which simplifies tooling but means some rollup-specific data (like proof status) requires custom endpoints or indexers. Applications targeting multiple ZK rollups need to handle these namespace differences in the RPC abstraction layer.

Soft Confirmation vs Hard Finality

The gap between soft confirmation (sequencer includes your transaction) and hard finality (proof verified on L1) creates a UX design question. For most applications like swaps, transfers, and NFT mints, soft confirmation is sufficient. Users expect the 1-2 second responsiveness it provides. For high-value operations like bridge withdrawals or large DeFi positions, you may want to wait for L1 finality.

Your RPC provider needs to clearly expose which confirmation level a response represents. When you call eth_getTransactionReceipt on a ZK rollup, the returned status reflects sequencer execution, not L1 proof verification. Checking L1 finality requires querying batch submission status through rollup-specific methods.

Archive Data Access Patterns

Archive data on ZK rollups behaves differently from Ethereum L1. State tree structures vary across networks - StarkNet uses a Merkle-Patricia trie over contract storage, while zkSync Era uses a different design. These structures are optimized for proof generation rather than random access reads, making historical state queries more expensive.

If your application needs historical state (analytics, compliance, portfolio tracking), verify that your RPC provider supports archive nodes for the specific ZK rollup you target. Not all providers maintain full archive data for newer ZK networks.

Hardware Requirements for Proving Infrastructure

For teams that need to run their own provers (decentralized sequencer designs, custom ZK applications, or self-hosted infrastructure), the hardware requirements are significant:

• GPU provers - NVIDIA A100 or H100 GPUs with 40-80 GB VRAM. A single proof generation for a StarkNet block can consume 64+ GB of GPU memory.
• CPU provers - 128+ CPU cores with 256+ GB RAM for some SNARK-based systems. Memory bandwidth is often the bottleneck.
• FPGA/ASIC provers - Emerging specialized hardware from companies like Cysic and Ingonyama that promises 10-100x efficiency improvements over GPU provers.

Most developers do not need to run provers. The rollup operator handles proving, and your application interacts with the network through standard RPC endpoints. But understanding the proving layer helps you evaluate network reliability and decentralization.

Multi-Chain ZK Infrastructure

Building applications that span multiple ZK rollups requires infrastructure that supports the distinct node types, RPC namespaces, and data access patterns of each network. Rather than operating separate node infrastructure for StarkNet's starknet_* namespace, zkSync Era's zks_* extensions, and Scroll's standard eth_* methods, teams typically rely on providers that abstract these differences.

Dwellir operates RPC infrastructure across StarkNet, zkSync Era, Scroll, Linea, and 50+ other networks, handling per-network node operations so your integration layer can focus on application logic.

Getting Started with ZK Development

If you are evaluating ZK technology for your project, here is a practical starting point:

1. Choose your network based on your compatibility needs. If you want maximum Ethereum tooling compatibility, Scroll or Linea. If you want the fastest provers and are comfortable with Cairo, StarkNet. If you want native account abstraction, zkSync Era.

2. Start with standard tooling. Hardhat and Foundry work on most ZK rollups (except StarkNet, which uses its own toolchain). Deploy your existing contracts first to validate compatibility before optimizing for ZK-specific features.

3. Understand confirmation semantics. Build your frontend to distinguish between soft confirmation and L1 finality where it matters for your use case.

4. If building ZK circuits, start with SP1 or RISC Zero if you know Rust. Only drop down to Circom or Halo2 if you need maximum proof efficiency for a performance-critical application.

5. Set up reliable RPC access. Public endpoints on ZK rollups carry the same limitations as Ethereum public RPCs: rate limits, no archive data, no SLA. Production applications need dedicated infrastructure.

Ready to build on ZK rollup networks? Contact the Dwellir team to discuss RPC infrastructure across StarkNet, zkSync Era, Scroll, Linea, and 50+ other networks. You can also create a free account to start testing endpoints immediately.