Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ZK Rollups vs Optimistic Rollups: Which Can Achieve Zero Inflation?


1. Why Optimistic Rollups (Optimism, Arbitrum) Struggle with Zero Inflation

Optimistic rollups rely on a game-theoretic security model based on fraud proofs.

  • The “Watcher” Problem: For fraud proofs to work, there must be independent, economically incentivized “watchers” or challengers who monitor the sequencer, lock up capital (bonds), and expend computational resources to dispute invalid state roots.
  • Incentive Misalignment: If transaction fees are low, the network may not generate enough organic revenue to compensate these watchers for their capital opportunity cost and computational work.
  • The Inflation Necessity: To ensure security and prevent centralization (where only the sequencer can afford to monitor itself), optimistic rollups often rely on an inflationary native token (like OP or ARB) to subsidize these security incentives, fund ecosystem growth, and reward governance participation until fee revenue is organically sufficient.

2. Why ZK Rollups (Starknet) Can Theoretically Achieve Zero Inflation

ZK rollups rely on a cryptographic security model based on validity proofs (zero-knowledge proofs).

  • Deterministic Verification: The Layer 1 smart contract deterministically verifies the cryptographic proof. There is no “watcher” game, no dispute period, and no need for redundant monitoring by multiple economic actors.
  • Math Over Economics: The math simply rejects invalid proofs. An attacker cannot submit a fraudulent state transition because the L1 contract will not accept it without a valid proof.
  • Fee-Based Sustainability: The prover’s cost is purely computational. They can be paid directly from the transaction fees collected by the sequencer as a service fee. Therefore, a ZK rollup can theoretically reach a steady state where transaction fees exactly cover prover costs and sequencer operations, allowing for “zero inflation” without compromising security.

3. Practical Nuances (The “But…”)

While the structural argument is sound, real-world tokenomics tell a slightly different story:

  • Starknet Currently Has Inflation: In practice, Starknet (STRK) does currently utilize token emissions (inflation) to incentivize staking, governance participation, and ecosystem growth. The “zero inflation” capability is a theoretical ceiling, not necessarily the current operational reality.
  • Ecosystem Bootstrapping: Both Optimism and Arbitrum use token inflation heavily for ecosystem incentives (grants, developer rewards, liquidity mining) to bootstrap network effects, not strictly for security. Starknet and other ZK rollups do the same to compete for market share.
  • Decentralized Sequencing: Both architectures are currently working on decentralizing their sequencers. The economic models for decentralized sequencing (e.g., bidding for proving rights, shared sequencing) may introduce new tokenomic requirements for both ZK and Optimistic rollups.

Zero Inflation is Theoretically Sound

Zero inflation in ZK Rollups is theoretically sound. ZK rollups have a structural advantage because they replace ongoing economic incentives with cryptographic guarantees, removing the fundamental need for inflation to maintain security. Optimistic rollups, by design, cannot easily decouple their security from ongoing economic incentives, making a true “zero inflation” model much harder to sustain without compromising decentralization or safety.

How Zero-Inflation Security Unlocks Capital for Real-World Utility

1. Capital Can Fund Real-World Utility (e.g., Supply Chains)

In traditional or optimistic models, a large portion of the treasury must be reserved to continuously incentivize network watchers. In a ZK model, those funds are freed up.

  • Supply Chain & IoT Integration: Capital can be deployed to build oracle networks, hardware integrations, and data-verification layers that connect physical supply chains to the blockchain.
  • Real-World Assets (RWAs): Instead of printing tokens to pay validators, treasuries can fund the technological infrastructure needed to tokenize real estate, commodities, or logistics data.
  • Value Creation over Value Extraction: Money flows into building products that generate real revenue, rather than being extracted by mercenary capital seeking yield.

2. Provers Are Paid as “Compute Services,” Not “Security Subsidies”

It is important to note that provers do get paid, but the economic model is fundamentally different and healthier:

  • The Old Model (Validators/Watchers): Paid via token inflation simply to monitor the network and hope no one else cheats. This is a continuous, draining subsidy.
  • The ZK Model (Provers): Paid via transaction fees to perform a specific computational task (generating a proof). This is akin to paying an AWS server for compute power. It is a sustainable, fee-based business expense, not a dilutive inflationary reward. Once the proof is generated and verified by Layer 1, the security is permanent and requires no further payment.

3. Sustainable, Non-Dilutive Tokenomics

When a chain does not need to inflate its token supply to maintain security, its tokenomics become inherently more attractive to long-term investors and institutions.

  • No “Death Spiral” Risk: In inflationary models, if token price drops, validator rewards lose value, security drops, and the price drops further. ZK chains avoid this because security is math-based, not price-based.
  • Value Accrual: With a fixed or deflationary supply, any increase in network usage (and thus fee revenue) directly accrues value to token holders or the protocol treasury, rather than being diluted by new token emissions.

4. Redirecting Treasury Funds to Developer Growth

Instead of using treasury tokens to bribe liquidity providers or pay security watchers, ZK ecosystems can allocate those resources to:

  • Developer Grants and Hackathons: Funding the creation of actual applications, better developer tooling, and improved user interfaces.
  • User Acquisition: Subsidizing gas fees for new users or funding marketing initiatives that bring real users to the platform, creating a genuine network effect.

5. Lower End-User Costs

In an optimistic rollup or traditional L1, the transaction fee must cover two things: the cost of execution and the premium needed to incentivize the security watchers. In a ZK rollup, the user only pays for the execution and the prover’s compute cost. Because there is no “security inflation tax” baked into the fee, the baseline cost of transactions can be driven down to fractions of a cent as proving hardware becomes more efficient.


Summary: The Paradigm Shift

