ERC-6900 & Modular Account Abstraction: What It Means for Smart Contract Wallets

erc 6900 and modular account abstraction: what it means for smart contract wallets

As developers, we constantly seek ways to push the boundaries of innovation and create more versatile solutions. Have you ever wondered how you can enhance the customizability of a smart contract wallet and unleash its true potential? Get ready to learn about a newly deployed Ethereum standard that enables modular account abstraction, which will revolutionize the way developers interact with smart contracts: ERC-6900.

In this article, we’ll embark on an exciting journey to explore the impact of ERC-6900 and integration of modular account abstraction within smart contract accounts (FYI: Smart contract account and smart contract wallet may be used interchangeably throughout this article.) and discover the potential opportunities they present for both developers and users to unlock new realms of innovation in the EVM ecosystem.

Before we get started, a quick shout-out to Konrad from Rhinestone who wrote the OG content on the architecture that ERC-6900 is based on! Now, are you ready to delve in and learn more about ERC-6900 and modular AA? Let’s dive in–starting with a brief introduction to ERC-6900!

What is ERC-6900?

Deployed in April 2023, Ethereum standard ERC-6900 proposes the notion of modular smart contract accounts and account plugins, which essentially enables composable logic (think of LEGO building blocks!). According to the proposal, ERC-6900 is compliant with the account abstraction standard ERC-4337, in addition to being inspired by the “diamond pattern” of ERC-2535 to define UI for querying and updating modular function implementations.

You can see ERC-6900 as an extension of the objectives that ERC-4337 aims to accomplish, specifically the goal of abstracting logic for execution and validation for each smart contract wallet. ERC-6900 enables developers to abstract the logic for execution and validation, in order to create new features for smart contract wallets.

ERC-6900’s modular approach recategorizes the functionality of smart contract wallets into a modular SCW with three distinct categories (listed and defined below): 

  • validation function: enables validation of caller’s authenticity and authority to the account
  • execution function: enables execution of custom logic allowed by the account
  • hook: enables execution of custom logic and authentication of pre/post-execution functions

These modular functions are then implemented into external contracts and have an expected execution flow from smart contract wallets.

What is modular account abstraction in the context of smart contract wallets?

Modular account abstraction is a subgroup of AA–which is its own ecosystem in its own right– which introduces modular smart contract wallets (accounts) to the broader EVM ecosystem. Modular smart accounts not only enable significantly better customizability for users, but also simplifies development of smart contract wallet features for developers. To better understand modular account abstraction, let’s learn more about what “modules” are in the context of modular AA.

What are modules and why are they important?

Often referred to as plugins (as stated in EIP-6900) or facets (as stated in ERC-2535), modules are the “LEGO building blocks” that enable the features to extend the functionality of smart contract wallets, making them extremely valuable components of the AA ecosystem. You can also think of them as external smart contracts, authorized by the user, that implement extended functionality for a smart contract wallet, while simultaneously isolating module logic from the core smart contract. 

Among the various functionalities that modules can enable are:

  • Usage of different signature schemes
  • Triggering specific actions upon token transfers
  • Daily expenditure limits
  • Budgets that permit spending without requiring consent from additional owners
  • Recurring transactions via session keys
  • Scheduled and/or automated transactions on specific dates
  • Social recovery

These are only a few examples of module functionality– with creativity, the sky’s the limit!

An informative diagram from our friends at Safe depicting module interaction with a smart contract account
An informative diagram from our friends at Safe depicting module interaction with a smart contract account

Lastly, there are different approaches to building and executing modules, depending on the implementation of smart contract wallets. Additionally, the structure of a module depends on the targeted account implementation of a feature. For example, our friends at Permissive are one team actively building a module for an authorization framework for smart contract wallets, primarily focusing on granular access control that allows users to give permission to various parties for specific actions that are executed by the smart account. 

Modular implementation requires a certain level of trust between users who want certain features and module developers who build those features, which leads us to another aspect of the modular AA ecosystem–the module registry.

The module registry: a trust mechanism for module development

The existing modular implementations of smart contracts and smart accounts have relied on a trust assumption between users and module developers. However, the ultimate goal is to eliminate this assumption and enable non-technical users to securely add modules to their wallets. To achieve this, a module registry can consolidate trust assumptions between users and developers into a single entity.

Although this suggests a centralized approach, the vision from developers and the community is far from that–the solution is a permissionless, open registry. Ultimately, this allows different parties with varying security assumptions to participate, and users can choose whom to trust based on their preferences.

Modular UI: the overlooked, yet valuable member of the modular AA family

According to Yoav Weiss of the Ethereum Foundation, an important but often overlooked aspect of modular AA is the modular UI, or client-side design. Modular UI is crucial because UI components must be tailored to activate specific on-chain functionalities, such as function selectors, argument encodings, and potential client-side or server-side logic. Creating a secure modular UI to accommodate external module developers is vital for the successful growth and development of modular AA and smart contract wallets.

Moving on, let’s head over to a very important section on learning more about the value of ERC-6900 for developers.

What value does ERC-6900 and modular AA offer developers?

The implementation of modules via modular AA not only enables developers to build more customizable and extensible features for smart contracts, but also the capability to reuse the modules, rather than having to rewrite the entire contract to add features. In other words, through the implementation of modules, ERC-6900 further enhances the flexibility of smart contract development for builders looking to create new features for a smart contract wallet.

Moreover, ERC-6900 supports the collaboration of feature implementation between both module developers and wallet developers, by outlining the implementation of a modular smart contract wallet (account) that seamlessly accommodates various modules adhering to the established standards.

Lastly, by adopting ERC-6900, developers can not only build smart contract wallets that enable modular, upgradeable execution, and validation logic, but also enhance the security and interoperability of module development. For further reading on module development, check out this helpful guide from Safe and another one from ZeroDev.

Future prospects for ERC-6900

Because ERC-6900 is still relatively new and subject to future changes, it is difficult to see what the final standard will look like. However, several propositions have been made:

  • Updating all function invocations, including execution functions, validation functions, and hooks to use call instead of delegatecall to ensure that storage and execution code are segregated on a per-module basis, eliminating the risk of unintended or malicious storage overrides among modules, fundamentally transforming the trust model for modules
  • Merging global hooks and regular hooks into a unified notion called “hook groups,” which will have the flexibility to include each hook type as an optional field and proper executability for accounts to establish a connection between execution functions and the applicable hook groups
  • Introducing pre-validation hooks, a new type of hook that not only executes before user op validators or runtime validators, but also serve the purpose of performing permission checks and other pre-transaction verifications unrelated to signature validation

End note

In summary, the deployment of ERC-6900 and the integration of modular account abstraction within smart contract wallets offer exciting possibilities for developers. With the introduction of modular smart contract wallets and account plugins, developers can enhance the customizability and versatility of their dApps. By implementing modular functions and adhering to the ERC-6900 standard, developers can create composable logic, introduce features like signature schemes and recurring transactions, and improve collaboration between module and wallet developers. 

As ERC-6900 continues to evolve, proposals such as updating function invocations, hook groups, and pre-validation hooks hold promise for enhancing the security and functionality of modular account abstraction in smart contract wallets. Ultimately, by embracing ERC-6900, developers can unlock new realms of innovation and create more powerful, yet flexible smart contract wallets.

For further reading on the broader AA ecosystem, you can check out this article regarding misconceptions and challenges of ERC-4337. Also, don’t forget to stay informed on the top ERC-4337 projects to watch in 2023 and keep exploring the Ethereum ecosystem–beginning with OpenBlocto, the starting ground for AA SDKs!

References