Possible Future of the Ethereum Protocol ( Six ): Prosperity

Many "details" in the design of the Ethereum protocol 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

• 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, enhance 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 perform static analysis, which makes it challenging to create efficient implementations, formally verify code, and further scale. In addition, the EVM is inefficient, 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 specifies a new version of EVM code with many unique features, the most notable of which are:

• The code ( is executable, but it cannot read ) from the EVM, and the data ( can be read, but it cannot execute the separation between ).
• 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 eventually 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 with the subroutine feature, followed by new features or reduced gas costs specific to EOF.

After the introduction of EOF, further upgrades have become easier. The most developed at present 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 in 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 extensions a natural pairing.

A rough design of a combined EIP will start with EIP-6690, and 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 the 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 work similarly 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 looping and non-looping), at least for powers of 2 modulus. At the same time, adding ISZERO( will 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( 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 that were 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 is possible but may be more difficult.

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

An important task that needs to be done is to implement functionalities similar to EVM-MAX plus SIMD and 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. If the two do not synchronize their adjustments, it may lead to incompatibilities and adverse effects. Furthermore, 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 intended to go beyond this, allowing the verification logic of accounts to be any 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 dependency point.

Since the proposal of account abstraction in 2015, its goals have expanded to include a variety of "convenience objectives", such as allowing an account that has no ETH but holds some ERC20 tokens to pay for gas using ERC20.

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

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 need to provide account abstraction convenience for all users, including EOA users (. It aims to improve the experience for all users in the short term and avoid a split 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 original account abstraction proposal can only be achieved by retroactively addressing the original issue: allowing smart contract code to control transaction validation. The reason it has not been realized so far is due to the challenge of implementing it securely.

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

)# 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 while preventing denial-of-service attacks.

A typical key challenge is the multiple failure issue:

If the validation functions of 1000 accounts 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 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 mitigating denial of service ### DoS ( risks, a solution for achieving "ideal account abstraction" has finally been developed: ERC-4337.

The operation of ERC-4337 works by dividing the processing of user operations into two stages: validation and execution. All validations are processed first, followed by all executions. In the memory pool, user operations are only accepted when the validation stage involves only their own account and does not read environmental variables. This can prevent multi-failure attacks. Additionally, strict gas limits are also enforced on the validation 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 had no extra energy to handle other functionalities. This is why ERC-4337 uses an object called user operation instead of regular transactions. However, we recently 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 additional 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 account abstract users.

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

• Payment Agent ) 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 agent mechanism.
• Aggregators ): Supports features for signature aggregation, such as BLS aggregation or SNARK-based aggregation. This is necessary for achieving the highest data efficiency on Rollups.

(# Remaining work and trade-offs

The main issue that needs to be addressed now 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 has set this code section, it 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 verification—disallowing access to external state, and even the initial gas limit set so low that it becomes 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, over time, we need to loosen these boundaries because allowing privacy-preserving applications to operate without intermediaries and quantum resistance is very important. To this end, we need to find more flexible ways to address the risk of denial of service ) DoS ### without requiring the verification steps to be extremely concise.