Ethereum founder Vitalik Buterin recently wrote an in-depth suspension exploring the question of which functions should become official parts of the Ethereum protocol versus building on top of it. This has been an ongoing conversation as the network evolves.
In the early days, Buterin explains, Ethereum tried to keep its core layer as simple and minimalistic as possible. This aligned with the Unix philosophy of creating simple, 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 questioned whether more features should be built directly into the core protocol. But what does “registration” mean? Buterin defines it as something inherent in the official Ethereum specification that client developers must implement. The alternative, “de-embedding,” means removing a feature from the base layer and pushing it out to be handled by smart contracts.
Advantages and disadvantages of integration features
Buterin analyzes the pros and cons of patenting several potential features. Integration can provide efficiency gains, stronger security and resistance to censorship. However, it also risks making transactions more expensive, overcomplicating governance and reducing flexibility to meet users’ unpredictable needs down the road.
Buterin uses account abstraction as a case study to analyze this debate. Previous proposals like EIP-86 tried to make transactions just simple VM calls, minimizing the complexity of the protocol but increasing the responsibilities of the miner. More recent proposals such as ERC-4337 still start outside the protocol, but may later include elements for efficiency and security.
Buterin explores incorporating several other potential features:
- ZK-EVMs: Could improve efficiency and allow Ethereum governance to be leveraged for fault management, but there are still challenges around supporting different ZK technologies.
- Proposer-creator separation: Could reduce trust assumptions, but off-protocol approaches already exist.
- Private registries: No current encryption technology seems strong enough to embed, but valuable to build at the application layer.
- Liquid betting: Could reduce concentration risks and open up more betting options, but governance challenges remain.
- More precompiles: This could improve efficiency, but there is a risk of overcomplicating the protocol and underutilizing previous precompiles.
Integration features can provide efficiency, security and resistance to censorship. But it can also overextend the governance of the protocol and make it too rigid for unpredictable user needs.
How community can be torn apart in vesting.
Within the Ethereum community, different perspectives are emerging on this question. Pragmatists may prioritize securing features that provide clear benefits to users today, even if they are complex to compromise. Instead, purists argue that the radical minimization of the core layer preserves Ethereum’s vision as a decentralized application platform.
Businesses and institutions want the features that support their use cases to be secured quickly, while decentralization advocates worry that there is a risk of mindless control by privileged groups. Developers want the expanded base-layer functionality to make it easier to build apps, but security researchers warn that integration can lock in suboptimal technical choices.
As Buterin thoughtfully states, navigating these exchanges will become more complex as expectations for Ethereum diversify and escalate. However, discussing basic principles helps stabilize the debate as progress necessitates re-evaluation. The full blog post “Should Ethereum be OK with incorporating more things into the protocol?” is worth reading.
Ultimately, Ethereum’s open “soft forking” process allows for continuous evolution based on emerging community priorities. Buterin’s post thus provides a valuable framework for weighing options and creating alignment as Ethereum moves toward its ambitious vision.