Lean Ethereum: How L1 Reaches 10k TPS | Beast Mode & Fort Mode

Key Concepts

• Lean Ethereum: A vision to leverage ZK-SNARKs to significantly enhance Ethereum's performance, scale, security, and decentralization.
• Beast Mode: Refers to the aggressive scaling and performance improvements for Ethereum, particularly on the execution layer (L1) and data availability for L2s.
• Fort Mode: Focuses on uncompromising security, best-in-class uptime, decentralization, post-quantum security, MEV decoupling, and rapid finality.
• ZK-SNARKs (Succinct Non-Interactive Argument of Knowledge): A cryptographic primitive that allows for small, verifiable proofs of computation, enabling scalability and decentralization.
• ZK-EVMs (Zero-Knowledge Ethereum Virtual Machines): Implementations that allow developers to run EVM-compatible code within a ZK-SNARK framework, making ZK technology accessible.
• Gas Limit: The maximum amount of computational effort (gas) that can be included in a single Ethereum block.
• Transactions Per Second (TPS): A measure of the number of transactions a blockchain can process in a given second.
• Data Availability: The ability for nodes to access and verify the data associated with transactions, crucial for L2 scalability.
• Validators: Nodes that secure the Ethereum network by proposing and attesting to blocks.
• Provers: Entities responsible for generating ZK-SNARK proofs for computations.
• Block Builders: Entities that construct blocks by selecting and ordering transactions, often optimizing for MEV.
• Proposer-Builder Separation (PBS): A mechanism that separates the role of block proposers from block builders to enhance decentralization and reduce MEV extraction.
• Post-Quantum Security: Cryptographic methods resistant to attacks from quantum computers.
• Lindy Effect: The theory that the longer a technology or idea has been around, the longer it is likely to remain in use.
• MEV (Maximal Extractable Value): The profit that can be made by including, excluding, or reordering transactions within a block.
• Hard Fork: A permanent divergence from the previous version of a blockchain, requiring all nodes to upgrade.
• Native Rollups: L2 solutions that share the same execution environment as L1 but operate on L2, simplifying development and security.

Lean Ethereum: Beast Mode and Fort Mode

Justin Drake introduces "Lean Ethereum" as a conviction that ZK-SNARKs can elevate Ethereum's performance and scale ("Beast Mode") while simultaneously enhancing its security and decentralization ("Fort Mode").

Beast Mode: Aggressive Scaling and Performance

• Vision: To scale the Ethereum L1 to 1 gigas per second (Ggas/s) and dramatically increase data availability for L2s to achieve 1 teragas per second (Tgas/s).
• Target Throughput:
  • L1: 10,000 Transactions Per Second (TPS)
  • L2s: 10 million TPS
• Goal: To have enough throughput for "all of finance."
• Scope: Encompasses the execution layer (where transactions, smart contracts, and block space activity occur) and the data availability layer for L2s.
• Amplifier: Provides a roughly 1000x improvement over current L1 capabilities.
• Current L1 State:
  • Gas limit has increased from 30 million gas four years ago to 45 million gas.
  • This represents only a 50% increase over four years, underperforming Moore's Law.
  • Current throughput is approximately 2 megagas per second (Mgas/s), translating to about 20 TPS for simple transactions.
• Target L1 State: 1 Ggas/s (1000 Mgas/s), a 500x improvement from the current 2 Mgas/s.
• L2 Scaling: Teras/s is envisioned as the aggregate throughput of all L2 rollups, effectively a thousand copies of L1 each doing 1 Ggas/s.
• Bottleneck: The primary bottleneck for L1 scaling is currently the validators, specifically the assumption that they run on commodity hardware (laptops, Raspberry Pi). Removing this bottleneck can unlock 10x-100x, and with sufficient work, 500x scaling.
• Historical Context: While Ethereum has seen L1 gas limit increases (e.g., from 6 million gas in 2016 to 30 million, then 45 million), these were achieved through "raw engineering" and not considered "beastly" scaling.
• Gas and Block Size: A simple transfer costs 21,000 gas, while a DEX swap costs 100,000 gas. 1 Ggas/s divided by an average transaction of 100,000 gas yields 10,000 TPS.
• Per Human Throughput: 1 Ggas/s offers 0.1 transactions per human per day, insufficient for all of finance. The goal of 10 million TPS (Terra Gas era) would provide 100 transactions per day per human.

