Written by: Rui S (SevenX Ventures)
Translated by: Deep Tide TechFlow
Introduction
The transition from externally owned accounts (EOA) to smart contract accounts (SCA) is gaining traction and receiving support from many enthusiasts, including Vitalik himself. Despite the excitement, the adoption of SCA is not as widespread as EOA. Key issues include challenges brought by the bear market, migration concerns, signature problems, gas expenses, 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 upgrading and combining functionality simultaneously 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 custom functionality. 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 “app store” for smart contract accounts, shifting the focus of wallets and dApps from building functionalities to enhancing user experience.
Brief Overview of AA
Traditional EOAs introduce several challenges such as seed phrases, gas, cross-chain, and multiple transactions. We never intended to introduce complexity, but in reality, blockchain is not a simple game for the masses.
Account abstraction leverages smart contract accounts, allowing programmable verification and execution. Users can approve a series of transactions in one go, eliminating the need to sign and broadcast each transaction individually, and enabling additional functionalities. 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 native support for account abstraction. ZKSync transactions, whether from EOA or SCA, follow the same process, using a single memory pool and transaction flow to support AA. Starknet has removed EOA entirely, and all accounts are SCA, with native smart contract wallets like Argent.
- Contract Layer: For Ethereum and its equivalent L2, 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 under discussion and has been brought into the spotlight this year by ERC4337. However, the number of deployed smart contract accounts still lags behind EOA.
Let’s delve into this dilemma:
Impact of bear market:
Although AA introduces benefits such as seamless login and gas abstraction, those currently experiencing the bear market are mainly educated EOA users rather than new users, so there is no incentive for dApps and wallets. Nevertheless, some leading applications are gradually adopting AA, such as Cyberconnect, which has driven about 360,000 UserOps (AA transactions) in just one month by introducing their AA system and gas-free solutions.
Migration barriers:
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 EOAs to initiate one-time migration transactions.
Signature issue:
Smart contracts themselves naturally cannot sign messages as they do not have private keys like EOAs. Efforts like ERC1271 make this type of signature possible, but message signing does not work until the first transaction, which poses a challenge for wallets deployed using counterfactual deployment. The ERC-6492 proposed by Ambire is a backward-compatible successor to ERC-1271 and may solve the previous problem.
Gas cost:
Deployment, simulation, and execution of SCAs generate higher costs compared to standard EOAs. This becomes a barrier to adoption. However, some tests have been conducted, such as decoupling account creation from user operations and considering eliminating account salts and existence checks to reduce these costs.
Engineering challenges:
The ERC-4337 team has established the eth-infinitism repository, providing developers with a basic implementation. However, as we branch out into more detailed or specific functionality 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 Solve Engineering Challenges
Further elaboration on the engineering challenges:
- 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 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 evaluation can increase the risk of account vulnerabilities.
- Scalability: With the evolution of functionalities, 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 improve overall development efficiency, and standardized interfaces to ensure smooth transitions between contract accounts in different frontends.
These terms converge into a common concept: building a Modular Account Abstraction (Modular AA) architecture.
Modular AA is a subset of the broader AA movement that envisions modularizing smart accounts to customize services for users and enable developers to seamlessly enhance functionality with minimal constraints.
However, establishing and promoting new standards is a significant challenge in any industry. In the initial stages, there may be various solutions before a major solution is widely accepted. Nevertheless, it is encouraging to see 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
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 in the current state 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 a composable and upgradable structure, a fundamental concept called “proxy contracts” is needed.
- Proxy Contract: A regular contract stores its logic and state and cannot be updated after deployment. A proxy contract uses delegatecall to invoke another contract. By referencing the implementation, it executes within the current state of the proxy contract.
- Use Cases: 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 battle-tested security and flexibility, enabling developers to create diverse applications and wallets. It is worth noting that many teams are building on top of Safe or are inspired by it. Biconomy introduces its accounts by extending native 4337 and 1/1 multisig on top of Safe. Safe has deployed over 164,000 contracts and locked over 30.7 billion in value, making it the preferred choice in the field.
The Structure of Safe
Safe Account Contract: Main Proxy Contract (Stateful)
Safe account is a proxy contract as it delegates calls (delegatecall) to a singleton contract. The Safe account includes owner, threshold, and implementation address, all of which are set as proxy variables, thus defining its state.
Singleton Contract: Integration Hub (Stateless)
The singleton serves and integrates with the Safe account, defining various integrations including plugins, hooks, function processors, and signature validators.
Module Contract: Custom Logic and Functionality
Modules are extremely powerful. As a modular type, plugins can define different functionalities such as payment flows, recovery mechanisms, and session keys, and act as cross-chain bridges between off-chain data and Web2 and Web3. Other modules, such as hooks, serve as security protections, and function processors respond to any instructions.
What Happens When We Use 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 version of the singleton to align with their preferences and requirements.
Composable and Reusable Modules:
The modular nature of plugins allows developers to build functionalities independently. They can then freely choose and combine these plugins according to their use cases, facilitating highly customizable approaches.
ERC-2535 Diamond Proxy
About ERC2535 and Diamond Proxy
ERC2535 standardizes the Diamond proxy, which is a modular smart contract system that allows for upgrades/extensions after deployment and has virtually no size limits. 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 (Stateful) Diamond is a proxy contract that calls functions from its implementation through delegatecall.
- Module/Plugin/Facet Contract: Custom Logic and Functionality (Stateless) A module or so-called facet is a stateless contract that can deploy its functionality to one or multiple Diamonds. They are independent contracts that can share internal functions, libraries, and state variables.
What Happens When We Use Diamond
- Upgradable Contracts: Diamond provides a systematic approach to isolate different plugins and connect them together, and directly add/replace/delete any plugins through the diamondCut function. Over time, there is no limit to the number of plugins that can be added to a 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 the core and referencing logic contracts to achieve upgradability and modularity.
However, the main difference lies in the handling of logic contracts. Here are more detailed explanations:
- Flexibility: In the case of enabling new plugins, Safe requires redeployment of 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: 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 between multiple module contracts (plugins). Therefore, malicious plugins have the potential to overwrite 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 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-sized enterprises striving to maintain strong security standards.
“Safe smart account method” and “Diamond method” 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: Validator, Executor, and Hook
Let’s expand our discussion by introducing the standard ERC6900 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 a smart account, there are three main steps: validation, execution, and hook. As we discussed earlier, these steps can be managed by invoking modules using a proxy account. While different projects may use different names, grasping the similar underlying logic is important.
- Validation: Ensuring the authenticity and permissions of the caller to the account.
- Execution: Performing 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.
It is crucial to separate the modules based on different logics. A standardized approach should specify how the validation, execution, and hook functions of a smart contract account should be written. Whether it is Safe or ERC6900, standardization helps reduce the need for unique development work specific to an implementation or ecosystem and prevents vendor lock-in.
Module Discovery and Security
A growing solution involves creating a place for users to discover verifiable modules, which we can call a “registry”. This registry is similar to an “app store” and aims to facilitate a simplified but thriving modular market.
Safe{Core} Protocol
The Safe{Core} protocol is an open-source and interoperable smart contract account protocol that aims to improve accessibility for various suppliers and developers while maintaining strong security through defined standards and rules.
- Accounts: In the Safe{Core} protocol, the concept of accounts is flexible and not limited to a specific implementation. This allows various account service providers to participate.
- Managers: Managers act as coordinators between accounts, registries, and modules. They are also responsible for security as a permission layer.
- Registry: The registry defines security attributes and enforces module standards such as ERC6900, aiming to create an open “app store” environment for discovery and security.
- Modules: Modules handle functionalities and are provided in various initial types, including plugins, hooks, signature validators, and function handlers. Developers can contribute to them as long as they meet the established standards.
Rhinestone Design
The process unfolds as follows:
- Create Pattern Definitions: Patterns serve as predefined data structures for proofs. Enterprises can customize patterns based on their specific use cases.
- Create Modules Based on Patterns: Smart contracts are registered as modules, obtaining bytecode and selecting a pattern ID. This data is then stored in the registry.
- Obtain Proofs for Modules: Provers/auditors can provide proofs for modules based on patterns. These proofs can include unique identifiers (UID) and references to other proofs for linking. They can be propagated on the chain and validate if specific thresholds are met on the target chain.
- Implement Complex Logic with Parsers: Parsers are optional settings included in the pattern. 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 structure of proofs.
- User-Friendly Query Access: Queries provide a way for users to access security information from the frontend. EIP can be found here.
Although this pattern 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 allow users to easily discover modules and verify their proof information. There may be several potential use cases in the future:
- Prover: Trusted entities, such as Safe, can work with Rhinestone as proofers for internal modules. Independent proofers can also join.
- Module Developers: With the formation of an open market, module developers have the possibility to commercialize their work through a registry.
- Users: Through user-friendly interfaces, such as wallets or dApps, users can view module information and delegate trust to different proofers.
The concept of “Module Registry” provides opportunities for plug-in and module developers to profit. It may also pave the way for a “Module Market”. Some aspects of it may be overseen 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 the expansion of the 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 they have no storage conflicts can be a challenge, emphasizing the importance of wallets or AA infrastructure in addressing such issues.
Summary
By leveraging modular smart contract account stacks, wallet providers and dApps can escape 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 that need to be addressed include striking a balance between flexibility and security, driving the progress of modular standards, and implementing standardized interfaces that allow users to easily upgrade and modify their smart accounts.
However, Modular Smart Contract Accounts (SCA) are just part of the puzzle being adopted. To fully realize the potential of SCA, support from second-layer solutions at the protocol layer is needed, as well as robust bundling 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 broad participation that raises some interesting questions: Once SCA order flow becomes profitable enough, how will traditional miner extractable value (MEV) mechanisms enter the field to build bundlers and capture value? When the infrastructure matures, how can Account Abstraction (AA) become the foundational layer for “intent-based” transactions? Stay tuned, as this field is constantly evolving and changing.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
