EVM Scaling
An Interactive Introduction
Build intuition for what EVM scaling actually means, how different solutions work, and how to evaluate performance claims.
The Execution Bottleneck
With PeerDAS, data availability is no longer the limit. Now what?
The Promise
- ✓Projects claim "10,000+ TPS"
- ✓Impressive benchmark numbers
- ✓"Blazing fast" execution
The Reality
- ✗Slow in production with real workloads
- ✗Benchmarks use unrealistic tx mixes
- ✗No shared model to compare solutions
We need a shared mental model for understanding EVM scaling — one that makes it easy to reason about tradeoffs and compare solutions honestly.
What We'll Build Together
A framework for understanding and comparing EVM scaling approaches
The Model
Resources, transactions, and block packing
Scaling Solutions
Different ways to grow the bars
Fee Markets
Why scaling alone isn't enough
Projects
Real implementations compared
Our Goal
Build intuition for what scaling means, so you can evaluate claims and understand tradeoffs — not just accept benchmark numbers at face value.
Bonus: Pump Your Numbers
Learn how to game benchmarks for your marketing team. (For educational purposes only!)
The Path to Teragas
What if we could just... increase the gas limit?
Transactions
Different transaction types consume different amounts of each resource.
Select Transaction Type
Resource Consumption per TX
ETH Transfer
Simple ETH transfer between accounts. Minimal state access.
Notice how swaps consume much more CPU gas but similar state access as transfers.
Pack a Block
Add transactions and watch which resources hit their limits first
Try different transaction mixes!
Adding ETH transfers mostly stresses state access. Uniswap swaps are heavy on EVM compute. Rollup batches hit block distribution limits.
Growing the Bars
Click any resource to increase its capacity. This is what scaling means.
This is Scaling
Each scaling technique targets specific resources. Parallel execution improves EVM compute. Better databases improve state access. ZK proofs help verification.
→ Check the Scaling Matrix to see which techniques improve which resources!
The Scaling Matrix
How each technology improves different resources
| Solution | ⚙️ EVM | 💾 State | 🌳 Merklization | ✅ Block | 📡 Block | 📈 State | 📚 History | 🔐 Proof |
|---|---|---|---|---|---|---|---|---|
| Execution | ||||||||
🔀Parallel Execution | +++ | ++ | - | - | - | - | - | - |
🔥State WarmingLIVE | + | ++ | - | - | - | - | - | - |
🎯Speculative Mempool ExecLIVE | ++ | + | - | - | - | - | - | - |
⚡Custom PrecompilesLIVE | ++ | - | - | ++ | - | - | - | + |
🚀JIT/Native ContractsLIVE | ++ | - | - | ++ | - | - | - | - |
| State Management | ||||||||
🗃️TriedbLIVE | - | +++ | ++ | - | - | + | - | - |
⏳State Expiry | - | + | + | - | - | +++ | - | - |
| Data & History | ||||||||
📚Historical State IndexingLIVE | - | - | - | - | - | - | + | - |
| Proving | ||||||||
🔮ZK Light Clients | - | - | - | ++ | + | - | - | +++ |
🔧RISC-V VM | +++ | - | - | - | - | - | - | +++ |
| Protocol | ||||||||
⏱️Delayed State Root | - | - | +++ | - | - | - | - | - |
📋Block Access Lists | - | - | - | +++ | - | - | - | - |
Scaling Up Resources Is Not Enough
Low-value transactions can consume all resources, blocking higher-value activity
Try this:
Add XEN mints until state-access fills up. Then keep clicking to see backpressure!
The Market Clearing Price
The ideal state: 100% utilization with zero backpressure
What is Market Clearing?
The market clearing price is the fee level where:
- ✓All block resources are fully utilized (100%)
- ✓No transactions are waiting (zero backpressure)
- ✓Supply exactly matches demand
Price Too Low
Block is full but transactions are waiting. Fee should rise to reduce demand.
Price Too High
No backpressure but block space is wasted. Fee should fall to attract more demand.
Market Clearing Price
Perfect equilibrium: every transaction that wants to pay the fee gets included, and no block space goes unused.
Why This Matters
Automatically adjust the base fee to find this market clearing price. When blocks are full, fee rises. When empty, fee falls.
Understanding Demand Curves
How price affects the quantity of transactions that want block space
The Core Insight
When block space prices are low, many transactions want to be included. When prices are high, only the most valuable transactions will pay.
This creates a downward-sloping demand curve: as price increases, quantity demanded decreases.
Why Demand Fluctuates
- •NFT drops create sudden spikes in demand
- •Market volatility drives DeFi arbitrage
- •Time of day affects user activity
- •Network events (airdrops, launches) spike demand
The Challenge
The blockchain needs to find the right price that fills blocks efficiently without creating long queues. Too low = congestion. Too high = wasted capacity.
Interactive Demand Curve
Shift the entire demand curve up or down
See how price affects block utilization
EIP-1559: How It Works
A mechanism that adjusts prices based on network congestion
The Mechanism
Target: Blocks should be 50% full on average.
If block > 50% full: Base fee increases (up to 12.5%)
If block < 50% full: Base fee decreases (up to 12.5%)
Base fee is burned: Not paid to validators
Why This Works
- •Users know roughly what to pay (just check current base fee)
- •Fee responds to demand automatically
- •Burning base fee prevents validator manipulation
- •Can still spike during sudden demand surges
Adjust to simulate different network conditions
Live Simulation
Limitation
EIP-1559 treats all gas as equal. But a block full of simple transfers vs. a block full of complex DeFi calls stress different resources. This is why multidimensional fee markets are being researched.
The Bottleneck Problem
When mixing transaction types, one resource becomes the limiting factor
Transaction Mix
Adjust the mix of transaction types in the mempool:
Current Bottleneck
Effective throughput: 110 TPS
The Problem: Whichever resource fills up first limits the entire block, even if other resources have capacity remaining.
Multiple Supply Curves
The Solution: Multidimensional Fee Markets
Instead of one gas price, have separate prices for each resource. This way, IO-heavy transactions pay more for IO but less for CPU, and vice versa. The result: better resource utilization and more efficient block packing.
Fee Market Improvements
Technologies to price transactions more accurately
Beyond scaling resources, we need to price them correctly. Mispriced operations lead to inefficient block packing and unfair fee distribution.
TPS Simulator
Compare how different scaling approaches handle the same demand
Simulation A
2.5 Mgas/sSimulation B
10.0 Mgas/sCompare Mode
Watch both simulations run simultaneously. Notice how the scaled version handles demand spikes better with lower fees and higher throughput.
Pump Your Numbers
Get those mass-marketable TPS numbers
Step 1: Pick Your "Representative" Workload
Pro tip: simpler = faster = bigger numbers
Step 2: Crank Up Those Threads
More cores = more TPS. Who's counting anyway?
Pick your workload, set your threads, and let's see how impressive we can make those numbers look.
Okay but seriously
TPS without context is like measuring a car's speed... downhill... with the engine off. Next time someone brags about TPS, ask: What transactions? What hardware? What's the catch?
Let's Build Together
Now we have a shared mental model
Shared Mental Model
Now that we understand the 8 resources, scaling tradeoffs, and fee market dynamics, we can prioritize and divide & conquer!
Let's Talk!
I'd love to discuss this stuff with you. Whether you're working on client implementations, L2 scaling, or fee market research — please reach out!
Especially Interested In...
How can we fix the fee markets so that client software improvements are reflected in the transaction fees of the network?
If we can properly price each resource, client teams would be directly rewarded for their optimization work.
Built with 💜 for the Ethereum community
View source on GitHubMore Coming Soon
Project comparisons and the infamous "Pump Your Numbers" section are in development.