The Art of Balance: What Should Ethereum Enshrine in Its Protocol?

·

Vitalik Buterin, the founder of Ethereum, has articulated a nuanced stance on how the network should evolve. He argues that Ethereum must flexibly weigh the benefits and drawbacks of embedding specific functionalities directly into its Layer 1 protocol. This approach aims to balance enhanced features with system complexity while steadfastly ensuring decentralization and meeting diverse user needs.

In a September blog post titled "Should Ethereum be okay with enshrining more things in the protocol?", Buterin delved into the pros and cons of "enshrinement"—integrating features natively into Ethereum’s core protocol. His analysis offers vital clues to Ethereum’s future developmental trajectory.

Understanding Enshrinement

In traditional software development, encapsulation refers to the technique of wrapping and hiding the implementation details of an abstract function interface. In the context of Ethereum, enshrinement means that more functionalities could be executed directly on the Ethereum mainnet. These are features that previously relied on external software or middleware. Once enshrined, these new capabilities become intrinsic "protocol features."

Buterin revisited Ethereum’s original "minimalist philosophy," which was designed to keep the base layer as simple as possible. This philosophy relied on off-chain solutions, such as Rollups, to provide additional functions and innovations. However, he now believes that this "minimal-enshrinement philosophy" might require some adjustment.

The Minimal-Enshrinement Philosophy

The minimal-enshrinement philosophy advocates for embedding only essential functions within the blockchain to simplify execution without imposing overly rigid rules. For instance, the Ethereum protocol doesn’t need to enshrine an entire liquid staking system (like Lido’s stETH); instead, it might only encapsulate specific features that address critical challenges. This approach helps achieve functionality in a straightforward manner, avoiding unnecessary complexity.

Ethereum’s core developers have consistently worked to keep the base layer clean, simple, and secure. Building new features on top of the Ethereum protocol has primarily been the responsibility of the broader community. As Buterin describes it, Ethereum is a protocol virtual machine where validating a block is essentially a single virtual machine call. A key advantage of this minimalist structure is that hard forks can be easily managed as updates to a single transaction block processor contract. Additional benefits include flexibility, the ability to cater to varied user needs, and prevention of software bloat.

Nonetheless, as the industry has matured, the community has recognized that incorporating more features natively could improve the Ethereum protocol by reducing gas fees, enhancing security, and minimizing centralization risks.

Account Abstraction and ERC-4337

In 2023, account abstraction, also known as ERC-4337, captured significant attention. Co-authored by Vitalik Buterin and five other developers, this token standard introduced smart contract wallets and enabled users to pay gas fees with ERC-20 tokens. These user-friendly features are expected to accelerate the adoption of cryptocurrencies and crypto wallets.

Account abstraction has undergone multiple revisions over the years, evolving from an early Ethereum Improvement Proposal (EIP-86) to its current form, ERC-4337. As an ERC standard, it doesn’t require a hard fork and technically exists outside the core Ethereum protocol.

Buterin now argues that enshrining certain parts of ERC-4337 offers distinct advantages. Native integration could enhance censorship resistance, improve gas efficiency, and better support Ethereum Virtual Machine (EVM) opcodes. If implemented externally, attackers might exploit vulnerabilities in entry point contracts to steal funds. By contrast, enshrining ERC-4337 would replace its entry point contract with a protocol-internal function, ensuring greater security for user funds. Additionally, as part of the L1 protocol, storage costs would be lower, leading to reduced gas fees for users.

👉 Explore advanced Ethereum development tools

Enshrined PBS to Mitigate Centralization Risks

Enshrinement can promote decentralization and create a more trustless system. A prime example is the potential enshrinement of Proposer-Builder Separation (PBS). In Ethereum, proposers (validators) sell block production rights to builders—entities that specialize in extracting Maximum Extractable Value (MEV) from blocks. Proposers earn MEV rewards in this process, while builders keep a portion for themselves.

Currently, validators often use third-party solutions like FlashBot’s mev-boost to access the builder market. This solution is immensely popular, accounting for about 90% of Ethereum’s block production. To mitigate the centralization risks associated with mev-boost, there is a push to enshrine PBS within Ethereum’s consensus layer. This protocol-internal builder market would eliminate reliance on centralized third-party networks ("relays") that act as auction houses in the mev-boost market.

Enshrining ZK-EVM and Liquid Staking

Buterin notes that since its inception, Ethereum has attempted to keep its core simple by building additional protocols on top of it. Recently, however, there has been cautious interest in integrating more features natively. Beyond account abstraction, this includes functionalities that enable smart contract wallets to support essential operations like account freezing and recovery. Zero-Knowledge Ethereum Virtual Machine (ZK-EVM) uses advanced cryptography to securely and reliably improve transaction processing efficiency. In theory, both account abstraction and ZK-EVM provide more effective methods to address vulnerabilities.

Regarding ZK-EVM, ERC-4337 plays a role, but the focus shifts more toward scalability than account abstraction. ZK protocol features could foster a more diverse ecosystem of Ethereum clients. Enshrining ZK-EVM would allow Ethereum’s social consensus to handle special cases, reducing the need for additional governance in the rollup ecosystem. However, integrating ZK-EVM might face challenges due to Ethereum’s limited data storage capacity—though this could be mitigated by ZK-EVM’s ability to compress data.

