Ethereum founder Vitalik Buterin recently wrote an in-depth one blog post exploring the question of which features should become official parts of the Ethereum protocol, rather than being built on top of it. This has been an ongoing debate as the network evolved.
Buterin explains that in the beginning, Ethereum aimed to keep the base layer as simple and minimalistic as possible. This aligned with the Unix philosophy of creating uncomplicated, flexible software. The goal was for Ethereum to provide a solid foundation for decentralized applications, with most functionality implemented through smart contracts.
Over time, however, some have questioned whether more features should be written directly into the core protocol. But what does ‘anchor’ mean? Buterin defines it as something intrinsic to the official Ethereum specification that customer developers must implement. The alternative, “de-enshrining,” means removing a function from the base layer and pushing it out to be handled by smart contracts instead.
Advantages and disadvantages of anchoring functions
Buterin analyzes the pros and cons of anchoring different potential features. Anchoring can bring efficiency gains, more robust security, and resistance to censorship. But it also risks making transactions more expensive, overcomplicating governance, and reducing flexibility to meet unexpected user needs later.
Buterin uses account abstraction as a case study to analyze this debate. Previous proposals such as EIP-86 attempted to make transactions simple VM calls, minimizing protocol complexity but increasing miners’ responsibilities. More recent proposals such as ERC-4337 still start outside the protocol, but may include components for efficiency and security later.
Buterin explores anchoring several other potential features:
- ZK EVMs: Could improve efficiency and enable leveraging Ethereum’s governance to manage bugs, but challenges remain around supporting various ZK technologies.
- Separation between proposer and builder: could reduce assumptions about trust, but approaches outside the protocol already exist.
- Private mempools: No current encryption technology seems robust enough to anchor, but valuable to build at the application layer.
- Liquid Staking: Could reduce centralization risks and open up more staking options, but governance challenges remain.
- More precompiles: This could improve efficiency, but risks overcomplicating the protocol and making less use of previous precompiles.
Embedding features can provide efficiency, security, and resistance to censorship. But it can also overextend the protocol’s governance and make it too rigid for unexpected user needs.
How the community can fall apart in the process of anchoring it.
Within the Ethereum community, different perspectives on this question are emerging. Pragmatists can prioritize embedding features that provide clear benefits for today’s users, even if they are complex to control. Purists, on the other hand, argue that radically minimizing the base layer preserves Ethereum’s vision as a decentralized application platform.
Enterprises and institutions want features that support their use cases to be quickly embedded, while decentralization raises concerns about the risk of unaccountable control by privileged groups. Developers want extensive base layer functionality to simplify app building, but security researchers warn that entrenchment can hinder suboptimal technical choices.
As Buterin carefully explains, navigating these tradeoffs will only become more complex as expectations for Ethereum diversify and expand. However, discussing core principles helps anchor the conversation as progress necessitates reassessment. The full blog post “Should Ethereum be okay with including more things in the protocol?‘ is definitely worth reading.
Ultimately, Ethereum’s open ‘soft forking’ process allows for continued evolution based on emerging community priorities. Buterin’s post thus provides a valuable framework for weighing options and building alignment as Ethereum marches toward its ambitious vision.