In-depth Analysis of Modular Smart Contract Account Architecture and Challenges

Exploring the Complexities and Obstacles of Modular Smart Contract Account Architecture A Comprehensive Analysis

Author: Rui, Investor of SevenX Ventures

Translation: Luccy, Joyce, BlockBeats

Editor’s note: The development momentum of Smart Contract Account (SCA) has received support from many core entrepreneurs, including Vitalik. However, the adoption of SCA still faces many challenges. The advantage of Account Abstraction (AA) lies in the ability to customize functions using code, but its lack of interoperability brings integration and vendor lock-in issues. Modular Account Abstraction aims to create a modular structure to develop wallets with diverse, secure, and seamless integration capabilities.

SevenX Ventures investor Rui points out the five major challenges faced by SCA adoption, namely bear market influence, migration difficulty, signature issues, high Gas costs, and engineering problems. Furthermore, after analyzing the architecture of modular smart contract accounts, it is pointed out that modular SCA is only a small part of addressing the adoption challenges.

• Cryptocurrency Market Weekly Summary (11.11-11.17) Continuous net inflow of funds, BTC ecosystem remains hot
• Weekly Preview | Blur may initiate the second season airdrop; Avalanche (AVAX) will unlock tokens worth nearly $200 million on November 24th
• a16z’s in-depth analysis of the current development, business boundaries, and regulatory innovations of Web3

In order to fully unleash the potential of SCA, Layer 2 solutions are needed to provide additional protocol layer support, powerful bundler infrastructure and peer-to-peer memory pool, cost-effective and feasible SCA signature mechanisms, cross-chain SCA synchronization and management mechanisms, as well as developing user-friendly interfaces, etc.

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

The transition from Externally Owned Account (EOA) to Smart Contract Account (SCA) is gaining momentum and has received support from many core entrepreneurs, including Vitalik. However, the adoption of SCA is not as widespread as EOA. The main problems include the impact of the bear market, the difficulty of migration from EOA to SCA, signature issues, high Gas costs, and the most critical of all, development challenges.

The most significant advantage of Account Abstraction (AA) is the ability to customize functions using code. However, the lack of interoperability of AA functions presents a major challenge. This decentralization hinders AA integration and strengthens vendor lock-in. In addition, ensuring security while allowing for upgradability and composability is also an important challenge.

The emergence of modular account abstraction is a niche area in the development trend of AA, and this innovative approach can separate the smart account from its custom functions. Its goal is to create a modular structure to develop wallets with diverse functionality, security, and seamless integration. In the future, modular account abstraction can achieve a free-marketplace for smart contract accounts, allowing wallets and dApps to focus on improving user experience without having to spend too much effort on building functionality.

A Brief Description of Account Abstraction (AA)

In the process of people’s exposure to blockchain, traditional EOA has brought many challenges, such as mnemonic words, gas fees, cross-chain operations, and multiple transactions.

Account abstraction utilizes smart contract accounts, allowing for programmable validation and execution. This means that users will be able to approve a series of transactions all at once, without needing to sign and broadcast for each transaction. Account abstraction can also enable additional functionalities, such as improving user experience (e.g., gas abstraction and session keys), reducing costs (e.g., batch transactions), and enhancing 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 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, 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. Companies like Stackup, Alchemy, Etherspot, Biconomy, Candide, and Plimico are building bundler infrastructure, while companies like Safe, Zerodev, Etherspot, and Biconomy are building bundlers and SDKs.

Challenges Facing the Adoption of SCA

The topic of Account Abstraction (AA) has been discussed since 2015 and has been further propelled into people’s sight this year by ERC 4337. However, the number of deployed smart contract accounts still lags far behind EOA.

Let’s delve into this dilemma:

1. Impact of Bear Market

Despite the advantages AA has, such as seamless login and gas abstraction, in the current bear market, all users are educated EOA users and there aren’t many new users. Therefore, dApps and wallets have little incentive to adopt SCA. Even so, some leading dApps are gradually adopting AA, for example, Cyberconnect has driven approximately 360,000 UserOps (AA transactions) in just one month by introducing their AA system and gasless solution.

