---

---

Ethereum builders outlined a “Lean Ethereum” roadmap that aims to trim layer-1 complexity while hardening security, according to researcher Thomas Coratger on June 12 via X. 

Co-founder Vitalik Buterin and researcher Justin Drake discussed the concept in a breakout session at the Forschungsingenieurtagung conference in Berlin. It proposes three guiding targets: security, simplicity, and optimality.

‘Lean Ethereum’

Coratger wrote that the roadmap calls for post-quantum-ready signatures and reworked data availability to guard the ledger against future cryptographic threats. 

He added that simplicity would come from slimming consensus, execution, and data layers so new contributors can audit code without steep learning curves. Optimality aims to achieve lower latency and overhead, keeping Ethereum competitive while maintaining its decentralization.

Buterin illustrated the effort with four research tracks already under review. The first is a three-step-finality (3SF) protocol that delivers rapid block finality in a compact codebase, while the second is aggregated post-quantum signatures.

A third research track focuses on zero-knowledge virtual machines that enable verifiable execution, with a data-layer refactor that merges blobs through erasure coding, rounding up the tracks. 

Drake connected those tracks to existing strategy items, including user-experience upgrades, scalability work, and full-chain sampling.

The ‘Lean’ banner

Furthermore, Drake laid out several near-term proposals under the “lean” banner, including lean staking, which would strip validator duties to the essentials.

Lean verifiability would let low-power devices confirm blocks with modest bandwidth. A lean crypto approach would reduce the protocol’s reliance on multiple primitives, favoring a single hash function and post-quantum schemes wherever possible. 

He also promoted “lean specs,” breaking logic into small modules, and “lean formal verification,” starting with zk-VMs and signature aggregation.

Coratger noted the alignment between these ideas and active engineering work, such as Fork-Choice enforced Inclusion Lists (FOCIL), zkEVM pilots, and beam roadmap prototypes. 

He reported that session participants acknowledged the difficulty of achieving optimality but viewed the payoff as worthwhile, especially as rollups and centralized sequencers reshape Layer 2 processing. 

Foundation response

Ethereum Foundation co-executive director Tomasz Stańczak described Drake’s presentation as a forward-looking synthesis of current projects and longer-range research.

Stanczak wrote that many ideas will proceed to testing while others will evolve, calling the roadmap an “unifying theory” rather than an immediate directive. He added that the talk motivated contributors by tying today’s milestones to a broader technical horizon.

Yet, Lean Ethereum remains a research framework without a scheduled hard fork proposal. Core teams plan to refine design documents, prototype features such as mini-3SF, and evaluate trade-offs in working group calls.

Mentioned in this article

In February, the Department of Government Efficiency (DOGE) began soliciting public input pertaining to the U.S. Securities and Exchange Commission (SEC) — a move suggesting reform at the agency is imminent.

Since then, the SEC, in line with President Trump, has taken a far less adversarial stance towards the cryptocurrency industry, as evidenced by the appointment of crypto-friendly personnel and the abandonment of numerous lawsuits and investigations into crypto companies. But DOGE has the potential to implement further change, and interest in the SEC signals growing pressure towards regulators to reassess their approach to digital assets.

In response to the request for public input, Paul Grewal, Chief Legal Officer at Coinbase — one of the companies no longer facing a lawsuit from the SEC — proposed a policy requiring the SEC to reimburse legal costs for companies that successfully challenge enforcement efforts. The motivation for his suggestion is obvious, but the impact of DOGE on crypto will likely be a bit broader.

As Joel Khalili summarized in Wired, the SEC’s recent retreat from lawsuits represents “an early signal of the agency’s intent to work arm in arm with the industry to come up with a set of rules to govern crypto transactions and products.”

As things currently stand, the SEC’s lack of proactive guidance makes it difficult for businesses to plan long-term compliance strategies, and their enforcement actions often come after years of operation, leaving companies and their investors exposed to unforeseen legal risks. Going forward, this will likely change.

Clear Compliance Over Reactive Enforcement

