Vitalik's Art of Tradeoffs: Which features should the Ethereum protocol encapsulate?

In September, Vitalik Buterin, the founder of Ethereum, weighed the pros and cons of "enshrinement" in his blog post titled "Should the Ethereum Protocol Encapsulate More Functionality?" This provided readers with clues about the future development direction of Ethereum. This article will introduce the concept of "enshrinement" and how it will affect Ethereum's roadmap.

Concept of "Encapsulation"

From the traditional definition of software development, encapsulation refers to a method of wrapping and hiding the implementation details of abstract function interfaces. However, in the context of Ethereum, "encapsulation" refers to the ability to directly execute more functions on the main chain, and these functions may have previously relied on external software implementation. The newly encapsulated functions will become "protocol functions".

In the blog post mentioned earlier, Vitalik Buterin discussed Ethereum's original "minimalist encapsulation philosophy". The idea is to keep the basic Ethereum L1 layer as simple as possible while relying on off-chain solutions (such as rollups) to gain additional functionality and new features.

However, he now believes that it may be necessary to make some adjustments to the "minimum encapsulation philosophy". Next, we will further explore the advantages and disadvantages of the "minimum encapsulation philosophy".

"Minimal Encapsulation Philosophy"

"Minimal encapsulation" refers to encapsulating specific functions in the blockchain, simplifying execution without imposing strict rules. For example, the Ethereum protocol does not need to encapsulate a complete liquidity staking system (such as stETH launched by Lido), but only needs to encapsulate specific parts of the functionality that solve key challenges. This will help implement the function in a simple way and avoid making it more complex.

Ethereum's core developers have always tried to keep the base layer clean, simple, and secure. Building new features on top of the Ethereum protocol is mainly the responsibility of the rest of the Ethereum community. As Vitalik Buterin put it, Ethereum was created to "verify blocks as a virtual machine." One of the key advantages of this approach is that hard forks can easily be described as a single transaction of the block processor contract. Other advantages of the minimalist structure include flexibility to meet different user needs and avoid software bloat.

However, with the development of the industry, the community has realized that encapsulating more functionality may improve the Ethereum protocol, such as reducing gas fees, enhancing security, and reducing centralization risks.

Encapsulation of ERC-4337

In 2023, the account abstraction, a new feature of Ethereum, caught everyone's attention. Account abstraction, also known as ERC-4337, was written by Vitalik Buterin and five other developers and is a token standard that introduces account abstraction. Account abstraction brings new features such as smart contract wallets and the ability to pay gas fees to Ethereum users using ERC-20 tokens. These user-friendly features are expected to accelerate the adoption of cryptocurrencies and crypto wallets, and have therefore gained widespread anticipation.

Over the years, the account abstraction has undergone multiple revisions. It has evolved from an Ethereum Improvement Proposal called EIP-86 to its final form, ERC-4337. As an ERC, the account abstraction does not require a hard fork and exists independently of the Ethereum protocol at a technical level.

Now, Vitalik Buterin believes that certain parts of the encapsulated ERC-4337 have obvious advantages. This standard is beneficial for improving censorship resistance, gas efficiency, and supporting Ethereum Virtual Machine (EVM) opcodes.

If implemented through external software, attackers may exploit vulnerabilities in the entry point contract to steal funds. Conversely, encapsulating ERC-4337 will replace its entry point contract as a protocol function, making user funds more secure. Additionally, as part of the L1 protocol, gas fees are lower for users when using encapsulated account abstraction due to lower storage costs.

Encapsulating PBS will help solve Ethereum's centralization risk

Encapsulation can promote decentralization and create a trustless system. Encapsulating PBS (proposer/builder separation) is a good example. In the Ethereum blockchain, proposers are validators who sell their block production rights to builders who specialize in extracting the maximum extractable value (MEV) from the blocks. Proposers win MEV rewards in this process, while block builders retain a portion of the MEV rewards for themselves.

Currently, validators use the third-party solution FlashBot's mev-boost to access the builder's market. This solution is currently widely popular, accounting for 90% of the generated Ethereum blocks. To eliminate the centralization risk of mev-boost, there is currently a push to encapsulate PBS, which will allow PBS to be executed in the consensus layer of the Ethereum protocol. This will free the builder's market within the protocol from the control of third-party centralized networks (known as "relays") acting as auction houses in the mev-boost market.

Encapsulating ZK-EVM and Liquidity Staking Functionality

Vitalik Buterin said that since the birth of the Ethereum project, efforts have been made to keep the core Ethereum as simple as possible by building protocols on top. However, there has recently been cautious interest in incorporating more functionality into the core Ethereum protocol. In addition to the aforementioned account abstraction, this feature can enable smart contract wallets to support key functions such as account freezing and recovery. ZKEVM (i.e. zero-knowledge proof-based virtual machine) also improves transaction processing efficiency in a secure and reliable manner by leveraging advanced cryptography. In theory, encapsulating account abstraction and ZKEVM can provide more effective methods for addressing vulnerabilities.

About ZKEVM, ERC-4337 also plays a role in this area, but the focus is more on scalability rather than account abstraction. The ZK protocol functionality can promote the diverse philosophy of Ethereum clients. Encapsulating ZKEVM will enable Ethereum's social consensus to handle special cases, thereby reducing the need for additional governance in the rollup ecosystem. However, Ethereum's encapsulation of ZKEVM may face challenges because the data that can be stored on the Ethereum blockchain is limited. However, this problem can also be alleviated by compressing more data with ZKEVM.

Vitalik Buterin believes that if ZKEVMs do not need to carry "witness" data, their data efficiency will be higher. In other words, if certain data has already been read or written in previous blocks, it can be assumed that the verifier can access it without providing evidence again.

The encapsulation of liquidity staking function can prevent centralization of validators. Typically, liquidity staking involves locking or staking cryptocurrencies on PoS blockchains and receiving corresponding tokens from platforms such as Lido, which can also be used for DeFi. If there is a dominance of a single token, it may lead to a single governance tool that is vulnerable to attack controlling most of the Ethereum validators. Protocols such as Lido have provided more protection against this, but one layer of defense may not be enough.

Encapsulation requires a flexible middle ground

When the complexity of the Ethereum protocol is pushed to the outer layer, there may be centralization risks, and encapsulation can avoid this situation. However, excessive encapsulation can overload the trust and governance of the protocol, thereby damaging its neutrality. Protocol complexity also brings system risks, such as the need to add more complexity for pre-coding.

Therefore, when it comes to encapsulation, Vitalik Buterin is taking a flexible middle ground. He is still enthusiastic about encapsulating private mempools to help users alleviate issues such as front-running transactions. Like mev-boost, the private mempool solution is also provided by third-party providers, which has raised concerns about centralization and trust.