Ethereum Acceleration

Since its inception, Ethereum has been a pioneering force in crypto. Ethereum paved the way for smart contracts, DAOs, and DeFi, and continues to innovate on frontier challenges like ZK and MEV. Ethereum’s community of researchers and engineers has built a strong foundation for the next generation of decentralized applications.

It’s easy to forget that the first version of the Ethereum protocol shipped in less than two years—a pace that drew many of us to the project as a developer platform in the first place.

But today, we think Ethereum’s core protocol could be improving much faster. There are many high-impact improvements that Ethereum can start accelerating towards today, without sacrificing its values.

Shipping faster helps Ethereum regardless of your vision for it.

There is reasonable debate about what Ethereum’s north star should be. But wherever you think Ethereum should go, surely it is better to get there faster. Investing in Ethereum’s shipping capacity is valuable regardless of which direction the protocol ends up going.

When faced with a technical choice, it’s tempting to immediately jump to arguments about values — like whether we care more about L1s vs. L2s, decentralization vs. efficiency, or financial vs. non-financial use cases. These debates are addictive because anyone can participate in them. They can generate a lot of heat, and build a lot of clout for the debaters. But if we haven’t hit the fundamental limits, discussions about tradeoffs in values might be premature. We think Ethereum should be focused on reaching the efficient frontier of what’s possible before arguing — hypothetically — about how we would choose between our values once we’ve hit those limits.

Shipping faster will help Ethereum get there. It also can dissolve many “either/or” dilemmas around prioritization, by responding to questions like “should we do X or Y first?” with “both.”

Ethereum has the resources it needs — incredible researchers and engineers eager to build the future. Empowering them with a mandate to move faster, and in parallel, will enable Ethereum to solve problems faster and avoid getting bogged down in premature debates.

How could Ethereum ship faster?

Historically, Ethereum has shipped about one change per year. Ethereum can do more.

Most importantly, by deciding to. The community can set more ambitious goals and work harder to meet them. One obstacle to this is inertia. But another is the somewhat common belief that the protocol should begin to ossify — that the best way to keep Ethereum decentralized is to slow down the pace of changes to the core protocol.

We think ossification is too risky for Ethereum. It prevents Ethereum from staying competitive as a platform, as applications and users move toward more centralized alternatives. Ossification also poses its own centralization risks to Ethereum. The core development process is one of the main mechanisms for offchain governance by Ethereum’s social layer, and reflects input from engineers, researchers, validators, and institutions. Ossifying the core protocol would mean abandoning that governance mechanism and Ethereum’s ability to evolve in response to changes in the market structures of areas like L2s and MEV.

Once we decide to move faster, there are R&D process improvements that could have a large impact.

For example, client teams should have an input, not a veto. Client diversity does not need to come at the expense of shipping speed. We should have more than one client ready for every upgrade, but we shouldn’t have an N-of-N where the most conservative client dictates the speed for protocol iteration. We maintain Reth, and we want to commit to never being the bottleneck on Ethereum’s roadmap.

The All Core Devs process can be improved (as Tim Beiko recently suggested on the Consensus Layer call). We invite the community to weigh in on the Pectra retrospective with concrete suggestions.

Let’s allocate more resources to DevOps and Testing so we can confidently deliver major improvements more often — while still preserving the reliability Ethereum is known for.

There are many ways to move faster beyond these initial suggestions — the high-order bit is explicitly recognizing the need for speed.

We aren’t lacking good ideas

We believe there is low-hanging fruit that the Ethereum community could put more of its energy behind. These non-controversial improvements are delayed because of slow shipping speed and the perception that only a few changes can be made per year. Instead of proactively limiting its ambition, Ethereum should aspire to do more, faster.

Here are some possible examples:

• Scaling and securing L2s:
  • Rollups need to confidently plan for what level of demand to accommodate. This requires allocating more resources on the post-EIP4844 roadmap like PeerDAS or Blob-Parameter-Only hardforks.
  • Rollups need to inherit L1 security and censorship resistance, see Native Rollups.
• Scaling L1 without burdening node operators:
  • Repricing the L1’s opcodes could help scale Ethereum without modifying the block gas limit [1, 2].
  • Increasing the L1 Execution gas limit safely is an active area of research which requires deep analysis of history and state growth to help decide how solutions like history expiry and statelessness should work.
• Improved Wallet UX & Security with Account Abstraction:
  • While EIP7702 started bridging the gap between EOAs and Account Abstracted wallets, we think there is room to go to further improve the UX of batched & sponsored transactions and eliminate users’ reliance on private keys.

How are we contributing to the mission of Ethereum Acceleration?

As researchers and engineers we will contribute with EIPs, data analysis, and code, with a particular focus on proposals like EIP-7862, that offer non-controversial improvements and don’t conflict with the rest of the roadmap. We have been diving deep into Ethereum’s state and history to inform what we can do safely with the gas limit.

Reth is production ready, and will continue to set a fast pace of shipping the milestones to unblock upcoming hardforks. We built Reth intentionally as an SDK for building “EVM-core” nodes to enable experimentation and innovation by researchers and engineers. We invite the research community to collaborate with us in prototyping new features towards improving Ethereum’s performance, censorship resistance, and future-proofing, with Reth.

Finally, we will continue building and supporting foundational tooling - like Foundry, Alloy, Solar, Revm, Wagmi and Viem - to ensure that any core protocol updates get exposed effectively to users

Outlook

We think agreeing to ship faster is the most important thing Ethereum can do as a community to expand the space of what is possible and enable the protocol to deliver on its ambitious roadmap.

Accelerating Ethereum development will make permissionless innovation accessible to more people, helping pave the way for a truly global, trust-minimized financial system.