SevenX Ventures: Modular Smart Contract Account Architecture and Challenges

Original Title: "Modular Smart Contract Account Architecture and Challenges"
Original Author: Rui, Investor of SevenX Ventures
Original Compiler: Luccy, Joyce, BlockBeats

Editor's Note:

The development momentum of Smart Contract Accounts (SCA) is strong, supported by many core entrepreneurs including Vitalik. However, the adoption of SCA still faces numerous challenges. The advantage of Account Abstraction (AA) lies in the ability to customize functionality using code, but its non-interoperability brings integration and vendor lock-in issues. Modular Account Abstraction aims to create a modular structure for developing wallets with diverse functionalities, security, and seamless integration.

SevenX Ventures investor Rui pointed out five major challenges in adopting SCA: the impact of the bear market, migration difficulties, signature issues, high gas costs, and engineering challenges, with further discussion on the engineering challenges. Additionally, after analyzing the architecture of modular smart contract accounts, it was noted that modular SCA is only a small part of the adoption problem.

To fully leverage the potential of SCA, Layer 2 solutions need to provide additional protocol layer support, robust bundler infrastructure and peer-to-peer memory pools, more cost-effective and feasible SCA signature mechanisms, cross-chain SCA synchronization and management mechanisms, as well as the development of user-friendly interfaces.

In the future, as current challenges are gradually resolved, more people will adopt SCA. What will happen next? Rui also raised some interesting questions about this. BlockBeats compiles the original text as follows:

The shift from Externally Owned Accounts (EOA) to Smart Contract Accounts (SCA) is gaining momentum and has already received support from many core entrepreneurs, including Vitalik. Nevertheless, the adoption of SCA is not as widespread as that of EOA. The main issues include the impact of the bear market, the difficulty of migrating from EOA to SCA, signature issues, high gas costs, and, most critically, engineering challenges.

The most significant advantage of Account Abstraction (AA) is the ability to customize functionality using code. However, the non-interoperability of AA functionalities presents a major challenge, as this decentralization can hinder AA integration and strengthen vendor lock-in. Additionally, ensuring security while maintaining upgradability and composability is also an important challenge.

The emergence of modular account abstraction is a niche within the trend of AA development. This innovative approach separates smart accounts from their customized functionalities. Its goal is to create a modular structure to develop wallets with diverse functionalities, security, and seamless integration. In the future, modular account abstraction could 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 functionalities.

Overview of Account Abstraction (AA)

In the process of engaging with blockchain, traditional EOA has brought many challenges, such as mnemonic phrases, gas fees, cross-chain operations, and multiple transactions.

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

· Protocol Layer: Some protocols provide native account abstraction support. ZKSync transactions use a single memory pool and transaction process to support AA; whether from EOA or SCA, they follow the same process. Starknet has removed EOA, and all accounts are SCA, with native 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. Teams like Stackup, Alchemy, Etherspot, Biconomy, Candide, and Plimico are building bundler infrastructure, while Safe, Zerodev, Etherspot, and Biconomy are developing bundlers and SDKs.

Challenges in Adopting SCA

Since 2015, the topic of Account Abstraction (AA) has been discussed and has gained further attention this year with ERC 4337. However, the number of deployed smart contract accounts still lags far behind EOA.

Let’s delve into this dilemma:

1. Impact of the Bear Market

Despite the advantages of AA, such as seamless login and gas abstraction, in the current bear market, all users are educated EOA users, with not many new users, so dApps and wallets lack the motivation to adopt SCA. Nonetheless, some leading dApps are gradually adopting AA; for example, Cyberconnect introduced their AA system and gasless solution, driving around 360,000 UserOps (AA transactions) in just one month.

2. Migration Barriers

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

3. Signature Issues

Smart contracts themselves cannot sign messages because they do not have private keys like EOA. Attempts like ERC1271 have made this possible, but message signatures do not work before the first transaction, which poses challenges for wallets using counterfactual deployments. The ERC-6492 proposed by Ambire is a backward-compatible successor to ERC-1271 and may address the previous issues.

4. Gas Costs

Deploying, simulating, and executing SCA incurs higher costs compared to standard EOA, which has become one of the barriers to adoption. However, some tests have been conducted, such as separating account creation from user operations and eliminating the "salt" associated with a specific account.

5. Engineering Challenges

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