2. Migration Obstacles

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

3. Signature Issues

Smart contracts themselves are unable to sign messages as they don’t have private keys like EOAs. Attempts like ERC1271 make it possible, but message signatures don’t work before the first transaction, presenting a challenge for wallets using retroactive deployment. ERC-6492 proposed by Ambire is a backward compatible successor to ERC-1271 and may be able to resolve the previous issue.

4. Gas Costs

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

5. Engineering Challenges

The ERC-4337 team has established the eth-infinitism repo, providing a basic implementation for developers. However, as developers extend to more detailed and specific features for different use cases, integration and decoding will face more challenges. In this article, we will delve into the engineering challenges.

Solving Engineering Challenges Through Modular Smart Contract Accounts

Engineering challenges can further be described in three aspects: fragmentation, security, and scalability.

· Fragmentation: There are currently multiple ways to enable functionality, whether through specific SCAs or independent plugin systems. Each platform and service provider follows their 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 functionality brings advantages in flexibility, it may also exacerbate security issues. Since all functionalities may be audited together, lack of independent evaluation may increase the risk of account vulnerabilities.

· Scalability: As accounts evolve, maintaining the ability to add, replace, or remove functionalities is crucial, and every update requiring re-deployment of existing functionalities introduces complexity.

To address these issues, we need upgradable contracts to ensure secure and efficient upgrades, reusable core to enhance 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 account abstraction is a subdomain in the broad development of AAs, envisioning modularization of smart contract accounts to provide customized services for users and enable developers to seamlessly enhance functionalities with minimal constraints.

However, establishing and promoting new standards in any industry is a great challenge. Before everyone accepts the same standard, there may be many different solutions in the initial stages. It’s encouraging to see the efforts of those who are dedicated to improving and promoting account abstraction, whether it’s the 4337 SDK, wallets, infrastructure teams, or protocol designers, as they all work together to expedite this process.

Modular Structure: Main Account and Modules

How to call modules to implement functionality in an account

Delegate call and proxy contract

External call and delegate call:

About delegate call

Although “delegate call” is similar to “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 changes made by the target contract will change the storage of the calling contract.

Proxy contract and delegate call

To achieve composability and upgradability, introduce the concept of a “proxy contract”.

Proxy contract: A regular contract stores its logic and state and cannot be updated after deployment. However, a proxy contract is deployed to another contract using delegate call. It executes the function in the context of the proxy contract’s current state.

Use case: Although the proxy contract remains unchanged, you can deploy new implementations behind the proxy. The proxy contract enables upgradability and reduces the deployment and maintenance costs on the public blockchain.

Safe architecture

Safe architecture

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

The structure of Safe includes the security account contract, singleton contract, and module contract.

Security account contract (proxy contract): Main proxy contract (Stateful)

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

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 contract: Custom logic and functionality

Module contracts are powerful. As modular types, plugins can define different functionalities such as payment flows, recovery mechanisms, and session keys, and can act as bridges between off-chain data and Web2 and Web3. Other modules, like the security protection hooks and function handlers, can respond to any instruction.

Changes brought by using Safe:

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.

Composable and reusable modules: The modular nature of plugins allows developers to independently develop functions. They can freely choose and combine these plugins based on their use cases, creating highly customizable approaches.

ERC-2535 Diamond proxy

About ERC2535, Diamond proxy:

The standardized ERC2535 Diamond model is a modular smart contract system that can be upgraded/extended after deployment with almost 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 (with state). Diamond is a proxy contract that uses delegation calls to call functions from its implementation.

Module/plugin/Facet contract: Custom logic and functionality (stateless). Modules, or so-called Facets, are stateless contracts that can deploy their functionality to one or multiple Diamonds. They are standalone 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, share data between them, and directly add/replace/delete any plugin using the diamondCut function. Over time, there will be no limit to the number of plugins that can be added to a Diamond.

Modular and reusable plugins: Deployed plugins can be used by any number of Diamonds, greatly reducing deployment costs.

Differences between Safe smart accounts and the Diamond approach:

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

