Introduction

The shift from Externally Owned Accounts (EOA) to Smart Contract Accounts(SCA) is gaining momentum and has been embraced by many enthusiasts, including Vitalik himself. Despite the excitement, the adoption of SCA is not as widespread as EOAs. The key among them are the challenges posed by bear markets, the concern of migration, signing issues, gas overheads, and most critically, engineering difficulties.

The most significant advantage of Account Abstractions (AA) is the ability to use code to customize functionality. However, one major engineering challenge is the non-interoperability of AA functionalities, and the fragmentation hampers integration and opens the door to vendor lock-in. Additionally, ensuring security while simultaneously upgrading and composing features can be intricate.

Enter Modular Account Abstraction, as a subset of the broader AA movement, this innovative approach can separate smart accounts from their custom functions. The goal is to create a modular structure to develop secure, seamlessly integrated wallets with diverse functionalities. In the future, it can realize a free “app store” for smart contract accounts that sets wallets and dApps free from building features but focuses on user experience.

After reading this article, readers will gain insights about:

1. What is Modular Account Abstraction
2. How does the account interact with modules
3. What’s the sequence of calling modules
4. How to find and verify modules in an open way

A Brief Review of AA

SCA Landscape

The traditional EOA introduces many challenges like seed phrase, gas, cross-chain, and multiple transactions. We never intended to introduce complexity, but in fact, blockchain is not an easy game for the masses.

Account Abstraction leverages the smart contract account allowing programmable validation and execution, where the user is able to approve a series of transactions in one go, rather than sign and broadcast each, and implement many more features. It introduces benefits to user experience(eg. gas abstraction, and session keys), cost(eg. batching transaction), and security(eg. social recovery, multi-sig). Currently, there are two ways to achieve account abstraction:

1. Protocol layer: Some protocols themselves provide native account abstraction support, ZKsync transactions follow the same flow whether originating from EOA or SCA which uses a single mempool and transaction flow to support AA, and Starknet has removed EOA and all accounts are SCA, and they have native smart contract wallets like Argent.
2. Contract layer: For Ethereum and its equivalent L2s, ERC4337 introduces a separate entry point for transactions to support AA without changing the consensus layer. Projects like Stackup, Alchemy, Etherspot, Biconomy, Candide, and Plimico are building bundler infrastructure, and many more like Safe, Zerodev, Etherspot, and Biconomy are building stack and SDK.

👉 If you’re not familiar with AA or ERC4337, check SevenX’s previous research here.

The Dilemma of SCA Adoption

The topic of Account Abstraction (AA) has been under discussion since 2015 and it was further propelled into the limelight by ERC4337 this year. However, the number of deployed smart contract accounts still pales in comparison to EOAs.

Let’s delve into this dilemma:

1. Bear Market Impact:
   Even though AA introduces benefits like seamless login and gas abstraction, the prevailing bear market primarily consists of educated EOA users rather than new ones, thus there’s no incentive for dApps and wallets. Even saying that, leading apps are still on the way to adopting AA, like Cyberconnect drove around 360,000 UserOps(transactions of AA) a month alone by introducing their AA system and gasless solution.
2. Migration Obstacles:
   For wallets and applications that have accumulated users and stored assets in EOAs, migrating assets securely and conveniently remains a challenge. Nevertheless, initiatives like EIP-7377 permit EOAs to initiate a one-time migration transaction.
3. Signing Issue:
   The smart contract itself naturally can’t sign messages, since it does not possess a private key like EOAs. Efforts like ERC1271 make it possible but the message signing won’t work until the first transaction, which proposes a challenge for wallets using counterfactual deployment. And ERC-6492 proposed by Ambire is a backwards-compatible successor to ERC-1271 that potentially solves the previous issue.
4. Gas Overheads:
   Deploying, simulating, and executing SCAs incur higher costs compared to standard EOAs. This becomes a deterrent for adoption. However, several tests have been conducted, such as decoupling account creation from user operations, and eliminating account salt and existence checks are being considered to reduce these costs.