Addressing Engineering Challenges through Modular Smart Contract Accounts

Engineering challenges can be further articulated in three aspects: fragmentation, security, and upgradability.

· Fragmentation: Functionality can now be enabled in various ways, whether through specific SCAs or independent plugin systems. Each platform and service provider follows its own standards, prompting developers to decide which platforms and service providers to support. This may lead to potential platform (vendor) lock-in or redundant work.

· Security: While decoupling accounts and functionalities brings the advantage of flexibility, it may also exacerbate security issues. All functionalities may be audited together, and the lack of independent assessments could increase the risk of account vulnerabilities.

· Upgradability: As accounts evolve, maintaining 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 front-ends.

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

Modular account abstraction is a niche within the broader development of AA, envisioning the modularization of smart accounts to provide customized services to users and enabling developers to seamlessly enhance functionalities with minimal constraints.

However, establishing and promoting new standards in any industry is a significant challenge. Before everyone adopts the same standard, many different solutions may emerge in the initial stages. It is encouraging to see those dedicated to refining and promoting account abstraction, whether they are 4337 SDKs, wallets, infrastructure teams, or protocol layer designers, all working together to accelerate this process.

Modular Structure: Main Account and Modules

How accounts call modules to implement functionalities

Delegate Call and Proxy Contract

External calls and delegate calls:

About Delegate Call

While "delegate call" is similar to "call," it executes in the context of the calling contract's current state rather than the target contract's context. This means any state changes made by the target contract will alter the storage of the calling contract.

Proxy Contract and Delegate Call

To achieve a composable and upgradable structure, a foundational concept of "proxy contract" needs to be introduced.

Proxy Contract: A regular contract stores its logic and state and cannot be updated after deployment. A proxy contract uses delegate call to deploy to another contract. By referencing the implementation function, it executes it in the current state of the proxy contract.

Use Case: While the proxy contract remains unchanged, you can deploy new implementations behind the proxy. The proxy contract enables upgradability and incurs lower deployment and maintenance costs on public blockchains.

Safe Architecture

Safe Architecture

What is Safe: Safe is a leading modular smart account infrastructure designed to provide battle-tested security and flexibility, enabling developers to create diverse applications and wallets. Many teams are building applications on or inspired by Safe. For example, Biconomy expanded Safe when launching its smart contract account by using native 4337 and 1/1 multi-signature. Safe has witnessed the deployment of over 164,000 contracts and locked over $30.7 billion in value, undoubtedly making it a leader in the field.

The structure of Safe includes secure account contracts, singleton contracts, and module contracts.

Secure Account Contract (proxy contract): Main Proxy Contract (Stateful)

The secure account is a proxy contract because the delegate call is a singleton contract. The secure account contains variables for owner, threshold, and implementation address set to the proxy, defining its state based on these.

Singleton Contract (singleton contract): Integration Hub (Stateless)

The singleton contract serves the Safe account and defines the integration of different module contracts, including Plugin, Hook, Function Handler, and Signature Validator.

Module Contracts: Custom Logic and Functionality

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

Changes Brought by Adopting Safe:

Upgradable Contracts: A new singleton must be deployed whenever a new plugin is introduced. Users retain the autonomy to upgrade Safe to the desired singleton version.

Composable and Reusable Modules: The modular nature of plugins allows developers to independently develop functionalities. They can freely choose and combine these plugins based on their use cases, resulting in a highly customizable approach.

ERC-2535 Diamond Proxy

About ERC2535, Diamond Proxy:

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

What is the Diamond Structure:

Diamond Contract: Main Proxy Contract (Stateful) Diamond is a proxy contract that uses delegate call to invoke functions from its implementation.

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

Changes Brought by Adopting Diamond:

Upgradable Contracts: Diamond provides a systematic way to isolate different plugins and connect them, sharing data among them, and allows for direct addition/replacement/deletion of any plugin using the diamondCut function. Over time, there will be no limit to the number of plugins that can be added to the Diamond.

Modular and Reusable Plugins: Deployed plugins 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 Safe and Diamond architectures; both rely on their core proxy contracts and reference logic contracts to achieve upgradability and modularity.

The main differences lie in how logic contracts are handled. Specifically:

· Flexibility: In the case of 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. This difference in approach means that Safe retains a higher degree of control, while Diamond introduces enhanced flexibility and modularity.

