In-depth exploration of modular smart contract account design: Solving technical challenges in implementation
Original Title: Modular Smart Contract Account Architecture and Challenges
Original Author: Rui S, SevenX Ventures
Original Translation: Deep Tide TechFlow
Introduction
The transition from Externally Owned Accounts (EOA) to Smart Contract Accounts (SCA) is thriving and has gained 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 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 with code. However, a major engineering challenge is the lack of interoperability of AA functionalities, and this fragmentation hinders integration and opens the door for vendor lock-in. Also, 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 offers an innovative approach to separate smart accounts from their customized functionalities. The goal is to create a modular structure to develop secure, seamlessly integrated wallets with diverse functionalities. In the future, it can enable a free "app store" for smart contract accounts, shifting the focus of wallets and dApps from building functionalities to improving user experiences.
AA Overview
Traditional EOAs introduced 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 a simple game for the masses.
Account Abstraction leverages smart contract accounts, allowing for programmable verification and execution, enabling users to approve a series of transactions in a single batch, instead of signing and broadcasting each transaction individually, and achieves more functionalities. It brings benefits in terms of user experience (e.g., gas abstraction and session keys), cost (e.g., batched transactions), and security (e.g., social recovery, multisignature). Currently, there are two ways to implement account abstraction:
Protocol Layer: Some protocols themselves provide support for abstracting local accounts. Whether the ZKsync transactions come from EOA or SCA, they follow the same process, using a single memory pool and transaction process to support AA. On the other hand, Starknet has removed EOA, and all accounts are SCA, and they have local smart contract wallets like Argent.
Contract Layer: For Ethereum and its equivalent L2, ERC 4337 introduced 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
The topic of Account Abstraction (AA) has been discussed since 2015 and has been brought 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 explore this dilemma in-depth:
Impact of Bear Market:
Despite the benefits of AA, such as seamless login and gas abstraction, the people currently experiencing the bear market are primarily educated EOA users rather than new users, so there is no incentive for dApps and wallets. Nonetheless, some leading applications are gradually adopting AA. For example, Cyberconnect's AA system and gas-free solution have driven approximately 360,000 UserOps (AA transactions) in just one month.
Migration Barrier:
For wallets and applications that have accumulated users and assets, securely and conveniently migrating assets is still a challenge. However, initiatives like EIP-7377 allow EOA to initiate one-time migration transactions.
Signature Issue:
The smart contract itself naturally cannot sign messages as it does not have a private key like an EOA. Efforts like ERC 1271 make this kind of signing possible, but message signing does not work until the first transaction, which poses a challenge for wallets that deploy using counterfactual deployment. ERC-6492, proposed by Ambire, is a backward-compatible successor to ERC-1271 that may solve the previous problem.
Gas costs:
Deployment, simulation, and execution of 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 the elimination of account salts and existence checks to reduce these costs.
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 nuanced 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
The further elaboration on engineering challenges is as follows:
Fragmentation: Various functionalities are now enabled in different ways, either through specific SCAs or independent plugin systems. Each follows its own standards, forcing developers to decide on which platforms to support. This may result in platform lock-in or duplicated efforts.
Security: While flexibility between accounts and functionalities brings advantages, it may also exacerbate security issues. Functionalities may undergo collective audits, but the lack of independent assessment may increase the risk of account vulnerabilities.
Scalability: With the evolution of functionalities, the ability to add, replace, or remove functionalities while preserving backwards compatibility becomes crucial. Redeploying existing functionalities with each update introduces complexity.
To address these issues, we need upgradable contracts to ensure secure and efficient upgrades, reusable core components to enhance overall development efficiency, and standardized interfaces to ensure smooth transitions of contract accounts across different frontends.
These terms converge into a common concept: building a Modular AA (Modular Account Abstraction) architecture.
Modularization in AA is a subfield of the broader AA movement, envisioning modularizing smart accounts to provide customized services to users and allowing developers to seamlessly enhance functionality with minimal constraints.
However, establishing and promoting new standards in any industry is a significant challenge. In the initial stages, there may be multiple different solutions before a widely accepted primary solution emerges. Nevertheless, it is encouraging that the 4337 SDK, wallet developers, infrastructure teams, and protocol designers are all working together to expedite this process.
Modular Structure: Main Account and Modules
Delegated Calls and Proxy Contracts
External Calls and Delegated Calls:
While delegatecall is similar to call, it does not execute the target contract in its own context; instead, it executes the target contract in the context of the calling contract. This means that any state changes made by the target contract will be applied to the storage of the calling contract.
To achieve composability and upgradability in the structure, a fundamental concept called "proxy contract" is required.
Proxy Contract: A regular contract stores its logic and state and cannot be updated after deployment. A proxy contract delegates calls (delegatecall) to another contract. By referencing functions, it executes within the context of the proxy contract.
Use Case: While the proxy contract remains unchanged, you can deploy new implementations behind the proxy. Proxy contracts are used for upgradability and have lower deployment and maintenance costs on public blockchains.
Security Architecture
Safe is a leading modular smart account infrastructure designed to provide proven security and flexibility, enabling developers to create diverse applications and wallets. It is worth noting that many teams are building on or inspired by Safe. Biconomy launches its accounts by extending native 4337 and 1/1 multi-signatures on Safe. Safe has deployed over 164,000 contracts and locked over 30.7 billion in value. Safe is undoubtedly the preferred choice in this field.
Safe's Structure
Safe Account Contract: Master Proxy Contract (stateful)
The Safe account is a proxy contract as it delegates calls (delegatecall) to a singleton contract. The Safe account includes owner, thresholds, and implementation address, all set as proxy variables, defining its state.
Singleton Contract: Integration Hub (stateless)
The singleton serves and integrates with the Safe account, defining and integrating different modules, including plugins, hooks, function processors, and signature validators.
Module Contract: Custom Logic and Functionality
The modules are very powerful. As a modular type, plugins can define different functionalities such as payment flows, recovery mechanisms, and session keys, serving as cross-chain bridges between off-chain data as well as Web 2 and Web 3. Other modules, like hooks, serve as security protections, and function processors respond to any instructions.
What Happens When We Adopt Safe
Upgradable Contracts:
Every time a new plugin is introduced, a new singleton needs to be deployed. Users have the autonomy to upgrade Safe to the desired singleton version to fit their preferences and requirements.
Composable and reusable modules:
The modular nature of plugins allows developers to independently build functionalities. They can then freely choose and combine these plugins according to their use cases, promoting highly customizable approaches.
ERC-2535 Diamond Proxy
About ERC 2535 and Diamond Proxy
The ERC 2535 standardizes the Diamond Proxy, which is a modular smart contract system that allows for upgrades/extensions after deployment with almost no size limit. So far, many teams have been inspired by it, such as Zerodev's Kernel and Soul Wallet's experiment.
What is the Diamond Structure
Diamond Contract: Main proxy contract (with state) Diamond is a proxy contract that calls functions from its implementation through delegate calls.
Module/Plugin/Facet Contracts: Custom logic and functionality (stateless) Modules or facets, also known as stateless contracts, can deploy their functionalities to one or more Diamonds. They are independent contracts that can share internal functions, libraries, and state variables.
What Happens When We Adopt Diamond
Upgradable contract: Diamond provides a systematic way to isolate and connect different plugins together, and can directly add/replace/delete any plugin through the diamondCut function. Over time, there is no limit to the number of plugins that can be added to Diamond.
Modular and reusable plugins: A deployed plugin can be used by any number of Diamonds, greatly reducing deployment costs.
Differences between Safe Smart Account and Diamond Approach
There are many similarities between the 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 the handling of logic contracts. Here is a more detailed explanation:
Flexibility: In order to enable new plugins, Safe needs to redeploy its singleton contract to implement the 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.
Security: Both structures currently 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 between multiple module contracts (plugins). Therefore, malicious plugins have the potential to override another plugin, introducing the risk of storage conflicts and potentially compromising the integrity of the proxy.
Cost: The inherent flexibility in the Diamond approach comes with increased security concerns. This adds a 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 functionality, which can be a challenge for small to medium-sized enterprises striving to maintain strong security standards.
"Safe Smart Account" and "Diamond Approach" are examples of different structures involving proxies and modules. It is crucial to balance flexibility and security, and these two approaches may complement each other in the future.
Module Order: Verifier, Executor, and Hook
Let's expand our discussion by introducing the standard ERC 6900 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 the work between plugin and wallet developers.
When it comes to the transaction process of AA, there are three main steps: validation, execution, and hook. As discussed earlier, these steps can be managed by using a proxy account. While different projects may use different names, understanding the underlying logic is important. - Validation: Ensures the authenticity and permission of the caller to the account. - Execution: Executes any custom logic allowed by the account. - Hook: Acts as 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 are written. Whether it's Safe or ERC 6900, standardization helps reduce the need for unique development work targeting specific implementations or ecosystems and prevents vendor lock-in. Discoverability and security of modules: An emerging solution involves creating a place where users can discover verifiable modules, which we can call a "registry". This registry functions like an "app store" and aims to facilitate a simplified yet thriving modular marketplace. Safe{Core} Protocol: Safe{Core} Protocol is an open-source, interoperable smart contract account protocol that aims to enhance accessibility for various vendors and developers while maintaining strong security through clearly defined standards and rules. - Account: 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 as a permission layer. - Registry: The registry defines security attributes and enforces module standards like ERC 6900, creating an open "app store" environment for discoverability and security.Module: Module processing functionality, provided in various initial types including plugins, Hooks, signature validators, and function handlers. Developers can contribute to it as long as they meet the established standards.
Rhinestone Design
The expansion of this process is as follows:
Create schema definition: A schema serves as a predefined data structure for proofs. Enterprises can customize schemas based on their specific use cases.
Create a module based on the schema: Smart contracts are registered as modules, obtain bytecode, and select a schema ID. These data are then stored in a registry.
Obtain proofs for the module: Provers/auditors can provide proofs for a module based on the schema. These proofs can include a unique identifier (UID) and other references to proofs for linking. They can be propagated on the chain and validate if the target chain meets specific thresholds.
Implement complex logic using parsers: Parsers are optional settings within the schema. They can be invoked 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 secure information from the frontend. EIP can be found here.
Although this schema 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. There may be several use cases in the future:
Provers: Trusted entities, such as Safe, can collaborate with Rhinestone as provers for internal modules. At the same time, independent provers can also join.
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.
"Module Registry" concept offers opportunities for plugin and module developers to profit. It may also pave the way for the "Module Market". Some 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. By adopting this approach, we can avoid vendor lock-in and attract a wider audience to support EVM's 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 that they do not have storage conflicts may be a challenge, emphasizing the importance of wallets or AA infrastructure in addressing such issues.
Conclusion
By leveraging modular smart contract account stacks, wallet providers and dApps can rid themselves of the complexity of technical maintenance. At the same time, external module developers have the opportunity to provide tailored professional services for individual needs. However, challenges to be addressed include striking a balance between flexibility and security, driving progress in modular standards, and implementing standardized interfaces that enable users to easily upgrade and modify their smart accounts.
However, the modular smart contract account (SCA) is just a piece of the puzzle being adopted. To fully realize the potential of SCA, support from layer-two solutions at the protocol level is required, as well as robust bundler infrastructure and peer-to-peer memory pools, cost-effective and feasible SCA signature mechanisms, cross-chain SCA synchronization and management, and the development of user-friendly interfaces.
We envision a future of widespread participation that raises some interesting questions: once the SCA order flow becomes lucrative enough, how will traditional miner-extractable value (MEV) mechanisms enter the field, building bundlers and capturing value? When the infrastructure matures, how does Account Abstraction (AA) become the foundational layer of "intent-based" transactions? Stay tuned, as this field is constantly evolving.