5. Engineering Difficulties:
   The ERC-4337 team has set up the eth-infinitism repo to provide developers with a foundational implementation. Yet, as we branch out to more nuanced or specific functions for different use cases, integration and decoding become challenging.

In this article, we’ll dive into the #5 problem: the engineering difficulties.

🤔️

Modular Smart Contract Account to Address Engineering Difficulties

To further elaborate on the engineering difficulties:

1. Fragmentation:
   Features are now enabled in various ways, whether natively by specific SCAs or through independent plugin systems. Each follows its standard, forcing developers to decide which platforms to endorse. This leads to potential platform lock-ins or redundant efforts.
2. Security:
   While the flexibility between accounts and features offers advantages, it may amplify security concerns. Features might be audited collectively, but the absence of independent assessments could heighten the risk of account vulnerabilities.
3. Upgradability:
   As features evolve, it’s important to retain the capacity to add, replace, or remove functionalities. Redeploying existing features with each update introduces complexities.

To navigate these waters, we need upgradable contracts that ensure secure and efficient upgrades, reusable cores to enhance overall development efficiency, and standardized interfaces to ensure contract accounts can transition smoothly between different frontends.

These terms converge on a singular concept: Building a Modular Account Abstraction Architecture (Modular AA).

Modular AA is a niche within the broader AA movement which envisions modularizing smart accounts to customize them for users and empower developers to seamlessly enhance features with minimal restrictions.

Yet, in any industry, setting up and promoting a new standard is a big challenge. Initial phases may witness many different solutions before everyone settles on the main one. However, it’s encouraging to see those working on account abstraction, whether it’s the 4337 SDK, wallet developers, infrastructure teams, or protocol designers, all coming together to speed up the process.

Modular Structure: Main Account and Modules

How does the account call modules to realize functions

Delegate call and proxy contract

External call and delegate call:

About delegateCall

While delegatecall is similar to call, but instead of executing the target contract in its own context, it executes it in the context of the calling contract’s current state. This means that any state changes made by the target contract are made to the calling contract’s storage.

Proxy contract and delegateCall

To realize the composable and upgradable structure, there’s a fundamental knowledge needed called “Proxy contract”.

1. Proxy contract: A normal contract stores its logic and states, which is unable to update after deployment. A proxy contract using delegatecall to another contract. By referring to the implementation function, it executes it in the proxy contract’s current state.
2. Use cases: While the proxy contract stays immutable, you can deploy a new implementation behind the proxy. Proxy contracts are used for upgradability and are cheaper to deploy and maintain 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, it empowers developers to create diverse applications and wallets. Notably, many teams are building on top of Safe or inspired by it. Biconomy launched its account by expanding Safe with native 4337 and 1/1 multi-signatures. Witnessing the deployment of over 164,000 contracts and locking in excess of 30.7 billion in value, Safe is no doubt the premier in space.

What’s Safe’s structure

1. Safe account contract: Main proxy contract (Stateful)
   Safe account is a proxy contract because it delegatecalls a singleton contract. Safe Account contains owners, threshold, and implementation addresses are all set as the variables of the proxy, hence defining its state.
2. Singleton contract: Integration Hub (Stateless)
   Singleton serves the Safe account and integrates and defines different integrations including Plugin, Hook, Function Handler, and Signature Validator.
3. Module contract: Custom logic and features:
   Modules are powerful. Plugins as a modular type can define different features like payment streamings, recovery mechanisms, and session keys, and can serve as a bridge between web2 and web3 by fetching off-chain data. Other modules like Hook as a safety guard, and Function Handler respond to any instructions.

What happens when we adopt Safe:

1. Upgradable Contracts:
   Deploying a new singleton is needed whenever new plugins are introduced. Users retain the autonomy to upgrade their Safe to the desired singleton version, aligning with their preferences and requirements.
2. Composable and Reusable Modules:
   The modular nature of plugins empowers developers to craft functionalities independently. They can then freely select and combine these plugins based on their use cases, fostering a highly customizable approach.

ERC-2535 Diamond Proxies

ERC2535 Diamond Architecture

