Introduction

By utilizing a modularized smart contract account stack, wallet providers and dApps can free themselves from the complexity of technical maintenance.

Written by: Rui S (SevenX Ventures)

Translated by: DeepTech TechFlow

Introduction

The transition from externally owned accounts (EOAs) to smart contract accounts (SCAs) is gaining momentum and has garnered support from many enthusiasts, including Vitalik himself. Despite the excitement it has generated, the adoption of SCAs is not as widespread as EOAs. Key issues include challenges brought about by bear markets, migration concerns, signature issues, gas expenses, and most importantly, engineering challenges.

One of the most significant advantages of account abstraction (AA) is the ability to customize functionality using code. However, a major engineering challenge is the non-interoperability of AA functionalities, which hinders integration and opens the door for vendor lock-in. Additionally, ensuring security while simultaneously upgrading and combining functionalities can be complex.

The emergence of modular account abstraction is a subset of the broader AA movement, and this innovative approach separates smart accounts from their custom functionalities. Its goal is to create a modular structure for developing secure, seamlessly integrated wallets with diverse functionalities. In the future, it could establish a free "app store" for smart contract accounts, allowing wallets and dApps to focus on user experience rather than building functionalities.

Overview of AA

Traditional EOAs introduce many challenges such as seed phrases, gas, cross-chain, and multiple transactions. We never intended to introduce complexity, but in reality, blockchain is not a simple game for the masses.

Account abstraction utilizes smart contract accounts, allowing programmable verification and execution, enabling users to approve a series of transactions at once, rather than signing and broadcasting each transaction individually, and achieving more functionalities. It brings benefits to user experience (e.g., gas abstraction and session keys), cost (e.g., batch transactions), and security (e.g., social recovery, multi-signature). Currently, there are two ways to implement account abstraction:

• Protocol Layer: Some protocols themselves provide native support for account abstraction. ZKsync transactions, whether from EOA or SCA, follow the same process, using a single memory pool and transaction flow to support AA, while Starknet has removed EOAs, and all accounts are SCAs, and they have native smart contract wallets like Argent.

• Contract Layer: For Ethereum and its L2 equivalents, ERC4337 introduced a separate transaction entry to support AA without changing the consensus layer. Projects like Stackup, Alchemy, Etherspot, Biconomy, Candide, and Plimico are building bundling infrastructure, while projects like Safe, Zerodev, Etherspot, and Biconomy are building stacks and SDKs.

Challenges of SCA Adoption

The topic of account abstraction (AA) has been under discussion since 2015 and has been brought into the spotlight this year by ERC4337. However, the number of deployed smart contract accounts still lags far behind EOAs.

Let's delve into this dilemma:

1. Impact of Bear Markets:

Despite the benefits introduced by AA such as seamless login and gas abstraction, the current bear market is mainly composed of educated EOA users, not new users, which does not provide incentives for dApps and wallets. Nevertheless, some leading applications are gradually adopting AA, for example, Cyberconnect, which introduced their AA system and gasless solution, driving approximately 360,000 UserOps (AA transactions) in just one month.

2. Migration Barriers:

For wallets and applications that have accumulated users and assets, securely and conveniently migrating assets remains a challenge. However, initiatives like EIP-7377 allow EOAs to initiate one-time migration transactions.

3. Signature Issues:

Smart contracts themselves naturally cannot sign messages as they do not have private keys like EOAs. Efforts like ERC1271 make this signature possible, but it does not work before the first transaction, posing a challenge for wallets using retroactive deployment. ERC-6492 proposed by Ambire is a backward-compatible successor to ERC-1271, which may solve the previous issue.

4. Gas Expenses:

Deploying, simulating, and executing SCAs incur higher costs compared to standard EOAs. This has become a barrier to adoption. However, some tests have been conducted, such as decoupling account creation from user operations and considering eliminating account salts and existence checks to reduce these costs.

5. Engineering Challenges:

The ERC-4337 team has established the eth-infinitism repository, providing a foundational implementation for developers. However, as we branch out into more detailed or specific functionalities in different use cases, integration and decoding become challenging.

In this article, we will delve into the fifth issue: engineering challenges.

Modular Smart Contract Accounts to Address Engineering Challenges

Further elaboration on the engineering challenges is as follows:

• Fragmentation: Various functionalities are now enabled in different ways, whether through specific SCAs or independent plugin systems. Each follows its own standards, forcing developers to decide which platforms to support. This may lead to platform lock-in or duplicated efforts.

• Security: While the flexibility between accounts and functionalities brings advantages, it may also exacerbate security issues. Functionalities may be collectively audited, but the lack of independent assessment may increase the risk of account vulnerabilities.

• Upgradability: With the evolution of functionalities, retaining the ability to add, replace, or remove functionalities is crucial. Redeploying existing functionalities with each update introduces complexity.

To address these issues, we need upgradable contracts to ensure secure and efficient upgrades, reusable cores to improve overall development efficiency, and standardized interfaces to ensure smooth transitions of contract accounts across different front-ends.

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

