Ethereum founder Vitalik Buterin recently wrote an in-depth blog post exploring the question of which features should become official parts of the Ethereum protocol versus being built on top of it. This has been an ongoing debate as the network evolves.
In the early days, Buterin explains, Ethereum strove to keep its base layer as simple and minimalist 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 built on top.
Over time, however, some have questioned whether more features should be directly enshrined in the core protocol. But what does “enshrining” mean? Buterin defines it as making something intrinsic to the official Ethereum specification that client developers must implement. The alternative, “de-enshrining,” means removing a feature from the base layer and pushing it out to be handled by smart contracts instead.
Pros and Cons of Enshrining Features
Buterin analyzes the pros and cons of enshrining several potential features. Enshrining can provide efficiency gains, more robust security, and censorship resistance. But it also risks making transactions more expensive, over-complicating governance, and reducing flexibility to meet unanticipated user needs down the road.
Buterin uses account abstraction as a case study to analyze this debate. Earlier proposals like EIP-86 tried to make transactions just simple VM calls, minimizing protocol complexity but increasing miner responsibilities. More recent proposals like ERC-4337 still start outside the protocol but may later enshrine components for efficiency and security.
Buterin explores enshrining several other potential features:
- ZK-EVMs: Could improve efficiency and allow leveraging Ethereum’s governance to manage bugs, but challenges around supporting diverse ZK technologies remain.
- Proposer-builder separation: Could reduce trust assumptions, but extra-protocol approaches already exist.
- Private mempools: No current encryption technology seems robust enough to enshrine, but valuable to build at the application layer.
- Liquid staking: Could reduce centralization risks and open more staking options, but challenges around governance remain.
- More precompiles: This could improve efficiency, but risks over-complicating the protocol and low usage of past precompiles.
Enshrining features can provide efficiency, security, and censorship resistance. But it can also over-extend the protocol’s governance and make it too rigid for unanticipated user needs.
How the community may be fractured on enshrining.
Within the Ethereum community, differing perspectives emerge on this question. Pragmatists may prioritize enshrining features that offer clear benefits to users today, even if complex to govern. In contrast, purists argue that radically minimizing the base layer preserves Ethereum’s vision as a decentralized application platform.
Businesses and institutions want features that support their use cases quickly enshrined, while decentralization advocates worry that risks unaccountable control by privileged groups. Developers desire expanded base layer functionality to ease app building, but security researchers warn enshrinement may lock in suboptimal technical choices.
As Buterin thoughtfully lays out, navigating these tradeoffs will only grow more complex as expectations of Ethereum diversify and scale. However, discussing core principles helps anchor the conversation as progress compels reassessment. The full blog post “Should Ethereum be okay with enshrining more things in the protocol?” is well worth the read.
Ultimately, Ethereum’s open “soft forking” process allows continued evolution based on emerging community priorities. Buterin’s post thus provides a valuable framework to weigh options and build alignment as Ethereum marches toward its ambitious vision.