Relying on enforcement instead of proactive guidance has forced companies like Coinbase, Ripple, and Celsius to spend millions in litigation to clarify their regulatory standing. But in one case against Debt Box, the SEC admitted to inaccuracies in its statements, leading a court to order the SEC to cover the company’s legal expenses — a preview of Coinbase’s suggestion. The ruling cast doubt on the agency’s credibility and highlighted concerns over its enforcement practices.

In the future, expect to see regulatory agencies – including the SEC – under increased pressure to align with the U.S. Treasury’s approach, which prioritizes clear compliance pathways over reactive enforcement. The Treasury’s digital asset guidelines are far more structured and address key areas like tax reporting, compliance and AML measures. Standardized definitions of what constitutes a security in the crypto space are essential for helping companies structure their products appropriately from the outset.

A Balancing Act

In addition to taking notes from the Treasury, the SEC can also look to the IRS for inspiration. A “safe harbor” provision for early-stage projects could encourage innovation while ensuring compliance over time, similar to proposals previously discussed by SEC Commissioner Hester Peirce. The IRS already embraced this approach, issuing temporary transitional relief for crypto taxpayers in January 2025.

The IRS historically relied on voluntary disclosure programs to bring taxpayers into compliance rather than imposing punitive actions upfront. A similar model should be applied to crypto regulation as well.

While some people assume regulation inherently hinders innovation, the opposite can be true. This is because clearly defined guardrails will entice more risk-averse entities to enter the ecosystem and help it grow. A light regulatory touch requires robust backend enforcement and can lead to unnecessary friction between regulators and businesses.

Altogether, better coordination between the SEC, Treasury, and IRS would help prevent regulatory conflicts and streamline compliance obligations for digital asset companies and stakeholders. The Treasury’s digital asset guidelines already offer a strong foundation for this type of cross-agency alignment. The current regulatory uncertainty and the SEC’s reactive enforcement approach stifles growth, while a clearer, more coordinated framework would benefit the entire ecosystem.

The Bottom Line

Between the DOGE’s request for input, the new administration’s broader commitment to digital asset reform, and Coinbase’s proposal, the stage is set for reforms aiming to make regulatory oversight more predictable. While we are in the early stages of the new administration, changes are already occurring at a staggering pace. It’s clear that DOGE’s influence on SEC policies will make an impact – especially with public discourse on these issues further strengthening the case for clearer guidelines rather than regulation by enforcement.

Of course, it’s worth noting that DOGE’s plans for the SEC will likely extend beyond crypto, just as efforts to regulate the industry extend beyond the SEC. Ultimately, it would be beneficial for the new administration, in conjunction with Congress, to create a legislative framework for the industry, so enterprises and individual taxpayers alike understand what constitutes a commodity, security, and digital asset. In other words, we must learn to walk before we run. In the meantime, the SEC should adopt a strategy that can foster growth while maintaining investor protections.

Vitalik Buterin has proposed a long-term overhaul to Ethereum’s execution environment to replace the Ethereum Virtual Machine with RISC-V, a standardized and extensible instruction set architecture.

The proposal, shared in the Ethereum Magicians forum on April 20, outlines a multi-phase shift to improve proving efficiency and simplify the execution layer, without changing core abstractions like accounts, storage, or cross-contract calls.

The change would retain Solidity and Vyper as primary development languages, which would be adapted to compile to RISC-V.

Per Buterin, while writing contracts directly in Rust would be technically possible, readability concerns and developer familiarity with existing languages suggest that Rust will not replace Solidity at the application layer. Existing EVM contracts would continue to operate and interact fully with new RISC-V-based contracts, preserving backward compatibility.

Execution bottlenecks and long-term scaling

Buterin identified execution as one of Ethereum’s final long-term bottlenecks, after near-term issues are mitigated by EIPs such as delayed execution, block-level access lists, and distributed historical storage.

In particular, he pointed to proving costs in ZK-EVMs as the key constraint for future scalability. Analysis from Succinct’s ZK-EVM indicates that block execution alone accounts for nearly half of all prover cycles, while the remainder is consumed by witness data handling and state tree operations.

