Modular Smart Contract Account Design: Solving Practical Technical Challenges

Original Title: Modular Smart Contract Account Architecture and Challenges

Original Author: Rui S, SevenX Ventures

Compiled by: Deep Tide TechFlow

Introduction

The transition from Externally Owned Accounts (EOA) to Smart Contract Accounts (SCA) is thriving and has garnered support from many enthusiasts, including Vitalik himself. Despite the excitement, the adoption of SCA is not as widespread as that of EOA. Key issues include challenges brought by bear markets, migration concerns, signature issues, Gas costs, and the most critical 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 features, which hinders integration and opens the door to 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, which aims to decouple smart accounts from their customized functionalities. The goal is to create a modular structure for developing secure, seamlessly integrated wallets with diverse functionalities. In the future, it could enable a free smart contract account "app store," allowing wallets and dApps to focus on user experience rather than building functionalities.

AA Overview

Traditional EOA introduces many challenges, such as seed phrases, Gas, cross-chain transactions, and multiple transactions. We never intended to introduce complexity, but the fact is that blockchain is not a simple game for the masses.

Account abstraction leverages smart contract accounts, allowing programmable validation and execution, enabling users to approve a series of transactions at once instead of signing and broadcasting each transaction, and achieving more functionalities. It brings benefits to user experience (e.g., Gas abstraction and session keys), costs (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 provide native account abstraction support. 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 EOA, making all accounts SCA, and they have native smart contract wallets like Argent.

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

The Dilemma of SCA Adoption

Since 2015, the topic of account abstraction (AA) has been discussed and has been brought to the spotlight this year by ERC4337. However, the number of deployed smart contract accounts still lags far behind EOA.

Let’s delve into this dilemma:

1. Impact of Bear Markets:

Although AA introduces benefits like seamless login and Gas abstraction, the current bear market is primarily composed of educated EOA users rather than new users, resulting in a lack of incentives for dApps and wallets. Nevertheless, some leading applications are gradually adopting AA, such as Cyberconnect, which drove approximately 360,000 UserOps (AA transactions) in just one month by introducing their AA system and Gasless solutions.

2. Migration Barriers:

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

3. Signature Issues:

Smart contracts cannot naturally sign messages as they lack private keys like EOAs. Efforts like ERC1271 make such signatures possible, but message signatures do not work before the first transaction, posing challenges for wallets using counterfactual deployments. The ERC-6492 proposed by Ambire is a backward-compatible successor to ERC-1271 that may address previous issues.

4. Gas Costs:

Deploying, simulating, and executing SCA incurs higher costs compared to standard EOA. This has become a barrier to adoption. However, some tests have been conducted, such as decoupling account creation from user operations and considering the elimination of account salts and existence checks to reduce these costs.

5. Engineering Challenges:

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

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

Modular Smart Contract Accounts to Address Engineering Challenges

Further elaboration on engineering challenges includes:

• 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 can lead to platform lock-in or duplicated efforts.

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

• Upgradability: As functionalities evolve, 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 enhance overall development efficiency, and standardized interfaces to ensure contract accounts can transition smoothly between different frontends.

These terms converge on a common concept: building a Modular Account Abstraction architecture (Modular AA).

Modular AA is a niche within the broader AA movement that envisions modularizing smart accounts to provide customized services to users and enable developers to seamlessly enhance functionalities with minimal restrictions.

However, establishing and promoting new standards is a significant challenge in any industry. Many different solutions may emerge in the initial stages before a consensus on a primary solution is reached. Encouragingly, whether it’s the 4337 SDK, wallet developers, infrastructure teams, or protocol designers, there is a collective effort to accelerate this process.

Modular Structure: Master 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 executes the target contract in the current state of the calling contract. This means any state changes made by the target contract will apply to the storage of the calling contract.

To achieve a composable and upgradable structure, a fundamental concept known as "proxy contracts" is required.

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

2. Use Cases: While proxy contracts remain unchanged, you can deploy new implementations behind the proxy. Proxy contracts are used for upgradability and incur lower deployment and maintenance costs on public blockchains.

Security 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. Notably, many teams are building on or inspired by Safe. Biconomy is launching its account by extending native 4337 and 1/1 multi-signature on Safe. Safe has deployed over 164,000 contracts and locked over $30.7 billion in value, making it undoubtedly the preferred choice in the field.

Structure of Safe

1. Safe Account Contract: Master Proxy Contract (Stateful)

Safe accounts are proxy contracts because they delegate calls to a singleton contract. Safe accounts contain owner, threshold, 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 handlers, and signature validators.

3. Module Contracts: Custom Logic and Functionality

Modules are powerful. As a modular type, plugins can define different functionalities, such as payment flows, recovery mechanisms, and session keys, and act as a cross-chain bridge by fetching off-chain data between Web2 and Web3. Other modules, like hooks, serve as security measures, and function handlers respond to any instructions.

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 meet their preferences and requirements.

2. Composable and Reusable Modules:

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

ERC-2535 Diamond Proxy

About ERC2535 and Diamond Proxy

ERC2535 standardizes the Diamond Proxy, a modular smart contract system that can be upgraded/extended after deployment with virtually no size limitations. So far, many teams have been inspired by it, such as Zerodev's Kernel and Soul Wallet's experiments.

What is the Structure of Diamond

1. Diamond Contract: Master Proxy Contract (Stateful) Diamond is a proxy contract that calls functions from its implementation through delegatecall.

2. Modules/Plugins/Facet Contracts: Custom Logic and Functionality (Stateless) Modules, or so-called facets, are stateless contracts that can deploy their functionalities into one or more 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 connect them, allowing any plugin to be added/replaced/removed directly through 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 an arbitrary number of Diamonds, significantly reducing deployment costs.

Differences Between Safe Smart Accounts and Diamond Approach

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

However, the main difference lies in how logic contracts are handled. Here’s 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 the 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 among multiple module contracts (plugins). Thus, a malicious plugin could potentially overwrite another plugin, introducing the risk of storage conflicts that could compromise the integrity of the proxy.

3. Cost: The inherent flexibility of the Diamond approach comes with increased security concerns. This raises cost factors that require comprehensive audits each time a new plugin is added. The key is to ensure that these plugins do not interfere with each other’s functionalities, which poses a challenge for small to medium enterprises striving to maintain robust security standards.

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

Module Sequence: Validators, Executors, and Hooks

Let’s expand our discussion by introducing the standard ERC6900 proposed by the Alchemy team, inspired by Diamond and specifically tailored for ERC-4337. It addresses the modularity challenges in smart accounts by providing common interfaces and coordinating the work between plugin and wallet developers.

When it comes to the transaction process of AA, there are three main processes: validation, execution, and hooks. As discussed earlier, these steps can be managed by calling modules through proxy accounts. While different projects may use different names, grasping the similar underlying logic is essential.

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

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

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

Separating modules based on different logics is crucial. A standardized approach should dictate 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 targeted at specific implementations or ecosystems and prevents vendor lock-in.

Discovery and Security of Modules

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

Safe{Core} Protocol

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

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

• Manager: The manager acts as a coordinator between accounts, registries, and modules. It is also responsible for security, serving as a permission layer.

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

• Modules: Modules handle functionalities and provide various initial types, including plugins, hooks, signature validators, and function handlers. Developers can contribute as long as they meet established standards.

Rhinestone Design

The unfolding of this process is as follows:

• Creating Schema Definitions: Schemas serve as predefined data structures for proofs. Enterprises can customize schemas based on their specific use cases.

• Creating Modules Based on Schemas: Smart contracts are registered as modules, obtaining bytecode and selecting schema IDs. This data is then stored in the registry.

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

• Implementing Complex Logic with Parsers: Parsers are optional settings within schemas. They can be called during module creation, proof establishment, and revocation processes. These parsers allow developers to incorporate complex and diverse logic while maintaining the proof structure.

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

While this model 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. Future potential uses may include:

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

• Module Developers: With the formation of an open market, module developers may have the opportunity 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 monetization opportunities for plugin and module developers. It may also pave the way for a "module marketplace." Some aspects may be overseen by the Safe team, while others may manifest as a decentralized market, inviting contributions from all and providing transparent audit trails. By adopting this approach, we can avoid vendor lock-in and attract a broader audience to support the expansion of EVM by providing a better user experience.

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

Conclusion

By leveraging a modular smart contract account stack, wallet providers and dApps can free themselves from the complexities of technical maintenance. Meanwhile, external module developers have the opportunity to offer specialized services tailored to individual needs. However, challenges to be addressed include balancing flexibility and security, advancing modular standards, and implementing standardized interfaces that enable users to easily upgrade and modify their smart accounts.

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

We envision a future of widespread participation, raising some intriguing questions: once the SCA order process becomes profitable enough, how will traditional miner extractable value (MEV) mechanisms enter the space, building bundlers and capturing value? As infrastructure matures, how will account abstraction (AA) become the foundational layer for "intention-based" transactions? Stay tuned, as this field continues to evolve.