Modular AA is a subset area within the broader AA movement, envisioning the modularization of smart accounts to provide customized services for users and enable developers to seamlessly enhance functionalities with minimal restrictions.

However, in any industry, establishing and promoting new standards is a huge challenge. There may be many different solutions in the initial stages before a major solution is universally accepted. Nevertheless, it is encouraging that whether it's the 4337 SDK, wallet developers, infrastructure teams, or protocol designers, they are all working together to accelerate this process.

Modular Structure: Main Account and Modules

Delegate Calls and Proxy Contracts

External calls and delegate calls:

While delegatecall is similar to call, it does not execute the target contract in its own context but rather in the context of the calling contract. This means that any state changes made by the target contract are applied to the storage of the calling contract.

To achieve a composable and upgradable structure, a fundamental knowledge called "proxy contracts" is needed.

1. Proxy Contracts: Regular contracts store their logic and state and cannot be updated after deployment. Proxy contracts use delegate calls to another contract. By referencing the implementation, it executes in the current state of the proxy contract.

2. Use Case: While the proxy contract remains unchanged, you can deploy a new implementation behind the proxy. Proxy contracts are used for upgradability and have lower deployment and maintenance costs on public blockchains.

Secure Architecture

Safe is a leading modular smart account infrastructure designed to provide battle-tested security and flexibility, enabling developers to create diverse applications and wallets. It is worth noting that many teams are building on top of Safe or are inspired by it. Biconomy is launching its accounts by extending native 4337 and 1/1 multisig on Safe. Safe has deployed over 164,000 contracts and locked over 30.7 billion in value, undoubtedly making it the preferred choice in this field.

Structure of Safe

1. Safe Account Contract: Main Proxy Contract (with state)

The Safe account is a proxy contract as it uses delegate calls to a singleton contract. It includes owners, thresholds, and implementation addresses, all set as variables of the proxy, defining its state.

2. Singleton Contract: Integration Hub (stateless)

The singleton serves the Safe account and integrates and defines various integrations, including plugins, hooks, function processors, and signature validators.

3. Module Contracts: Custom Logic and Functionalities

Modules are very powerful. As a modular type, plugins can define different functionalities such as payment flows, recovery mechanisms, and session keys, and bridge between Web2 and Web3 by fetching off-chain data. Other modules, such as hooks for security protection, and function processors for responding to any instruction.

What Happens When We Adopt Safe

1. Upgradable Contracts:

Whenever a new plugin is introduced, a new singleton needs to be deployed. Users retain the autonomy to upgrade Safe to the desired singleton version to align with their preferences and requirements.

2. Composable and Reusable Modules:

The modular nature of plugins allows developers to independently build functionalities. They can then freely select and combine these plugins according to their use cases, promoting a highly customizable approach.

ERC-2535 Diamond Proxy

About ERC2535 and Diamond Proxy

ERC2535 standardizes the Diamond proxy, which is a modular smart contract system that allows for upgrades/extensions post-deployment with almost no size limit. Many teams have been inspired by it so far, such as Zerodev's Kernel and Soul Wallet's experiment.

What is the Diamond Structure

1. Diamond Contract: Main Proxy Contract (with state) Diamond is a proxy contract that calls functions from its implementation via delegatecall.

2. Modules/Plugins/Facets Contracts: Custom Logic and Functionalities (stateless) Modules or so-called facets are stateless contracts that can deploy their functionalities to one or multiple Diamonds. They are independent contracts that can share internal functions, libraries, and state variables.

What Happens When We Adopt Diamond

1. Upgradable Contracts: Diamond provides a systematic way to isolate different plugins and link them together, and directly add/replace/remove any plugin via the diamondCut function. There is no limit to the number of plugins that can be added to Diamond over time.

2. Modular and Reusable Plugins: A deployed plugin can be used by any number of Diamonds, significantly reducing deployment costs.

Differences Between Safe Smart Accounts and Diamond Approach

There are many similarities between the Safe and Diamond architectures, both relying on proxy contracts as the core and referencing logic contracts to achieve upgradability and modularity.

However, the main difference lies in the handling of logic contracts. Here is a more detailed explanation:

1. Flexibility: In the case of enabling new plugins, Safe requires redeploying its singleton contract to implement changes in its proxy. In contrast, Diamond achieves this directly through its diamondCut function in its proxy. This difference in approach means that Safe retains a higher degree of control, while Diamond introduces greater flexibility and modularity.

2. Security: Currently, both structures use delegatecall, which allows external code to manipulate the storage of the main contract. In the Safe architecture, delegatecall points to a single logic contract, while Diamond uses delegatecall across multiple module contracts (plugins). Therefore, malicious plugins could potentially overwrite another plugin, introducing the risk of storage conflicts that could compromise the integrity of the proxy.

3. Cost: The inherent flexibility in the Diamond approach comes with added security concerns. This increases the cost factor, requiring comprehensive audits with each new plugin added. The key is to ensure that these plugins do not interfere with each other's functionalities, which is a challenge for small to medium-sized enterprises striving to maintain strong security standards.

