The original text is from Alchemy's "Hello, Modular Account," compiled by Odaily jk.

Alchemy announces the launch of the Modular Account, a new, from-scratch contract account implementation designed for ERC-4337 and ERC-6900 compatibility. The Modular Account provides enterprise-level security, industry-best cost, and powerful account scalability for developers building on Ethereum L2.

Start using the Modular Account and continue reading for more information.

Why Choose a Contract Account

In the past few years, the Web3 ecosystem has experienced unprecedented growth, but it still faces one of the most stubborn obstacles:

Poor user experience.

Just imagine trying to explain various details like hot wallets or cold wallets, private keys, Gas, authorizations, random numbers, and more to an average person with no blockchain experience.

Now, to truly understand the problem, let's take it a step further and envision what the user experience, which crypto natives have become accustomed to, would look like in real-life scenarios:

Imagine a world where you have to sign for every item you purchase in a store, losing your bank card PIN means losing all your account funds, and every purchase you make is permanent and irreversible.

Luckily, we have a solution to unravel the confusion caused by poor user experience in the industry - account abstraction. Account abstraction focuses on using smart contract accounts (or commonly known as smart accounts) instead of externally owned accounts (EOAs) to move transactions and activities management on the blockchain to a more adaptable place.

Introduction to the difference between externally owned accounts and smart contract accounts

By using smart accounts instead of EOAs, you are "abstracting" to a more versatile participant to handle transactions and activities on the blockchain.

Smart accounts have infinite flexibility in their functionalities compared to EOAs. Each smart account can define different rules and configurations in its code.

We see through the abstraction that has arisen in the maturation of the internet, increasingly complex primitives are layered into the infrastructure stack, resulting in the modern web applications we have today. This approach of packaging technologically complex features into well-defined modules greatly simplifies the end-user experience of netizens around the world.

To further illustrate abstraction, we provide a simple example below:

Example of email abstraction, dynamic emails allow you to schedule send, customize information, use shared accounts, and MFA, etc.

Clearly, at this critical intersection of Web3, building a better user experience is crucial to attract the next wave of users.

From single point of failure and asset custody issues to simply reducing the huge resistance of starting with a new user, we must abstract these complexities and push towards a future where the user experience is smoother for everyone.

Why Choose Modular Contract Accounts

Clearly, smart accounts are essential and can be built upon for limitless improvements. Different account implementations will inevitably share many logical components, such as account recovery, multi-signature support, and key permissions. Each new implementation of these components introduces new security risks for the accounts that implement them.

On the contrary, just as popular cryptography libraries do today, modular components can be hardened and maximally reused to avoid teams independently writing complex account code. As the security saying goes: "Do not roll your own crypto" - this also applies to account logic. These components can be designed as plugins, and accounts can interchangeably install and interact with these plugins to add the desired functionality.

Once multiple accounts start using multiple plugins - as defined by ERC-6900  - the dependency on a single on-chain account implementation is reduced. Users are protected from the impact of single point failures and if needed or desired, can update their accounts to different implementations while retaining most of their existing functionality through the installation of plugins on their accounts.

With these two core pillars of reusability and interoperability, developers can leverage the open ecosystem of modular accounts and plugins to accelerate development through cumulative progress on account functionality and on-chain user experience.

Introduction to Modular Accounts

Modular Account

Alchemy's Modular Account is an enterprise-level account designed to scale with user growth and maintain future compatibility through account abstraction of the ecosystem's ongoing development.

It has scalability and a robust security model to ensure a seamless user experience without trust. When we introduced the Modular Account, it came with two plugins that significantly enhance user experience and security: the Multi-Owner Plugin and Session Key Plugin, along with SDK support to simplify integration and development. Modular Account v1.0 is compatible with ERC-4337 v0.6 and ERC-6900 v0.7.

We are excited to release the Modular Account under a permissive open-source license and actively contribute to building and promoting public products that contribute to the development of the account abstraction ecosystem on GitHub.

Modular Account Demo: Worth of Words

On-chain Zero-Knowledge Proof Wordle Game

An example that highlights the powerful user experience and security features provided by modular accounts is the game we built - Worth of Words. Worth of Words is a "Wordle Battle Royale" style word game where players compete against each other to guess their secret word. This game utilizes the following features to provide a Web2-like gaming experience:

• Modular accounts with session key plugins, allowing users to sign in once to start a new game and then securely allow the browser to sign transactions on their behalf throughout the game for a seamless transaction experience.

• ERC-4337 Gas Manager, abstracting Gas from the user experience.

• Rundler from Alchemy, relaying UserOperations to the underlying network.

• Zero-knowledge proofs to hide words on-chain.

