The shift from externally owned accounts (EOA) to smart contract accounts (SCAs) is gaining momentum and is already supported by many core entrepreneurs, including Vitalik. Despite this, the adoption of SCA has not been as widespread as that of EOA. Key issues include the impact of the bear market, the difficulty of migrating EOA to SCA, signature issues, high gas costs, and most critically, development challenges.

The most significant 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, it is also an important challenge to ensure security while being upgradable and composable.

The emergence of modular account abstraction is a niche in the AA trend, an innovative approach that separates smart accounts from their custom features. The goal was to create a modular structure to develop wallets with multiple features, security, and seamless integration. In the future, modular account abstraction will enable a free smart contract account “app store”, allowing wallets and dApps to focus on improving the user experience rather than having to spend too much effort building features.

Account Abstraction in Brief (AA)

Traditional EOA brings many challenges to people’s exposure to blockchain, such as seed phrases, gas fees, cross-chain operations, and multiple transactions.

Account abstraction leverages smart contract accounts to allow programmable validation and ution. This means that users will be able to approve a series of transactions at once, rather than having to sign and broadcast each transaction. Account abstraction can also enable more features such as improved user experience (e.g., gas abstraction and session keys), reduced costs (e.g., bulk transactions), and improved security (e.g., social recovery, multi-signature). Currently, there are two ways to abstract accounts:

· Protocol layer: Some protocols natively provide native account abstraction support, ZKSync transactions use a single mempool and transaction flow to support AA, both from EOA and SCA follow the same process, while Starknet has removed EOA, all accounts are SCA, and they have native smart contract wallets like Argent.

· Contract layer: For Ethereum and similar L2s, ERC4337 introduced a separate mempool to support AA without changing the consensus layer. Places like Stackup, Alchemy, Etherspot, Biconomy, Candide, and Plimico are building bundler infrastructure, while things like Safe, Zerodev, Etherspot, and Biconomy are building bundlers and SDKs.

The dilemma of adopting SCA

The topic of account abstraction (AA) has been discussed since 2015 and has been further advanced to the spotlight this year by ERC 4337. However, the number of deployed smart contract accounts is still nowhere near as low as EOA.

Let’s delve into this dilemma:

1. The impact of a bear market

Despite AA’s advantages such as seamless login and gas abstraction, in the current bear market, where all users are educated EOA users and there aren’t many new users, there is no incentive for dApps and wallets to adopt SCA. Even so, some of the leading dApps are gradually adopting AA, such as Cyberconnect, which drove around 360,000 UserOps (AA transactions) in just one month by introducing their AA system and gas-less solution.

2. Migration barriers

For wallets and apps that have already accumulated users and assets, it remains a challenge to migrate assets safely and conveniently. However, a scheme like EIP-7377 allows EOA to initiate a one-time migration transaction.

3. Signature issues

The smart contract itself cannot sign messages because it does not have a private key like EOA. Attempts like ERC1271 make this possible, but message signing doesn’t work until the first transaction, which in turn poses a challenge for wallets deployed with counterfactuals. ERC-6492, proposed by Ambire, is the backwards compatible successor to ERC-1271 and may be able to solve the previous problem.

4. Gas cost

The higher cost of deploying, simulating, and executing SCA compared to standard EOA is also a barrier to adoption. However, some tests have been conducted, such as separating account creation from user actions, eliminating “salt” associated with an account, and more.

5. Engineering problems

The ERC-4337 team has built an eth-infinitism repo that provides a base implementation for developers. However, as developers scale to more granular and specific features for different use cases, integration and decoding face more challenges. In this article, we’ll dive into engineering challenges.

Solve engineering challenges with modular smart contract accounts

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

· Fragmentation: Features can now be enabled in a variety of ways, whether through a specific SCA or through a standalone plug-in system. Each platform and service provider follows its own standards, prompting developers to decide which platforms and service providers to support. This can lead to potential platform (vendor) lock-in or redundant work.

· Security: While decoupling accounts and functions brings the benefit of flexibility, it can also exacerbate security concerns. Because all features may be reviewed together, the lack of an independent assessment may increase the risk of account vulnerabilities.

· Upgradeability: As your account grows, it’s important to maintain the ability to add, replace, or remove features, and each update that redeploys existing features introduces complexity.

To address these issues, we need upgradable contracts to ensure safe and efficient upgrades, reusable cores to improve overall development efficiency, and standardized interfaces to ensure a smooth transition between different frontends.

These terms converge on a common concept: building a modular account abstraction architecture (Modular AA).

Modular account abstraction is a subdivision of the broader AA development that envisions the modularization of smart accounts to provide customized services to users and enable developers to seamlessly enhance functionality with minimal constraints.