Fort Mode: Uncompromising Security and Decentralization

• Focus: Best-in-class uptime, decentralization, post-quantum security, clean decoupling of MEV from validators, and sub-second finality.
• Current Finality: 10-20 minutes.
• Goal Finality: A matter of seconds.
• Analogy: Described as "offensive and defensive," with Beast Mode being aggressive scaling and Fort Mode being Ethereum's traditional resilience and "bunker coin" nature.
• Decentralization: ZK-SNARKs enable validators to verify small proofs, drastically lowering the hardware barrier to entry for becoming a validator.
• Uptime and Resilience: Aims for a security model where Ethereum maintains uptime even if all data center operators globally attack it. This contrasts with other high-performance L1s that often rely on data centers and have fewer validators.
• Self-Imposed Constraint: Ethereum prioritizes home internet connections and commodity hardware, avoiding the data center dependency seen in chains like Solana. This is to ensure liveliness during outages (e.g., AWS) and maintain a robust security model.
• Moneyiness and Store of Value: The market empirically values robustness, uptime, credible neutrality, and slow, long-term guarantees for assets with "moneyiness." This is reflected in market caps: Bitcoin ($2T), Ethereum ($500B), Solana ($100B).
• Bitcoin vs. Ethereum: Bitcoin, with its primitive cryptography and low throughput, is seen as a store of value. Ethereum aims for both performance and robustness. Solana, leaning heavily on "Beast Mode," has a lower valuation.
• Bitcoin's Future: Concerns exist about Bitcoin's security with dwindling issuance, as transaction fees currently only constitute about 0.5% of miner revenue.
• User Preferences: Post-2021, user preferences have shifted towards "Beast Mode" (fast chains, high transaction volume). Ethereum's strategy is to aggressively penetrate this market.
• Beast Mode without Fort Mode: Can lead to shallow activity, as seen with meme coins on Solana having a low aggregate market cap compared to stablecoins on Ethereum L1.
• Lean Ethereum Components:
  1. ZK-SNARKs: The core cryptographic unlock.
  2. Beast Mode: Scaling L1 and L2 throughput.
  3. Fort Mode: Defending decentralization and lowering validator entry barriers.

The Role of ZK-SNARKs: The Cryptographic Unlock

History of Ethereum's Cryptography

• Current Primitives: Ethereum, like Bitcoin, relies on "primitive" cryptography:
  • Hash Functions: Used for building blocks, chains, Merkle trees, and state commitments.
  • Digital Signatures: Used for authenticating ownership and signing transactions.
• "Stone Age" Cryptography: These primitives are considered "stone age" compared to modern advancements.
• ZK-SNARKs as "Moon Math": A new primitive that unlocks a new design space for blockchains, enabling a solution to the scale-decentralization trilemma.
• Scaling Resources:
  • Execution: Solved by ZK-SNARKs.
  • Data: Solved by data availability sampling.
• Long-Term Sustainability: ZK-SNARKs also contribute to post-quantum security.
• Data Layer Shortcut: KZG cryptography, used for data sampling, is not post-quantum secure, necessitating a plan for upgrades where ZK-SNARKs can assist.

ZK-SNARKs vs. ZK-EVMs

• ZK-SNARK: The technical term. "S" for succinct (small), "nark" for non-interactive argument of knowledge (proof). It's a small proof.
• Zero-Knowledge Property: ZK-SNARKs also provide zero-knowledge, relevant for privacy, but not the primary focus for scaling.
• ZK-EVMs: A way to leverage ZK-SNARKs without being a SNARK expert. Developers can write typical programs and compile them to a ZK-EVM.
• Naming Convention: The term "ZK-EVM" is used even when privacy isn't the focus, leading to potential confusion. "Snarky VMs" would be more accurate but is not the adopted term.

Robustness and Security of ZK-SNARKs

• Lindy of ZK-SNARKs: While theoretically older, practical implementation in production is about 10 years old (Zcash, launched 2016).
• Zcash Vulnerability: Zcash experienced a critical bug where arbitrary amounts of ZEC could be minted, highlighting the need for robust security. The privacy aspect made it difficult to ascertain if the bug was exploited.
• Ethereum's Security Approach:
  1. Diversity of SNARKs: Using multiple (e.g., five) different SNARK providers and accepting a block if a majority (e.g., three) return valid proofs. This mirrors the diversity in consensus and execution layers.
  2. Formal Verification: Auditing a single proof system to a high degree of certainty, essentially a mathematical proof of correctness.
