This article is original by the SevenX research team and is for communication and learning purposes only and does not constitute any investment reference. If you need to cite, please indicate the source.
The original English report was published on SevenXs Mirror platform in September 2023.For more Chinese investment research content, please follow the public account [SevenXVentures].
Thanks to Lukas, co-founder of Safe, Noam, head of engineering at Alchemy, Kurt and Konrad, co-founders of Rhinestone, and investor Arnav from HashKey Capital.
Editors note: Smart Contract Accounts (SCA) are developing strongly and are supported by many core entrepreneurs, including Vitalik. However, the adoption of SCA still faces many challenges. Account Abstraction (AA) has the advantage of customizing functionality using code, but its non-interoperability brings integration and vendor lock-in issues. The modular account abstraction aims to create a modular structure for developing wallets with diverse functionality, security, and seamless integration.
SevenX Ventures investor Rui pointed out the five major challenges facing the adoption of SCA, namely bear market impact, migration difficulty, signature issues, high gas costs and engineering difficulties, and further discussed the engineering issues. Furthermore, an analysis of the architecture of modular smart contract accounts points out that modular SCA is only a small piece of the adoption puzzle.
In order to fully realize the potential of SCA, Layer 2 solutions are required to provide additional protocol layer support, powerful bundler infrastructure and peer-to-peer memory pools, more cost-effective and feasible SCA signature mechanisms, cross-chain SCA synchronization and management mechanisms, and development User-friendly interface and more.
In the future, as current challenges are gradually resolved and more people 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 received support from many core entrepreneurs, including Vitalik. Despite this, adoption of SCA is not as widespread as EOA. The main problems include the impact of the bear market, the difficulty of migrating from eoa to sca, signature issues, high gas costs, and the most critical development problems.
The most significant advantage of Account Abstraction (AA) is the ability to customize functionality using code. However, the non-interoperability of AA functionality poses major challenges. This fragmentation can hinder AA integration and reinforce vendor lock-in. In addition, ensuring security while being upgradable and composable is also an important challenge.
One niche area within the AA development trend is the emergence of modular account abstraction, an innovative approach that separates smart accounts from their custom functionality. The goal is to create a modular structure to develop wallets with diverse functionality, security, and seamless integration. In the future, modular account abstraction can implement a free smart contract account app store, allowing wallets and dApps to focus on improving the user experience without spending too much energy on building functions.
A brief introduction to Account Abstraction (AA)
In the process of people coming into contact with the blockchain, traditional EOA has brought many challenges, such as mnemonic words, gas fees, cross-chain operations and multiple transactions.
Account abstraction leverages smart contract accounts, allowing programmable validation and execution. This means that users will be able to approve a series of transactions at once, instead of having to sign and broadcast each transaction. Account abstraction can also achieve more functions, such as improving user experience (such as Gas abstraction and session keys), reducing costs (such as batch transactions) and improving security (such as social recovery, multi-signature). Currently, there are two ways to implement account abstraction:
Protocol layer: Some protocols themselves provide native account abstraction support. ZKSync transactions use a single memory pool and transaction process to support AA; whether it is from EOA or SCA, they follow the same process, and Starknet has removed EOA and all accounts are SCA, and they have native smart contract wallets like Argent.
Contract layer: For Ethereum and similar L2, ERC 4337 introduces 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.
Dilemmas when adopting SCA
The topic of Account Abstraction (AA) has been discussed since 2015, and was further 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 delve deeper into this dilemma:
1. The impact of the bear market
Although AA has advantages such as seamless login and Gas abstraction, in the current bear market, all users are educated EOA users and there are not many new users, so dApps and wallets have no incentive to adopt SCA. Even so, some leading dApps 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.
2. Barriers to migration
For wallets and applications that have accumulated users and assets, migrating assets safely and conveniently remains a challenge. However, schemes like EIP-7377 allow EOA to initiate one-time migration transactions.
3. Signature issue
The smart contract itself cannot sign messages because it does not have a private key like EOA. Attempts like ERC 1271 make this possible, but message signatures do not work before the first transaction, which again poses challenges for wallets using counterfactual deployments. ERC-6492, proposed by Ambire, is a backward-compatible successor to ERC-1271 and may be able to solve the previous problems.
4. Gas cost
One of the barriers to adoption is the higher cost of deploying, simulating, and executing SCA compared to standard EOA. However, some tests have been carried out, such as separating account creation from user actions and eliminating the"salt"wait.
5. Engineering problems
The ERC-4337 team has established the eth-infinitism repo to provide basic implementation for developers. However, integration and decoding will face more challenges as developers scale into more nuanced and specific functionality for different use cases. In this article, we’ll take a closer look at an engineering challenge.
Solve engineering challenges with modular smart contract accounts
The engineering challenges can be further elaborated into three aspects: fragmentation, security, and scalability.
Fragmentation
Features can now be enabled in a variety of ways, whether through a specific SCA or through a standalone plug-in system. Each platform and service provider follows its own standards, forcing developers to decide which platforms and service providers to support. This can lead to potential platform (vendor) lock-in or redundant work.
safety
While decoupling accounts and functions brings the advantage of flexibility, it can also make security issues worse. Because all features may be reviewed together, the lack of independent evaluation may increase the risk of account vulnerabilities.
Upgradeability
As an account grows, its important to maintain the ability to add, replace, or remove functionality, and each update that redeploys existing functionality introduces complexity.
In order 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 account abstraction is a subdivision within the broad AA development that envisions modularizing smart accounts to customize services to users and enable developers to seamlessly enhance functionality with minimal restrictions.
However, establishing and promoting new standards in any industry is a huge challenge. Many different solutions are likely to emerge in the initial stages until everyone accepts the same standard. It’s encouraging to see those working on refining and promoting the account abstraction, whether it’s the 4337 SDK, wallets, infrastructure teams, or protocol layer designers, working together to speed up this process.
Modular structure: master account and modules
How accounts call modules to implement functions
Delegate call and proxy contract
External calls and delegate calls:
About delegate calls
Although delegation call is similar to invocation, 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 contracts and delegate calls
To achieve a composable and upgradeable structure, a basic concept agency contract needs to be introduced.
Agent contract: Ordinary contracts store their logic and status and cannot be updated after deployment. The proxy contract uses delegate call to deploy to another contract. Implement the function by reference, executing it 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 enable upgradability and are cheaper to deploy and maintain on public blockchains.
Safe architecture
Safe architecture
What is Safe:
Safe is the leading modular smart account infrastructure designed to deliver battle-tested security and flexibility, enabling developers to create diverse applications and wallets. Many teams are building applications based on (or inspired by) Safe. For example, when Biconomy launched its smart contract account, it used native 4337 and 1/1 multi-signature to expand Safe. With over 164, 000 contracts deployed and over $30.7 billion in value locked, Safe is undoubtedly the leader in its field.
The structure of Safe includes security account contract, singleton contract, and module contract.
Security account contract (proxy contract): main agent contract (Stateful)
The security account is a proxy contract because the delegate call is a singleton contract. A security account contains variables for the owner, threshold, and implementation address that are all set to the agent, and its status is defined based on these.
Singleton contract: Integration Hub (stateless)
The singleton contract serves the Safe account and defines different module contract integrations, including Plugin, Hook, Function Handler and Signature Validator.
Module contracts (modules): custom logic and functions
Module contracts are powerful. Plug-ins, as modular types, can define different functions, such as payment flows, recovery mechanisms, and session keys, and can serve as a bridge between Web2 and Web3 by obtaining off-chain data. Other modules such as Hook and Function Handler as security guards can respond to any command.
Changes brought about by adopting Safe:
Upgradeable contracts: New singletons need to be deployed whenever a new plugin is introduced. Users retain the autonomy to upgrade Safe to the desired singleton version.
Composable, reusable modules: The modular nature of plugins enables developers to develop functionality independently. They are free to select and combine these plugins according to their use cases, resulting in a highly customizable approach.
ERC-2535 Diamond Agent
About ERC 2535, Diamond agent:
ERC 2535 standardized Diamond model, a modular smart contract system that can be upgraded/expanded after deployment with almost no size limit. Currently, the experiments of many teams, such as Zerodevs Kernel and Soul Wallet, are inspired by the Diamond structure.
What is Diamond structure:
Diamond Contract: Main Proxy Contract (Stateful) Diamond is a proxy contract that uses delegate invocation methods to call functions from its implementation.
Modules/Plugins/Facet Contracts: Custom Logic and Functionality (Stateless) A module or so-called Facet is a stateless contract that can deploy its functionality to one or more Diamonds. They are separate, independent contracts that can share internal functions, libraries, and state variables.
Changes brought about by adopting Diamond:
Upgradeable contracts: Diamond provides a systematic way to isolate different plug-ins and connect them together, share data between them, and also directly add/replace/remove any plug-in using the diamondCut function. Over time, there will be no limit to the number of plugins that can be added to Diamond.
Modular and reusable plug-ins: Deployed plug-ins can be used by any number of Diamonds, thus greatly reducing deployment costs.
The difference between Safe smart account and Diamond method:
There are many similarities between the Safe and Diamond architectures, with both relying on proxy contracts at their core and referencing logic contracts for upgradability and modularity.
The main difference between the two is the handling of logical contracts. Specifically:
Flexibility: With new plugins enabled, Safe needs to redeploy its singleton contract to implement changes in its proxy. In contrast, Diamond does 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 used in two structures that allow external code to manipulate the storage of the main contract. In the Safe architecture, delegate calls point to a single logical contract, while Diamond uses delegate calls in multiple module contracts-plugins. Therefore, it is possible for a malicious plug-in to overwrite another plug-in, thereby introducing the risk of storage conflicts and compromising the integrity of the agent.
Cost: With the Diamond approach, flexibility comes with safety concerns. This adds cost and requires a full review every time a new plugin is added. The key is to ensure that these plug-ins do not interfere with each others functionality, a task that can be challenging, especially for small and medium-sized businesses that strive to maintain high 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 these two approaches will continue to evolve and complement each other in the future.
Module order: Validator, Executor and Hook
Lets take the discussion further by introducing ERC-6900, a standard proposed by the Alchemy team, inspired by Diamond, and specifically tailored for ERC-4337. It solves the challenges of smart account modularization by providing a common interface and coordinating the work between plugin and wallet developers.
When it comes to AAs transaction process, there are three main processes: verification, execution, and hooking. As we discussed earlier, these steps can all be managed by calling the module using a proxy account. While different projects may use different names, its important to grasp similar underlying logic.
Function names in different designs
Validator: Ensure the authenticity and authority of the account caller.
Executor: Execute any custom logic allowed by the account.
Hook: Acts as a module that runs before or after another function. It can modify state or undo the entire call.
ERC 6900
It is crucial to separate modules based on different logic. A standardized approach should dictate how to write verification, execution, and hooking functions for smart contract accounts. Whether its Safe or ERC-6900, standardization helps reduce the need for unique development efforts specific to certain implementations or ecosystems and prevents vendor lock-in.
Module discovery and security
How to find and verify modules in an open way: One solution being advanced involves creating an area that allows users to discover verifiable modules, call it a registry. The registry functions like an app store and is designed to foster a simplified but thriving modular marketplace.
Safe{Core} Protocol
Safe{Core} Protocol is an open source, interoperable protocol for smart contract accounts designed to enhance accessibility for a variety of 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 tied to a specific implementation. This enables different account service providers to participate.
Manager: The manager acts as a coordinator between accounts, registries, and modules. It also acts as a permission layer responsible for security.
Registration center: The registration center defines security attributes and implements module standards such as ERC 6900, aiming to create an open application store environment to achieve discoverability and security.
Modules: Modules handle functionality and have various initial types, including plugins, hooks, signature validators, and function handlers. Developers can participate as long as they meet established standards.
Rhinestone design
The process unfolds as follows:
Create a schema definition (schema): The schema provides predefined data structures. People can customize it to fit their specific use cases.
Create modules based on the architecture: The smart contract registered as a module gets the bytecode and selects the architecture ID, and the data will be stored in the registry.
Obtain attestation of modules: Certifiers/auditors can provide attestations for modules based on the architecture. These certificates can include unique identifiers (UIDs) and references to other certificates used for linking. They can propagate across chains and verify that the target chain meets certain thresholds.
Implement complex logic using a resolver: The resolver (optional setting) comes into play. They can be called during module creation, proof establishment, and teardown. These parsers allow developers to integrate complex and diverse logic while maintaining the proof structure.
User-friendly query access (query): Query provides users with a way to access secure information from the front end.
While 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 verify their attestation information. Several future uses may be:
Attestor: A trusted entity like Safe can work with Rhinestone to serve as attestors for internal modules. At the same time, independent certifiers can also join.
Module developers: With the formation of open markets, it is possible for module developers to monetize their work through registries.
Users: Participate through a user-friendly interface such as a wallet or dApp, where users can inspect module information and delegate trust to different provers.
The concept of a module registry opens up profitable avenues for plugin and module developers. It can further pave the way for the module market. Some aspects may be overseen by the Safe team, while others may appear as decentralized marketplaces, inviting everyone to contribute and providing a transparent audit trail. Integrating this avoids vendor lock-in and supports the expansion of EVM by adding an enhanced user experience that appeals to a wider audience.
While these methods secure individual modules, smart contract accounts are not foolproof when it comes to broader security. Integrating with compliance modules and proving that they are free of storage conflicts can be a challenge, which highlights 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 be freed from the complexity 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 striking a balance between flexibility and security, driving modular standards, and implementing standardized interfaces that enable users to easily upgrade and modify their Smart Accounts.
Furthermore, modular smart contract accounts (SCA) are only a small piece of the adoption puzzle. In order to fully realize the potential of SCA, Layer 2 solutions are required 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, and Develop user-friendly interfaces.
In the future, there will be more adoption of SCA, but it also raises some interesting questions: once SCA order flow becomes profitable enough, how will traditional miner extractable value (MEV) mechanisms enter the space to build bundlers? and get value? When the infrastructure matures, how can Account Abstraction (AA) serve as the base layer for intent-based transactions? let us wait and see.
