The original text is from Alchemy's "Hello, Modular Account" on Odaily Star Daily, translated by jk.

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

Get started with 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 our ecosystem expansion still faces one of the most stubborn obstacles:

Poor user experience.

Imagine trying to get an ordinary person with no blockchain experience to understand hot wallets or cold wallets, private keys, Gas, authorization, random numbers, and various other details.

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

Imagine a world where you have to sign for every item you purchase in a store, losing your bank card password means losing all your account funds, and you can never revoke any purchase you make.

Fortunately, we have a solution to unravel the confusion caused by the 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.

Brief comparison 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 functionality compared to EOAs. Each smart account can define different rules and configurations in its code.

We see through the abstraction that emerged during the maturation of the Internet, increasingly complex primitives were stacked into the infrastructure stack, leading to today's modern web applications. This approach of packaging complex technical functionality into well-defined modules greatly simplified the end-user experience for netizens around the world.

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

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

Clearly, we are at a critical juncture in Web3, and building a better user experience is crucial to attracting the next wave of users in large numbers.

From addressing single points of failure and asset custody issues to simply reducing the huge resistance for a brand-new user to start, we must move towards abstracting these complexities and driving towards a smoother future for all user experiences.

Why choose a modular contract account

Clearly, smart accounts are necessary and can be infinitely improved upon. 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, as popular cryptographic libraries do today.

Instead, as popular cryptographic libraries do today, these components can be fortified and maximally reused as modular components to avoid many teams independently writing complex account code. As the security adage goes: "Don't roll your own crypto"—this also applies to account logic. These components can be designed as plugins, and accounts can install and interact with these plugins interchangeably to add the desired functionality.

Once multiple accounts start using multiple plugins, as defined by ERC-6900, the lock-in of suppliers for on-chain account implementations is reduced. Users are protected from the impact of single points of failure and can update their accounts to different implementations, while maintaining most of their existing functionality through the installation of plugins on their accounts.

On these two pillars—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.

Introducing the modular account

Modular account

Alchemy's modular account is an enterprise-grade account designed to scale with user growth and maintain future compatibility through the continued development of the account abstraction ecosystem.

It has scalability and a robust security model to ensure a smooth user experience without the need for trust. We released the modular account with two plugins, which promote significant improvements in user experience and security: the multi-owner plugin and the session key plugin, and provide 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 maintain an active attitude in building and promoting public products that contribute to the development of the account abstraction ecosystem.

Modular account demo: Worth of Words

On-chain zero-knowledge proof word game

One prominent example showcasing the powerful user experience and security features provided by the modular account is the game we built—Worth of Words. Worth of Words is a "Wordle Battle Royale" style word game where players compete with each other to guess their secret words. This game leverages the following features to provide a Web2-like gaming experience:

• Using the session key plugin of the modular account, users only need to sign once to start a new game and then securely allow the browser to sign transactions on their behalf during the game process to achieve a transaction-free experience.
• ERC-4337 Gas Manager, abstracting Gas from the user experience.
• Alchemy's Rundler, relaying UserOperations to the underlying network.
• Zero-knowledge proof, hiding words on the chain.

Learn more about Worth of Words here.

Note: "Worth of Words" is a translation by the Odaily editor and is not an official translation.

Technical Deep Dive

Technical Deep Dive Chart for Modular Account

The modular account uses the UUPSUpgradeable proxy pattern, and the plugins are singleton contracts.

The initial release of the modular account includes multiple components:

Core Account

The base account supports 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 upgradeability, with ERC-7201 to achieve secure storage conflict-resistant upgrades.
• Logic execution triggered by plugins, when called from an allowed plugin, in the context of the account.
• Installation and uninstallation of any ERC-6900 compatible plugins, not limited to Alchemy's.
• View functions to retrieve the account's plugin configuration, including installed execution functions, validation functions, and hooks.
• Strong ordering guarantees for plugin execution.
• Receipt of ERC-721, ERC-777, and ERC-1155 tokens. If there is no token receiver implemented, the contract account cannot receive digital assets through the OpenZeppelin standardized safeTransfer method.

Account Factory

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

In production, it is expected that certain users will be assigned addresses to receive assets before counterfactual deployment 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 compliant with the ERC-1271 standard as owners of the account. The plugin:

• Supports ECDSA signature verification (standard EOA signature verification).
• Supports ERC-1271 signature verification (standard contract owner signature verification).
• Supports multiple equal owners, who have the same root access permissions to the account.
• Implements EIP-712, allowing the client to sign prompts in a structured and readable format.
• Adds user operations and runtime validation functions to the modular account's native functions, including:
• installPlugin and uninstallPlugin
• upgradeToAndCall
• execute and executeBatch

Session Key Plugin

The session key plugin allows the addition of session keys to perform various limited operations on behalf of the account under preset rules. They improve the user experience while providing on-chain security protections, enabling behaviors such as transaction-free experiences and account automation. Session keys are only used in the UserOperation context. The plugin supports:

• Key rotation, allowing the update of keys while maintaining permissions.
• Expiry/time range rules, limiting the access of session keys within specified time ranges.
• External contract address restrictions, limiting the external contract addresses that the session key can call. This restriction can be an allowlist, a denylist, or both.
• External contract method restrictions, limiting the external contract methods that the session key can call.
• ERC-20 spending limits (for a total amount per key, or refreshed at intervals).
• ETH/native token spending limits (for a total amount per key, or refreshed at intervals).
• Gas spending limits (for a total amount per key, or refreshed at intervals). By default, no limit is set, and a session key with permission can consume an unlimited amount of Gas.
• ERC-721 permissions, implemented through contract method restrictions (e.g., allowing safeTransferFrom(address,address,uint256)) and address restrictions.
• Default internal calls are restricted. If no initial external call restrictions are specified when the session key permission plugin is installed, all external calls are by default prohibited.
• Payment master requirements, allowing session keys to be used for user operation verification only when using a specific payment master address. This is another way to prevent session keys from consuming your native tokens on Gas, rather than Gas limits.

Account Library

The account library supports modular account and plugin implementation through reusable code that implements specific functionalities.

Data Structures

• LinkedListSetLib implements a "linked list set" where elements are saved 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 on-chain set. This set requires the collection to prevent the addition of duplicate values, prevent the addition of zero values, and maintain a special value as a "sentinel" to identify the start and end of the list. To achieve this, the available data size is reduced to a maximum of bytes30.
• In addition to supporting these efficient operations, the library supports a less efficient removal operation that does not require knowledge of the predecessor, which traverses the linked list to find the element to be removed.
• Additionally, entries support "flags"—which can be thought of as additional values attached to each entry, similar to a submapping 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 the account. This library is intended to be used by plugins, and if plugins wish to access or update these values during ERC-4337 validation, they must store the values in storage associated with the account.
• CountableLinkedListSetLib extends LinkedListSetLib, allowing a value to be added multiple times. It uses the upper byte (8 bits) of the 14 available flag bits to track this and supports adding an entry up to 256 times. This library does not have a version stored in associated storage.
• The common types and constants used by these libraries are defined in Constants.sol.
• PluginStorageLib is a lower-level library that provides utilities to retrieve storage slots in address-associated storage using different numbers of input data as keys.

Type and Conversion Utilities

• FunctionReferenceLib provides a user-defined value type designed 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 adopted a multi-stage security strategy, with Spearbit conducting a security review of the modular account protocol in 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.

Reports can be obtained from Spearbit and Quantstamp respectively. We are pleased 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 that highlight the security and permission model of the modular account.

Plugin Manifest

The plugin manifest functionality is a key 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 detailing the execution functions, hooks, and permission requests necessary for the operation of the plugin. This can be presented to the user before installing the plugin and granting these requests. This determines permissions at installation, preventing any unexpected runtime behavior.

Call vs. DelegateCall

The modular account only performs calls to plugins, not delegate calls. Delegate calls execute in the context of the account, without auditing the plugin code, making it difficult to limit the potential harm of malicious plugins.

Modular Account Call Flow

The chart below shows the call paths through the modular account. The left-hand flow is the UserOperation path from the ERC-4337 entry point, and the right-hand flow is the runtime path for calls from all other sources, including other contracts.

Upgradeability

The modular account is designed to be compatible for future upgrades and storage conflict resolution. Specifically:

• Thanks to the use of EIP-7201 for initializing storage modes, there is no risk of storage conflicts when upgrading to and from the modular account.

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

Benchmark Testing

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 required to bring mainstream users on-chain, the modular account aims to provide an optimized foundational primitive for a rollup-centric future.

