Original Title: "Modular Smart Contract Account Architecture and Challenges"

Original Author: Rui, Investor of SevenX Ventures

Original Translation: Luccy, Joyce, BlockBeats

The momentum of the transition from External Owned Accounts (EOAs) to Smart Contract Accounts (SCAs) is strong and has received support from many core entrepreneurs, including Vitalik. However, the adoption of SCAs is not as widespread as EOAs. The main issues include the impact of the bear market, difficulty in migrating from EOA to SCA, signature problems, high Gas costs, and the most critical development challenges.

The most prominent advantage of Account Abstraction (AA) is the ability to customize functionality using code. However, the non-interoperability of AA functionality presents a major challenge, as this fragmentation hinders AA integration and reinforces vendor lock-in. In addition, ensuring security while maintaining upgradability and composability is also an important challenge.

The emergence of modular account abstraction is a subfield in the development trend of the blockchain industry. This innovative approach separates the intelligent account from its customized functions. The goal is to create a modular structure to develop a wallet with diverse functions, security, and seamless integration. In the future, modular account abstraction can realize a free smart contract account "app store", allowing wallets and dApps to focus on improving user experience without spending too much effort on building functions.

Brief Introduction to Account Abstraction (AA)

During the process of people's engagement with blockchain, traditional EOA has brought many challenges, such as mnemonic phrases, gas fees, cross-chain operations, and multiple transactions.

The account abstraction utilizes smart contract accounts, allowing for programmable validation and execution. This means that users will be able to approve a series of transactions at once, without the need to sign and broadcast for each individual transaction. Account abstraction can also enable additional functionalities, such as improving user experience (such as gas abstraction and session keys), reducing costs (such as batch transactions), and enhancing security (such as social recovery and multi-signature). Currently, there are two ways to implement account abstraction:

· Protocol Layer: Some protocols themselves provide native account abstraction support, and ZKSync transactions use a single memory pool and transaction process to support AA; whether from EOA or SCA, they follow the same process, while Starknet has removed EOA, and all accounts are SCA, and they have local smart contract wallets like Argent.

· Contract Layer: For Ethereum and similar L2s, ERC4337 introduces a separate mempool to support AA without changing the consensus layer. Companies such as Stackup, Alchemy, Etherspot, Biconomy, Candide, and Plimico are building bundler infrastructure, while companies such as Safe, Zerodev, Etherspot, and Biconomy are building bundlers and SDKs.

Challenges Faced by SCA Implementation

Since 2015, the topic of Account Abstraction (AA) has been discussed and further brought into people's attention this year by ERC 4337. However, the number of deployed smart contract accounts is still far less than EOA.

Let's delve into this dilemma:

1. The Impact of Bear Market

Despite the advantages of features such as seamless login and Gas abstraction, in the current bear market, all users are educated EOA users and there are not many new users, so dApps and wallets have no incentive to adopt SCA. Nevertheless, some leading dApps are gradually adopting AA, such as Cyberconnect, which has driven about 360,000 UserOps (AA transactions) in just one month by introducing their AA system and Gas-free solution.

2、Migration Obstacles

For wallets and applications that have already accumulated users and assets, securely and conveniently migrating assets is still a challenge. However, solutions like EIP-7377 allow for one-time migration transactions to be initiated by EOA.

3、Signature Issue

Smart contracts themselves cannot sign messages because they do not have a private key like EOA. Attempts like ERC1271 make it possible, but message signing does not work before the first transaction, which poses a challenge for wallets that use counterfactual deployment. ERC-6492 proposed by Ambire is a backward-compatible successor to ERC-1271 and may be able to solve the previous problem.

4、Gas Cost

Compared with standard EOA, deploying, simulating, and executing SCA will incur higher costs, which has become one of the adoption barriers. However, some tests have been conducted, such as separating account creation from user operations and eliminating "salt" related to a certain account.

5、Engineering Challenges

The ERC-4337 team has established the eth-infinitism repo, providing a basic implementation for developers. However, as developers expand to more detailed and specific features for different use cases, integration and decoding will face more challenges. In this article, we will delve into engineering difficulties.

通过模块化智能合约账户来解决工程难题

Translation:

Using modular smart contract accounts to solve engineering problems

The engineering challenges can be further elaborated into three aspects: fragmentation, security, and upgradability.

· Fragmentation: Now, functionality can be enabled through various means, whether it's through specific SCAs or through independent plugin systems. Each platform and service provider follows their own standards, which prompts developers to decide which platforms and service providers to support. This may lead to potential platform (vendor) lock-in or redundant work.

