Vitalik's art of trade-offs: What features should the Ethereum protocol encapsulate?

In September, Ethereum founder Vitalik Buterin wrote a speech titled "Should the Ethereum Protocol Encapsulate More Features?" The blog post weighs the advantages and disadvantages of "enshrinement" for the Ethereum L1 protocol, giving readers clues about the future direction of Ethereum. This article will introduce the concept of "encapsulation" and how it will affect Ethereum's roadmap.

The concept of "encapsulation"

From the traditional definition of software development, encapsulation refers to a method of wrapping and hiding the implementation details of an abstract function interface. For Ethereum's "encapsulation", it means that more functions can be directly executed on the main chain, and these functions may have relied on external software in the past, and the new functions that are encapsulated will become "protocol functions".

In the aforementioned blog post, Vitalik Buterin talked about Ethereum's original "minimally encapsulated philosophy." The idea is to keep the basic Ethereum L1 layer as simple as possible, while relying on off-chain solutions such as rollup, for additional functionality and new features.

However, he now believes that a slight adjustment to the "minimum encapsulation philosophy" may be necessary. Next, we will further explore the "minimally encapsulated philosophy" and its pros and cons.

"Minimum encapsulation philosophy"

"Minimal encapsulation" refers to encapsulating specific functionality in the blockchain to simplify execution without imposing strict rules. For example, the Ethereum protocol does not need to encapsulate a complete liquidity staking system (such as Lido's stETH), but only specific parts of functionality that solve key challenges. This will help to implement the feature in a simple way and avoid complicating it.

Ethereum's core developers have been trying to keep it clean, simple, and secure at the base layer. Building new features on top of the Ethereum protocol is primarily the responsibility of the rest of the Ethereum community. In the words of Vitalik Buterin, Ethereum was created to "validate blocks as a virtual machine." One of the key advantages of this approach is that a hard fork can easily be described as a single transaction of a block processor contract. Other advantages of the minimalist architecture include flexibility to meet different user needs and avoid software bloat.

However, as the industry grew, the community realized that encapsulating more features could lead to improvements to the Ethereum protocol, such as lower gas fees, increased security, and reduced centralization risks.

encapsulates ERC-4337

In 2023, account abstraction, a new feature of Ethereum, came into everyone's sight. Account abstraction, also known as ERC-4337, was written by Vitalik Buterin along with five other developers and is a token standard that introduces account abstraction. Account abstraction brings new features such as smart contract wallets and the use of ERC-20 tokens to pay gas fees to Ethereum users. These user-friendly features are widely expected because they are conducive to accelerating the adoption of cryptocurrencies and crypto wallets.

The account abstraction has been revised several times over the years. It evolved from an Ethereum improvement proposal called EIP-86 to its final form, ERC-4337. As an ERC, account abstraction does not require a hard fork and exists technically independent of the Ethereum protocol.

Now, Vitalik Buterin sees clear advantages to encapsulating some parts of ERC-4337. The standard facilitates censorship resistance, gas efficiency, and support for Ethereum Virtual Machine (EVM) opcodes.

If implemented through external software, it is possible that an attacker can exploit a vulnerability in the entry point contract to steal funds. Conversely, encapsulating ERC-4337 will replace its entry point contract as an in-protocol feature, making users' funds more secure. In addition, as part of the L1 protocol, users have lower gas charges when using encapsulated account abstractions due to lower storage costs.

Encapsulating PBS will help address Ethereum centralization risks

Encapsulation can promote decentralization and create a trustless system, and encapsulation PBS (Proposer/Builder Separation) is a good example. Proposers of the Ethereum blockchain are validators who sell their block production rights to builders who specialize in extracting maximum extractable value (MEV) from blocks. Proposers earn MEV rewards in the process, while block builders keep a portion of MEV rewards for themselves.

Currently, validators use mev-boost, FlashBot's third-party solution, to access builders' marketplaces. The solution is currently widely welcomed, accounting for 90% of Ethereum blocks generated. In order to exempt the protocol from the risk of mev-boost centralization, it is currently advocating encapsulating PBS, which will allow PBS to be implemented in the consensus layer of the Ethereum protocol. Builder marketplaces within such agreements would be freed from the control of a third-party centralized network (known as "relays") that acts as auction houses in the mev-boost marketplace.

Encapsulates ZK-EVM and liquidity staking functions

Vitalik Butein said that since the birth of the Ethereum project, it has tried to keep core Ethereum as simple as possible by building a protocol on top. Recently, however, there has been a cautious interest in incorporating more features into the core Ethereum protocol. In addition to the account abstraction just mentioned, the feature enables smart contract wallets to support key features such as account freezing and recovery. ZKEVM, or virtual machine based on zero-knowledge proofs, also improves transaction processing efficiency in a secure and reliable manner by leveraging advanced cryptography. Theoretically, both encapsulating account abstractions and ZKEVM provide a more efficient way to address vulnerabilities.

Regarding ZKEVM, ERC-4337 also plays a role in this, but the focus is more on scaling than account abstraction. The ZK protocol feature can promote a philosophy of diversification of Ethereum customers. Encapsulating ZKEVM will enable Ethereum's social consensus to handle special cases, reducing the need for additional governance in the rollup ecosystem. However, Ethereum can face challenges in encapsulating ZKEVM because the Ethereum blockchain has limited data to store. HOWEVER, THIS PROBLEM CAN ALSO BE MITIGATED BY ZKEVM COMPRESSING MORE DATA.

Vitalik Buterin believes that if ZKEVMs don't have to carry "witness" data, their data efficiency will become higher. That is, if a particular piece of data has been read or written in some previous block, it can simply be assumed that the prover will be able to access it without having to provide evidence again.

Encapsulating liquidity staking prevents validator centralization. Typically, liquidity staking involves locking or staking a cryptocurrency on a PoS blockchain and receiving a corresponding token from a platform such as Lido, which can also continue to be used for DeFi. If such a single token were dominant, it could result in a single potentially compromised governance tool controlling the majority of Ethereum validators. Protocols like Lido already provide more assurance for this, but a layer of defense may not be enough.

Encapsulation requires a flexible middle ground

Centralization risks can occur when the complexity of the Ethereum protocol is pushed to the outer layer, and encapsulation avoids this. However, over-encapsulation overloads the trust and governance of the protocol, undermining its neutrality. Protocol complexity also introduces systemic risks, such as the need to add more complexity to precoding.

So, when it comes to packaging, Vitalik Buterin is taking a flexible middle ground. He remains passionate about encapsulating private mempool to help users mitigate issues such as preemptive transactions. Like Mev-Boost, private MemPool solutions are provided by third-party providers, raising concerns about centralization and trust.

While encapsulating private mempools solves this problem, Vitalik Buterin takes a more pragmatic approach, arguing that encapsulating anti-frontrunning in L1 remains a difficult proposition, at least until latency encryption is perfected or some other technological breakthrough emerges.

The main points he shared in his blog post are as follows:**

1. Encapsulation can help avoid the risk of centralization;

2. However, if encapsulation weakens Ethereum's trust model and makes Ethereum more subjective, it is best to avoid using encapsulation;

3. Encapsulating too many functions will overcomplicate the protocol;

4. If the encapsulated function is not used by enough users, the encapsulation may be counterproductive in the long run.

! [Vitalik's art of trade-offs: What features should the Ethereum protocol encapsulate?] ](https://cdn-img.panewslab.com/panews/images/B13yINjz59.png)

(Editor's note: The "abstract more functions" here is the opposite of "encapsulating more functions", abstract functions can be handed over to more external software for indirect implementation, and encapsulated functions are directly implemented by relying on more built-in functions)

On the one hand, the tendency to abstract more features has the following advantages:

1. Avoid overextending protocol trust and governance load protocols;

2. Support diversified user needs;

3. When future demand is uncertain;

4. Reduce protocol complexity.

On the other hand, the preference for packaging more functionality has the following advantages:**

1. Deal with high fixed costs;

2. Enhance the protocol authorization function;

3. Reduce the risk of code errors for users;

4. Avoid high-level centralization risks.

The bottom line of protocol evolution

While Ethereum's original plan was to make the blockchain run securely by building a protocol on top, Vitalik Buterin believes that Ethereum's future is not set in stone. As the industry saying goes, "There is no perfect solution in cryptocurrency, only trade-offs." "Encapsulation has the advantage of reducing the risk of vulnerabilities and reducing the probability of centralization, but its obvious disadvantage is that it can lead to increasingly complex protocols and eventually become overextended and unwieldy. It's a complex trade-off about which features should be brought into the protocol and which should be left at other levels of the ecosystem.

Overall, in the current environment, Vitalik Buterin sees blockchain as a "social system," and in justified and beneficial examples, he tends to support the Ethereum protocol encapsulating some specific functionality. For rarely used functions, it may be necessary to remove the encapsulation to ensure compatibility with older versions and lightweight protocols. Of course, he acknowledges that the trade-off around packaging will continue to evolve over time.