Traditional / Optimistic ModelZK Proof Model
Security Source: Economic incentives (bribes).Security Source: Mathematics (cryptographic proofs).
Capital Drain: Continuous token inflation to pay watchers/validators.Capital Efficiency: Provers paid one-time fees for compute (like a SaaS model).
Resource Allocation: Treasury bleeds value to maintain baseline security.Resource Allocation: Treasury funds real-world use cases, supply chains, and developer growth.
Tokenomics: Inflationary, prone to dilution and mercenary capital.Tokenomics: Zero-inflation potential, deflationary pressure, attracts long-term capital.

Conclusion: By decoupling security from inflation, ZK technology transforms a blockchain from a “rent-seeking” machine into a value-creating infrastructure. It allows ecosystems to spend their money on what actually matters: building real-world applications, optimizing supply chains, and delivering tangible value to users.

Starkex

https://starkware.co/starkex/

What is the difference between Starknet and StarkEx?

StarkNet is a permissionless decentralized ZK-Rollup that supports independent deployment of smart contracts. Any developer can write and deploy their smart contract permissionlessly. Starknet also supports composability.

StarkEx is a permissioned tailor-made scaling engine, designed by StarkWare to fit the specific needs of apps.

Both Starknet and StarkEx provide scalability and L1 security by using STARK-based validity proofs, and both are designed to support general computation, allowing any use case to be scaled.

How will StarkEx evolve in a Starknet world?

StarkEx is a scaling engine built with Cairo and SHARP. While Starknet is a general purpose, permissionless, and decentralized ZK-Rollup. As StarkNet development progresses, StarkEx deployments will be able to port to Starknet. This will offer them the benefit of a fully-decentralized network, as well as composability with other applications.

Scaling: StarkEx vs Starknet

StarkEx scales horizontally at Layer 2, while Starknet scales vertically at Layer 2 and horizontally at Layer 3.


1. StarkEx: Horizontal Scaling at Layer 2 (Siloed Appchains)

StarkEx is currently a permissioned, application-specific scaling engine. Rather than being a general-purpose blockchain, it is custom-built to meet the exact needs of a single application (e.g., dYdX v3, Immutable X, Sorare, rhino.fi). Note: As the technology matures, StarkEx is evolving and may eventually offer the capability to build permissionless L2 environments.

  • How it scales horizontally: If an application outgrows the capacity of its current StarkEx instance, it cannot simply “add more power” to the same shared state. Instead, the application must deploy a brand new, separate StarkEx instance (a new L2 appchain).
  • The Trade-off & Mitigation: This approach creates siloed environments where liquidity, users, and state are fragmented across different StarkEx instances. However, this fragmentation can be effectively mitigated by decentralized multichain bridges and intent-based exchanges, which can seamlessly connect these disparate L2s.

2. Starknet: Vertical Scaling at Layer 2 (Monolithic Shared State)

Starknet is a permissionless, general-purpose Validity Rollup. Its primary goal is to act as a single, unified, high-throughput settlement layer (a “monolithic” L2) where all applications share the same state and liquidity.

  • How it scales vertically: Instead of splitting into multiple chains, Starknet increases the capacity of the single chain through advanced cryptography and engineering:
    1. Recursive STARKs: This is the holy grail of vertical scaling. Instead of submitting thousands of individual proofs to Ethereum, Starknet can “roll up” multiple STARK proofs into a single, tiny recursive proof. This drastically reduces L1 verification costs and allows the L2 to process exponentially more transactions without hitting L1 bottlenecks.
    2. Parallel Execution: Introduced in the v0.13.2 “Bolt” upgrade, Starknet can now process independent transactions simultaneously rather than sequentially, massively boosting raw TPS (Transactions Per Second) on the same chain.

3. Starknet: Horizontal Scaling at Layer 3 (Appchains)

While Starknet handles vertical scaling at Layer 2, it plans to achieve horizontal scaling through Layer 3.

  • How it scales horizontally: If a specific application (like a high-frequency trading platform or a massive multiplayer game) needs dedicated throughput that even a vertically scaled L2 cannot provide, it can launch as a Layer 3 Appchain on top of Starknet.
  • The Advantage: This L3 appchain settles its proofs to Starknet (L2), which then settles to Ethereum (L1). The app gets its own dedicated, horizontally scaled environment.
  • Key disadvantages of Layer 3s in the StarkNet ecosystem include compromised security and increased complexity. Unlike Layer 2s which settle directly to Ethereum, Layer 3s inherit security from the Layer 2, creating a dependency chain that can introduce vulnerabilities if the underlying Layer 2 or its sequencers are compromised.
  • Higher Withdrawal Friction: Exiting an optimistic Layer 3 can require waiting through both the Layer 3’s dispute window and the Layer 2’s delay, significantly slowing down withdrawals compared to native Layer 2 exits.
  • Limited Scalability Gains: Critics argue that stacking rollups provides minimal additional scalability because data compression cannot be effectively repeated, and the cost savings are often negligible compared to Layer 2s after EIP-4844.
  • Centralization Risks: Many Layer 3s rely on centralized sequencers controlled by the app team, which can halt the chain if they go offline or act maliciously

Summary Comparison

FeatureStarkEx (L2 Engine)Starknet (L2 Network + L3 Ecosystem)
ArchitectureCurrently permissioned, app-specific (evolving toward permissionless).Permissionless, general-purpose.
Primary L2 ScalingHorizontal: Spin up new, separate L2 instances for new apps or more capacity.Vertical: Recursive STARKs and Parallel Execution to increase the capacity of the single shared chain.
Horizontal ScalingHappens at L2 (fragmented liquidity/state).Happens at L3 (Appchains settle to Starknet, preserving unified L2 liquidity).