Author: Alfred, Developer at imToken Labs

From July 8th to 11th, 2024, the Ethereum Community Conference (EthCC) was held in Brussels, Belgium. This is the largest annual Ethereum event in Europe, focusing on technology and community.

At this year's Ethereum Community Conference (EthCC 7), over 350 active industry leaders in the blockchain field delivered speeches. Alfred from imToken Labs was invited to participate and delivered a speech titled "Revealing the Future: Analysis of Multi-Chain Account Abstraction" at the conference.

Summary of the Speech:

• Account Abstraction (AA) mainly includes two key points: signature abstraction and payment abstraction. Signature abstraction allows users to choose any preferred verification mechanism, while payment abstraction allows the use of multiple transaction payment options. This flexibility provides a more secure and optimal user experience.
• In ERC-4337 and Native AA, the entry point function for the "validation" stage is fixed, while in the "execution" stage, only the entry point in Native AA is fixed. There are specific features and limitations in different implementations for validating transactions and executing transaction steps.
• Implementing ERC-4337 on EVM-compatible chains has two key differences: protocol differences in Rollup design and differences in address calculation methods, leading to unnoticed development details when implementing ERC-4337 between L1 and L2.

Full Text of the Speech:

Hello everyone, I'm Alfred, a blockchain developer at imToken Labs. Today, I will introduce the concepts of ERC-4337 and Native AA, discuss their differences, and focus on analyzing the main differences of the 4337 standard between L1 and L2.

Introduction to Account Abstraction

1. What is Account Abstraction

Account Abstraction (AA) mainly includes two key points: signature abstraction and payment abstraction.

• Signature abstraction: Users can choose any preferred verification mechanism, not limited to specific digital signature algorithms (such as ECDSA).
• Payment abstraction: Users can use multiple transaction payment options, such as using ERC-20 assets instead of native assets for payment, or allowing third-party sponsorship of transactions.

This flexibility provides a more secure and optimal user experience. The goal of account abstraction is to achieve these two key points in multiple ways.

2. What is ERC-4337