Learn more about Worth of Words here.

Note: Worth of Words is the translation provided by Odaily editors and is not an official translation.

Technical Deep Dive

Modular account technical deep dive diagram

Modular accounts use the UUPSUpgradeable proxy pattern, and the plugins are singleton contracts.

The initial release of modular accounts includes multiple components:

Core Account

Basic accounts support core account abstraction features, including gas abstraction and batch execution. Its features include support for:

- ERC-4337, for censorship-resistant account abstraction.

- ERC-165, for standard interface detection.

- UUPSUpgradeable, for account upgradability, combined with ERC-7201 to achieve secure storage conflict-resistant upgrades.

- Triggering execution by plugins, when the call originates from an allowed plugin, executing logic based on the account's context.

- Installing and uninstalling any ERC-6900 compatible plugins, not limited to Alchemy's.

- Viewing functions to obtain the plugin configuration of an account, including installed execution functions, verification functions, and hooks.

- Strong ordering guarantee for plugin execution.

- Receiving ERC-721, ERC-777, and ERC-1155 tokens. If there is no token receiver implementation, the contract account cannot receive digital assets through OpenZeppelin's standardized `safeTransfer` method.

Account Factory

An account factory contract that generates new modular account instances. These parameters can be specified by the user and used to provide a deterministic address. Using CREATE2, a counterfactual address is generated for the user by combining the provided salt and the account's specified owner.

In production, we expect certain users to be assigned addresses that are used to receive assets before being counterfactually deployed to their assigned address.

Account Plugins

The initial release includes two ERC-6900 compatible plugins:

Multi-Owner Plugin

The multi-owner plugin supports one or more EOA accounts or contracts compatible with the ERC-1271 standard as owners of an account. This plugin:

- Supports ECDSA signature verification (standard EOA signature verification).

- Supports ERC-1271 signature verification (standard contract owner signature verification).

- Supports multiple equal owners with the same root access permissions to the account.

- Implements EIP-712, allowing clients to sign prompts in a structured and readable format.

- Add user operation and runtime verification functionality to native functions of modularized accounts, including:

  - installPlugin and uninstallPlugin

  - upgradeToAndCall

  - execute and executeBatch

Session Key Plugin

The session key plugin allows for the addition of session keys, which represent limited operations that an account can perform within predefined rules. They provide on-chain security while improving user experience by enabling features such as transaction-free experiences and account automation. Session keys are only used within the UserOperation context. This plugin supports:

- Key rotation, allowing the updating of keys while maintaining permissions.

- Expiration/time range rules that limit access to session keys within specified time frames.

- External contract address restrictions that limit the external contract addresses that session keys can call. This restriction can be an allowlist, denylist, or a combination of both.

- External contract method restrictions that limit the external contract methods that session keys can call.

- ERC-20 spending limits (total amount for a key or refreshed periodically).

- ETH/native token spending limits (total amount for a key or refreshed periodically).

- Gas spending limits (total amount for a key or refreshed periodically). By default, there is no limit set, and a session key with permissions to perform any operation can consume an unlimited amount of gas.

- ERC-721 permissions, which can be implemented through contract method restrictions (e.g., allowing safeTransferFrom(address, address, uint 256)) as well as address restrictions.

- Default internal call restrictions. If no initial external call restrictions are specified when installing the session key permission plugin, all external calls will be prohibited by default.

- Required payment main rule, where session keys can only verify user operations when a specific payment main address is used. This serves as another means to prevent session keys from consuming your native tokens on gas fees, in addition to gas limits.

Account Library

The account library supports the modularization of accounts and plugins through reusable code that implements specific functionalities.

Data Structures

• LinkedListSetLib implements a "linked list set" where elements are stored through a mapping from one element to the next. This allows for O(1) addition, removal, and containment operations while maintaining the enumerability of the set on the chain. This set implementation requires preventing duplicate values from being added, preventing zero values from being added, and maintaining a special value as a "sentinel" to mark the start and end of the list. To achieve this, the maximum size of the data available to users is reduced to a maximum of 30 bytes.

• In addition to supporting these efficient operations, the library also supports a less efficient removal operation that does not require prior knowledge of the predecessor. This operation traverses the linked list to find the element to be removed.

• Furthermore, entries support "flags" - which can be thought of as additional values attached to entries, akin to sub-mappings for each element in the set. There are 14 bits available for flag values, with the lowest two bits reserved for sentinel implementation and list traversal optimization.

• AssociatedLinkedListSetLib is almost identical to LinkedListSetLib, except that its entries are stored in storage associated with an account. This library is intended to be used by plugins, and if plugins wish to access or update these values during the validation of ERC-4337, they must store the values in storage associated with the account.

