Off the back of the EF’s recent announcements, Vitalik dropped a new post: “Simplifying the L1.”
In it, he lays out a long-term vision to streamline $ETH's base layer — arguing that it needs to be as simple as $BTC in five years if it wants to be the world’s settlement layer.
Here’s the gist of Vitalik’s plan.👇
~~ Article by @davewardonline ~~
|— Why Simplicity Matters
For @vitalikbuterin, simplicity isn’t just about cleaner code — it’s about making Ethereum stronger. The more people who can understand and, as a result, work with the protocol, the more secure, decentralized, and adaptable it becomes.
He points to Bitcoin: its base layer is so minimal a high schooler (he believes) could build a client. That simplicity has helped it remain stable, widely auditable, and hard to corrupt.
Ethereum, by contrast, has added complexity over time — sometimes necessary, often not. This complexity has slowed upgrades, increased risk, and made contributing harder.
Simplifying now would unlock key advantages:
• Easier to verify and secure: Less code means fewer places for bugs or attacks to hide.
• Lower maintenance burden: Fewer legacy systems make future upgrades smoother.
• Wider contributor base: Simpler design invites more developers to get involved.
• Stronger neutrality: Clear, predictable rules are harder to manipulate or politicize.
With the network stable and ready to mature, Vitalik sees now as the moment to clean house.
|— 1. A Simpler Consensus Layer
For simplifying consensus, Buterin points to the new Beam Chain proposal, which advocates replacing older, complex systems with a cleaner design:
⚙️ Simpler core with 3-slot finality: Cuts out technical systems like epochs, committee shuffling, and sync committees, making the consensus engine easier to understand, audit, and maintain.
🔗 Easier fork choice rules: Reduces the number of active validators at any time, lowering complexity when deciding which version of the chain to follow and improving safety.
🗳️ Simpler vote collection (STARK-based): Makes it easier and cheaper to gather validator votes without needing to trust specific actors or deal with repeated data.
🧹 Cleaner validator lifecycle: Makes validator onboarding, exiting, key updates, and offline recovery more straightforward, reducing edge cases and helping the network define clearer safety windows.
🤝 Simplified peer-to-peer communication: Fewer protocol parts make it easier for nodes to connect, sync, and stay in agreement.
|— 2. A Simpler Execution Layer
Next, Vitalik reiterates support for replacing Ethereum’s current virtual machine — the EVM — which he sees as bloated and a blocker to scalability, with the simpler, more modern RISC-V alternative.
For those who missed our piece on RISC-V, this general-purpose virtual machine can be thought of like Linux for hardware: a clean, open-source blueprint already used by companies like Intel and Arm to build chips.
In Ethereum, it would serve as the new smart contract engine, offering these benefits:
→ Simpler virtual machine spec: Far easier to understand than the EVM, reducing bugs, making upgrades easier, and being better suited for long-term maintenance.
→ Fewer special-case shortcuts (precompiles): Replaces most built-in functions with regular smart contract code, shrinking the base protocol and making it easier to maintain.
→ Already in use for ZK: Used by projects like @RiscZero and @succinctlabs since RISC-V speeds up zero-knowledge proofs.
→ More language flexibility: Developers could use languages like Rust or Move, not just Solidity.
Vitalik sees this as a chance to build the foundation back better, potentially increasing its performance by 100x.
|— 3. A Backwards-Compatible Transition
What happens to all the apps and tools that still rely on the EVM? Vitalik lays out a phased transition plan that keeps everything working, without forcing the base protocol to carry legacy baggage forever.
The aim: move legacy features out of the core, where they still work but don’t weigh Ethereum down. Like storing old files in the cloud, they're still there if needed, but off your desktop. This keeps the core protocol lean while preserving compatibility for everything already built. Here’s how he proposes doing it:
1. Start with RISC-V precompiles: New features would be built using RISC-V, warming the ecosystem up to the VM.
2. Support both VMs: Developers could deploy in either EVM or RISC-V, with full cross-compatibility, during the transition.
3. Swap precompiles for RISC-V code: Replaces most built-in functions with simple onchain RISC-V, cutting protocol bloat.
4. Wrap the EVM in a contract: Moves the EVM into a RISC-V smart contract, meaning older logic would still work, but wouldn’t clutter up the most sensitive parts of the protocol.
This way, Ethereum can clean up its foundation without breaking what’s already built.
|— 4. Shared Standards = Less Complexity
Lastly, Vitalik wants to simplify Ethereum by standardizing tools across the network.
Right now, different parts of the protocol often solve the same problem in slightly different ways — mostly because teams build them separately. Unifying those pieces under shared standards would cut down on complexity and make the whole stack easier to maintain. His suggestions:
• One shared encoding system (SSZ): Already used in the consensus layer to track network state. Expanding it across Ethereum would simplify tooling and make apps easier to build and connect.
• One shared method for splitting data (erasure code): Ethereum splits and verifies data in multiple areas: data availability sampling, P2P broadcasting, and history storage. Using the same method everywhere would cut code, improve speed, and ensure data checks out.
• One shared state structure (tree format): Replacing the current complex (Merkle) data tree with a simpler, binary one would save space, speed up proofs, and help light apps work more efficiently.
Overall, @ethereum's strength is its flexibility, but it's become complex. Vitalik envisions making Ethereum simpler yet powerful — leaner, clearer, and easier for building. To support crucial data and systems, Ethereum must be scalable and durable, starting with simplification.
