Author: Alfred, developer at imToken Labs

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

More than 350 opinion leaders active in the blockchain industry gave speeches at this Ethereum Community Conference (EthCC 7). Alfred from imToken Labs was invited to participate and delivered a speech entitled "Unveiling the Future: Multi-chain Account Abstraction Analysis" at the conference.

Quick summary of the speech:

  • Account abstraction (AA) mainly includes two key points: signature abstraction and payment abstraction. Signature abstraction allows users to choose any verification mechanism they like, while payment abstraction allows the use of multiple transaction payment options. This flexibility provides a safer and better user experience.

  • In ERC-4337 and native AA, the entry point function in the "verification" phase is fixed, while in the "execution" phase, only the entry point in native AA is fixed. The restrictions on verifying transactions and the steps for executing transactions have their own characteristics and restrictions in different implementations.

  • There are two key differences in implementing ERC-4337 on an EVM-compatible chain: protocol differences in Rollup design and differences in how addresses are calculated, which lead to development details that are difficult to notice when implementing ERC-4337 between L1 and L2.

The following is the full text of the speech:

Hello everyone, I’m Alfred, a blockchain developer at imToken Labs. Today, I’ll introduce the concepts of ERC-4337 and Native AA, discuss the differences between them, and focus on analyzing the main differences between the 4337 standards for L1 and L2.

Account Abstraction Introduction

1. What is account abstraction?

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

  • Signature abstraction: Users can choose any verification mechanism they like, rather than being limited to certain digital signature algorithms (such as ECDSA).

  • Payment abstraction: Users can use a variety of transaction payment options, such as using ERC-20 assets instead of native assets to pay, or having a third party sponsor the transaction.

This flexibility provides greater security and a better user experience. Account abstraction aims to achieve these two key points in a number of ways.

2. What is ERC-4337

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

  • userOp structure: In ERC-4337, the user sends 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 handles transactions like an operating system. Its main functions include:

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

  • Fee.

  • Call the execute function in the account contract to perform 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 design in each blockchain network:

  • ERC-4337 Account Abstraction: Ethereum, Arbitrum, Optimism, Base, Linea, Scroll, Polygon PoS

  • Native account abstraction follows ERC-4337: StarkNet & zkSync era

  • Native Account Abstraction with Privacy by 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 my article, which is listed at the end of the article.

The difference between ERC-4337 and native AA

1. Operating system role

AA OS needs to answer the following questions:

  • Who determines the gas price?

  • Who decides the order of transactions? Where is the memory pool?

  • Who triggers the entry point function?

  • What determines the flow of transaction processing?

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

In native AA, users send their userOps to the operator/sequencer of the official server instead of the Bundler and EntryPoint Contract.

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

In zkSync, the main difference between Era and other AA implementations is that the Operator needs to work 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

The account contract interface is similar across different implementations due to the presence of three steps, these entry point functions can only be called by the AA OS:

  • ERC-4337: Verifying User Actions

  • zkSync: Verify transactions, pay for transactions, and execute transactions

  • StarkNet：execute、validate、validate_declare、validate_deploy

In ERC-4337 and native AA, the entry point function in the "verification" phase is fixed, while in the "execution" phase, only the entry point in native AA is fixed.

3. Limitations of the verification step

Since there is no cost limit for validating a transaction (essentially, validating a transaction is calling a view function), an attacker can perform a DoS attack on the memory pool, thereby compromising the bundler (EIP-4337) or the operator/sorter (native AA).

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

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

  • The storage slot belonging to address A

  • A storage slot belonging to any other address A

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

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

4. Restrictions on execution steps

In zkSync, executing system calls requires confirming the presence of a system flag. For example, the only way to increment a nonce is to interact with the NonceHolder, and deploying a contract requires interacting with the ContractDeployer. System flags ensure that account developers are intentionally interacting with system contracts.

In ERC-4337 and StarkNet, there are no special restrictions on the execution phase.

5. Random Numbers

  • In ERC-4337, the design of the entry point random number distinguishes between the 192-bit key value and the 64-bit random value.

  • In zkSync, the NonceHolder system contract manages nonce and ensures strict increment, that is, the random number is increased by 1.

  • In StarkNet, nonces are also strictly increasing, but there is no abstract nonce to be managed by a specific contract.

6. Deploy using the first transaction

  • ERC-4337 includes an initcode field in the userOp struct to deploy the sender (account contract) in its first userOp.

  • In StarkNet and zkSync, the user must send the first transaction to the operator/sequencer to deploy the account contract.

7. Special Design in zkSync

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

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

The difference between L1's 4337 and L2's 4337

There are two key differences in implementing ERC-4337 on an EVM-compatible chain: protocol differences and address differences.

1. Protocol Differences

In the 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 major challenge.

2. Address Difference

The way addresses are encoded in zkSync ERA's create function is different from Ethereum and OP Rollup. In addition, StarkNet uses a unique hash function for address calculation. In the context of ERC-4337 on EVM-compatible chains, we usually assume that address calculation is consistent across chains. However, there is a subtle detail that may cause account contract addresses to differ 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 will cause the bytecode to change, 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).

For an introduction to Aztec account abstraction, please refer to:

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

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

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

For an introduction to 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, available at:

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