A foundational layer to modular account abstraction
Part 1: Introducing the Module Registry
Starting in the first half of 2023, the idea of modularizing smart accounts started to gain a lot of interest, with projects like Biconomy and ZeroDev releasing modular, 4337-native account implementations and getting a lot of traction with users and developers. We think that this leads to an ecosystem in which smart accounts can become a platform for permissionless innovation while also giving users a far superior experience by being able to customize how their accounts work.
However, to reach this goal, there are several significant problems to be solved. The two most important ones are interoperability and security. In this blog series, we will focus on the security problem and how the Module Registry aims to solve it. On a high level, the Module Registry is an open-source contract that allows attesters to make (security) statements about modules and users to query these to ensure that a module they are about to install or use is secure. We have also been supported by the ERC-4337 team at the Ethereum Foundation with a grant to build the Module Registry and ensure security of the modular account abstraction ecosystem.
Security challenges for modular accounts
The most important security challenge is determining whether modules are safe to use at installation and execution time. The more rights a module has on the account, the more important it is to ensure this. For example, if a module has write access to the account, a malicious or compromised module can easily change the owners of an account and completely take over the account. If a module can propose transactions to be executed on the account without additional validation, then this module could drain the account.
Ensuring the security of modules at installation and execution time is non-trivial, especially on-chain. One solution to this problem is implementing some sort of permissions system that an account implements and verifies on-chain. This system could allow modules to self-declare permissions, which are enforced by the account whenever a module is called. Examples of such permissions could be write-access on the account or the ability to execute a transaction on behalf of the account.
However, implementing this permissions system in such a way that the account checks all the permissions and edge cases on-chain is infeasible today and likely also in the future on public blockchains. A more feasible approach to ensuring the security of modules is through attestations. In this context, the term attestation refers to some statement made about a smart account module, most commonly about the security of that module. Using attestations as a building block, it is possible to create a registry of attestations on-chain that a smart account can query whenever the user wants assurance that their module is secure, as determined by the creator of that attestation (the attester).
The Module Registry
This approach of an attestation registry is what we are currently pursuing in order to give users more security guarantees when adding modules to their smart accounts. However, there are further constraints when pursuing a solution like this. The most important of these constraints are:
- building this system in a permissionless way that avoids lock-in,
- building this system to be as secure as possible,
- aligning the incentives of the different actors,
- creating as little fragmentation as possible for users and module devs,
- making the registry as cheap as possible to query for the user and
- ensuring flexibility so that the needs of various actors are met.
Based on these constraints, we set out to build the Module Registry, an open-source, permissionless attestation registry that smart accounts can query to determine whether a module is considered secure.
The first main characteristic of the Module Registry is that it is a singleton, meaning that it is designed to be used as the only registry for attestations on modules. The biggest advantage of this design is that there is no module fragmentation, meaning that developers only need to register their modules on one entity to achieve complete distribution and users can discover the entire supply of modules in a single place.
One major downside of the singleton design is that it creates a central point of dependence, potentially leading to significant lock-in for users and developers. However, this is not the case with the Module Registry since it is free, permissionless, and ownerless, meaning that, after deployment, we have no more control over the registry than anyone else. Because of this, any entity can create attestations and users can delegate their trust to any number of these entities when determining whether a module is secure. This ensures that there is absolutely no lock-in that forces a user to trust any specific party.
The second main characteristic of the Module Registry is that it is extremely flexible in order to cater to the needs of the different entities that want to use it, whether that be attesters, users, smart account developers, or anyone else. This article won’t go into too much technical detail around this flexibility (it will be covered in the second part of the series), but on a high level, the Module Registry consists of specific components, called Schemas and Resolvers, that allow for custom logic to be introduced into the Module Registry by anyone.
One example of why this is needed is if an entity wanted to build a marketplace for modules on top of the registry and use only a subset of modules, such as ones attested to by trusted auditors. While building this marketplace, an entity might want to enforce certain rules, for example, that all the attestations follow the same data structure that is decoded in a frontend and presented to users. By building the registry to be extremely flexible, entities can implement custom logic like the example above without needing to spin up their own module registries and fragmenting module liquidity, leading to worse distribution for devs and harder discoverability for users.
Finally, a core characteristic of the Registry is that it is cheap to use. The base cost for querying whether a module is safe is under 8,000 gas (less than 0.01 cents on any L2s currently). In the chart below, you can see a comparison of querying attestations on a module using increasing numbers of attesters between the Module Registry and extremely minimal, single-attester registries. As you can see below, not only does having multiple single-attester registries reduce module liquidity and thus make distribution and discoverability harder, it is also only cheaper when querying a single attester and then very quickly becomes a lot more expensive, roughly by 2,500 gas per additional attester.
Conclusion
As mentioned above, the remaining two parts of this blog series will cover the implementation details of the Registry in more technical depth. The next part will cover the general topic of attestations, including how they are created and stored and how the Registry can be extended to implement custom behavior. The third part will go into more technical details on querying the Registry from the smart account side, including gas efficiency and ERC-7484, which standardizes registries and smart account adapters.
The Module Registry is open-source and currently undergoing testing on testnets before being audited and deployed on mainnets. If you have any ideas, suggestions or feature requests, feel free to take out an issue on the repo or create a pr, we welcome any contribution. If you have any further questions, feel free to reach out to me or anyone else from the rhinestone team.
