ethereum founder Vitalik Buterin recently wrote an in-depth article 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 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 flexible and simple software. The goal was for ethereum to provide a solid foundation for decentralized applications, with most functions implemented through smart contracts built on top of it.
However, over time, some have questioned whether more functions should be directly enshrined in the core protocol. But what does “consecrate” mean? Buterin defines it as doing something intrinsic to the official ethereum specification that client developers must implement. The alternative, “decommission,” means removing a feature from the base layer and moving it out to be handled by smart contracts.
Pros and cons of consecrating functions
Buterin discusses the pros and cons of enshrining several potential features. Consecration can provide efficiency gains, stronger security, and censorship resistance. But it also risks making transactions more expensive, overcomplicating governance, and reducing flexibility to meet unforeseen user needs in the future.
Buterin uses account abstraction as a case study to analyze this debate. Previous proposals like EIP-86 attempted to make transactions simple VM calls, minimizing protocol complexity but increasing miners’ responsibilities. Newer proposals like ERC-4337 still start outside the protocol, but can then enshrine components for greater efficiency and security.
Buterin explores the possibility of enshrining several other potential features:
- ZK-EVM: They could improve efficiency and allow you to leverage ethereum governance to handle errors, but challenges related to supporting various ZK technologies remain.
- Separation between proposer and constructor: could reduce trust assumptions, but extra-protocol approaches already exist.
- Private mempools: No current encryption technology seems strong enough to enshrine, but valuable to build into the application layer.
- Liquid staking: Could reduce centralization risks and open up more staking options, but challenges around governance remain.
- More precompiles: This could improve efficiency, but risks overcomplicating the protocol and reducing the use of previous precompiles.
Enshrining features can provide efficiency, security, and censorship resistance. But it can also overextend the governance of the protocol and make it too rigid for unforeseen user needs.
How the community can fracture when consecrated.
Within the ethereum community, different perspectives emerge on this issue. Pragmatists may prioritize enshrining features that offer clear benefits to today’s users, even if they are complex to govern. By contrast, purists argue that radically minimizing the base layer preserves the vision of ethereum as a decentralized application platform.
Companies and institutions want features that support their use cases to be quickly enshrined, while advocates of decentralization fear the risk of irresponsible control by privileged groups. Developers want to extend the functionality of the base layer to make it easier to build applications, but security researchers warn that hardening can block suboptimal technical choices.
As Buterin carefully lays out, navigating these trade-offs will only become more complex as expectations for ethereum diversify and scale. However, discussing basic principles helps anchor the conversation as progress forces reassessment. The full blog post “Should ethereum be okay with enshrining more things in the protocol?”It is worth reading.
Ultimately, ethereum‘s open “soft fork” process allows for continued evolution based on emerging community priorities. Therefore, Buterin’s post provides a valuable framework for weighing options and creating alignment as ethereum moves towards its ambitious vision.