• CountableLinkedListSetLib extends LinkedListSetLib and allows for adding a value multiple times. It uses the upper byte (8 bits) of the 14 available flag bits to keep track of this and supports adding an entry up to 256 times. There is no version of this library that is saved in associated storage.

• The generic types and constants used by these libraries are defined in Constants.sol.

• PluginStorageLib is a lower-level library that provides utilities for accessing storage slots in address-associated storage using varying amounts of input data as keys.

Types and Conversion Utilities

• FunctionReferenceLib provides a user-defined value type intended to store plugin addresses and function IDs for calling plugin functions.

• CastLib provides utility functions for converting and casting between various data types, including collection values, function pointers, and addresses.

Audit

We have implemented a multi-stage security strategy. Spearbit conducted a security review of the modular account protocol during the early stages of development, followed by independent audits of the current version of the protocol by Spearbit and Quantstamp. No major vulnerabilities were found in either audit.

You can access the reports separately from Spearbit and Quantstamp. We are excited to collaborate with Spearbit and Quantstamp to offer discounted rates and services to teams looking to develop on the modular account and the broader ERC-6900 ecosystem.

Security and Permission Model

Let's explore four key areas to highlight the security and permission model of the modular account.

Plugin Manifest

The Plugin Manifest functionality is a crucial aspect of ERC-6900 and the modular account, inspired by the Android OS permission system. All ERC-6900 plugins are required to provide a list specifying the executable functions, hooks, and permission requests needed for the plugin to run. This can be displayed to the user before installing the account and granting these requested permissions. This ensures that permissions are determined during installation, preventing any unexpected runtime behaviors.

Call vs DelegateCall

The modular account only performs calls to plugins, not delegate calls. Delegate calls execute within the account's context without auditing the plugin code, making it difficult to restrict potential damage caused by malicious plugins.

Modular Account Calling Process

The following diagram shows the call paths through the modular account. The left flow represents the UserOperation path for calls from the ERC-4337 entry point, while the right flow represents the runtime path for calls from all other sources, including other contracts.

Scalability 

The modular account is designed to be future-compatible with upgrades and storage conflicts. Specifically:

• Thanks to the use of the EIP-7201 initialization storage mode, there is no risk of storage conflicts when upgrading to or from a modular account.

• Minor version changes to the modular account will use an inherited storage mode to prevent storage conflicts, while major version releases of the modular account will use different storage slots.

Benchmarking

The modular account provides industry-leading costs for end users on Ethereum rollups, including Arbitrum, Base, and Optimism. As we continue to drive the three core transitions needed to onboard mainstream users onto the chain (source), the modular account aims to provide an optimized foundational primitive for a rollup-centric future.

Specifically, it often sacrifices the amount of data usage to increase execution costs, in order to provide a cheaper experience for end users.

In addition, as a persistent user account, the modular account contains security measures for interoperable use without permission, going beyond the popular paradigm of embedding accounts within each application to help drive a virtual and interoperable future. The account has been heavily optimized for day-to-day use, with some security features adding additional execution costs during deployment.

To measure costs, we have built a comprehensive test suite for smart contract accounts for accurate transaction-based cost measurement and calculation. You can find the repository, full methodology, and complete results here. The following results were obtained from benchmark testing conducted on Optimism on February 18, 2024.

*LightAccount is not a modular account, its inclusion is for reference to the industry's best smart accounts.

**ERC-6900 session key plugin offers stronger security control compared to other products.

Please note that there are trade-offs between optimization for rollups and optimization for Layer 1 Ethereum and sidechains. These benchmarks capture the performance measured within the rollup ecosystem.

Bug Bounty Program

With the release of modular accounts, we are also pleased to announce the launch of Alchemy's paid bug bounty program. Bug bounties are a key component of the security toolbox, and we are excited to collaborate with security researchers in the ecosystem and reward them for finding opportunities to strengthen the overall protocol.

From today, anyone can report vulnerabilities in any package released in the modular account through our HackerOne hosted bug bounty platform. For more information about the bug bounty program, please see the overview on HackerOne.

Modular Account SDK & PluginGen

Alchemy's AccountKit, which includes the aa-sdk, is the most widely used smart account development SDK, abstracting away the costs and complexities of building on smart accounts. From today, AccountKit will provide first-class support for modular accounts, including multi-owner and session key plugins. The 3.0 version of the SDK greatly simplifies building and submitting UserOperations, managing off-chain addresses, upgrading to modular accounts, and incurring the costs of advanced features like user sessions.

In addition, this release includes PluginGen, which can automatically generate client classes for using and leveraging plugins, extracting information about any ERC-6900 plugin from the plugin manifest. This allows for a client-side programming user experience based on the user account state.

