Multi-Chain Account Abstraction: A New Direction for Encryption Infrastructure

From July 8 to 11, 2024, the largest annual Ethereum event in Europe—the Ethereum Community Conference (EthCC)—will be held in Brussels, Belgium. This conference (EthCC 7) brings together over 350 leading opinion leaders in the blockchain industry. A blockchain developer delivered a speech titled "Revealing the Future: Multi-chain Account Abstraction Analysis" at the conference.

The main points of the speech include:

• The two cores of account abstraction (AA): signature abstraction and payment abstraction. The former allows users to choose any verification mechanism, while the latter permits various transaction payment options, thus providing a safer and more convenient user experience.

• The entry point function design of ERC-4337 and native AA differs in the verification and execution stages. Each implementation scheme has its own characteristics in verifying transaction limits and execution steps.

• When implementing ERC-4337 on EVM-compatible chains, it is important to pay attention to the protocol differences caused by Rollup design, as well as the differences in address calculation methods, as these details may affect the implementation between L1 and L2.

Account Abstraction Overview

Account abstraction ( AA ) mainly includes two key points:

1. Signature abstraction: Users can choose any verification mechanism, not limited to specific digital signature algorithms.

2. Payment Abstraction: Users can utilize various transaction payment options, such as paying with ERC-20 tokens or having transactions sponsored by third parties.

This flexibility can provide a more secure and optimized user experience. Account abstraction aims to achieve these two core goals through multiple ways.

Introduction to ERC-4337

Currently, there are some limitations in the externally owned account (EOA) in the Ethereum protocol, such as fixed signature methods and payment design. ERC-4337 addresses these issues by introducing more flexible account management and transaction processing methods.

Main features:

• userOp structure: Users send the userOp structure to the Bundler, which collects multiple userOps and calls the handleOps function of the EntryPoint contract.

• EntryPoint contract: similar to an operating system handling transactions, main functions include:

  1. Call the validate function of the account contract to ensure userOp is authorized
  2. Charge fees

3. Call the execute function of the account contract to perform the target operation of userOp.

Introduction to Native Account Abstraction

In native account abstraction, each account is a contract, and the transaction processing mechanism is directly embedded in the blockchain protocol.

AA design of different blockchain networks:

• ERC-4337 account abstraction: Ethereum, Arbitrum, Optimism, Base, Linea, Scroll, Polygon PoS
• Native account abstraction following ERC-4337: StarkNet and zkSync Era
• Native account abstraction with privacy design: Aztec

Differences Between ERC-4337 and Native AA

1. Operating System Role

AA operating system needs to solve issues such as Gas pricing, transaction ordering, entry point function triggering, transaction processing flow, etc.

ERC-4337 accomplishes these tasks through the collaboration of the Bundler and EntryPoint Contract. In native account abstraction, users send userOps to the operator/sorter of the official server.

2. Contract Interface

The account contract interfaces of different implementations are similar, all containing three steps: verification, payment, and execution. In ERC-4337 and native AA, the entry point function in the "verification" phase is fixed, while only the entry point in the "execution" phase is fixed for native AA.

3. Verification Step Limitations

To prevent DoS attacks, different implementations have set various restrictions on validating transactions. For example, EIP-4337 defines restrictions on disabled opcodes and storage access, while zkSync Era relaxes the use of certain OpCodes.

4. Execution Step Limitations

zkSync requires a confirmation system flag to execute system calls. There are no special restrictions during the execution phase for ERC-4337 and StarkNet.

5. Random Number

ERC-4337 distinguishes between a 192-bit key value and a 64-bit random value. zkSync and StarkNet use a strictly increasing nonce.

6. First Transaction Deployment

ERC-4337 includes the initcode field in the userOp structure, which is used for the initial deployment of the account contract. StarkNet and zkSync require the user's first transaction to be sent to the operator/sorter to deploy the account contract.

Differences between L1 and L2 in ERC-4337

There are two key differences in implementing ERC-4337 on EVM-compatible chains:

1. Protocol Differences

In Rollup design, L2 needs to upload data to L1 to ensure security and settlement. Related fees ( such as L1 security fees and blob fees ) should be included in the pre-validation Gas, but determining the appropriate upload fees is a significant challenge.

2. Address Differences

The address calculation methods vary across different chains. For example, the address encoding method in the create function of zkSync ERA is different from that of Ethereum and OP Aggregation, while StarkNet uses a unique hash function to calculate addresses.

It is worth noting that the new opcodes introduced in hard forks may lead to changes in bytecode, thereby affecting the consistency of account contract addresses. For example, if the L2 chain does not support the Shanghai hard fork and the EVM version is not specified at compile time, the introduction of push0 will alter the bytecode, even if the Solidity code remains the same.