Two weeks ago, Ethereum researchers met in Berlin to keep charting the protocol’s long-term trajectory, picking up threads from the client-team discussions held in Svalbard back in April. The output is an updated strawmap, the community’s deliberately provisional sketch of where the protocol is headed, and a set of high-level takeaways that Vitalik Buterin published on July 4. The framing that ties them together is a name: Lean Ethereum.
It helps to be precise about what that name means, because it is easy to file under “another roadmap.” Lean Ethereum is not a single one-shot upgrade. It is a collection of improvements that will come online over the course of three or four years. But make no mistake: this is the third major iteration of Ethereum, in the same way that the Merge was the second. Almost every major piece of the protocol is on the table to be replaced, and the through-line is simplification, cleanup, and future-proofing, done in a way that minimizes disruption to the applications already running. Ethereum has done exactly this before with the transition from proof-of-work, so the precedent for a deep rebuild that users barely feel already exists.
The third iteration of Ethereum
The scope is the part that is hard to internalize. Verification moves from direct re-execution to recursive STARKs, which become an enshrined, first-class component of the protocol rather than an optional layer bolted on top. Everything quantum-vulnerable gets replaced with quantum-safe alternatives. Consensus is redesigned around a decoupled available chain and finality, with one or two-round finality that is theoretically close to optimal on security, simpler than today, and faster than today. Gas becomes multidimensional. State changes not just in its tree structure but in what types of state are even available. Client architecture shifts underneath all of it. None of these is a tweak; together they are a new protocol wearing the same address space.
The naming convention marks the transition cleanly. Hegota, the fork after Glamsterdam (sometimes written H-star, since Ethereum’s upgrade names cycle through the alphabet by first letter), is probably the last thematically “pre-Lean” fork. Starting from I-star, most of what gets shipped will have a strong Lean feel to it in one way or another. So the practical dividing line is not far off: the forks currently in flight are the tail of the current era, and the next letter opens the new one.
What follows walks through the pieces that matter most, roughly in order of how disruptive each one is. Everything here is strawman-stage by design; the strawmap is a sketch meant to provoke iteration, not a finalized spec, and details will move.
Verification by proof, not re-execution
Ethereum today verifies the same way it always has: every full node re-executes every transaction in every block to check that the result is what the block claims. It is trustless precisely because everyone redoes the work. It is also why running a node costs what it costs, and why the gas limit can only rise as fast as the slowest hardware anyone is willing to support can keep up.
Recursive STARKs invert that. One prover does the heavy computation once and produces a compact cryptographic proof that the execution was carried out correctly; everyone else verifies the proof, which is cheap and roughly constant in cost regardless of how much work it attests to. Recursion is what makes it practical at chain scale: proofs about proofs collapse an entire block, and eventually an entire chain’s history, into something a light device can check in milliseconds.
There is a second reason STARKs sit at the center of the plan, and it is the quiet core of the whole thing. STARKs rely only on hash functions, not on the elliptic-curve math that today’s signatures and commitments depend on. Hash-based cryptography is not known to be breakable by a quantum computer. So the move to proof-based verification is also the move to a quantum-safe foundation, which is why these two threads keep showing up together.
Quantum safety moves to the front
Quantum safety has shifted up a lot in priority relative to earlier roadmaps, and that reprioritization adds real work. The uncomfortable fact is that most of Ethereum’s live cryptography is elliptic-curve based and therefore quantum-vulnerable: ECDSA transaction signatures, BLS aggregate signatures in consensus, and the KZG commitments that underpin blob data availability. Each needs a hash-based or STARK-based replacement, and finalizing a quantum-safe blobs design in particular has become urgent; that work has already been ongoing for months.
Underwriting all of this is a commitment to formal verification of everything that matters for security. Formal verification also makes the researchers far more comfortable with canonicalization, meaning having pieces of the protocol that are directly defined as a piece of bytecode expressed in some language rather than described in prose and re-implemented by each client. That is part of why evm-asm is being written: in part to become a canonical, formally verifiable proof system for the EVM. The pattern is consistent; if a component is going to be load-bearing for security, the plan is to define it precisely enough that a machine can check it and prove it correct.
The state question is the disruptive one
Probably the single most disruptive part of the plan is the change to state. The direction gaining consensus is to leave present-day “dynamic” state mostly unchanged and scale it only a medium amount, while adding entirely new types of state that are far more scalability-friendly, at the cost of being more restrictive. The new-style state is designed so that, for example, builders do not need to sync or store all of it, which is exactly the property that lets it scale a large amount.
The numbers make the split concrete. One plausible shape for 2030 is on the order of 2 TB of present-day dynamic state alongside 100 TB of new-style state. The dynamic tier keeps doing what today’s state does and suits the “central,” complex objects that only a small fraction of state actually needs: Uniswap contracts, onchain order books, and other highly-shared machinery that is crucial to Ethereum even though it is a minority of storage by volume. The new tier is built for the opposite: simple, numerous objects like ERC-20 balances, NFTs, and many DeFi use cases.
The important nuance is that nothing forces a migration. It will never be necessary to rewrite an application. It will simply be very cost-effective to do so where the new tier fits; rewriting an ERC-20 token onto a newer design that uses a new kind of UTXO storage currently being explored could cut its transaction fees by more than 10x. Designing these state types is genuinely open work. The current candidates include keyed nonces, ring buffers, UTXOs, statically accessible state, and temp state, and settling on them will take heavy feedback from application developers, including privacy-focused ones, across probably several rounds of rethinking.
A larger total state also surfaces an incentive problem that is being elevated to a first-class research area. Once state is this big, saying “each node stores 1%” is not good enough as an answer. The open question is why a given node stores its particular slice and why it is willing to serve it. Storage and serving incentives, not just data structures, become part of the protocol design surface.
Consensus, gas, and the question of the VM
Consensus gets a redesign aimed at properties that are simultaneously stronger and simpler. The plan decouples the available chain from finality and moves to one or two-round finality, which the researchers describe as close to theoretically optimal on security while being both simpler and faster than the current fork-choice and finality machinery. Gas becomes multidimensional, pricing distinct resources like execution, data, and state growth separately instead of collapsing them into one number, so that the protocol can raise the ceiling on plentiful resources without over-exposing scarce ones.
The most structural of these questions is the virtual machine. Ethereum will need to have a VM other than the EVM in one form or another; at the very least, recursive STARKs need something like leanISA, an instruction set designed to be efficient to prove. Once such a VM exists, the gains from exposing it to users directly are large, because it is what enables programmable privacy and better scalability. The two leading contenders right now are leanISA and RISC-V.
Vitalik’s own stated ideal goes one step further: adjust the protocol so that the EVM becomes a high-level-language, compiler-level feature, and the protocol itself only ever “sees” RISC-V or leanISA directly. In that world the EVM is preserved for compatibility but demoted from a protocol primitive to a compilation target, the same way a high-level language compiles to machine code today. He is careful to note this is still far away, but the direction of travel is clear.
Privacy as a first-class goal
One shift is cultural as much as technical. Privacy is no longer an afterthought that gets a dedicated protocol bolted on later; it is a first-class design goal that constrains everything else. When the researchers design Frames, the mempool, or additions to the state tree, they now explicitly ask: how does a quantum-safe, intermediary-free privacy protocol transaction go through this, and what is the overhead? That question being asked at design time, rather than after the fact, is what changes. It is also why the mempool and the new state types keep coming back to the same reviewers; a design that is efficient but cannot carry a private transaction cheaply is now considered incomplete rather than merely un-optimized.
What this means if you build on Ethereum today
The honest framing is that most of Lean Ethereum is three to four years out, with the core post-quantum pieces targeted around 2029. The strawmap is a research artifact, not a shipping schedule, and the specific mechanisms will change more than once. Nothing here requires you to rewrite an application, and nothing here lands next quarter.
What is near-term and concrete is the scaling that continues regardless. Gas-limit increases, blob-count increases, and slot-time decreases will each happen many times over the next roughly five years, and a large gas-limit increase is expected with Glamsterdam specifically. Every one of those steps is gated on the same thing: getting to the point where it is safe to do, which comes from a combination of client optimization and protocol changes. Glamsterdam is already carrying two of those enabling changes, ePBS (EIP-7732) on the consensus side and Block-Level Access Lists (EIP-7928) on the execution side, and both are what make the higher gas limit tolerable.
For anyone whose work is consuming or producing Ethereum data, the practical takeaway is the same one those two Glamsterdam changes already point at, and Lean only sharpens it: the chain is going to produce more data per block, verify it differently, and store it across more tiers. Larger blocks and richer per-block data reward pipelines that read from a node they control over a local socket rather than pulling growing payloads across the public internet and paying per-megabyte on the way. If you index state, the two-tier state model is worth watching early, because the new tier changes what a “balance” or a “token transfer” even looks like at the storage layer, and indexers that assume one universal state shape will have work to do. On BLAZED.sh the deployment shape already matches where this is heading: your container or script runs on the same host as a fully synced node, so when the protocol starts shipping more per block, you are reading it locally instead of moving it to use it.
The one thing not to do is treat Lean Ethereum as either imminent or hypothetical. It is neither. It is a multi-year rebuild whose early forks are already visible on the calendar, and the cheapest way to be ready is to build against the direction rather than the date.
FAQ
What is Lean Ethereum?
Lean Ethereum is the umbrella name for Ethereum’s third major protocol iteration, a three to four year collection of upgrades that replaces most of the protocol’s core: verification via recursive STARKs instead of re-execution, quantum-safe cryptography, a redesigned consensus with fast finality, multidimensional gas, and new types of state. It follows the same pattern as the Merge, a deep rebuild designed to minimize disruption to existing applications.
Is Lean Ethereum a single hard fork?
No. It is explicitly a series of forks over several years rather than one event. The current thinking is that Hegota, the fork after Glamsterdam, is the last “pre-Lean” fork, and that the Lean character begins in earnest at the following fork, I-star, with core post-quantum work targeted around 2029.
Will I have to rewrite my smart contracts?
No. Backward compatibility is a stated design constraint, and existing applications are meant to keep working. The new state tiers make it cost-effective, not mandatory, to rewrite certain contracts; for example moving a simple ERC-20 onto new-style storage could reduce its fees by more than 10x. Complex, highly-shared contracts like Uniswap or order books stay on the present-day dynamic state.
Why do recursive STARKs and quantum safety keep getting mentioned together?
Because STARKs rely only on hash functions rather than elliptic-curve cryptography, and hash-based cryptography is not known to be breakable by quantum computers. Moving verification onto recursive STARKs therefore doubles as moving Ethereum’s security onto a quantum-safe foundation, which is why the two goals advance as one.
Does any of this affect how I run infrastructure today?
Indirectly, and soon in one respect. The Lean direction reinforces that Ethereum blocks will carry more data and be verified and stored differently over the next few years, and near-term gas-limit and blob increases (starting with Glamsterdam) already push more data per block now. That rewards running your code next to the node rather than pulling large payloads over the internet, which is the same conclusion the Glamsterdam changes already reach.
Conclusion
Lean Ethereum is the clearest statement yet that Ethereum intends to reinvent its own internals rather than merely extend them, and to do it on the same schedule as the scaling users actually feel. Verification by proof, quantum-safe cryptography, a two-tier state model, faster and simpler consensus, a real answer on privacy, and eventually a different virtual machine underneath the EVM: taken together it is a new protocol, delivered as a sequence of forks that existing applications are meant to ride through unbothered. Vitalik summed up the posture in four lines. Ethereum is CROPS, the Ethereum Foundation’s shorthand for censorship resistance, open source, privacy, and security. Ethereum is scaling. Ethereum is reinventing itself. Onward. The place to follow the shape of it as it firms up is the strawmap.