In-depth discussion on modular smart contract account design: solving technical problems in implementation

Original title: Modular Smart Contract Account Architecture and Challenges

Original author: Rui S, SevenX Ventures

Original compilation: Deep Chao TechFlow

introduce

The shift from Externally Owned Accounts (EOA) to Smart Contract Accounts (SCAs) is booming and is supported by many enthusiasts, including Vitalik himself. Despite the excitement, SCA adoption has not been as widespread as EOA. Key issues include bear market challenges, migration concerns, signature issues, gas overhead, and most critically, engineering challenges.

One of the most important advantages of Account Abstraction (AA) is the ability to customize functionality using code. However, a major engineering challenge is the non-interoperability of AA functionality, and this fragmentation hinders integration and opens the door to vendor lock-in. Additionally, ensuring security when upgrading and combining features simultaneously can be complex.

Modular account abstraction emerged as a subset of the broader AA movement, an innovative approach to decoupling smart accounts from their custom functionality. The goal is to create a modular structure to develop secure, seamlessly integrated wallets with diverse functionality. In the future, it can implement a free smart contract account "app store" so that wallets and dApps no longer focus on building functions, but focus on user experience.

AA Brief Description

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

Account abstraction leverages smart contract accounts, allowing programmable verification and execution, enabling users to approve a series of transactions at once, rather than having to sign and broadcast each transaction, and enable more functionality. It brings benefits to user experience (e.g., Gas abstraction and session keys), cost (e.g., batched transactions), and security (e.g., social recovery, multi-signature). Currently, there are two ways to implement account abstraction:

• Protocol layer: Some protocols themselves provide local account abstraction support. ZKsync transactions, whether from EOA or SCA, follow the same process, using a single memory pool and transaction process to support AA, while Starknet has removed EOA and all accounts Both are SCA, and they have native smart contract wallets like Argent.
• Contract layer: For Ethereum and its equivalent L2, ERC 4337 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.

Dilemmas of SCA adoption

The topic of Account Abstraction (AA) has been under discussion since 2015 and was thrust into the spotlight this year by ERC 4337. However, the number of deployed smart contract accounts is still far less than that of EOA.

Let’s dig deeper into this dilemma:

• Impact of bear market:

Although AA introduced benefits such as seamless login and Gas abstraction, the people currently experiencing the bear market are mainly composed of educated EOA users rather than new users, so there is no incentive for dApps and wallets. Even so, some leading applications are gradually adopting AA, such as Cyberconnect, which drove about 360,000 UserOps (AA transactions) in just one month by introducing their AA system and Gas-free solution.

• Barriers to migration:

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

*Signature issue:

The smart contract itself cannot naturally sign messages because it does not have a private key like EOA. Efforts like ERC 1271 make such signing possible, but message signing does not work until the first transaction, which poses a challenge for wallets using counterfactual deployments. ERC-6492 proposed by Ambire is a backward-compatible successor to ERC-1271 and may solve the previous problems.

*Gas overhead:

Deploying, simulating, and executing SCA incurs higher costs than standard EOA. This becomes a barrier to adoption. However, there have been some tests, such as decoupling account creation from user actions and considering eliminating account salts and existence checks, to reduce these costs.

• Engineering problems:

The ERC-4337 team has established the eth-infinitiism repository to provide developers with basic implementations. However, as we branch out into more granular or specific functionality in different use cases, integration and decoding becomes challenging.

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

Modular smart contract accounts to solve engineering problems

A further explanation of the engineering challenges is as follows:

• Fragmentation: Various features are now enabled in different ways, whether through specific SCAs or independent plug-in systems. Each follows its own standards, forcing developers to decide which platforms to support. This can lead to platform lock-in or duplication of efforts.
• Security: While flexibility between accounts and features brings advantages, it can also exacerbate security concerns. Features may be audited collectively, but the lack of independent assessment may increase the risk of account breaches.
• Upgradability: As functionality evolves, it is important to retain the ability to add, replace, or remove functionality. Redeploying existing functionality with every update introduces complexity.

To deal with these problems, we need upgradable contracts to ensure safe and efficient upgrades, reusable cores to improve overall development efficiency, and standardized interfaces to ensure that contract accounts can transition smoothly between different front ends.

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 tailor services to users and enable developers to seamlessly enhance functionality with minimal restrictions.