· Security: Currently, both structures allow external code to manipulate the storage of the main contract. In the Safe architecture, delegate calls point to a single logic contract, while Diamond uses delegate calls across multiple module contracts-plugins. Therefore, malicious plugins could potentially override another plugin, introducing the risk of storage conflicts and compromising the integrity of the proxy.

· Cost: In the Diamond approach, flexibility comes with security risks. This increases costs, as comprehensive audits are required each time a new plugin is added. The key is to ensure that these plugins do not interfere with each other's functionalities, which is challenging, especially for small and medium-sized enterprises striving to maintain high 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 will continue to evolve and complement each other in the future.

Module Sequence: Validator, Executor, and Hook

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

Regarding the transaction flow of AA, there are three main processes: validation, execution, and hooking. As discussed earlier, these steps can be managed by using proxy accounts to call modules. While different projects may use different names, it is important to grasp the similar underlying logic.

Function Names in Different Designs

Validation (Validator): Ensures the authenticity and authorization of the account caller.

Execution (Executor): Executes any custom logic allowed by the account.

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

Separating modules based on different logics is crucial. A standardized approach 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 discover and verify modules in an open manner: An ongoing solution involves creating an area that allows users to discover verifiable modules, which can be referred to as a "registry." The functionality of this registry is similar to an "app store," aimed at nurturing a simplified yet thriving modular market.

Safe{Core} Protocol

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

· Accounts: In the Safe{Core} protocol, the concept of accounts 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 a permission layer responsible for security.

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

· Modules: Modules handle functionalities and come in various initial types, including plugins, hooks, signature validators, and function handlers. Developers can participate as long as they meet the established standards.

Rhinestone Design

The process unfolds as follows:

· Create Schema Definition: The schema provides predefined data structures. It can be customized to fit specific use cases.

· Create Modules Based on Schema: Smart contracts registered as modules obtain bytecode and select schema IDs, and the data is stored in the registry.

· Obtain Attestation for Modules: Attestors/auditors can provide attestations for modules based on the schema. These attestations may include unique identifiers (UID) and references to other proofs used for linking. They can propagate across chains and verify whether the target chain meets specific thresholds.

· Implement Complex Logic Using Resolvers: Resolvers (optional setup) come into play. They can be called during module creation, proof establishment, and revocation. These resolvers allow developers to integrate complex and diverse logic while maintaining proof structures.

User-friendly Query Access: Queries provide users with a way to access security information from the front end.

Although this model is still in its early stages, it has the potential to establish standards in a decentralized and collaborative manner. The registry enables developers to register their modules, auditors to verify their security, wallets to integrate, and users to easily find modules and validate their proof information. Future potential uses may include:

· Attestors: Trusted entities like Safe can collaborate with Rhinestone to serve as attestors for internal modules. Independent attestors can also join.

· Module Developers: As an open market forms, module developers may have the opportunity to monetize their work through the registry.

· Users: By participating through user-friendly interfaces (such as wallets or dApps), users can check module information and delegate trust to different attestors.

The concept of a "module registry" opens up monetization avenues for plugin and module developers. It could further pave the way for a "module marketplace." Certain 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. Integrating this can avoid vendor lock-in and support EVM expansion by adding enhanced user experiences that can attract a broader audience.

While these methods can ensure the security of individual modules, smart contract accounts are not foolproof in broader security terms. Combining modules and proving they do not have storage conflicts can be a challenge, highlighting 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. At the same time, external module developers have the opportunity to provide personalized professional services. However, challenges that need to be addressed include balancing flexibility and security, promoting modular standards, and implementing standardized interfaces that allow users to easily upgrade and modify their smart accounts.

Moreover, modular smart contract accounts (SCA) are only a small part of the adoption problem. To fully realize the potential of SCA, Layer 2 solutions need to provide additional protocol layer support, such as robust bundler infrastructure and peer-to-peer memory pools, more cost-effective and feasible SCA signature mechanisms, cross-chain SCA synchronization and management mechanisms, as well as the development of user-friendly interfaces.

In the future, more people will adopt SCA, but it will also raise some interesting questions: once the order flow of SCA becomes sufficiently lucrative, how will traditional miner-extracted value (MEV) mechanisms enter the field to build bundlers and extract value? How will account abstraction (AA) serve as a foundational layer for "intent-based" transactions once the infrastructure matures? Let’s wait and see.