The possible future of the Ethereum protocol ( Six ): The Splurge

There are many "details" in the design of the Ethereum protocol that are critical 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

• Transforming 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 trading fee economy, 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 further scale. Moreover, 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 ( can be executed, but cannot read ) from the EVM, and the data ( can be read, but cannot execute between the separation of ).
• Dynamic redirection is prohibited, only static redirection is 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 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 reduced bytecode from subroutine features, and then from new EOF-specific functionalities or reduced gas costs.

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 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 has been a concept in Ethereum 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.

Existing research links

• EOF:
• EVM-MAX:
• SIMD:

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 instances in previous hard forks where features were temporarily removed, doing so would face significant challenges. Removing EOF means that any future upgrades to the EVM would need to be carried out without EOF, which is possible but may be more difficult.

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

Since the proposal of account abstraction in 2015, its goals have also expanded to include a variety of "convenience objectives," such as an account that has no ETH but holds 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.

EIP-7702 is a proposal planned to be introduced in the next hard fork. EIP-7702 is the result of the growing recognition of the need to provide account abstraction convenience for all users, including EOA users (, aiming 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 (.

![Vitalik on Ethereum's Possible Future (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, rather than just EOA. The entire complexity arises 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 issue:

If the validation function of 1000 accounts relies 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 garbage transactions to the memory pool at a very low cost, thereby blocking the resources of network nodes.

After years of efforts aimed at expanding functionality while limiting denial of service ### DoS ( risks, a solution has finally been reached to achieve "ideal account abstraction": ERC-4337.

The working principle of ERC-4337 is to divide the processing of user operations into two stages: validation and execution. All validations are processed first, followed by all executions. In the mempool, user operations are accepted only when the validation stage involves only their own accounts and does not read environmental variables. This can prevent replay 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 ), with no extra energy to handle other features. This is why ERC-4337 uses an object called user operation instead of conventional 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. The inherent inefficiency of EntryPoint as a contract: each bundle has a fixed overhead of about 100,000 gas, plus thousands of additional gas for each user operation.
2. Ensuring the Necessity of Ethereum Attributes: Such as the guarantee created by the inclusion list that needs to be transferred to account abstract users.

In addition, ERC-4337 also expands two functionalities:

• Payment Proxy ( 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 has been introduced to ensure the security of the payment proxy mechanism.
• Aggregators (: Support for signature aggregation features, such as BLS aggregation or SNARK-based aggregation. This is essential for achieving maximum data efficiency on Rollups.

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

)# Existing research links

• Speech on the history of account abstraction:
• ERC-4337:
• EIP-7702:
• The BLSWallet code ( uses the aggregation function ):
• EIP-7562### account abstraction protocol (:
• EIP-7701) Based on EOF Write Protocol Account Abstraction (:

)# Remaining work and trade-offs

The main issue that needs to be resolved currently is how to fully incorporate 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. 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 boundaries on the complexity of executable code during the validation period—disallowing access to external state, and even the initially set gas limit being so low that it is 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 on, we need to loosen these boundaries, as allowing privacy-preserving applications to operate without relays 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 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 approach 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 adopted proposal in order to be willing to implement it, especially to ensure that L1 and/or other L2s can adopt a compatible solution in the future.

Another application we need to consider clearly is key storage accounts, this