The Possible Future of the Ethereum Protocol ( Six ): Prosperity

In the design of the Ethereum protocol, there are many important "details" 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 meaning of "prosperity".

Prosperity: Key Objectives

• Turn the EVM into a high-performance and stable "final state"
• Introduce account abstraction into the protocol, allowing all users to enjoy a safer and more 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, making it challenging to create efficient implementations, formally verify code, and carry out further expansions. In addition, the efficiency of the EVM is low, making it hard to implement many forms of advanced cryptography unless explicitly supported through precompiles.

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 of which are:

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

Legacy contracts will continue to exist and can be created, although they may eventually be gradually deprecated in favor of legacy contracts ( and may even be forcibly converted to EOF code ). The new contracts will benefit from the efficiency improvements brought by EOF—first through slightly smaller bytecode due to subroutine features, and then through new features specific to EOF or reduced gas costs.

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

A newer idea is to combine EVM-MAX with single instruction multiple data ( SIMD ) features. SIMD has been a concept for Ethereum 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 pairing.

A rough design of a combination EIP will start with EIP-6690, then:

• Allow (i) any odd number or (ii) any power of 2 up to 2768 as the modulus.
• For each EVM-MAX opcode ( addition, subtraction, multiplication ), add a version that no longer uses 3 immediate values x, y, z, but instead uses 7 immediate values: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. In Python code, these opcodes function similarly to:

for i in range(count): mem[z_start + z_skip * count] = op( mem[x_start + x_skip * count], mem[y_start + y_skip * count] )

In actual implementation, this will be processed in parallel.

• Possibly add XOR, AND, OR, NOT, and SHIFT( including looping and non-looping), at least for powers of 2 modulus. At the same time, adding ISZERO( will push the output to the EVM main stack), which will be powerful enough to implement elliptic curve cryptography, small field cryptography( such as Poseidon, Circle STARKs), traditional hash functions( such as SHA256, KECCAK, BLAKE), and lattice-based cryptography. Other EVM upgrades may also be implemented, but so far have received less attention.

Remaining work and trade-offs

Currently, EOF is planned to be included in the next hard fork. Although it is always possible to remove it at the last minute—there have been functions temporarily removed in previous hard forks, doing so would pose significant challenges. Removing EOF means that any future upgrades to the EVM would have to be conducted without EOF, which is possible but may be more difficult.

The main trade-off of EVM is the complexity of L1 versus infrastructure complexity. EOF requires a significant 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, simplify EVM implementations, and gain other benefits. It can be said that the roadmap prioritizing the continuous improvement of Ethereum L1 should include and be built upon EOF.

An important task that needs to be done is to implement features 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 allow L2 to make corresponding adjustments more easily. If both do not synchronize their adjustments, it may lead to incompatibility and adverse effects. Additionally, 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 impact efficiency.

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 wallet and social recovery wallet
• 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 dependency.

Since the proposal of account abstraction in 2015, its goals have expanded to include a variety of "convenience objectives", such as an account without ETH but holding some ERC20 being able to 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 multiple failure problem: if the validation functions of 1000 accounts all rely on a single value S, and the current value S makes the transactions in the memory pool valid, then a single transaction that flips the value of S may cause all other transactions in the memory pool to become invalid. This allows an attacker to send junk 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 ), a solution for achieving "ideal account abstraction" has finally been reached: ERC-4337.

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

ERC-4337 was designed as an additional protocol standard (ERC), because at that time Ethereum client developers were focused on the Merge (Merge) and did not have additional energy to handle other features. This is why ERC-4337 uses an object called user operation 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 several thousand gas for each user operation.
2. Ensuring the necessity of Ethereum attributes: such as the inclusion of the list created to guarantee the need for transfer to account abstract users.

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

• Payment Agent ( Paymasters ): Allows one account to pay fees on behalf of another account, which violates the rule that during the validation phase, only the sender's own account can be accessed. Therefore, special handling is introduced to ensure the security of the payment agent mechanism.
• Aggregators (: Support for signing aggregation features, such as BLS aggregation or SNARK-based aggregation. This is necessary for achieving the highest data efficiency on Rollup.

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

)# Remaining work and trade-offs

Currently, the main issue to address 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 validation; if the account has set this code section, it will be executed during the validation step of transactions from that account.

The charm of this approach lies in its clear demonstration of two equivalent perspectives on 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 boundaries on the complexity of executable code during the validation period—disallowing access to external state, and even the initial gas limits being low enough to render quantum resistance or privacy protection applications ineffective—then the security of this approach becomes 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-preserving applications to operate without relays and ensuring quantum resistance are both very important. To this end, we need to find more flexible ways to address denial of service ### DoS ( risks without requiring the verification steps to 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 faster while allowing more time to explore other use cases. Another approach is to first deploy a more ambitious account abstraction version on L2. However, the challenge here is that the L2 team needs to have confidence in the work of the adoption proposal to be willing to implement it, especially to ensure that L1 and/or other future L2s can adopt a compatible solution.

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

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 achieving this may require L2 to support protocols such as L1SLOAD or REMOTESTATI.