Multi-Chain Account Abstraction Analysis: Exploring the Future of 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 year's conference (EthCC 7) brings together over 350 leading opinion leaders from the blockchain industry. A blockchain developer was invited to participate and delivered a speech titled "Unveiling the Future: An Analysis of Multi-Chain Account Abstraction."

Key Points of the Speech

• The core of account abstraction (AA) includes signature abstraction and payment abstraction. The former allows users to choose any verification mechanism, while the latter supports multiple transaction payment options, enhancing security and user experience.

• The entry point functions for ERC-4337 and native AA during the validation phase are fixed, but only the entry point for native AA is fixed during the execution phase. Different implementations have their own characteristics regarding the limitations of validating transactions and the steps for executing transactions.

• When implementing ERC-4337 on EVM-compatible chains, the differences in protocols within Rollup designs and the methods of address calculation are two key distinctions, which lead to some subtle development details when implementing between L1 and L2.

Account Abstraction Overview

The core of account abstraction

Account abstraction (AA) mainly includes two key points:

1. Signature abstraction: Allows users to choose any verification mechanism, not limited to specific digital signature algorithms.
2. Payment Abstraction: Supports various transaction payment options, such as using ERC-20 assets instead of native assets for payment, or allowing third-party sponsorship of transactions.

This flexibility greatly enhances security and user experience.

Introduction to ERC-4337

ERC-4337 aims to address some limitations of externally owned accounts (EOA) in the Ethereum protocol:

• The user sends the userOp structure to the Bundler, which collects multiple userOps and sends them to the EntryPoint contract by calling the handleOps function.
• The EntryPoint contract is responsible for handling transactions, and its main functions include:

1. Call the validate function of the account contract to ensure that userOp is authorized.
2. Charge fees.
3. Call the execute function of the account contract to perform the target operation of userOp.

Overview of Native Account Abstraction

In native account abstraction, each account is a contract, and the transaction processing mechanism is directly embedded in the blockchain protocol. The AA designs of different blockchain networks have their own characteristics:

• ERC-4337 account abstraction: multiple networks such as Ethereum, Arbitrum, Optimism
• Native account abstraction following ERC-4337: StarkNet and zkSync era
• Native account abstraction with privacy design: Aztec

Comparison of ERC-4337 and Native Account Abstraction

operating system roles

The key issues that the AA operating system needs to address include: Gas price determination, transaction order confirmation, entry point function triggering, and transaction processing flow.

• ERC-4337: Completed through the Bundler and EntryPoint Contract.
• Native AA: Users send userOps to the operator/sorter of the official server.
• StarkNet: The sequencer is responsible for handling all tasks.
• zkSync Era: The operator needs to work with the bootloader (system contract).

contract interface

The account contract interfaces in different implementations are similar and all contain entry point functions for the validation and execution phases.

verification step limitations

To prevent DoS attacks, different implementations have set various limits on validating transactions:

• ERC-4337: Defines prohibited opcodes and storage access restrictions.
• zkSync Era: Relaxed the use of certain OpCodes, but restricted storage access and global variable access.
• StarkNet: External contract calls are not allowed.

execution step limitations

• zkSync: Requires confirmation of system flags to execute system calls.
• ERC-4337 and StarkNet: No special restrictions during the execution phase.

random number processing

Different implementations vary in random number management:

• ERC-4337: Distinguish between 192-bit key values and 64-bit random values.
• zkSync: Uses the NonceHolder system contract management to ensure strict incrementation.
• StarkNet: Also strictly increasing, but without specific contract management.

first transaction deployment

• ERC-4337: Deploys the account contract in the first userOp through the initcode field in the userOp structure.
• StarkNet and zkSync: Users need to send their first transaction to the operator/sorter to deploy the account contract.

Differences between L1 and L2 in the implementation of 4337

When implementing ERC-4337 on EVM-compatible chains, there are two key differences:

1. Protocol Differences

In Rollup design, L2 needs to upload data to L1 to ensure security and settlement. This involves additional costs (such as L1 security fees and blob fees), which need to be considered in the pre-validation Gas, presenting a significant challenge.

2. Address differences

The address calculation methods of different chains vary:

• The address encoding method in the create function of zkSync ERA is different from that of Ethereum and OP aggregation.
• StarkNet uses a unique hash function for address calculation.

When implementing ERC-4337 on EVM-compatible chains, it is usually assumed that address calculation is consistent across chains. However, adding new opcodes in hard forks may lead to changes in bytecode, thereby affecting the address calculation results.

Conclusion

Account abstraction technology is rapidly developing, bringing new possibilities to blockchain infrastructure. Different implementations each have their advantages and disadvantages, and developers need to deeply understand these differences to make the best choices in various scenarios. As the technology continues to evolve, we look forward to seeing more innovative applications and solutions emerge, further promoting the development of the blockchain ecosystem.