Using the PluginGen tool is as simple as adding a PluginGenConfig that describes your plugins in the aa-sdk and then running `yarn generate`:

Looking into the Future

Iteration of Modular Account Ecosystem

We look forward to continue collaborating with the ERC-6900 community to develop a robust permissionless plugin and account ecosystem. We are excitedly pursuing some broader ideas, including:

- Building on the security model, creating application-level permission concepts as a combination of plugin-level permissions. In analogy to web2, when installing an application like WhatsApp, the operating system will request a set of permissions. This set of permissions is required by the application, such as WhatsApp, to properly perform privileged actions like access to location, camera, microphone, contacts, etc.

Given the existing security model around plugin-based permissions, we want to explore how this can be extended to application-level permission sets.

- Continuously iterating towards maximally hardened, maximally optimized account implementation. We are excitedly exploring techniques to simplify and optimize operations and iterating on data models to improve understanding and reduce end-user costs.

- Collaborating with teams to build an accelerated interoperable plugin ecosystem. We have already seen several development teams starting to work, and we look forward to seeing what use cases the ecosystem will bring forth.

Well-designed plugins can unlock enormous benefits in user experience and user security, all of which can be added to existing accounts.

- Contributing research and development effort for the next wave of challenges. Many converging leads need to be realized to safely onboard 1 billion users onto the chain. Two aspects of account space that we look forward to seeing are cross-chain interoperability and user privacy. These advancements heavily rely on pushing the limits of zero-knowledge engineering and incorporating these primitives into solutions, such as key storage chains, to aid in managing account configurations deployed across multiple chains.

Reducing User Costs with Smart Accounts and L2

We hear one of the most common criticisms of smart accounts is cost. As the smart account ecosystem develops, we're excited to collaborate with the community and demonstrate that, in fact, smart accounts provide cheaper transactions for end users compared to today's EOAs.

There have been several research methods to reduce these costs, but some methods we're closely monitoring in 2024 include:

Data call compression

As mentioned above, the transaction cost on L2 is primarily due to L1 data availability costs, rather than L2 execution costs. Therefore, by reducing the data call size through increased execution costs, overall costs can often be lowered. The Ethereum Foundation's WAX team has conducted research and prototyped UserOperation compression, achieving some fairly remarkable results, and we're pleased to see this technology being adopted to improve operational efficiency.

Signature aggregation

In practice, signature aggregation is a similar technique that reduces data availability costs by aggregating a bundle of signatures into a single fixed overhead. Most of the discussions here focus on BLS signatures, but in reality, this can be extended to other signature schemes through zero-knowledge proofs. We're pleased to see some ERC-6900 plugins supporting BLS signatures and features like zk-R1 or zk-K1 aggregation to achieve similar results on non-aggregate elliptic curves.

Proto-Danksharding

With the highly anticipated EIP-4844 as part of the Dencun hard fork landing, L2 networks will be able to publish L2 data calls using blob space instead of storing them as L1 data calls. Although estimates vary, proto-Danksharding is expected to significantly reduce transaction costs on L2s.

Acknowledgements

The work on modular accounts goes far beyond Alchemy's scope. Firstly, we would like to thank the dozens of developers who have worked on and contributed to ERC-6900, driving iterations that allow for the safe onboarding of 1 billion users to the chain.

A special thanks goes to Yoav Weiss and Dror Tirosh from the Ethereum Foundation's Account Abstraction team, Huawei Gu, Daniel Lim, Zhiyu Zhang, and Alokik Bhasin from Circle's Programmable Wallet team, and Seungmin Jeon, Sangyeup Kim, Brynn Park, and others from Decipher Global for their significant efforts in advancing the specification.

In addition, we would like to thank our excellent auditing teams. Safety is a fundamental requirement when dealing with contract accounts. Gerard Persoon, Riley Holterhus, Blockdev, and Christos Pap from Spearbit, as well as Nikita Belenkov, Alejandro Padilla, Shih-Hung Wang, and Ruben Koch from Quantstamp, have been diligent in assessing and improving the implementation and architecture of modular accounts.

We would also like to thank the engineering team at a16z crypto, particularly Daejun Park and Matt Gleason, for their early validation meetings of the smart accounts and iterating using modular accounts as the Halmos testing standard, further improving the security posture and development mindset around secure smart accounts.

Finally, we would like to thank the entire modular account ecosystem for supporting the discussion and driving the development of space. In collaboration with the wider community, we have gone through numerous early iterations and architectural proposals. We would like to give special mention to the individuals from Safe, Biconomy, ZeroDev, and Rhinestone who have frequently provided excellent insights and suggestions.