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

Some things are hard to categorize. In the design of the Ethereum protocol, many "details" are crucial to the success of Ethereum. 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

• Transform 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 trading fee economics, improve scalability while reducing risks.
• Explore advanced cryptography to significantly improve Ethereum in the long term.

EVM improvement

What problem has been solved?

Currently, the EVM is difficult to conduct static analysis, making it challenging to create efficient implementations, formally verify code, and further scale. Additionally, the EVM is inefficient and difficult to implement many advanced cryptographic techniques 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 of which are:

• The code ( is executable, but cannot read ) from the EVM, while the data ( can be read, but cannot execute the separation of ).
• Dynamic redirection is prohibited, only static redirection is allowed
• EVM code can no longer observe fuel-related information.
• Added a new explicit subroutine mechanism

Legacy contracts will continue to exist and can be created, although ultimately legacy contracts may be gradually deprecated, and even possibly forcibly converted to EOF code (. New contracts will benefit from the efficiency improvements brought by EOF—first with the slightly reduced bytecode through subroutine features, and subsequently with 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 the Single Instruction Multiple Data ) SIMD ( feature. SIMD, as a concept for Ethereum, has existed for a long time, first proposed by Greg Colvin in 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 extensions a natural pairing.

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

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

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

python 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 practice, this will be handled in parallel.

• Possibly add XOR, AND, OR, NOT, and SHIFT) including loops and non-loops(, at least for powers of 2 modulo. At the same time, add ISZERO) to push outputs 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) like SHA256, KECCAK, BLAKE(, and lattice-based cryptography. Other EVM upgrades may also be implemented, but have received less attention so far.

)# 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 face significant challenges. Removing EOF means that any future upgrades to the EVM would need to be done without EOF, which can be done, but may be more difficult.

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

An important task that needs to be accomplished is to implement functionalities 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 the two do not synchronize their adjustments, it may lead to incompatibility and bring 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 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 (
• Multi-signature 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.

Allowing privacy protocols to operate without relays significantly reduces their complexity and eliminates a key central dependency point.

Since the proposal of account abstraction in 2015, its goals have also expanded to include a large number of "convenience objectives", such as an account without ETH but with some ERC20 being able to pay gas with ERC20.

MPC) multi-party computation ( is a technology with a history of 40 years, used to split keys into multiple parts and store them on multiple devices, utilizing cryptographic techniques to generate signatures without directly combining these key parts.

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

EIP-7702 is a proposal planned to be introduced in the next hard fork. EIP-7702 is the result of an increasing awareness of the convenience of providing account abstraction to benefit all users ), including EOA users (. It aims to improve the experience of all users in the short term and avoid splitting into two ecosystems.

The work began with EIP-3074 and eventually formed EIP-7702. EIP-7702 provides the "convenience features" of account abstraction to all users, including today's EOA) externally owned accounts, which are accounts controlled by ECDSA signatures (.

Although some challenges ), especially the "convenience" challenge (, can be addressed through progressive technologies such as multi-party computation or EIP-7702, the main security objective of the initial account abstraction proposal can only be achieved by retroactively addressing the original problem: allowing smart contract code to control transaction validation. The reason it has not been implemented so far lies in the challenge of secure implementation.

)# What is it and how does it work?

The core of account abstraction is simple: it allows smart contracts to initiate transactions, rather than just EOAs. The entire complexity arises from achieving 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 the validation function of 1000 accounts depends 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 could invalidate all other transactions in the memory pool. 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 was finally reached 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 will only be accepted if the validation phase involves only their own accounts and does not read environment variables. This can prevent replay attack. In addition, strict gas limits are also enforced on the validation steps.

ERC-4337 was designed as an additional protocol standard ) ERC (, because at that time Ethereum client developers were focused on the Merge ), with no additional effort to address other functionalities. This is why ERC-4337 used an object called user operations instead of regular transactions. However, recently we have realized the need to write at least part of this into the protocol.

The two key reasons are as follows:

1. EntryPoint as the inherent inefficiency of contracts: each bundle incurs a fixed overhead of about 100,000 gas, along with additional thousands of gas for each user operation.
2. Ensuring the necessity of Ethereum attributes: Such as the guarantees created by the inclusion list that need to be transferred to the account abstract user.

In addition, ERC-4337 also extends two functions:

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

)# Remaining work and trade-offs

The main issue that needs to be resolved currently is how to fully integrate account abstraction into the protocol. The recently popular proposal for account abstraction in writing protocols 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 has set this code section, it will be executed during the verification steps 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—disallowing access to external state, and even the initially set gas limits being so low that they are ineffective for quantum-resistant or privacy-preserving 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 by, we need to loosen these boundaries, as allowing privacy-preserving 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 risk of denial of service ( DoS ) without requiring the validation steps to be extremely minimal.

The main trade-off seems to be "quickly writing a solution that satisfies fewer people" versus "waiting longer.