However, establishing and promoting new standards is a huge challenge in any industry. Many different solutions may emerge in the initial stages before everyone accepts the main solution. However, it is encouraging that both the 4337 SDK, wallet developers, infrastructure teams, and protocol designers are working together to speed up this process.

Modular structure: main account and modules

Delegate call and proxy contract

External calls and delegate calls:

Although delegatecall is similar to call, instead of executing the target contract in its own context, it executes the target contract in the current state of the calling contract. This means that any state changes made by the target contract will be applied to the calling contract’s storage.

In order to implement composable and upgradable structures, a basic knowledge called "agency contracts" is required.

• Agent contract: Ordinary contracts store their logic and status and cannot be updated after deployment. A proxy contract uses a delegate to call another contract. Implement a function by reference, which executes in the current state of the agent contract.
• Use case: While the proxy contract remains the same, you can deploy new implementations behind the proxy. Proxy contracts are used for upgradability and are cheaper to deploy and maintain on public blockchains.

Security Architecture

Safe is a leading modular smart account infrastructure designed to provide battle-proven security and flexibility, enabling developers to create diverse applications and wallets. It's worth noting that many teams are building on top of or inspired by Safe. Biconomy launches its account by extending native 4337 and 1/1 multi-signature on Safe. With over 164,000 contracts deployed and over $30.7 billion in value locked, Safe is undoubtedly the top choice in this space.

Safe structure

• Safe account contract: main agent contract (stateful)

The Safe account is a proxy contract because it delegatecalls a singleton contract. The Safe account contains the owner, threshold, and implementation address, which are set as variables for the agent, thus defining its state.

• Singleton contract: integration center (stateless)

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

• Module contract: custom logic and functions

Modules are very powerful. As a modular type, plug-ins can define different functions such as payment flows, recovery mechanisms, and session keys, and serve as a cross-chain bridge between Web2 and Web3 by obtaining off-chain data. Other modules such as Hooks act as safety guards, and function handlers respond to any instructions.

What happens when we adopt Safe

• Upgradeable 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 match their preferences and requirements.

• Composable and reusable modules:

The modular nature of plugins enables developers to build functionality independently. They are then free to select and combine these plug-ins according to their own use cases, facilitating a highly customizable approach.

ERC-2535 Diamond Agent

About ERC 2535 and Diamond Agent

ERC 2535 standardizes the Diamond Agent, a modular smart contract system that can be upgraded/expanded after deployment and has virtually no size restrictions. 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?

• Diamond Contract: Main Agent Contract (Stateful) Diamond is a proxy contract that calls functions from its implementation through delegate calls.
• Modules/plugins/faceted contracts: Custom logic and functionality (stateless) A module or so-called facet is a stateless contract that can deploy its functionality into one or more Diamonds. They are independent contracts that can share internal functions, libraries, and state variables.

What happens when we use Diamond

• Upgradeable contracts: Diamond provides a systematic way to isolate different plug-ins and connect them together, and add/replace/remove any plug-in directly through the diamondCut function. There is no limit to the number of plug-ins that can be added to Diamond over time.
• Modular and reusable plug-ins: A deployed plug-in can be used by any number of Diamonds, thus greatly reducing deployment costs.

Difference between Safe smart account and Diamond method

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

However, the main difference lies in the handling of logical contracts. Here are more detailed instructions:

• Flexibility: With new plugins enabled, Safe needs to redeploy its singleton contract to implement changes in its agent. In contrast, Diamond does this directly through the diamondCut function in its delegate. This difference in approach means that Safe retains a higher degree of control, while Diamond introduces greater flexibility and modularity.
• Security: Currently, delegatecall is used in both structures, which allows external code to manipulate the main contract's storage. In the Safe architecture, delegatecall points to a single logical contract, while Diamond uses delegatecall between multiple module contracts (plug-ins). Therefore, it is possible for a malicious plug-in to overwrite another plug-in, thereby introducing the risk of storage conflicts that may compromise the integrity of the agent.
• Cost: The flexibility inherent in the Diamond approach comes with increased security concerns. This adds a cost factor and requires a full audit every time a new plugin is added. The key is ensuring these plugins don't interfere with each other's functionality, which can be a challenge for small and medium-sized businesses trying to maintain strong security standards.

The "Safe Smart Account Method" and the "Diamond Method" are examples of different structures involving agents and modules. How to balance flexibility and security is critical, and the two approaches are likely to complement each other in the future.

Module order: validator, executor and Hook

