Particle officially releases the omnichain account abstraction infrastructure.

Authors: Peter Pan & Vijay Singh, Particle Network

Translation: Peng SUN, Foresight News

Over the past two months, Particle Network has been making big moves, from disclosing the upcoming v2 design with ZK and intent-based features, to detailing the token-centric economy and gradually showcasing our overall plan to onboard the next billion users to Web3.

Particle's CTO recently published an article discussing various existing approaches to addressing challenges in the account abstraction (AA) space. The article also outlines Particle's solution, which is to achieve omnichain account abstraction based on existing solutions, addressing multiple user experience and robustness issues in the account abstraction infrastructure and its design. Additionally, omnichain account abstraction can also address the long-standing pain points of cross-chain and interoperability in the industry.

Today, Particle officially releases the omnichain account abstraction infrastructure.

TL;DR: Particle's omnichain account abstraction (Omnichain AA) solves existing issues in cross-chain transactions and multi-chain account abstraction, achieving decoupling of smart account storage and code. It introduces Particle Chain as the central hub for account storage. Within this framework, cross-chain messaging is used to synchronize storage changes. Omnichain account abstraction also introduces deployer contracts for unified address generation and multi-chain storage management, as well as a cross-chain messaging solution leveraging existing interoperability protocols to support interactions across different chains. Finally, we propose using the Particle token as a unified Gas token to address the inefficiency of Gas in multi-chain execution. This design streamlines the management process of smart accounts across multiple chains and improves cross-chain operational efficiency.

1. Motivation for Omnichain Account Abstraction

As analyzed by our CTO, the current ERC-4337 AA framework is more akin to "transaction flow abstraction," as it primarily focuses on optimizing the underlying processes of transaction execution rather than the accounts themselves.

This framework is important as it lays the foundation for the adoption of smart wallets and subsequent protocol-level implementations, but it also brings about a series of specific issues, namely:

• Difficulty in integrating AA solutions, leading developers to build custom implementation solutions;
• Poor compatibility of account modules, resulting in ecosystem fragmentation;
• Significant disparities between different blockchains, making it difficult to provide a unified and high-quality experience for users and developers, leading to poor user experience.

In light of these challenges, there are currently three approaches:

• Biconomy has proposed a standardized modular approach, allowing developers to build their own solutions on top of it instead of adopting ERC-4337 smart account implementation. The proposal also includes creating highly specialized markets for different modules that can be integrated with smart accounts (Bundlers, Paymasters, etc.).
• Safe (formerly Gnosis Safe) has proposed a similar but fundamentally different approach. It aims to create a protocol for lightweight smart accounts similar to EOA. Based on this, a module market will be created where different vendors can create their own implementations while maintaining compatibility.
• Vitalik Buterin has proposed a system using Ethereum or highly secure zk-rollup as the source chain and deploying a Keystore contract to store users' global keys. In this system, smart contract accounts on L2 share storage in the Keystore contract on the source chain.

The first two approaches focus on modularity and compatibility, which are two necessary features of AA; while Vitalik's approach focuses on guiding AA in a multi-chain ecosystem with multiple L2 and EVM chains. Next, we will delve into the multi-chain impact of smart accounts under the current framework and Vitalik's proposed solution.

2. Multi-Chain Issues of Smart Accounts

The current multi-chain EVM environment results in users deploying smart accounts independently on different chains. For each account, information related to account management (including permissions) is stored in the contract's Storage. Updating this information requires users to initiate transactions on multiple chains, making it technically challenging to ensure consistency between networks and time-consuming.

Vitalik Buterin’s proposed design.

In the design of ERC-4337, smart accounts use a globally unique address determined by initCode. Initial management permissions are encoded in initCode, which means that if a user deploys a smart account on a new chain but has already made management permission changes on other chains, they would need to repeat these changes on the new chain. This adds complexity for users and wallets.

To illustrate the importance and challenges of these issues, consider the following scenarios:

1. Alice deploys a smart account on Polygon and Arbitrum with Owner1 as the account owner. She regularly changes Owners as a habit.
2. Alice changes the account owner to Owner2 and forgets the private key for Owner1.
3. Bob transfers USDC to Alice's address via Linea.
4. Alice realizes that she needs the private key for Owner1 to initiate transactions, as the initialization initCode depends on Owner1. Unfortunately, she has forgotten Owner1's private key, rendering her unable to access her assets at all.

Vitalik's solution does address the issue of managing addresses across multiple chains, especially regarding changes in account storage, such as ownership transfers and social recovery. However, the solution also comes with drawbacks as it involves significant costs. Apart from the non-negligible setup fee, if the global key recorded in the Keystore contract on the source chain (Ethereum mainnet) changes, then every account on L2/target chains would need to be synchronized through cross-chain interactions. However, the cost of interaction between Ethereum and L2 is too high for most users to accept.

Equally important, the operation of smart contract accounts differs from EOA, making it difficult for users to maintain the same address across different chains, regardless of their compatibility with EVM. Therefore, Particle Network has made some key changes based on Vitalik's proposal to minimize the impact on users.

3. Particle Network's Solution

Particle proposes an alternative solution that addresses the shortcomings of multi-chain AA solutions and leverages other foundational components of Web3.

Specifically, Particle Network proposes using a standalone Particle Chain as the omnichain storage database for smart accounts. Through third-party cross-chain messaging solutions (such as LayerZero, CCIP, Axelar, Connext, etc.), changes to account storage by users will ultimately be synchronized with the local storage of that account on other chains. Particle Network introduces cross-chain user operations, further abstracting the concept of chains and facilitating seamless cross-chain interactions. It also uses the Particle Network token as a unified Gas token, abstracting away complex Gas mechanisms and simplifying the use of cross-chain smart accounts. As shown in the following diagram:

Particle Network omnichain smart account abstraction architecture

Particle Network's omnichain account abstraction allows users to have a unified smart contract account address on different EVM chains. To achieve this goal, our design includes deploying a set of deployer contracts on each chain. Users must generate a new account on the Particle Network Chain to trigger all deployer contracts on different chains, ensuring that the generated smart contract account address remains consistent across different chains. Additionally, users can interact with multiple chains through contracts on the Particle Chain without actively managing multiple addresses, and can use the Particle token as a unified payment method.

Through executing transactions on the target chain and paying the corresponding Gas fees on the source chain, omnichain account abstraction can also facilitate cross-chain user operations. For example, it allows users to use USDC on Polygon to purchase NFTs on Base.

The omnichain AA indeed requires highly coordinated deployment contracts and cross-chain messaging components to achieve synchronization between multi-chain accounts and source chain storage. This places high demands on the oracle or cross-chain messaging bridge used, which is also a common issue in omnichain interoperability solutions. However, synchronizing cross-chain accounts can be achieved by flexibly configuring different combinations of messaging bridges, rather than relying on a single bridge. For example, a 2/3 strategy can be used, requiring any two protocols from LayerZero, Axelar, and Connext to confirm storage changes on the target chain, addressing the single point of failure issue. Particle Network also addresses another issue, which is promoting the compatibility of EVM-compatible chains that often have different AA implementations, making it impossible to unify addresses with ERC-4337. ### 4. Key Components of Omnichain Account Abstraction #### Particle Chain By separating the management permissions and account logic of smart accounts (understood as the separation of storage and code logic), we need a secure blockchain to store users' account management permissions (Storage/KeyStore). Therefore, Particle Chain is the most critical component of omnichain. It stores the data (Storage) of users' smart accounts, coordinates deployer contracts on different chains, and handles cross-chain messaging components to ensure the storage and updates of users' multi-chain smart accounts. #### Deployer Contracts Multi-chain smart accounts require a unified address determined by deployer contracts (Create2). Deployer contracts and cross-chain messaging components jointly achieve unified storage across multiple chains. For the initial deployment of smart accounts, deployer contracts will reject deployments on non-Particle Chain, ensuring that the initial deployment also has the same Storage data. #### Cross-Chain Messaging Updating the Storage of accounts on Particle Chain requires support from cross-chain messaging components. For this, we directly adopt implementations such as LayerZero. Whether it's the initial deployment or subsequent updates, users can call the xManage method of smart accounts on Particle Chain to synchronize the account state to any other chain. Users can also initiate cross-chain user operations by calling xExecuteTx on the source chain where the smart account is deployed, ensuring that transactions are executed correctly on the target chain. #### Tokens We also introduce the Particle Network token to address the gas consumption issue in multi-chain execution, further improving execution efficiency and user experience. Paymasters in ERC-4337 ensure that any ERC-20 token can be used to pay for gas. In cross-chain transactions, the Particle token on any chain can be used to directly pay for gas fees on other chains. Providing a single payment token for cross-chain transactions can greatly alleviate the burden of managing multiple tokens. Currently, any cross-chain interaction requires at least two types of tokens to pay for gas fees on different chains, and in daily transactions, users need to hold the same number of token types as the number of chains they interact with. For users, omnichain account abstraction can facilitate the following scenarios: 1. Alice initiates user operations on Chain A, consuming Particle tokens on Chain A. 2. By calling the xExecuteTx of the smart account on Chain A, a cross-chain execution on Chain B is initiated to complete the corresponding operation on Chain B.  ### 5. Future Plans and Particle Network v2 As Particle's omnichain account abstraction is still in the development stage, its design can be further improved. For example, we are analyzing the use of optimistic cross-chain protocols to mitigate settlement delays and improve the speed of omnichain user operations. Since the v2 version of Particle will introduce omnichain account abstraction, modularity and ecosystem adaptability are important components of its strategic release. Particle Network v2 will also adopt an intent-based approach, aiming to abstract potential difficulties in handling different AA and smart account modules. In this architecture, the Ethereum ERC-4337 ecosystem—or native account abstraction facilities of other chains such as zkSync—can be viewed as specific instances under the Solver/Reactor type. Particle v2 will be released within the zero-knowledge wallet as a service (zkWaaS) ecosystem framework, with zero-knowledge capabilities to enhance user identity and transaction privacy. Thanks to the convenient development experience and modular features of v2's zkWaaS, integrated DApps of Particle can leverage a consistent, optimized transaction flow, reducing the development costs associated with transaction logic. The WaaS model aims to optimize user experience and seamless onboarding, allowing developers to focus on core application logic and innovative features. It is worth noting that some features of the v2 version, in addition to their own purposes, can also reduce the costs for users of omnichain account abstraction. There are three factors that can help omnichain account abstraction reduce user usage and setup costs: 1. Aggregating user activities through confidential Paymaster/transaction bundling: Particle v2's omnichain account abstraction will achieve transaction privacy through confidential Paymasters and reduce costs for users through transaction aggregation. 2. Intent-based development will promote continuous optimization: The intent-based design of Particle v2 will incentivize the Solver market to continuously optimize the user experience of expressing intent, thereby saving costs for users. The multi-chain framework provided by the omnichain account abstraction model is crucial for DApps that require AA flexibility in a diverse ecosystem. Additionally, the intent-based design will also change the way users interact with DApps.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。