• Formal Verification Program: Ethereum has a $20 million program for formal verification, aiming for an end-to-end formally verified SNARK with zero bugs by 2029-2030.
• Custom Circuits vs. ZK-EVMs: Zcash used custom circuits, requiring deep cryptographic expertise. ZK-EVMs make the technology accessible to general developers.
• EVM Compatibility: A key requirement is the ability to compile existing EVM implementations to ZK-EVMs, ensuring compatibility with current Ethereum infrastructure.

Lean Execution: Replacing the Execution Client

The Problem with Current Execution Clients (e.g., Geth)

• Intensive Verification Process:
  1. Download Block: A bottleneck if blocks are too large for home internet.
  2. Load State: Requires loading ~100GB of Ethereum state (potentially terabytes with increased gas limits).
  3. Execute Transactions: Demands significant CPU power (many cores) and RAM.
  4. Maintain Mempool & P2P Connections: Additional resource requirements.
  5. Store History: Hundreds of gigabytes of historical data.
• Hardware Constraints: Current execution clients are not adequate for processing 1 Ggas/s on commodity hardware.
• Elon Musk Quote: "The most common error of a smart engineer is to optimize a thing that should instead be eliminated." This applies to optimizing Geth rather than removing it.

The ZK-EVM Solution: Verification, Not Execution

• New Actor: The Prover: Responsible for generating ZK-SNARK proofs.
• Shift in Validator Role: Validators move from executing every transaction to verifying ZK-EVM proofs.
• Statelessness: No need to keep a copy of the state.
• Historylessness: No need to keep a copy of the full history.
• RAMless: Requires minimal RAM (e.g., 100 kilobytes).
• Single Core: Only needs one CPU core, even a weak one.
• Target Hardware: The goal is to run validators on devices as constrained as a Raspberry Pi Pico ($8 hardware), smartphones, or smartwatches.
• User Sovereignty: Enables users to directly verify the correctness of the chain state within their browser or phone, reducing reliance on intermediaries like Infura or MetaMask and enhancing censorship resistance.

The Prover Landscape and Incentives

• Two Regimes:
  1. Optional Proofs: Relies on altruism for proof generation and validator opt-in for verification. A proof of concept.
  2. Mandatory Proofs: Block producers are responsible for generating proofs. If proofs are missing, the block is invalid.
• Incentives: Block producers (receiving fees) are incentivized to generate proofs to avoid penalties.
• Separation of Concerns:
  • Proposer: Randomly sampled validator to propose a block.
  • Builder: Sophisticated entity that constructs economically valuable blocks, often outsourcing to provers.
  • Prover: Generates ZK-SNARK proofs.
  • Validator: Verifies proofs.
• Centralization Concerns: While builders and provers might be centralized in practice, the security model relies on:
  • Honest Minority Assumption (Validators): 50% of validators need to be honest for consensus. Ethereum has ~10,000 individual operators.
  • One Honest Prover Assumption (Provers): Only one honest prover is needed for the system to work. The goal is to have a large number of potential provers (e.g., 100+ data center operators, and eventually home provers).
• On-Prem Proving: The goal is to have provers run on home hardware (e.g., 10kW power draw, equivalent to 10 toasters or a Tesla home charger). This ensures liveliness even if cloud providers fail.
• Prover Hardware: Requires commodity hardware like gaming GPUs (e.g., 16 GPUs like the 5090 can prove all of Ethereum in real time).
• Censorship Resistance: The "Fossil" proposal aims to increase forced inclusion opportunities by 160x, ensuring builders and provers cannot censor transactions.
• Justin Drake's DevConnect Demo: Plans to run a validator by downloading proofs from multiple ZK-EVM clients (e.g., five) and accepting a block if three agree. This provides internal client diversity.
• Benefits of ZK-EVMs for Validators:
  1. Internal Client Diversity: Reduces reliance on external validator diversity.
  2. Lower Barrier to Entry: More decentralization and security.
  3. Code Simplification: Deletes tens of thousands of lines of code related to mempool, history, state, and P2P networking.
  4. Elimination of Engine API Bugs: Removes a historical source of bugs.
  5. Minimalism: Aligns with the "lean" philosophy.

