Note: The original text comes from @tmel0211 who posted a long tweet.
Seeing that particle network has newly released full-chain account abstraction, it seems that they want to add a "middle layer" on the basis of the existing ERC4337 standard. Why do they have to do this? I feel puzzled but understand at the same time. If you are familiar with the current status of account abstraction, it is not difficult to come up with the answer:
1) Currently, each EVM equivalent chain, including layer 1, layer 2, and layer 3 application chains, has completely different methods. This type of abstraction is chain-oriented, not user-oriented; 2) To truly achieve user-orientedness, such as allowing a user to connect all related chains based on one entry and one address, thereby achieving a more coherent and global interactive experience, a "middle layer" role that can define unified intent specifications and execution standards becomes necessary.
Why is the current market "account abstraction" practice so fragmented? How is Particle Network's full-chain account abstraction technically implemented? How long is it going to achieve Mass Adoption in the intent-centric abstraction track? Let's analyze them one by one:
1) Account abstraction AA solutions are unified at the "engineering" level, but the practical level varies from person to person.
In simple terms of the technical layer, account abstraction is that the user puts a series of intentions into the UserOP memory pool, which is packaged by the Bundler and sent to the Entrypoint contract for execution. Aggregator can be used to aggregate signatures to process batch transactions, and Paymaster handles the details of paying Gas fees. This is a set of standards defined by ERC4337, and the back-end implementation logic is also unified, but it is essentially an abstraction based on the EVM chain, and the front end that accesses the user is not necessarily "unified".
For example, zkSync uses the EOA address to bind the account, and the user only sees a transferable shadow address, and the front-end can hardly feel the existence of the AA account; while Starknet uses the form of upgradeable contract accounts, and users need to continuously upgrade contracts to update account functions. In addition, Argent uses the Guardian mechanism of social recovery mechanism, and Unipass's account abstraction solution tends to be applied in heterogeneous multi-chain environments in non-EVM environments, etc.
Wait, this inconsistency in the entry point seems to be a kind of personalization, but it undoubtedly increases the threshold for users. After all the abstractions, how come the threshold is higher in the "user-oriented" environment? It is manifested in: a user cannot interact with only one chain in a multi-chain and multi-layer2 environment. Generally speaking, learning costs are generated out of thin air when crossing multiple wallets and multiple chains; a user will have multiple different contract addresses in different EVM chains, which brings challenges to unified asset management.
How can such a fragmented multi-chain ERC4337 standard engineering implementation lead to a user-oriented Mass Adoption?
2) What is the difficulty in implementing unified account abstraction logic? Take full-chain account abstraction as an example
As mentioned above, the current account abstraction is only EVM chain-based, but the EOA address can be kept consistent between the same EVM chain. Why? Because the EOA address is derived from the public key calculation. As long as the algorithms of different chains are consistent and the private keys are the same, the derived addresses are also the same. However, the contract address is calculated from the Creator address and Nonce. Since the Nonce of each chain is different, the contract address obtained is also different. A seemingly feasible way is to use the registry method to map the same address between different chains, but this poses a centralization risk.
Looking at the Particle Network's full-chain account abstract structure diagram, it is trying to take on the role of a "dispatching center" with a decentralized chain native framework. Every new chain with a new address will be uniformly connected to the sub-Deploy Contract by the dispatch center's general contract for unified operation, including deployment and upgrade. All aspects will be uniformly dispatched by the general contract.
The only difficulty in doing this lies in the smoothness of instant communication between heterogeneous chains. The "middle layer" is required to act as an efficient connection medium, which can achieve unified scheduling through contracts distributed on light nodes of each chain. The practical solution is similar to layerZero's cross-chain solution.
This approach at least breaks through the attribute limitations of the EVM chain, allowing any multi-chain that supports heterogeneous chain contract interoperability and the EIP-4337 solution to be included in the multi-chain system. It can achieve full-chain account abstraction to a great extent.
However, non-EVM chains like Aptos and Sui are currently unable to connect in a similar way to contract series. Well, after looking at each other, it is still the EVM camp's stacking solution. At a time when the Ethereum ecosystem has an absolute dominance in the layer, Layer2 and Layer3 categories, the market is already large enough.
3) What imagination space can be released by other modular abstract services in the “middle layer”?
Of course, to truly achieve a comprehensive "user-oriented" abstraction, full-chain account abstraction is just the beginning. In addition to abstracting the account itself to improve the experience, a "middle-layer" scheduling center can also try to do other abstract work:
1. The transfer of cross-chain assets and the unified settlement layer allow users to manage and circulate assets between different chains in a decentralized manner, reducing the slippage friction consumption that may exist across chains. DappOS adopts a similar middle-layer abstraction solution;
2. Cross-chain DID unifies the connection of identity and credit, with the middle layer as the "authentication center", to achieve identity sharing and data synchronization between multiple chains, and then derive "credit" that can be applied across chains, reducing the user's cross-platform threshold, while breaking the data separation between chains, and truly realizing an interactive experience based on "identity";
3. Implement a unified decentralized solver solution. It is best to aggregate all these decentralized solvers into a super solver dispatch center. For example, users can connect to various solver solutions such as UniswapX, Cowswap, and Flashbot's SUAVE on one platform, and construct a platform that is convenient for potential solver participants such as market makers, institutional traders, and arbitrage scientists. Because if there is no middle layer for dispatching, there is no doubt that these solvers will still exist in fragments between chains.
In order to connect the various chain hubs, the Cosmos chain abstracts an IBC intermediate communication layer. You can understand that under the premise that there are various standard splits in the EVM ecosystem, ERC4337 defines the communication rules, and communication still depends on an IBC that acts as this "middle layer".
And don’t underestimate the value of this kind of middle-layer infra, because it may be a necessary supplement for account abstraction to break away from the engineering abstraction layer and move towards large-scale popularization and implementation.
We have placed too much expectation on the Intent-centric abstract track, but this track will remain very abstract for a long time. How to maximize the value of the ERC4337 standard, how to unify the products and protocol standards of various wallets, chains and other builders in the track, and how to truly fill the gap between the web2 user experience and the native characteristics of the web3 chain based on user orientation are all topics that need to be overcome.