Currently, there are some limitations for externally owned accounts (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.

• userOp structure: In ERC-4337, users send the userOp structure to the Bundler. The Bundler collects multiple userOps and sends them to the EntryPoint contract by calling the handleOps function.

• EntryPoint contract: This contract processes transactions like an operating system, with main functions including:

• Calling the validate function in the account contract to ensure userOp is authorized by the account owner.

• Collecting fees.

• Calling the execute function in the account contract to execute the target operation of userOp.

3. What is Native AA

In Ethereum, accounts are divided into EOA and contract accounts. However, in Native AA, each account is a contract, and the transaction processing mechanism is directly embedded in the blockchain protocol.

AA designs in various blockchain networks:

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

If you are interested in Aztec Native AA or EIP-3074, EIP-7702, today we will focus on Native AA after ERC-4337. For more details, please refer to the article I wrote, listed at the end of the document.

Differences between ERC-4337 and Native AA

1. Role of the Operating System

AA OS needs to answer the following questions:

• Who determines the gas price?
• Who determines the transaction order? Where is the memory pool?
• Who triggers the entry point function?
• What determines the transaction processing flow?

In ERC-4337, these roles are completed through collaboration between the Bundler and EntryPoint Contract.

In Native AA, users send their userOps to the operator/sorter of the official server, rather than the Bundler and EntryPoint Contract.

In StarkNet, the Sequencer is responsible for handling all these tasks.

In zkSync, the main difference of Era from other AA implementations is that the Operator needs to work in conjunction with the bootloader (system contract). The bootloader opens a new block, defines its parameters (including block parameters and other gas parameters), and receives transactions from the Operator for verification.

2. Contract Interface

Due to the existence of three steps, the account contract interface is similar in different implementations, and these entry point functions can only be called by AA OS:

• ERC-4337: Validate user operations
• zkSync: Validate transactions, transaction payments, execute transactions
• StarkNet: execute, validate, validate_declare, validate_deploy

In ERC-4337 and Native AA, the entry point function for the "validation" stage is fixed, while in the "execution" stage, only the entry point in Native AA is fixed.

3. Limitations of the Validation Steps

Since validating transactions have no cost restrictions (essentially, validating transactions is calling view functions), attackers can launch DoS attacks on the memory pool, thereby disrupting the Bundler (EIP-4337) or operator/sorter (Native AA).

EIP-4337 defines which opcodes are prohibited and how to limit storage access. zkSync Era relaxes the use of some opcodes:

• Contract logic can only access its own storage slots. If the address of the account contract is address A, it can access:

• Storage slots belonging to address A

• Storage slots belonging to any other address A

• Storage slots belonging to any other address keccak256 (A || X): This means directly using the address as the key in a mapping (for example, mapping (address => value)), is equivalent to accessing slot keccak256 (A || X). For example, asset balances in an ERC-20 contract.

• Contract logic cannot access global variables, such as block number. StarkNet also does not allow external contract calls.

4. Limitations of the Execution Steps

In zkSync, executing system calls requires confirmation of the existence of system flags. For example, the only way to increase the nonce is to interact with the NonceHolder, and deploying contracts requires interaction with the ContractDeployer. The system flags ensure that account developers consciously interact with system contracts.

In ERC-4337 and StarkNet, there are no special restrictions in the execution stage.

5. Random Numbers

• In ERC-4337, the design of entry point random numbers distinguishes between 192-bit key values and 64-bit random number values.
• In zkSync, the NonceHolder system contract manages the nonce, ensuring strict incrementation by adding 1 to the random number.
• In StarkNet, the nonce is also strictly incremented, but there is no abstract nonce managed by a specific contract.

6. Deploying with the First Transaction

• ERC-4337 includes the initcode field in the userOp structure to deploy the sender (account contract) in its first userOp.
• In StarkNet and zkSync, users must send the first transaction to the operator/sorter to deploy the account contract.

7. Special Design in zkSync

If you transfer ETH directly from an Ethereum EOA to zkSync, without deploying a custom account contract, you will receive a default account with the same address. This account can function like an Ethereum EOA and is controlled by the corresponding Ethereum EOA's private key.

This account type is version None instead of version1. You cannot call functions of DefaultAccount because it has not deployed any code in kernel space.

Differences between L1's 4337 and L2's 4337

Implementing ERC-4337 on EVM-compatible chains has two key differences: protocol differences and address differences.

1. Protocol Differences

In Rollup design, L2 needs to upload data to L1 for security and settlement. In the context of ERC-4337, the fees associated with this upload process, such as L1 security fees and blob fees, should be included in the pre-verification gas. Determining the appropriate upload fee in the pre-verification gas is a significant challenge.

2. Address Differences

The address encoding in the create function of zkSync ERA is different from Ethereum and OP Rollup. Additionally, StarkNet uses a unique hash function for address calculation. In the context of ERC-4337 on EVM-compatible chains, it is generally assumed that address calculation is consistent across chains. However, there is an unnoticed detail that may lead to different account contract addresses between Ethereum and ERC-4337 implementations in L2.

The key issue is adding new opcodes in a hard fork. 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 would result in bytecode changes, even if the Solidity code is the same.

Conclusion

Here are some resources for you to learn more about account abstraction. Feel free to reach out to me if you have any questions, you can find me on Twitter (@murmurlu).

"Introduction of Aztec Account Abstraction," please refer to:

https://medium.com/@ChiHaoLu/introduction-of-aztec-account-abstraction-98535c9edf2e

"Introduction of StarkNet Account Abstraction," please refer to:

https://medium.com/taipei-ethereum-meetup/introduction-of-starknet-account-abstraction-2c343b561d6e

"Introduction of zkSync Account Abstraction," please refer to:

https://medium.com/taipei-ethereum-meetup/zksync-%E4%B8%AD%E7%9A%84%E5%8E%9F%E7%94%9F-account-abstraction-%E4%BB%8B%E7%B4%B9-bc7269f8893a

"Starknet and zkSync: A Comparative Analysis," please refer to:

https://medium.com/nethermind-eth/starknet-and-zksync-a-comparative-analysis-d4648786256b

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。