While state-related overhead can be reduced by shifting from Keccak-based Patricia trees to binary trees with prover-optimized hash functions such as Poseidon, block execution efficiency will remain limiting unless the EVM is addressed directly.

Buterin noted that ZK-EVMs already compile to RISC-V under the hood, suggesting that exposing RISC-V as the primary VM could eliminate a layer of abstraction and yield efficiency gains. Some test scenarios reportedly show 100x improvements in prover performance by bypassing EVM translation altogether.

Coexistence, migration, and simplification paths

Multiple implementation pathways are under consideration. The most conservative would allow dual support for both EVM and RISC-V contracts, maintaining interoperable calls and shared access to persistent state. EVM contracts would continue to function and could call into or be called by RISC-V contracts via system calls mapped to traditional opcodes such as CALL, SLOAD, and SSTORE.

A more aggressive approach involves transforming existing EVM contracts into wrappers that delegate execution to an EVM interpreter written in RISC-V. Under this model, a contract’s bytecode would be replaced with logic that routes calls and execution parameters to a designated RISC-V interpreter contract, receives the return value, and forwards it to the caller.

An intermediate strategy proposes protocol-level support for virtual machine interpreters, enshrining this delegation process and enabling multiple execution formats to coexist. While EVM would be the first VM supported under this model, others, including Move, could be added in the future.

Each approach seeks to balance compatibility with long-term simplification. According to Buterin, incremental simplifications to the EVM, such as removing SELFDESTRUCT, have proven difficult due to complex edge cases and legacy behaviors.

A complete transition to RISC-V could enable a more maintainable base layer with minimal execution logic, comparable in compactness to projects like Tinygrad that enforce strict codebase limits.

Broader design philosophy and alignment with Beam Chain

The proposal aligns with ongoing efforts like the beam chain initiative, which aims to simplify Ethereum’s consensus mechanism. The RISC-V plan would bring parallel improvements to the execution layer, enabling the network to pursue modularity and reduced complexity across both domains.

As posted on Ethereum Magicians, Buterin characterized the proposal as a radical but possibly necessary step toward realizing long-term L1 efficiency and simplicity. While active EIPs and statelessness frameworks address short- and medium-term scalability improvements, Ethereum’s future as a performant and sustainable protocol may hinge on architectural changes of this magnitude.

No timeline has been announced for any implementation phase. The Ethereum community is expected to engage in further discussion to evaluate trade-offs, tooling impact, and developer migration paths as part of a longer deliberation cycle.

The proposal remains exploratory and is intended to open a broader conversation about the direction of Ethereum’s execution environment over the coming years.

Community response

Some community members raised strategic and technical reservations in response to Buterin’s proposal. Adam Cochran questioned the prioritization of L1 efficiency at the potential expense of L2 enablement, suggesting that enshrining RISC-V could narrow Ethereum’s modular roadmap.

He highlighted alternative proposals such as recursive proof aggregation, stateless commitment roots, and BLS signature unification, which could potentially offer broader systemic gains with fewer implementation costs.

Others, including Ben A Adams, Co-founder and CTO of Illyriad Games, and levs57, a web3 developer, pointed to performance trade-offs, particularly around hardware compatibility and the persistent role of precompiles.

Concerns included the difficulty of optimizing low-level RISC-V instructions back into efficient 256-bit operations and doubts about whether current zk-RISC-V systems are sufficiently mature or auditable to justify a foundational shift.

Buterin responded by downplaying the extent to which the EVM’s 256-bit word size constrains execution, stating that most values in practice are smaller, typically u32, u64, or u128, which compilers can efficiently map to RISC-V instructions.

He reiterated that today’s ZK-EVMs already operate as RISC-V environments embedding an EVM interpreter, framing direct exposure of RISC-V as a way to remove redundant layers. While acknowledging stack management and jumps as potential friction points, he maintained that eliminating interpretive overhead remains a net gain.

Mentioned in this article