Possible Future Development Directions of the Ethereum Protocol: Prosperity Chapter

There are many "details" in the Ethereum protocol that are crucial to its success. In fact, about half of the content involves different types of EVM improvements, while the rest consists of various niche topics, which is the essence of "prosperity."

Prosperity: Key Objectives

• Transform the EVM into a high-performance and stable "final state"
• Introduce account abstraction into the protocol, allowing all users to enjoy a more secure and convenient account.
• Optimize transaction fee economics, improve scalability while reducing risk.
• Explore advanced cryptography to significantly improve Ethereum in the long term.

EVM Improvement

What problem has been solved?

Currently, the EVM is difficult to perform static analysis, which makes it challenging to create efficient implementations, formally verify code, and carry out further extensions. In addition, the EVM's efficiency is low, making it difficult to implement many forms of advanced cryptography unless explicitly supported through pre-compilation.

What is it and how does it work?

The first step in the current EVM improvement roadmap is the EVM object format (EOF), which is planned to be included in the next hard fork. EOF is a series of EIPs that specify a new version of EVM code with many unique features, the most notable being:

• The code ( is executable, but cannot read the separation between ) from the EVM and the data (, which can be read but not executed ).
• Dynamic redirection is prohibited, only static redirection is allowed.
• EVM code can no longer observe information related to fuel.
• A new explicit subroutine mechanism has been added.