The Roadmap to Lean Ethereum

Phased Integration of ZK-SNARKs

The integration of ZK-SNARKs into Ethereum will be a gradual, phased process, not a single hard fork.

• Phase 0 (Current/Near Future):
  • Opt-in Verification: A small subset of validators (~1%) altruistically opt-in to verifying proofs generated by projects like EF Proofs.
  • Downside: Loss of timeliness rewards due to delayed attestation.
• Phase 1 (2026): Delayed Execution/Attestation
  • Incentivized Opt-in: Validators gain more time (a full slot) to attest, retaining timeliness rewards.
  • Increased Adoption: Expected to attract ~10% of validators, especially those running on lower-spec hardware.
  • Gas Limit Increases: Opportunity to start increasing the gas limit for proof-verifying nodes.
• Phase 2 (2027): Mandatory Proofs
  • Hard Fork (Fork Choice Rule): Requires block producers to generate proofs.
  • Universal ZK-EVM Adoption: All validators are expected to run on ZK-EVMs.
  • Minimal Hard Fork: Primarily changes the fork choice rule.
• Phase 3 (2028+): Enshrined Proofs
  • Single, Formally Verified Verifier: Select one ZK-EVM and formally verify it end-to-end for maximum security.
  • Simplification and New Features: Unlocks native validiums and simplifies the design.
  • Timeline: This phase is projected to take approximately five years of battle-testing.

Gas Limit Increases and Throughput

• Donrad's Proposal: A social commitment to increase Ethereum's gas limit by 3x per year for four years, aiming for 1 Ggas/s.
• Current Progress: Gas limit increased from 30M to 36M, then to 45M. Fusaka upgrade in December aims for 60M-80M, potentially 100M.
• Automatic Increases: The goal is to move towards automatic, incremental gas limit increases (1-2 gas per block) after initial social coordination, rather than laborious manual upgrades.
• 6-Year Target: Extending the 3x per year increase to six years would achieve the 500x scaling to 1 Ggas/s.
• Lean Ethereum's Role: ZK-EVMs provide the "landing pad" for home validators to migrate to as the gas limit increases, preventing centralization.
• Gas Limit vs. Throughput:
  • Gas limit is the maximum gas per block.
  • Current throughput (2 Mgas/s) is calculated from the gas limit (45M), slot duration (12s), and EIP-1559 target (divide by 2).
  • Reducing slot duration (e.g., to 6s) would require a corresponding reduction in gas limit to maintain balance.

Slot Duration and Real-Time Proving

• Slot Duration: Currently 12 seconds. Reducing it to 6 seconds is a proposal.
• Competition: Reducing slot duration makes real-time proving harder, as prover time is valuable.
• Goal: To achieve economically relevant blocks provable within 10 seconds (slightly less than a slot).
• Proof Killers: Artificially crafted blocks that take longer than 10 seconds to prove. Mandatory proofs disincentivize builders from creating these.
• Endgame Vision: Integrated "SNARK CPUs" that generate proofs in parallel with computation, potentially achieving nanosecond-level proving times.

Prover Incentives and Energy Consumption

• Prover Cost: Running provers at home requires significant power (~10kW).
• GPU Clusters: 16 gaming GPUs can currently prove all of Ethereum in real time.
• Future Efficiency: As ZK-EVMs improve, fewer GPUs will be needed, allowing for higher gas limits while maintaining the ~10kW requirement.
• Reserve Army Analogy: Home provers act as a "reserve army" activated only during network issues, consuming minimal electricity otherwise.
• Incentives: Provers are paid by block builders through transaction fees and MEV.
• User Cost: Transaction fees will increase slightly to cover proving costs (estimated at a hundredth of a cent per transaction, decreasing over time).
• Penalties: A system of penalties (e.g., 1 ETH for missing a slot) will be implemented for builders and provers, especially after the Assigner-Proposer Separation (APS) upgrade.

Data Layer and Native Rollups

Data Availability Scaling

• Danksharding: The ongoing effort to scale data availability for L2s to achieve Terra Gas/s.
• Parallel Development: This is happening in parallel with L1 execution layer scaling.

