This paper is available on arxiv under CC 4.0 license.
Authors:
(1) Qin Wang, CSIRO Data61, Australia;
(2) Shiping Chen, CSIRO Data61, Australia.
Table of Links
- Abstract & Introduction
- Ethereum Accounts
- Account Abstraction
- Security Analysis
- Further Discussions
- Conclusion & References
V. FURTHER DISCUSSIONS
A. More about AA Design
AA represents an application-level update with its primary impact centered around the application layer. Aligned with the idea outlined in EIP-4337, AA introduces perfect backward compatibility, minimizing its effects on consensus layers and underlying structures. The fact is evident in security enhancements, which effectively tackle many challenges originating from the application layer rather than fundamental design flaws (refer to Tab.III).
Rather than directly merging EOA and CA, AA incorporates key functionalities and delegates subsequent tasks to related contracts in tandem. Notably, separating the functions required to be executed within the smart contract and allocating a portion of them to the user’s account enhances overall efficiency. The corresponding batch processing isn’t limited to user operations but also extends to fee payments.
The user experience is markedly improved when employing an AA account as opposed to an EOA. While a series of interconnected contracts work harmoniously to support the functionality of an AA account, users perceive it as effortlessly accessible as popular Web2 Apps (e.g., shopping, and banking). Complex technical jargon is relegated to the backend, and this will spare regular users from unnecessary cognitive load. The user interface offers a friendly entry point.
B. AA Opportunities
Ease accessibility to Web3. Account abstraction not only streamlines the interaction with DApps but also significantly enhances the user experience within Web3. By embracing AA, users gain the ability to tailor their accounts to operate exclusively under specific conditions, which significantly differs from previous solutions that rely on complicated invocation across functions or contracts [32]. Users are empowered with a greater degree of control over their customized programming functions. For instance, unlike the traditional multi-sig setup, where the conditions for executing transactions are relatively standardized, account abstraction allows for a more personalized set of conditions. This adaptability ensures that the operations are only executed when predetermined criteria are met, such as a predefined number of signatories.
Promoting Layer-2 (L2). The fundamental L2 projects revolve around alleviating the substantial computational load on L1 chains. As a result, a significant focus of various L2 solutions lies in streamlining the intricate processing logic inherent in DApps. This optimization not only reduces the overall gas cost but also enriches the user experience through the introduction of extended functionalities. To realize this goal, numerous L2 projects have embraced the notion of incorporating account abstraction, marking a pivotal step toward achieving their mission. Notable examples [7] include zkSync, which seamlessly integrates the IAccount interface, and StarkNet, with the wellregarded platform Argent. Similarly, Optimistic rollups also witness the integration of customized APIs.