The "Safe Smart Account Method" and the "Diamond Method" are examples of different structures involving proxies and modules. Balancing flexibility and security is crucial, and these approaches may complement each other in the future.

Module Order: Validator, Executor, and Hook

Let's expand our discussion by introducing the standardized ERC6900 proposed by the Alchemy team, which is inspired by Diamond and specifically tailored for ERC-4337. It addresses the modular challenges in smart accounts by providing common interfaces and coordinating work between plugins and wallet developers.

When it comes to the transaction process of AA, there are three main processes: validation, execution, and hook. As we discussed earlier, these steps can be managed by using module calls through the proxy account. While different projects may use different names, grasping the similar underlying logic is important.

• Validation: Ensuring the authenticity and permissions of the caller to the account.

• Execution: Executing any custom logic allowed by the account.

• Hook: Acting as a module that runs before or after another function. It can modify state or cause the entire call to be reverted.

It is crucial to separate modules based on different logics. A standardized approach should specify how the validation, execution, and hook functions of smart contract accounts should be written. Whether it's Safe or ERC6900, standardization helps reduce the need for unique development work for specific implementations or ecosystems and prevents vendor lock-in.

Module Discovery and Security

A burgeoning solution involves creating a place for users to discover verifiable modules, which we can call a "registry." This registry is akin to an "app store," aimed at fostering a simplified yet thriving modular market.

Safe{Core} Protocol

The Safe{Core} protocol is an open-source, interoperable smart contract account protocol designed to increase accessibility for various vendors and developers while maintaining strong security through defined standards and rules.

• Accounts: In the Safe{Core} protocol, the concept of accounts is flexible and not limited by specific implementations. This allows various account service providers to participate.

• Managers: Managers act as coordinators between accounts, registries, and modules. They also handle security as a permission layer.

• Registry: The registry defines security properties and enforces module standards such as ERC6900, aiming to create an open "app store" environment for discovery and security.

• Modules: Modules handle functionalities and are provided in various initial types, including plugins, hooks, signature validators, and function processors. Developers can contribute to them as long as they meet the established standards.

Rhinestone Design

The unfolding of this process is as follows:

• Creation of Pattern Definitions: Patterns serve as predefined data structures for proofs. Enterprises can customize patterns based on their specific use cases.

• Module Creation Based on Patterns: Smart contracts are registered as modules, obtaining bytecode and selecting a pattern ID. This data is then stored in the registry.

• Obtaining Proofs for Modules: Provers/auditors can provide proofs for modules based on patterns. These proofs can include unique identifiers (UID) and references to other proofs for linking. They can be propagated on-chain and verify if specific thresholds are met on the target chain.

• Implementing Complex Logic Using Resolvers: Resolvers are optional and set within patterns. They can be invoked during module creation, proof establishment, and revocation processes. These resolvers allow developers to incorporate complex and diverse logic while maintaining the structure of proofs.

• User-Friendly Query Access: Queries provide a way for users to access security information from the front end. EIPs can be found here.

While this pattern is still in its early stages, it has the potential to establish a standard in a decentralized and collaborative manner. Their registry allows developers to register their modules, auditors to verify their security, and wallets to integrate and enable users to easily find modules and verify their proof information. In the future, it may have the following uses:

• Provers: Trusted entities, such as Safe, can act as provers for internal modules in collaboration with Rhinestone. Meanwhile, independent provers can also join in.

• Module Developers: With the formation of an open market, module developers have the potential to commercialize their work through the registry.

• Users: Through user-friendly interfaces, such as wallets or dApps, users can view module information and delegate trust to different provers.

The concept of a "module registry" provides opportunities for plugin and module developers to profit. It may also pave the way for a "module market." Some aspects may be overseen by the Safe team, while others may manifest as a decentralized market, inviting contributions from everyone and providing transparent audit records. By adopting this approach, we can avoid vendor lock-in and attract broader support for EVM expansion by providing a better user experience.

While these methods ensure the security of individual modules, the overall security of smart contract accounts is not entirely reliable. Combining legitimate modules and proving they have no storage conflicts may be a challenge, emphasizing the importance of wallets or AA infrastructure in addressing such issues.

Conclusion

By utilizing a modularized smart contract account stack, wallet providers and dApps can free themselves from the complexity of technical maintenance. At the same time, external module developers have the opportunity to provide professional services tailored to individual needs. However, challenges to be addressed include striking a balance between flexibility and security, driving progress in modular standards, and implementing standardized interfaces to enable users to easily upgrade and modify their smart accounts.

However, modular smart contract accounts (SCA) are just a piece of the adoption puzzle. To fully realize the potential of SCAs, support from protocol layers in second-layer solutions, robust bundling infrastructure and peer-to-peer memory pools, more cost-effective and feasible SCA signature mechanisms, cross-chain SCA synchronization and management, and the development of user-friendly interfaces are also needed.

We envision a future of broad participation, sparking some interesting questions: How will the traditional miner extractable value (MEV) mechanism enter the field once SCA order flow becomes profitable? How can account abstraction (AA) become the foundational layer for "intent-based" transactions as infrastructure matures? Stay tuned, as this field is constantly evolving and changing.

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