However, establishing and promoting new standards in any industry is a huge challenge. Until everyone accepts the same standard, many different solutions may emerge in the initial phase. It’s encouraging to see that those working to refine and promote account abstraction, whether it’s the 4337 SDK, wallets, infrastructure teams, or protocol layer designers, are working together to accelerate this process.

Modular structure: master accounts and modules

How the account invokes the module to implement the function

Delegate call and proxy contract

External and delegated calls:

About delegate calls

While a “delegated call” is similar to a “call”, it is not executed in the context of the target contract, but in the context of the current state of the calling contract. This means that any state change made by the target contract will change the storage of the calling contract.

Proxy contracts and delegate calls

**To achieve a composable and upgradable structure, a basic concept of “agency contract” needs to be introduced. **

Proxy contract: A normal contract stores its logic and state, and cannot be updated after deployment. The proxy contract is deployed to another contract using a delegate call. Implement the function by reference to execute it in the current state of the proxy contract.

Use case: While the proxy contract remains the same, you can deploy a new implementation behind the broker. Proxy contracts are upgradeable and less expensive to deploy and maintain on public blockchains.

Safe architecture

Safe 架构

WHAT IS SAFE: Safe is the leading modular smart account infrastructure designed to provide battle-tested security and flexibility, and it enables developers to create diverse applications and wallets. Many teams are building apps on top of (or inspired by) Safe. For example, Biconomy extended Safe with native 4337 and 1/1 multisig when it launched its smart contract account. Having witnessed the deployment of over 164,000 contracts and locked in over $30.7 billion in value, Safe is undoubtedly a leader in its space.

The structure of Safe includes a secure account contract, a singleton contract, and a module contract. **

Proxy contract: Stateful

The secure account is a proxy contract because the delegated call is a singleton contract. A security account contains variables where the owner, threshold, and implementation address are all set as agents, and their state is defined based on these.

单例合约（singleton contract）：Integration Hub（无状态）

The singleton contract serves Safe accounts and defines different module contract integrations, including Plugin, Hook, Function Handler, and Signature Validator.

Modules: Custom Logic and Functions

Module contracts are powerful. Plugins as modular types can define different functions such as payment flows, recovery mechanisms, and session keys, and can act as a bridge between Web2 and Web3 by fetching off-chain data. Other modules, such as Hooks and Function Handlers as security guards, can respond to any command.

Changes after adopting Safe:

Upgradeable contracts: Whenever a new plugin is introduced, a new singleton needs to be deployed. The user retains the autonomy to upgrade Safe to the desired singleton version.

Composable, reusable modules: The modular nature of plugins enables developers to develop features independently. They are free to choose and combine these plugins according to their use case, resulting in a highly customizable approach.

ERC-2535 Diamond 代理

About ERC2535, Diamond Agent:

ERC2535 standardized Diamond model, a modular smart contract system that can be upgraded/scaled after deployment with virtually no size limitations. Currently, many teams such as Zerodev’s Kernel and Soul Wallet’s experiments have been inspired by the Diamond structure.

What is the Diamond Structure:**

Diamond Contract: Primary Proxy Contract (Stateful) Diamond is a proxy contract that uses a delegate call method to call a function from its implementation.

Module/Plugin/Facet Contract: Custom Logic and Functionality (Stateless) A module or so-called Facet is a stateless contract that can deploy its functionality to one or more Diamonds. They are separate, independent contracts that can share intrinsic functions, libraries, and state variables.

Changes with Diamond:

Upgradeable Contracts: Diamond provides a systematic way to isolate different plugins and connect them together, share data between them, and also add/replace/remove any plugin directly using the diamondCut feature. 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, dramatically reducing deployment costs.

The difference between Safe and Diamond:

There are a lot of similarities between the Safe and Diamond architectures, both of which rely on their core proxy contracts and reference logical contracts for upgradeability and modularity.

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

· Flexibility: With a new plugin enabled, 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.

· Secure: Currently used in both 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 across multiple module contracts-plugins. As a result, it is possible for a malicious plugin to overwrite another plugin, introducing the risk of storage conflicts and compromising the integrity of the proxy.

· Cost: In the Diamond approach, flexibility and security come together. This increases the cost, and every time a new plugin is added, it needs to be fully audited. The key is to ensure that these plugins don’t interfere with each other’s functionality, a purpose that is challenging, especially for small and medium-sized businesses struggling to maintain high security standards.

The “Safe Smart Account Method” and the “Diamond Method” are examples of different structures involving agents and modules. Balancing flexibility and security is critical, and these two approaches will continue to evolve and complement each other in the future.

Module Order: Validator, Executor and Hook