Native Rollups

• Definition: L2 solutions with the same execution environment as L1 but operating on L2.
• Advantages:
  • No need to worry about SNARK prover bugs or maintaining EVM equivalence with L1.
  • Eliminates the need for a security council to manage bugs.
• ZK-EVMs for L2s: ZK-EVM technology can effectively remove the gas limit on L2s, with data availability being the sole bottleneck.
• Powerful Provers: L2s can use more powerful provers off-chain.
• Championed by: Luca Dono from L2B is a key proponent.

Governance and Lean Consensus

Governance Challenges

• ACD (All Core Devs) Process: Ethereum's governance process involves hard forks and a limited number of EIPs per upgrade.
• "Meat Grinder" Effect: The process can be slow and frustrating for developers, leading to technical debt accumulation.
• Limited Capacity: Only a few EIPs can be included in each hard fork.

Lean Consensus: A New Approach

• Governance Batching: An optimization to group multiple EIPs into larger, more impactful upgrades.
• Focus on R&D: Allows for extended periods of pure research and development before proposing significant changes.
• Vision: To enable larger upgrades on a 4-year timeframe, rather than decades of small incremental upgrades.
• Goal: To rebalance governance towards the next 100 years of Ethereum's development, rather than being constrained by the last 10 years of technical debt.

Components of Lean Ethereum (CDE)

1. Consensus Layer:
   • Replacing BLS aggregate signatures with post-quantum equivalents.
   • Faster finality (e.g., 2-3 slots instead of 64).
   • Reduced slot duration.
   • "Snarkifying" the consensus layer for verification on weak devices.
2. Data Layer:
   • Needs to be post-quantum secure.
3. Execution Layer:
   • The focus of Beast Mode scaling with ZK-EVMs.

The Future of Ethereum and Competition

ZK-SNARKs as Cryptography 2.0

• Upgrade: Ethereum is transitioning from "cryptography 1.0" (hash functions, signatures) to "cryptography 2.0" (ZK-SNARKs).
• "Snarkifying" the Stack: The goal is to apply ZK-SNARKs across the entire Ethereum stack.

Competition and Talent Drain

• Tempo: A new competitor raising significant funding, potentially using ref and implementing parts of Ethereum's roadmap.
• Brain Drain: While some talent leaves Ethereum (e.g., Dankrad), there's a larger influx of high-caliber talent from other ecosystems (Bitcoin, Polkadot, Aztec, Filecoin, StarkNet, Polygon).
• Ethereum's Advantages: Community, vision, ideology, and advanced technology are seen as key differentiators that cannot be bought with money.
• L1 vs. L2 Strategy: The argument that L1s should become L2s to leverage Ethereum's network effects. Tempo's success as an L1 is questioned, with a possibility of them pivoting to an L2.
• L1 Premium: New L1s may be capitalizing on an "L1 premium" due to unexplored design space, but this may not be sustainable.

Next Steps and Getting Involved

• DevConnect: A key event for showcasing ZK-EVM progress and community alignment.
• Community Alignment: The goal is for the community to agree on the ZK-EVM path, with disagreements shifting from fundamentals to timelines.
• Timeline Evolution: Skeptics' timelines for ZK-EVMs are shrinking as the technology progresses.
• Tipping Point: When ZK-EVM technology matches L1 throughput and quality, it will no longer be the bottleneck.
• Staying Informed: Follow developments on EF Proofs and related teams.
• Call to Action: Be bold and ambitious, thinking about the next 100 years of Ethereum.

Conclusion/Synthesis

Lean Ethereum represents a paradigm shift, leveraging ZK-SNARKs to achieve unprecedented scalability ("Beast Mode") and fortify security and decentralization ("Fort Mode"). This ambitious vision involves a phased integration of ZK-EVMs, transforming validators from executors to verifiers, and enabling the network to run on commodity hardware. The roadmap prioritizes gradual adoption, robust security through diversity and formal verification, and a fundamental upgrade of Ethereum's cryptographic foundation. While challenges remain in governance and the pace of adoption, the influx of talent and the inherent advantages of Ethereum's ecosystem suggest a strong trajectory towards realizing a future where Ethereum can support global finance. The transition is not just an engineering upgrade but an evolution, driven by cryptographic innovation and a commitment to long-term resilience and decentralization.