Authored by Kiwi Yao, researcher @OKX Ventures
Multi-chain account abstraction (AA) solutions are a new and innovative way to interact with multiple blockchains. They allow users to create and manage accounts on multiple blockchains without having to worry about the underlying technical details, like having enough of the native tokens for gas payments. This makes it much easier for users to get started with blockchain technology and to use multiple blockchains simultaneously. There are two main types of multi-chain AA solutions: native support and ERC-4337 compatibility.
Native support is when a blockchain directly supports multi-chain AA. ERC-4337 compatibility is when a blockchain or layer 2 scaling solution uses a smart contract to implement multi-chain AA. In this article, we'll explore both native support and ERC-4337 compatibility for multi-chain AA solutions. We'll also discuss the benefits and drawbacks of each approach.
Networks compatible with ERC-4337 account abstraction
Arbitrum
Arbitrum officially activated AA endpoints on Arbitrum One and Arbitrum Nova following the adoption of the AIP-2 proposal. The proposal introduces a new RPC endpoint — eth_sendRawTransactionConditional — that's specifically designed to cater to the needs of ERC-4337 bundlers.
Polygon
Polygon is ERC-4337 compliant and achieves this by leveraging solutions such as Biconomy, Gas Station Network (GSN), Infura, and Gelato for meta-transactions. Also, Polygon's zkEVM supports AA via ERC-4337, enabling users to pay with any token.
Optimism
Various AA infrastructures are currently available on the OP mainnet through projects such as Alchemy, Biconomy, CyberConnect, Pimlico, and Stackup, although detailed architectural information is yet to be released.
BNB
In the technical roadmap for BNB Chain for 2023, the team mentions the establishment of AA infrastructure. Compatibility with ERC-4337 is also confirmed, with more details slated for release soon.
Native account abstraction
Starknet
Starknet natively supports AA by rendering all accounts as contract accounts (CAs) or smart accounts. The goals of natively supporting AA include signature abstraction and payment abstraction. These are aimed at allowing different account contracts to use diverse signature validation schemes and different payment models for transactions. In doing so, the experience of managing the account will be greatly improved as individuals now have more options regarding signature validation and payment from a third party or smart contract.
Starknet transaction flow
When a transaction is picked to be added to a block, the sequencer picks it up and executes it. The execution of the transaction happens in two stages. First, the sequencer asks the account contract to validate the transaction. Then, it asks the account contract to execute it. These two stages are encoded in two separate functions in the account contract — validation and execution.
The distinction between these stages allows Starknet OS to guarantee payment to the sequencer. To prevent a denial of service (DoS) attack on the Starknet transaction pool and filling it with invalid transactions, Starknet mandates that a node accepting a transaction simulates locally against the known state before it adds the transaction to the pool and broadcasts it to other nodes and sequencers. Upon completing the simulation, the transaction can then be entered into the pool and propagated on the network.
Source: StarkNet
Starknet AA vs ERC-4337 AA
Starknet removes additional complexity introduced by the bundler and designates the sequencer to fulfill the role of the bundler. This is unlike ERC-4337's AA solution, which calls for bundlers to execute user operations (user ops)
Compared to ERC-4337's AA solution, Starknet doesn't incorporate a paymaster-like transaction fee abstraction protocol
Starknet also doesn't distinguish between regular transactions and user ops, simplifying the process
One notable difference is in deployment. Starknet deploys the CA first before it can be invoked. Essentially, Starknet requires accounts with token balances to create a new CA by calling a specialized 'deploy_account' function. This deployed account contract can pay gas. Comparatively, ERC-4337's AA solution doesn't require deployment in advance. The bundler deploys a CA by executing a user op transaction with a non-null initCode parameter. An account with a token balance isn't required for the deployment process and the gas fee can be paid by paymaster.
zkSync
zkSync supports native AA and offers compatibility with the Ethereum Virtual Machine (EVM). Similar to Starknet, zkSync aims for signature and payment abstraction, supporting different signature verification schemes for various account contracts and diverse payment models and token forms for transactions.
zkSync transaction flow
zkSync's transaction flow involves the individual sending the signed transaction to the operator, which is then sent to the bootloader for validation. After validation and fee acquisition, the bootloader calls the CA to execute the transaction.
zkSync AA vs ERC-4337 AA
Unlike ERC-4337's AA solution, zkSync doesn't distinguish between externally owned accounts (EOAs) and CAs.
zkSync allows the validateTransaction function to call deployed external contracts. This is a feature that's restricted in Ethereum as it may create a state change that causes transaction validation to pass and the execution aspect of the transaction to fail.
Another difference is that zkSync allows the validateTransaction function and paymaster to call the external storage of the CA that issued this transaction. For example, the CA's token balance on the external contract can be viewed thanks to the paymaster and validateTransaction function. In contrast, Ethereum prohibits such a feature.
AA solution comparisons among zkSync, Starknet and ERC-4337 compatible networks
Similarities
zkSync, Starknet, and ERC-4337 compatible networks share similar AA processes. These include the verification phase, fees mechanism (paid by account contract or paymaster), and the execution phase. Additionally, smart contract wallet interfaces are categorized into the validateTransaction and executeTransaction functions.
zkSync, Starknet, and ERC-4337 handle DoS Attacks similarly. zkSync's contract logic is only allowed to touch its own slots, and its contract logic is not allowed to use global variables. Similarly, Starknet's sequencer requires local emulation before adding transactions to the memory pool and broadcasting them. Lastly, ERC-4337's user operation puts a gas limit on the validateUserOp step and requires paymaster to pledge tokens.
Differences
The biggest difference would be that zkSync and StarkNet are both native AA with architectural differences from ERC-4337 compatible networks
Regarding on-chain gas consumption, zkSync and StarkNet are both layer 2 scaling solutions that need to consider Rollup costs
There are differing roles concerning AA execution. zkSync architecture has operator and bootloader (system contract) working together to fulfill user ops. For StarkNet, sequencer handles user ops, without bundler and paymaster mechanisms. Lastly, ERC-4337 compatible networks have different architectures involving bundlers and entry point contracts
Another key difference is in whether transactions can be sent before the CA is deployed. In both StarkNet and zkSync, the entry point contract doesn't have an initCode field that allows it to deploy the CA for the individual. This makes it so neither of them can send transactions before the account is deployed.
Lastly, there's a difference in calling external contracts. zkSync allows the validateTransaction function to call deployed external contracts. However, both ERC-4337 compatible networks and Starknet don't allow this.
Difference in paymaster
Starknet has no paymaster interface
For ERC-4337 compatible networks, the paymaster interface defines validatePaymasterOp. This defines the logic for paymaster to pay for a transaction. The interface also uses the postOp function, which makes sure paymaster can extract the gas fee compensation after the transaction is executed. Paymaster needs to deposit Ethereum on the entry point contract as a form of gas payment and pledges Ethereum on the entry point contract to prevent bots from creating malicious batches.
zkSync is similar to ERC-4337 compatible networks, where the interface defines validatePaymasterOp and postOp functions. The definitions are similar to ERC-4337 but this part of the function has not yet been implemented. Unlike ERC-4337's paymaster, zkSync's paymaster won't start execution until it calls postTransaction when it has enough gas. On the other hand, ERC-4337's paymaster won't call postOp if validatePaymasterUserOp doesn't return a context.
Comparison table
Need a quick reference to find out the difference between native support and networks featuring ERC-4337 compatibility? Check out our table below.
Comparison | ERC-4337 | Starknet | zkSync |
|---|---|---|---|
AA account | Smart contract | Protocol native | Protocol native |
Process logic | Verification phase → Fee mechanism (paid by account contract or paymaster) → Execution phase | ||
Execution/invocation process | Bundler → entry point | Sequencer | Operator → bootloader |
Role in determining transaction order | Bundler | Sequencer | Operator |
Role in determining gas | Bundler | Sequencer | Operator |
Gas fee consumption | Layer 1 | Layer 1 on-chain + layer 2 | Layer 1 on-chain + layer 2 |
Can transactions be sent before deploying account contract | Yes | No | No |
Paymaster validation rules | Defined logic through validatePaymasterOp and postOp, paymaster needs to deposit and stake Ether | No paymaster | Defined logic through validatePaymasterOp and postOp, where postOp calling logic is slightly different from Ethereum |
Can external contracts be called | No | No | Yes |
How to mitigate DoS threats | User ops imposes gas limitation on validateUserOp step, and paymaster needs to stake tokens | Transactions must be added to mempool and locally simulated before broadcasting | Only allowed to touch their own slots, cannot use global variables |
The bottom line
As Ethereum introduces AA, we're witnessing plenty of other networks follow suit by addressing a lot of problems that could make mass adoption more challenging. With multi-chain AA, competing ecosystems might be showing that they're not far behind regarding solving problems like gas payment inflexibility and reliance on private keys.
Has multichain AA sparked your interest in exploring the Web3 space with us? Find out how OKX will integrate AA into our multichain wallet.
© 2023 OKX. This article may be reproduced or distributed in its entirety, or excerpts of 100 words or less of this article may be used, provided such use is non-commercial. Any reproduction or distribution of the entire article must also prominently state:"This article is © 2023 OKX and is used with permission." Permitted excerpts must cite to the name of the article and include attribution, for example "Article Name, [author name if applicable], © 2023 OKX." No derivative works or other uses of this article are permitted.