Let’s discuss this further by introducing ERC6900, a Diamond-inspired standard from Alchemy’s team that is tailored specifically for ERC-4337. It solves the challenges of smart account modularity by providing a common interface and coordinates the work between plugin and wallet developers.

When it comes to the transaction process of AA, there are three main processes: validation, execution, and pegging. As we discussed earlier, these steps can all be managed by using the proxy account call module. While different projects may use different names, it’s important to grasp the underlying logic of similarity.

Function names in different designs

Validator: Ensures the authenticity and permissions of the account caller.

Execution (UTOR): Execute any custom logic that the account allows.

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

It is important to separate the modules according to different logics. The standardized approach should specify how to write validation, execution, and pegging functions for smart contract accounts. Whether it’s Safe or ERC6900, standardization helps reduce the need for unique development efforts specific to certain implementations or ecosystems and prevents vendor lock-in.

Module discovery and security

How to find and validate modules in an open way: One solution that is being developed involves creating an area that allows users to discover verifiable modules, which can be called a “registry”. The registry functions like an “app store” and aims to foster a simplified but thriving modular marketplace.

Safe{Core} 协议

The Safe{Core} protocol is an open-source, interoperable protocol for smart contract accounts designed to enhance accessibility for a wide range of vendors and developers while maintaining strong security through well-defined standards and rules.

· Accounts: In the Safe{Core} protocol, the concept of accounts is flexible and not tied to a specific implementation. This allows different account service providers to get involved.

· Manager: The manager acts as a coordinator between accounts, registries, and modules. It also takes care of security as a licensing layer.

· Registry: The registry defines security attributes and enforces module standards such as ERC6900 to create an open “app store” environment for discoverability and security.

· Modules: Modules handle functionality and have a variety of initial types, including plugins, hooks, signature validators, and function handlers. Developers can get involved as long as they meet the established criteria.

Rhinestone 设计

The process unfolds as follows:

· Create a schema: A schema provides a predefined data structure. People can tailor it to fit their specific use case.

· Create modules based on the schema: The smart contract registered as a module gets the bytecode and selects the schema ID, and the data is stored in the registry.

· Obtain attestation of the module: The prover/auditor can provide proof of the module based on the architecture. These attestations can include a unique identifier (UID) and references to other attestations used for the link. They can propagate across chains and verify that the target chain meets certain thresholds.

· Implement complex logic with a resolver: The parser (optional) comes into play. They can be called during module creation, attestation establishment, and revocation. These parsers allow developers to integrate complex and diverse logic while maintaining proof structures.

User-friendly query access: Query provides a way for users to access security information from the front end.

While the model is still in its early stages, it has the potential to establish standards in a decentralized and collaborative way. The registry enables developers to register their modules, auditors to verify their security, wallets to integrate, and enables users to easily find modules and verify their attestation information. Several future uses could be:

· Attestor: A trusted entity like Safe can work with Rhinestone as a prover for internal modules. At the same time, independent certifiers can also join.

· Module developer: With the formation of an open marketplace, it is possible for module developers to monetize their work through a registry.

· Users: Participating through a user-friendly interface, such as a wallet or dApp, allows users to check module information and delegate trust to different provers.

The concept of a “module registry” opens up ways for plugin and module developers to monetize. It could further pave the way for a “module market”. Some aspects may be overseen by the Safe team, while others may manifest as a decentralized marketplace that invites everyone to contribute and provides a transparent audit trail. Incorporating this avoids vendor lock-in and supports the expansion of the EVM by adding an enhanced user experience that appeals to a wider audience.

While these methods guarantee the security of individual modules, smart contract accounts are not foolproof when it comes to broader security. It can be a challenge to combine with compliance modules and prove that they don’t have storage conflicts, which highlights the importance of wallets or AA infrastructure in addressing such issues.

Summary

By leveraging a modular smart contract account stack, wallet providers and dApps can be freed from the complexities of technical maintenance. At the same time, external module developers have the opportunity to provide personalized professional services. However, challenges that need to be addressed include striking a balance between flexibility and security, pushing for modular standards, and implementing standardized interfaces that allow users to easily upgrade and modify their smart accounts.

In addition, Modular Smart Contract Accounts (SCAs) are only a small part of the adoption puzzle. To realize the full potential of SCA, Layer 2 solutions are needed to provide additional protocol layer support, such as robust bundler infrastructure and peer-to-peer memory pools, a more cost-effective and viable SCA signing mechanism, cross-chain SCA synchronization and management mechanisms, and the development of user-friendly interfaces.

In the future, there will be more adoption of SCA, but it will also raise some interesting questions: how will traditional miner extractable value (MEV) mechanisms enter the space to build bundlers and capture value once the SCA order flow becomes profitable enough, and how will account abstraction (AA) serve as the base layer for “intent-based” transactions when the infrastructure matures?