About ERC2535, Diamond Proxies:

The ERC2535 standardizes diamonds, a modular smart contract system that can be upgraded/extended after deployment and has virtually no size limit. Up till now, lots of teams have been inspired by it, like Zerodev’s Kernel, and Soul Wallet’s experiment.

What’s diamond structure:

1. Diamond contract: Main proxy contract (Stateful) A diamond is a proxy contract that calls functions from its implementations using delegatecall.
2. Module/ Plugin/ Facet contract: Custom logic and features (Stateless) A Module or so-called Facet is a stateless contract that could deploy its features to one or more diamonds. They are separate, independent contracts that can share internal functions, libraries, and state variables.

What happens when we adopt Diamond:

1. Upgradable Contracts: Diamond provides a systematic way to isolate different plugins and connect them together and share data between them, also directly adds/replaces/removes any plugin using the diamondCut function. There is no limit to the amount of plugins that can be added to diamonds over time.
2. Modular and reusable plugin: A deployed plugin can be used by any number of diamonds to tremendously reduce deployment costs.

Difference between Safe Smart Account and Diamond Approach:

Similarities abound between the Safe and Diamond architectures, both relying on proxy contracts at their core and referencing logic contracts to achieve upgradability and modularity.

Nonetheless, the primary distinction lies in the handling of logic contracts. Here’s a closer look:

1. Flexibility:
   In the context of enabling new plugins, Safe necessitates the redeployment of its Singleton contract to implement the change in its Proxy. In contrast, Diamond achieves this directly through the diamondCut function in its Proxy. This variance in approach translates to Safe retaining a higher degree of control, while Diamond introduces enhanced flexibility and modularity.
2. Security:
   delegatecall, utilized in both structures for now, can permit external code to manipulate the storage of the main contract. In the Safe architecture, delegatecall points to a single logic contract , whereas Diamond employs delegatecall across multiple module contracts- plugins. Consequently, a malicious plugin holds the potential to overwrite another plugin, thereby introducing the risk of storage collisions that could compromise the integrity of the Proxy.
3. Cost:
   The flexibility inherent in the Diamond approach comes hand in hand with amplified security concerns. This increases the cost factor, necessitating comprehensive audits with every addition of a new plugin. The key is to make sure that these plugins don’t interfere with each other’s functions, presenting a challenge, particularly for small or medium-sized enterprises striving to maintain robust security standards.

The “Safe Smart Account approach” and the “Diamond Approach” serve as examples of distinct structures involving proxies and modules. How to balance flexibility and security is crucial, and these two methods could potentially complement each other in the future.

Modules Sequence: Validator, Executor, and Hook

What’s the sequence of calling modules

Let’s expand our discussion by introducing ERC6900, a standard proposed by the Alchemy team, inspired by Diamond, and tailored specifically for ERC-4337. It addresses the challenge of modularity in smart accounts by providing common interfaces and coordinates the efforts between plugin and wallet developers.

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

Function names in different design

1. Validation: Ensures the authenticity and authority of the caller to the account.
2. Execution: Performs any custom logic that the account allows.
3. Hook: Acts as a module that runs before or after another function. It can modify the state or cause the entire call to undo.

ERC6900

It’s crucial to separate modules based on a different logic. A standardized approach should dictate how validation, execution, and hook functions for smart contract accounts should be written. Whether it is Safe or ERC6900, the standardization helps reduce the need for unique development efforts specific to certain implementations or ecosystems and prevents vendor lock-in.

Modules Discovery and Security

How to find and verify modules in an open way

A solution that’s gaining momentum involves the creation of a place that allows users to discover verifiable modules, which we can call “registry.” This registry functions akin to an “App Store” and aims to foster a simplified yet thriving modular marketplace.

Safe{Core} Protocol

Safe{Core} Protocol

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