Let us expand our discussion by introducing the standard proposed by the Alchemy team, ERC 6900, which was inspired by Diamond and specifically adapted for ERC-4337. It solves the modularity challenge in smart accounts by providing a common interface and coordinating the work between plugin and wallet developers.

When it comes to AA's transaction process, there are three main processes: Verification, Execution, and Hook. As we discussed earlier, these steps can be managed by calling the module using a proxy account. Although different projects may use different names, it is important to capture a similar underlying logic.

• Verification: Ensure the authenticity and authority of the caller's account.
• Execution: Execute any custom logic allowed by the account. *Hook: as a module that runs before or after another function. It can modify state or cause the entire call to be undone.

Separating modules based on different logic is crucial. A standardized approach should specify how smart contract account verification, execution, and Hook functions should be written. Whether it's Safe or ERC 6900, standardization helps reduce the need for unique development efforts for a specific implementation or ecosystem and prevents vendor lock-in.

Module discovery and security

One solution that is booming involves creating a place that allows users to discover verifiable modules, what we might call a "registry." This registry is similar to an "app store" designed to facilitate a simplified but thriving modular marketplace.

Safe{Core}Protocol

Safe{Core} Protocol is an open source, interoperable smart contract account protocol designed to increase accessibility for a variety of vendors and developers through clearly defined standards and rules, while maintaining strong security.

• Account: In the Safe{Core} protocol, the concept of account is flexible and not restricted by a specific implementation. 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, acting as a permissions layer.
• Registry: The registry defines security attributes and enforces module standards such as ERC 6900, aiming to create an open "app store" environment for discovery and security.
• Modules: Modules handle functionality and are provided in various initial types, including plugins, Hooks, signature validators, and function handlers. Developers can contribute to it as long as they meet established standards.

Rhinestone Design

The process unfolds as follows:

• Create schema definition: schema serves as a predefined data structure for proof. Enterprises can customize the pattern based on their specific use cases.
• Create a module based on a pattern: the smart contract is registered as a module, gets the bytecode and selects the pattern ID. This data is then stored in the registry.
• Obtain proofs of modules: Certifiers/auditors can provide proofs for modules based on the schema. These certificates can include unique identifiers (UIDs) and references to other certificates for linking. They can be propagated on-chain and verify that certain thresholds are met on the target chain.
• Use parsers to implement complex logic: parsers are optionally set in the pattern. They can be called during module creation, proof establishment, and teardown. These parsers allow developers to incorporate complex and diverse logic while maintaining the structure of the proof.
• User-friendly query access: Query provides a way for users to access security information from the front end. EIP can be found here.

Although this model is still in its early stages, it has the potential to establish a standard in a decentralized and collaborative manner. Their registry enables developers to register their modules, auditors to verify their security, wallets to integrate and users to easily find modules and verify their attestation information. There may be the following uses in the future:

• Certifier: Trusted entities, such as Safe, can cooperate with Rhinestone as certifiers for internal modules. At the same time, independent provers can also join in.
• Module developers: With the formation of an open market, it is possible for module developers 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 profitable opportunities for plugin and module developers. It could also pave the way for a "module market." Some of these aspects may be overseen by the Safe team, while others may manifest themselves as decentralized marketplaces that invite everyone to contribute and provide a transparent audit trail. By taking this approach, we can avoid vendor lock-in and support the expansion of EVM by providing a better user experience that appeals to a wider audience.

Although 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 solving such problems.

Summarize

By leveraging a modular smart contract account stack, wallet providers and dApps can escape 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 that need to be addressed include striking a balance between flexibility and security, driving the advancement of modular standards, and implementing standardized interfaces that enable users to easily upgrade and modify their Smart Accounts.

However, modular smart contract accounts (SCA) are only one piece of the adoption puzzle. To fully realize the potential of SCA, protocol layer support from second-layer solutions is also required, as well as powerful bundler infrastructure and peer-to-peer memory pools, more cost-effective and feasible SCA signing mechanisms, cross-chain SCA synchronization and management , as well as developing user-friendly interfaces.

We envision a future with broad participation, which raises some interesting questions: Once the SCA order process becomes profitable enough, how will traditional miner extractable value (MEV) mechanisms enter the space, build bundlers, and capture value? When the infrastructure matures, how can Account Abstraction (AA) become the base layer for "intent-based" transactions? Please stay tuned as this area is constantly evolving.