From July 8th to 11th, 2024, the Ethereum Community Conference (EthCC) will be 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 leaders actively engaged in the blockchain industry will be speaking. Alfred from imToken Labs has been invited to participate and will deliver a talk titled "Unveiling the Future: Multi-Chain Account Abstraction Explained. Below is the full text of the speech:
Hello everyone, I am Alfred, currently working at imToken Labs as a blockchain developer.
Today, I will introduce the concept of ERC-4337 and Native AA. Following that, I will discuss the differences between Native AA and the 4337 standard. Finally, I will highlight the key differences between L1's 4337 and L2's 4337.
Introduction of Account Abstraction
What is Account Abstraction
Let's quickly recap the AA. The essence of AA can be divided into two key points: Signature Abstraction and Payment Abstraction .
Signature Abstraction means that users are not limited to using only certain digital signature algorithms (e.g. ECDSA), but can instead choose any validation mechanism they prefer.
Payment Abstraction seeks to offer users a range of payment options for transactions. For instance, it is possible to pay using ERC-20 tokens instead of the native token, or to have a third party sponsor the transaction .
This flexibility allows for a more secure and better user experience. The Account Abstract's target is using various ways to achieve these two points.
What is ERC-4337
We've encountered several limitations with EOAs in the current Ethereum protocol, such as the fixed signature method and payment design.
ERC-4337 aims to address these issues by introducing a more flexible approach to account management and transaction processing.
Some may argue that meta transaction or other relayer mechanisms, when combined with smart contract accounts, could potentially solve these issues. But ERC-4337 goes further by aiming to establish an open relayer system to be more decentralized and offers a unified interface.
In ERC-4337, we send a structure called userOp to a Bundler. The Bundler collects several userOps from different users and sends them to an EntryPoint Contract by calling the handleOps function.
The EntryPoint Contract plays the role as an transaction processing OS, which will:
- call the validate function in the account contract to ensure this userOp is authorized by the account owner.
- charge the fee from the account contract or paymaster.
- call the execute function in the account contract to complete the target behavior the userOp wants to do.
What is Native AA
In Ethereum, there are two types of accounts: EOAs and Contract Accounts. However, in Native AA, every account is a contract.The term "native" signifies that the transaction (aka userOp) handling mechanism is embedded directly into the blockchain protocol.
Faction
Let's overview the design of AA in various blockchain networks:
- Account Abstraction with ERC-4337: Ethereum, Arbitrum, Optimism, Base, Linea, Scroll, Polygon PoS
- Native Account Abstraction follows 4337: StarkNet & zkSync Era
- Native Account Abstraction with privacy design: Aztec
Today we will focus on the native AA following 4337, if you're interested in Aztec Native AA or 3074, 7702. I've written an article that covers it in detail which is listed at the end of slides.
Difference between ERC-4337 and Native AA
OS Role
AA OS determines the answers to the following questions:
- Who determines the gas price?
- Who determines the transaction order? Where is the mempool?
- Who triggers the entry point function?
- What determines the flow of transaction processing?
In ERC-4337, this role is fulfilled by the Bundler and EntryPoint Contract working together.
In Native AA, users send their userOps to the operator/sequencer which is an official server, instead of Bundler and EntryPoint Contract.
In StarkNet, the Sequencer handles all these tasks.
In zkSync Era, the primary difference from other AA implementations is that the Operator needs to work in conjunction with the bootloader (a System Contract) .The bootloader opens a new block, defines its parameters (including block params and other gas params), and receives transactions from the Operator for verification .
Contract Interface
Due to the three steps we have mentioned, the account contract interface definitions are similar across different implementations. These entrypoint functions can only be called by the AA OS.
ERC-4337
- validateUserOp
zkSync
- validateTransaction
- payForTransaction 、
- executeTransaction
StarkNet
- execute
- validate、-validate_declare_、-validate_deploy_
In both ERC-4337 and Native AA, the entry point function for the "validation" phase is fixed, while for the "execution" phase, only the entry point in Native AA is fixed.
Limitation in validation step
It’s known that because verifying transactions has no cost restrictions (essentially, verifying a transaction is calling a view function), attackers can perform DoS attacks on the mempool to disrupt the bundler (EIP-4337) or the operator/sequencer (Native AA) .
EIP-4337 defines which OpCodes are prohibited and how to limit storage access. zkSync Era relaxes the usage of some OpCodes:
1. The contract logic can only access its own storage slots (if the address of the Account Contract is address A) :
- 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 implies the direct use of an address as a key in a mapping (e.g., mapping (address => value) ), which is equivalent to accessing slot keccak256 (A ||X) . For example, the token balance in an ERC-20 contract.
2. The contract logic cannot access global variables, such as block numbers. While StarkNet doesn’t allow external contract calls at all.
Limitation in execution step
In zkSync, executing a System Call requires confirming the presence of an is System flag.
For example, the only way to increase the nonce is to interact with the NonceHolder, and deploying a contract requires interaction with the ContractDeployer. The system flag ensures that account developers are consciously interacting with SystemContracts.
In ERC-4337 and StarkNet, there are no special restrictions during the execution phase.
Nonce
- In ERC-4337, the design of the Entrypoint nonce distinguishes between a 192-bit key value and a 64-bit nonce value.
- In zkSync, the NonceHolder system contract manages the nonce, ensuring strict incrementation, i.e., it increases the nonce by 1.
- In StarkNet, nonce is also strictly incremented, but there is no abstraction of nonce to be managed by specific contracts.
Deploy with First Transaction
- ERC-4337 includes an initcode field in userOp struct to deploy the sender (account contract)in its first userOp.
- In StarkNet and zkSync, users must send the first transaction to the operator/sequencer to deploy the account contract.
Special Degin in zkSync
If you directly transfer ETH from an Ethereum EOA to zkSync, without deploying a customized account contract, you will receive a Default Account with the same address. This account canworks like an Ethereum EOA, and is controlled by the corresponding Ethereum EOA's private key, too.
This type of account is version None instead of version1 . You cannot call DefaultAccount's function because it does not have any code deployed in kernel space.
Difference between L1's 4337 and L2's 4337
Next, l will highlight two key differences in implementing ERC-4337 on EVM-compatible chains
Protocol Difference
In the rollup design, L2s need to upload data to L1 for security and settlement. in the context ofERC-4337, fees related to this upload process, such as L1 security fees and blob fees, should be included in the preverification Gas.
Determining the appropriate upload fee in PVG is indeed a significant challenge. This topic could be discussed in more detail in future conversations.
Address Difference
The address encoding method in zkSync ERA's create function differs from that of Ethereum and other OP-rollups. Additionally, StarkNet uses a unique hash function for address calculation.
In the context of ERC-4337 on EVM-compatible chains, we usually assume that the address calculation will be consistent across chains. However, there's a hard-to-notice detail that can lead to different account contract addresses between Ethereum and ERC-4337 implementations in L2.
The key issue is the addition of new opcodes in hardforks. For instance, if the L2 chain doesn't support the Shanghai hardfork and the EVM version isn't specified during compilation. The Introduction of pusHo can cause bytecode to change even if the solidity code is the same.
Closing
Here are some resources for you to know more about account abstraction. Feel free to reach out to me on Twitter if you have any questions. And you can find more about me at chihaolu.me.
If you'd like access to the presentation materials, please scan the QR code
Thanks for your attention.