1. Account: In Safe{Core} Protocol, the concept of an account is flexible and not bound to a specific implementation. This enables diverse account service providers to participate.
2. Manager: The Manager serves as a coordinator among Accounts, Registries, and Modules. It’s also responsible for security as the permissioning layer.
3. Registries: Registries define security attributes and enforce standards like ERC6900 for Modules, aiming to create an open “app store” environment for both discoverability and safety.
4. Modules: Modules handle functionalities and come in various initial types, including Plugins, Hooks, Signature Validators, and Function Handlers. These are open for developers to contribute to, provided they meet the established standards.

Rhinestone Design

Rhinestone Design

The process unfolds as follows:

1. Creating a Schema Definition: A schema serves as a predefined data structure required for attestation. It can be customized by businesses to align with their specific use cases.
2. Creating Modules Based on A Schema: Smart contracts are registered as modules, obtaining bytecode and choosing a schema ID. This data is then stored within the registry.
3. Attaining Attestation for a Module: Attestors/ auditors can provide attestations for modules on a schema basis. These attestations can include a unique identifier (UID), and references to other attestations for chaining. They can propagate across chains and verify if specific thresholds are met on destination chains.
4. Implementing Complex Logic with Resolvers: Resolvers, optionally set in the schema, come into play. They could be invoked during module creation, attestation establishment, and revocation. These resolvers allow developers to incorporate intricate and diverse logic while maintaining attestation structures.
5. User-Friendly Query Access: Queries offer a means for users to access security information from the front-end. Find this EIP here.

While this schema is in its early stages, it holds the potential to establish a standard in a decentralized and collaborative way. Their registry enables developers to register their modules, auditors to verify their security, and wallets to integrate and enables users to effortlessly locate modules and verify their attestation information. Several future uses might be:

1. Attestors: Trustworthy entities, like Safe, could collaborate with Rhinestone as attestors for in-house modules. Simultaneously, independent attestors could join in.
2. Module Developers: As an open market takes shape, module developers could potentially monetize their work through the registry.
3. Users: Engaging via user-friendly interfaces, such as wallets or dApps, users can examine module information and delegate trust to diverse attestors.

The concept of “Module Registry” opens avenues for monetization for plugin and module developers. It could further pave the way for a “Module Marketplace.” Some aspects might be supervised by Safe’s team, while others could manifest as decentralized marketplaces, inviting contributions and transparent audit records for all. By incorporating this, we can avoid vendor lock-in and support the expansion of the EVM by adding an enhanced user experience that attracts a wider audience.

While these approaches guarantee the safety of a single module, the broader security of smart contract accounts isn’t foolproof. Combining legitimate modules and proof they don’t have storage collisions can be a challenge, underscoring the importance of wallet or AA infrastructure in addressing such concerns.

Closing thoughts

By utilizing a modular smart contract account stack, wallet providers and dApps can be liberated from the complexities of tech maintenance. Meanwhile, external module developers have the opportunity to offer specialized services tailored to individual needs. However, challenges to address include striking a balance between flexibility and security, pushing modular standards forward, and implementing standardized interfaces that empower users to easily upgrade and modify their smart accounts.

Yet, modular Smart Contract Accounts (SCA) represent just one piece of the adoption puzzle. To fully realize the potential of SCA, additional protocol-layer support is needed from Layer 2 solutions, so as robust bundler infrastructure and peer-to-peer mempool, more cost-effective and feasible SCA signing mechanism, cross-chain SCA synchronization and management, and develop user-friendly interfaces.

Looking ahead, we envision a future where participation is widespread, sparking intriguing questions: Once SCA order flow becomes sufficiently profitable, how will traditional Miner Extractable Value (MEV) mechanisms enter the field to build bundlers and capture value? When the infrastructure matures, how can Account Abstractions (AA) serve as the foundational layer for “intent-based” transactions? Stay tuned; the landscape is evolving by the minute.

Important pieces

1. Safe whitepaper: https://github.com/safe-global/safe-core-protocol-specs/blob/main/whitepaper.pdf
2. Rhinestone doc: https://docs.rhinestone.wtf/
3. Biconomy doc: https://www.biconomy.io/post/making-biconomy-smart-accounts-modular

Disclaimer：

1. This article is reprinted from [SevenX Ventures ]. All copyrights belong to the original author [SevenX Ventures]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.