Account Abstraction in a Multichain Landscape - Part 1: Addresses

This is the first article in a series of posts exploring account abstraction in a multichain landscape. A base level knowledge on the topic of account abstraction is presumed, here’s a good summary to get up-to-speed, if required.

It becomes increasingly common for users to operate on multiple chains, each with its own ecosystem, features, limitations, and implementation details. When it comes to account abstraction wallets like Safe, the question arises:

Can the same blockchain address be used on different chains for smart contract wallets? and if yes, is it advisable to do so?

The Dilemma: One address vs. multiple addresses

Users of account abstraction wallets expect to have the same address for their wallets on different chains because they are used to having a consistent address for their wallets, such as Metamask. In these conventional wallets, known as "EOAs" (Externally Owned Accounts), a user creates an account that is immediately accessible on all Ethereum Virtual Machine (EVM) chains. This consistency makes it easier for users to manage their digital assets cross-chain. Consequently, users expect account abstraction wallets to offer the same level of convenience and ease of use as conventional EOA wallets.

However, account abstraction wallets are, by design, unique smart contract instances deployed on individual chains. While users can create account abstraction wallets on different chains, they ultimately have distinct account addresses, which introduces several drawbacks:

• Risk of lost funds: An account holder might share their account abstraction wallet address without specifying the particular chain on which they can receive assets, leading to inaccessible funds if the sender transmits assets on an unsupported chain.

• Breaking assumptions: Bridges often assume identical addresses on both sides of cross-chain bridging, misleading users into bridging assets to a chain where they lack access.

• Added complexity: Managing multiple addresses across chains imposes additional overhead for users.

The first issue can be mitigated by adopting chain-specific addresses as proposed in ERC-3770 as a way to remove ambiguity for dApps, wallets, and users. This standard adds a prefix. 

Chain-specific addresses

We have implemented the ERC-3770 address format in Safe{Wallet} already, in order to reduce the risk of people mistakenly receiving assets on an address where they do not have a Safe deployed. 

But it became obvious that this is not the ideal end-state as users continue to request a way to have a single address for all chains.

Counterfactual Deployment: A Double-Edged Sword

Technically, counterfactual deployment (CREATE2) allows deploying the same smart contract code on multiple chains with identical initial conditions, thereby creating an account abstraction wallet with the same address on different chains. However, this approach presents several concerns:

• Unconscious state drift: Each chain has its unique state and data storage, which can cause discrepancies between the states of a smart contract on different chains. Consequently, users might experience varying outcomes when interacting with the supposedly identical account abstraction wallet on separate chains. For example, an account might initially be created with a specific signer key as the controller on different chains, but a key rotation on chain A would not be reflected on chain B. Users may not be aware of this state drift as a single address suggests the access/control policies to be identical, which can cause security risks.

• Incompleteness: Counterfactual deployment may work on numerous pure EVM chains, but chains with even slight deviations from the EVM, such as some zk-Rollups, could disrupt the ability to create identical addresses. If users begin expecting the same address for their account abstraction wallet everywhere, exceptions may become increasingly critical, particularly as more chains emerge where a counterfactual deployment may not suffice.

So while it is understandable that users would prefer a single low-level address, and counterfactual deployment seems like a feasible solution, it seems short-sighted and could quickly turn into an anti-pattern.

The Goal: Safe Multichain IDs

An ideal solution would combine distinct low-level account addresses with a single overarching identifier. Chain-specific addresses remain critical to remove any ambiguity on the side of wallets and dApps. However, they can be abstracted away from the user with the Ethereum Name Service (ENS). ENS enables users to register human-readable domain names and map them to blockchain addresses.

ENS supports multichain address resolution, which allows a single ENS name to be mapped to different addresses depending on the chain. This approach is superior to using counterfactual deployments. It provides a unified human-readable identifier, yet still uses distinct low-level addresses for the unique accounts on each chain. Additionally, the same mechanism could be used even outside the EVM ecosystem. Wallets that accept ENS names as an address input could then automatically resolve the correct low-level address without any additional complexity for the sender.

Single ENS mapped to distinct low-level addresses on different chains

Summary

In conclusion, users clearly expect to only have a single identifier for managing assets across multiple chains. Counterfactual deployment (CREATE2) is a feasible solution, but it can be short-sighted and problematic, leading to state drift and incompleteness. A better solution is to leverage ENS names to map a single unique identifier to distinct low-level addresses on different chains. This approach offers a more reliable and user-friendly method for managing addresses in a multichain landscape.

If you want to contribute to this discussion on our forum, please add your comments👇