Specifically, it often sacrifices call data usage to increase execution costs for a cheaper experience for end users. Additionally, as a persistent user account, the modular account includes security measures for permissionless interoperable usage, surpassing today's popular embedded account paradigms in every app to help drive a seamless and interoperable future. The account is heavily optimized for daily use, with some security features adding some execution overhead at deployment.

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

*LightAccount is not a modular account, and its inclusion is for reference to the best-in-class smart accounts.

**The ERC-6900 session key plugin offers more robust security controls compared to other products.

Please note that there are trade-offs between optimizations for rollups and optimizations for the first layer of Ethereum and sidechains. These benchmark tests capture performance measured in the rollup ecosystem.

Bug Bounty Program

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

Starting today, anyone can report vulnerabilities in any package of the modular account release 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 developer SDK for building smart accounts, abstracting away the costs and complexities of building on smart accounts. As of today, AccountKit will provide first-class support for the modular account, including multi-owner and session key plugins. The 3.0 version of the SDK greatly simplifies the construction and submission of UserOperations, managing counterfactual addresses, upgrading to the modular account, and using advanced features such as user sessions.

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

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

Future Outlook

Iterating on the Modular Account Ecosystem

We look forward to continuing to collaborate with the ERC-6900 community to develop a robust permissionless plugin and account ecosystem. We are excited to pursue some broader ideas, including:

- Building application-level permission concepts as a combination of plugin-level permissions based on a secure model. Analogous to web2, when installing applications like WhatsApp, the operating system requests a set of permissions that the application, such as WhatsApp, needs to function properly, such as location, camera, microphone, contacts, etc.

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

- Continuing to iterate towards the most hardened, most optimized account implementation. We are excited to explore technologies that simplify and optimize operations, and iterate on data models to improve understanding and reduce end-user costs.

- Collaborating with teams to develop an accelerated interoperable plugin ecosystem. We have already seen several development teams start working, and we look forward to seeing what use cases the ecosystem can propose.

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

- Contributing to R&D efforts for the next wave of challenges. Many converging clues need to be implemented to safely onboard a billion users. Two aspects of the account space we look forward to seeing are cross-chain interoperability and user privacy. These advancements largely hinge on pushing the limits of zero-knowledge engineering and incorporating these primitives into solutions, such as key storage chains, to help manage account configurations deployed across multiple chains.

Leveraging Smart Accounts and L2 to Reduce User Costs

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

Several research approaches have been proposed to reduce these costs, but some methods we are closely watching in 2024 include:

Calldata Compression

As mentioned earlier, the cost of L2 transactions is primarily the data availability cost on L1, not the execution cost on L2. Therefore, reducing the size of data calls can often reduce overall costs by increasing execution costs. The Ethereum Foundation's WAX team has researched and prototyped UserOperation compression and achieved some quite remarkable results, and we are excited to see this technology adopted to improve operational efficiency.

Signature Aggregation

In practice, signature aggregation is a similar technique to reduce data availability costs by aggregating a bundle of signatures into a single fixed cost. Most of the discussion here focuses on BLS signatures, but in reality, this can be extended to other signature schemes through zero-knowledge proofs. We are excited to see some ERC-6900 plugins support BLS signatures and functionalities like zk-R1 or zk-K1 aggregation to achieve similar results on non-aggregate elliptic curves.

Proto-Danksharding

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

Acknowledgments

The work on the modular account goes far beyond Alchemy. First and foremost, we want to thank the dozens of developers working and contributing to ERC-6900, who have driven iterations to safely onboard a billion users.

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

Additionally, we want to thank our excellent audit teams. Security is paramount when dealing with contract accounts. Gerard Persoon, Riley Holterhus, Blockdev, and Christos Pap of Spearbit, and Nikita Belenkov, Alejandro Padilla, Shih-Hung Wang, and Ruben Koch of Quantstamp have been diligent in evaluating and improving the implementation and architecture of the modular account.

We also want to thank the engineering teams at a16z crypto, especially Daejun Park and Matt Gleason, for early form validation meetings on smart accounts and iterating with the modular account as a Halmos testing standard—further improving the security posture and development mindset around secure smart accounts.

Finally, we want to thank the entire modular account ecosystem for the support, discussions, and driving the space forward. Through many early iterations and architectural proposals in collaboration with the broader community, we want to specifically mention the individuals at Safe, Biconomy, ZeroDev, and Rhinestone, who often provide excellent insights and suggestions.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。