Buterin observes, "If ZK-EVMs don’t have to carry 'witness' data, they can process data more efficiently." That is, if specific data has been read or written in previous blocks, the prover can simply assume access without repeatedly providing evidence.

Enshrining liquid staking functionalities could prevent validator centralization. Typically, liquid staking involves locking or staking cryptocurrency on a Proof-of-Stake (PoS) blockchain and receiving corresponding tokens from a platform like Lido. These tokens can then be used in DeFi applications. If a single liquid staking token becomes dominant, it might lead to a single, potentially fragile governance tool controlling most Ethereum validators. Protocols like Lido have implemented more safeguards, but a single layer of defense may not be sufficient.

A Flexible Middle Ground for Enshrinement

When Ethereum’s complexity is pushed to external layers, centralization risks can emerge—risks that enshrinement can help prevent. However, excessive enshrinement might overload the protocol’s trust and governance models, compromising its neutrality. Protocol complexity also introduces systemic risks, such as the need for more pre-compiled code.

Therefore, Buterin advocates for a flexible middle ground on enshrinement. He remains enthusiastic about developing private mempools to help users mitigate issues like front-running. Similar to mev-boost, private mempool solutions are currently offered by third-party vendors, raising concerns about centralization and trust.

While establishing private mempools natively could address this, Buterin takes a more pragmatic view. He believes that implementing anti-front-running measures at L1 remains challenging, at least until delay encryption technology matures or other breakthroughs occur.

Key takeaways from Buterin’s blog post include:

  1. Enshrinement can help avoid centralization risks.
  2. However, if enshrinement weakens Ethereum’s trust model or makes it more subjective, it might be best avoided.
  3. Incorporating too many features could overcomplicate the protocol.
  4. If an enshrined feature fails to achieve sufficient user adoption, it might be counterproductive in the long run.

It’s worth noting that "abstraction" is the opposite of enshrinement. Abstraction delegates functionality to external software for indirect implementation, while enshrinement relies on built-in features for direct execution.

Advantages of leaning toward abstraction (more external features):

Advantages of leaning toward enshrinement (more built-in features):

The Bottom Line for Protocol Evolution

Although Ethereum’s initial plan was to ensure secure blockchain operation by building protocols on top of it, Buterin believes Ethereum’s future is not set in stone. As a common industry saying goes: "There are no solutions, only trade-offs. You try to get the best trade-off possible, and that’s what you hope for." The benefit of enshrinement is reducing vulnerability risks and the probability of centralization. However, the clear downside is that it may make the protocol increasingly complex, eventually becoming overextended and cumbersome. Deciding which features to enshrine and which to leave to other ecosystem levels is a delicate balancing act.

In the current environment, Buterin contends that "blockchains are not personal computing operating systems; they are social systems." Where there are reasonable and substantive benefits, he leans toward enshrining certain features into the Ethereum protocol. For rarely used functions, it might be necessary to remove their enshrinement to ensure backward compatibility and a lightweight protocol. He acknowledges that the analysis around enshrinement will continue to evolve over time.

Frequently Asked Questions

What does 'enshrinement' mean in the context of Ethereum?
Enshrinement refers to integrating specific functionalities directly into Ethereum’s Layer 1 protocol. These features become native parts of the protocol, unlike those implemented through external software or smart contracts, which often require more trust assumptions and can introduce centralization risks.

Why is there a debate about enshrining more features into Ethereum?
The debate centers on balancing simplicity and security with functionality and efficiency. Enshrining features can reduce reliance on external parties, lower gas costs, and enhance security. However, it can also increase protocol complexity, create governance challenges, and potentially lead to bloat if underutilized features are added.

How might enshrining PBS benefit Ethereum?
Enshrining Proposer-Builder Separation (PBS) would create a trustless, protocol-level market for block building. This would reduce dependence on centralized third-party relays (like those used in mev-boost), mitigate MEV-related centralization risks, and promote a more decentralized and resilient validator ecosystem.

What is account abstraction, and why consider enshrining it?
Account abstraction, defined by ERC-4337, allows smart contracts to function as wallets and enables users to pay fees with ERC-20 tokens. Enshrining parts of this standard could improve gas efficiency, enhance security by reducing external contract risks, and strengthen censorship resistance by making these features core to the protocol.

Could enshrining ZK-EVM improve Ethereum’s scalability?
Yes, enshrining ZK-EVM could significantly boost scalability by integrating zero-knowledge proofs natively for efficient transaction verification. It would allow the base layer to handle more data compression and reduce the governance burden on rollups, though challenges related to data storage and proof verification would need to be addressed.

What are the risks of enshrining too many features?
Over-enshrinement risks making the Ethereum protocol overly complex, difficult to upgrade, and potentially more vulnerable to bugs. It could also strain the consensus mechanism, increase the required resources for node operators, and compromise the network’s minimalist, neutral foundation if poorly adopted features become permanent.