Exploring multi-chain account abstraction solutions: native support and ERC-4337 compatibility

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.

An illustration outlining the flow of a Starknet transaction

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.

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.