The main difference lies in the handling of logic contracts. Specifically:

· Flexibility: In the case of enabling new plugins, Safe requires re-deploying its singleton contracts 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 Safe retains a higher degree of control, while Diamond introduces enhanced flexibility and modularity.

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

· Cost: In the Diamond approach, flexibility and security risks coexist. This increases costs, as a comprehensive audit is required every time a new plugin is added. The key is to ensure that these plugins do not interfere with each other’s functionality, which is challenging, especially for small to medium-sized enterprises that strive to maintain high security standards.

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

Module Order: Validator, Executor, and Hook

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

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

Function names in different designs

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

Executor: Executes any custom logic allowed by the account.

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

It is crucial to separate modules based on different logic. Standardization should dictate how to write the validation, execution, and hook functions of smart contract accounts. Whether it’s Safe or ERC6900, standardization helps reduce the need for specific development work tied to certain implementations or ecosystems and prevents vendor lock-in.

Module Discovery and Security

How to find and verify modules in an open manner: One advancing solution involves creating an area that allows users to discover verifiable modules, which can be called a “registry.” The functionality of this registry is similar to that of an “app store” and aims to foster a streamlined yet thriving modular marketplace.

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 well-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.

· Managers: Managers act as coordinators between accounts, registries, and modules. They also serve as the security layer responsible for permissions.

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

· Modules: Modules handle functionalities and have various initial types, including plugins, hooks, signature validators, and function handlers. Developers can participate as long as they comply with established standards.

Rhinestone Design

The process unfolds as follows:

· Schema Creation: The schema provides predefined data structures. People can customize it to fit their specific use cases.

· Module Creation based on Schema: Smart contracts registered as modules obtain bytecode and select a schema ID, and the data is stored in the registry.

· Obtaining Module Attestation: Attestors/auditors can provide attestations for modules based on the schema. These attestations can include a unique identifier (UID) and references to other attestations used for linkage. They can be propagated and verified across chains to ensure specific thresholds are met.

· Resolver for Complex Logic Implementation: Resolvers (optional) start to come into play. They can be invoked during module creation, attestation establishment, and revocation. These resolvers allow developers to integrate complex and diverse logic while maintaining the proof structure.

User-Friendly Query Access: Queries provide a way for users to access secure information from the frontend.

Although this pattern 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 them, and users to easily find modules and verify their attestation information. Some potential future use cases could be:

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

· Module Developer: With the formation of open markets, module developers may be able to monetize their work through a registry.

· Users: Users can participate through user-friendly interfaces (such as wallets or dApps), where they can check module information and delegate trust to different validators.

The concept of a “module registry” opens up avenues for profit for plug-in and module developers. It can further pave the way for a “module market.” Certain aspects may be supervised by the Safe team, while others may manifest as a decentralized market, inviting everyone to contribute and providing transparent audit records. Integrating this can avoid vendor lock-in and support the scalability of EVM by adding enhancements that appeal to a wider audience.

While these methods can ensure the security of individual modules, smart contract accounts are not foolproof in terms of broader security. Combining with compliant modules and proving they do not have storage conflicts may be a challenge, highlighting the importance of wallets or AA infrastructure in addressing such issues.

Conclusion

By leveraging modular smart contract account stacks, wallet providers and dApps can free themselves from the complexities of technical maintenance. At the same time, external module developers have the opportunity to offer personalized professional services. However, challenges to be addressed include striking a balance between flexibility and security, driving 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 just a small part of the puzzle. To fully unleash the potential of SCAs, Layer 2 solutions are needed to provide additional protocol layer support, such as robust bundler infrastructure and peer-to-peer memory pools, cost-effective and feasible SCA signing mechanisms, cross-chain SCA synchronization and management mechanisms, and the development of user-friendly interfaces.

In the future, more people will adopt SCAs, but it will also raise some interesting questions: Once SCA order flow becomes profitable enough, how will the traditional miner extractable value (MEV) mechanism enter the field to build bundlers and capture value? When the infrastructure matures, how will Account Abstraction (AA) serve as the foundational layer for “intent-based” transactions? Let’s wait and see.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!