Legacy contracts will continue to exist and can be created, although they may ultimately be phased out in favor of new contracts, and may even be forcibly converted to EOF code (. New contracts will benefit from the efficiency improvements brought by EOF – first through slightly smaller bytecode due to subroutine features, and then from new functionalities specific to EOF or reduced gas costs.

After the introduction of EOF, further upgrades have become easier. The most developed one at present is the EVM module arithmetic extension ) EVM-MAX (. EVM-MAX creates a new set of operations specifically for modular arithmetic and places them in a new memory space that cannot be accessed by other opcodes, making optimizations such as Montgomery multiplication possible.

A newer idea is to combine EVM-MAX with Single Instruction Multiple Data ) SIMD ( features. SIMD, as a concept for Ethereum, has existed for a long time, first proposed by Greg Colvin's EIP-616. SIMD can be used to accelerate many forms of cryptography, including hash functions, 32-bit STARKs, and lattice-based cryptography. The combination of EVM-MAX and SIMD makes these two performance-oriented expansions a natural pair.

![Vitalik on the possible future of Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0ed34ee4adbb5c0bb752dcd01c1f7a7.webp(

)# Existing research link

• EOF:
• EVM-MAX:
• SIMD:

Remaining work and trade-offs

Currently, EOF is planned to be incorporated in the next hard fork. Although it is always possible to remove it at the last minute—previous hard forks have seen features temporarily removed—doing so would face significant challenges. Removing EOF would mean that any future upgrades to the EVM would need to be done without EOF, which is possible but may be more difficult.

The main trade-off of the EVM lies in the complexity of L1 versus the complexity of infrastructure. The EOF requires a substantial amount of code to be added to the EVM implementation, and static code analysis is relatively complex as well. However, in exchange, we can simplify high-level languages, streamline the EVM implementation, and gain other benefits. It can be said that the roadmap prioritizing the continuous improvement of Ethereum L1 should include and build upon the EOF.

An important task that needs to be done is to implement functionality similar to EVM-MAX combined with SIMD, and to benchmark the gas consumption of various cryptographic operations.

How to interact with other parts of the roadmap?

L1 adjusts its EVM to make it easier for L2 to make corresponding adjustments as well. If both do not synchronize their adjustments, it may cause incompatibility, leading to adverse effects. In addition, EVM-MAX and SIMD can reduce the gas costs of many proof systems, making L2 more efficient. It also makes it easier to replace more precompiled contracts with EVM code that can perform the same tasks, which may not significantly affect efficiency.

![Vitalik on the Possible Future of Ethereum (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(

) Account Abstraction

What problem has been solved?

Currently, transactions can only be verified in one way: ECDSA signatures. Initially, account abstraction was designed to go beyond this, allowing the verification logic of accounts to be any arbitrary EVM code. This can enable a range of applications:

• Switch to post-quantum cryptography
• Rotating old keys ### is widely regarded as a recommended security practice (
• Multisignature wallets and social recovery wallets
• Use one key for low-value operations, and use another key ) or a set of keys ( for high-value operations.

Allow privacy protocols to operate without relays, significantly reducing their complexity and eliminating a key central point of dependence.

Since the proposal of account abstraction in 2015, its goals have also expanded to include a number of "convenience objectives", for example, an account that does not have ETH but holds some ERC20s can use ERC20 to pay for gas.

)# What is it and how does it work?

The core of account abstraction is simple: it allows smart contracts to initiate transactions, not just EOAs. The entire complexity comes from implementing this in a way that is friendly to maintaining a decentralized network and preventing denial of service attacks.

A typical key challenge is the issue of multiple failures:

If there are 1000 account validation functions that rely on a single value S, and the current value S makes all transactions in the memory pool valid, then a single transaction that flips the value of S may invalidate all other transactions in the memory pool. This allows an attacker to send garbage transactions to the memory pool at a very low cost, thereby clogging the resources of network nodes.

After years of effort, aimed at expanding functionality while limiting the risk of denial-of-service ### DoS (, we have finally arrived at a solution to achieve "ideal account abstraction": ERC-4337.

The working principle of ERC-4337 is to divide the processing of user operations into two phases: validation and execution. All validations are processed first, followed by all executions. In the memory pool, user operations are only accepted when the validation phase only involves their own account and does not read environment variables. This helps prevent replay attacks. Additionally, strict gas limits are also enforced on the validation step.

ERC-4337 was designed as an additional protocol standard ) ERC (, as at the time Ethereum client developers were focused on the Merge ), and had no extra energy to handle other features. This is why ERC-4337 uses an object called user operations instead of regular transactions. However, recently we realized the need to write at least part of it into the protocol.

The two key reasons are as follows:

1. EntryPoint as the inherent inefficiency of the contract: each bundle has a fixed overhead of about 100,000 gas, plus additional thousands of gas for each user operation.
2. Ensuring the Necessity of Ethereum Attributes: For example, the guarantee created by the inclusion list needs to be transferred to account abstract users.

In addition, ERC-4337 also expands on two features:

• Payment Proxy ( Paymasters ): Allows one account to pay fees on behalf of another account, which violates the rule that only the sender's account itself can be accessed during the validation phase. Therefore, special handling has been introduced to ensure the security of the payment proxy mechanism.
• Aggregators (: Support functions for signature aggregation, such as BLS aggregation or SNARK-based aggregation. This is necessary to achieve the highest data efficiency on Rollups.

![Vitalik on the Possible Future of Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(

)# Existing research links

• Speech about the history of account abstraction:
• ERC-4337:
• EIP-7702:
• The BLSWallet code ( uses the aggregation feature ):
• EIP-7562### Account Abstraction Protocol: (
• EIP-7701) based on EOF's writing protocol account abstraction (:

)# Remaining work and trade-offs

The main issue to be resolved currently is how to fully integrate account abstraction into the protocol. The recently popular write protocol account abstraction EIP is EIP-7701, which implements account abstraction on top of EOF. An account can have a separate code section for verification, and if the account sets this code section, the code will be executed during the verification step of transactions from that account.

The charm of this approach lies in its clear demonstration of the two equivalent perspectives of local account abstraction:

1. Incorporate EIP-4337 as part of the protocol
2. A new type of EOA where the signature algorithm is EVM code execution.

If we start by setting strict limits on the complexity of executable code during the verification period - not allowing access to external state, and even the gas limits set in the early stages are so low that they are ineffective for quantum resistance or privacy-protecting applications - then the security of this approach is very clear: it simply replaces ECDSA verification with EVM code execution that requires a similar amount of time.

However, as time goes on, we need to relax these boundaries, as allowing privacy-protecting applications to operate without relays and quantum resistance are both very important. To this end, we need to find more flexible ways to address the risks of denial of service (DoS) without requiring that the verification steps be extremely minimal.

The main trade-off seems to be between "quickly writing a solution that satisfies fewer people" and "waiting longer for a potentially more ideal solution"; the ideal approach might be some sort of hybrid method. One hybrid method is to write some use cases more quickly while allowing more time to explore other use cases. Another method is to first deploy a more ambitious account abstraction version on L2. However, the challenge faced is that the L2 team needs to be confident in the work of the proposed adoption in order to be willing to implement it, especially to ensure that L1 and/or other L2 can adopt a compatible solution in the future.

Another application we need to clearly consider is key storage accounts, which store account-related states on L1 or dedicated L2, but can be used on L1 and any compatible L2. Effectively doing this may require L2 to support opcodes such as L1SLOAD or REMOTESTATICCALL, but it also requires the account abstraction implementation on L2 to support these operations.

How does it interact with other parts of the roadmap?

The inclusion list needs to support account abstract transactions. In practice, the demand for inclusion lists is very similar to the demand for decentralized memory pools, although there is slightly more flexibility for inclusion lists. Furthermore, the implementation of account abstraction should aim for coordination between L1 and L2 as much as possible. If we expect most users to use key-stored Rollups in the future, the design of account abstraction should be based on this.

EIP-1559 Improvement

(# What problem does it solve?

EIP-1559 was activated on Ethereum in 2021, significantly improving the average block inclusion time.

However, the current implementation of EIP-1559 is not perfect in several aspects:

1. The formula has a slight flaw: it does not target 50% of the blocks, but rather around 50-53% of the full blocks, depending on the variance ), which relates to what mathematicians refer to as the "arithmetic-geometric mean inequality."