· Security: Although decoupling accounts and functions brings the advantage of flexibility, it may also make security issues more serious. Because all functions may be audited together, the lack of independent evaluation may increase the risk of account vulnerabilities.

Module/Plugin/Facet Contract: Custom Logic and Functionality (Stateless) Modules or so-called Facets are stateless contracts whose functionality can be deployed to one or more Diamonds. They are separate, independent contracts that can share internal functions, libraries, and state variables.

Changes brought by using Diamond:

Upgradable contract: Diamond provides a systematic way to isolate different plugins and connect them together, share data between them, and use the diamondCut function to directly add/replace/delete any plugin. Over time, there will be no limit to the number of plugins that can be added to Diamond.

Modular and reusable plugins: Deployed plugins can be used by any number of Diamonds, greatly reducing deployment costs.

Safe Intelligent Account vs. Diamond Method: Differences

There are many similarities between the Safe and Diamond architectures, both of which rely on their core proxy contracts and reference logic contracts to achieve upgradability and modularity.

The main difference between the two lies in the handling of logical contracts. Specifically:

· Flexibility: When enabling new plugins, Safe needs to redeploy its singleton contract to implement changes in its proxy. In contrast, Diamond achieves this directly through the diamondCut function in its proxy contract. The difference in approach means that Safe retains a higher degree of control, while Diamond introduces enhanced flexibility and modularity.

· Security: Currently used in two structures, it allows external code to manipulate the storage of the main contract. In the Safe architecture, delegate calls point to a single logical contract, while Diamond uses delegate calls in multiple module contracts-plugins. Therefore, malicious plugins may overwrite another plugin, introducing the risk of storage conflicts and compromising the integrity of the agent.

· Cost: In the Diamond method, flexibility and security risks coexist, which increases the cost. A comprehensive review is required every time a new plugin is added. The key is to ensure that these plugins do not interfere with each other's functions, which is challenging, especially for small and medium-sized enterprises that strive to maintain high security standards.

Safe Intelligent Account Method" and "Diamond Method" are examples of different structures involving agents and modules. Balancing flexibility and security is crucial, and these two methods will continue to evolve and complement each other in the future.

Module Order: Validator, Executor, and Hook

Let's further discuss by introducing ERC6900, a standard proposed by the Alchemy team and inspired by Diamond, specifically tailored for ERC-4337. It solves the challenge of modularizing smart accounts by providing a universal interface and coordinating the work between plugin and wallet developers.

Speaking of the transaction process of AA, there are mainly three steps: verification, execution, and hooking. As we discussed earlier, these steps can all be managed by using proxy accounts to call modules. Although different projects may use different names, it is important to understand the similar underlying logic.

Function Names in Different Designs

验证 (Validator): Ensures the authenticity and permissions of the account caller.

Executor: Executes any custom logic allowed by the account.

Hook: serves as a module that runs before or after another function. It can modify the state or undo the entire call.

According to different logics, it is crucial to separate modules. Standardized methods should specify how to write validation, execution, and hook functions for smart contract accounts. Whether it is Safe or ERC6900, standardization helps reduce the need for unique development work specific to certain implementations or ecosystems and prevents vendor lock-in.

Module Discovery and Security

How to find and verify modules in an open way: an advancing solution involves creating an area that allows users to discover verifiable modules, which can be called a "registry". The function of this registry is similar to an "application store", aimed at cultivating a simplified but thriving modular market.

Safe{Core} Protocol

Safe{Core} protocol is an open-source, interoperable protocol for smart contract accounts, aimed at enhancing accessibility for various vendors and developers, while maintaining strong security through well-defined standards and rules.

· Account: In the Safe{Core} protocol, the concept of account is flexible and not constrained by specific implementations. This allows different account service providers to participate.

· Manager: The manager acts as a coordinator between accounts, registries, and modules. It also serves as the licensing layer responsible for security.

· Registry: The registry defines security attributes and implements ERC6900 and other module standards, aiming to create an open "application store" environment for discoverability and security.

· Module: The module processes functions and has various initial types, including plugins, hooks, signature validators, and function handlers. As long as developers comply with established standards, they can participate in it.

Rhinestone Design

The process unfolds as follows:

· Create schema definition: The schema provides pre-defined data structures that can be customized to fit specific use cases.

· Create modules based on architecture: Smart contracts registered as modules obtain bytecode and select architecture IDs, and the data is stored in the registry.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia