Note: Before reading this article, it will be helpful to have a basic understanding of ERC-4337 and account abstraction. You can learn more from this and this guide. It will also be helpful to learn about the various types of crypto wallets, especially smart contract wallets (accounts).
Do you remember two-factor authentication (2FA)? More likely than not, you’ve probably used it to authenticate the login to your bank account, that Netflix account you share with your family, or maybe even a crypto exchange during the last bull run. 2FA has become an integral part of security in our regular interactions with the digital world. As we enter a new digital epoch, there is a need for more innovative authentication models more suitable to Web3.
This brings us to EIP-6662, an Ethereum Improvement Proposal designed to create a new authentication model for Web3 wallet and other dApps. Aligned with the ethos of Web3, think of it as a method to implement “decentralized 2FA” into Web3 wallets and dApps. This article will introduce EIP-6662, including a brief segment about its background, motivation, and how it works, then elaborate on the value it provides for developers and users in the EVM ecosystem.
Let’s get started!
Background
Drafted in March 2023, EIP-6662 is an innovative proposal that outlines the potential future of authentication for dApps in the EVM ecosystem, and the broader multi-chain Web3 ecosystem. Spearheaded by talented developers–Shu Dong, Peter Chen, Zihao Chen–who are all founders of Hexlink, EIP-6662 defines a new IAccountMetadata interface for all dApps, including Web3 wallet.
Why is EIP-6662 important for dApps and Web3 wallets?
The proposal not only introduces an unified account view on dApps for users, but also, using the new IAccountMetadata interface, it proposes a user-friendly authentication model for Web3 by enabling on-chain storage of authentication data through one-time publishing. With this approach, dApps can proactively access the data from the blockchain, eliminating the need for users to repeatedly log in with their wallets and connect them to dApps in advance. Ultimately, this promises to offer a more flexible and streamlined authentication process, providing an alternative to the existing methods.
How does EIP-6662 work?
EIP-6662 is actually an extension of EIP-4337 (also known as ERC-4337), the Ethereum standard for account abstraction, meaning it proposes the novel concept of an extended IAccountMetadata interface for the ERC-4337 IAccount interface that facilitates a cutting-edge authentication workflow. This also means that the EIP-6662 IAccountMetadata interface is entirely backward compatible with ERC-4337.
As we mentioned earlier, EIP-6662 aims to define a more user-friendly and flexible authentication model for dApps and Web3 wallets on Ethereum. The next section will explain how it aims to achieve this by breaking down the technicalities of the proposal.
EIP-6662: Let’s get technical
The technical specifications of EIP-6662 introduce a novel authentication flow that enhances user flexibility and convenience in Web3. The authentication flow involves various components, including the Authenticator, which can be either an offline authenticator mobile app or an online cloud service. The Relay service plays a pivotal role by forwarding requests from dApps to the Authenticator. If the Authenticator is online, it can directly serve as the Relay service, establishing a seamless connection.
To implement this workflow, dApps require essential information:
- The location of the authenticator: This is accomplished through the relayURI field in the struct AuthenticationInfo. Users publish the URI as account metadata, facilitating service discovery by the dApp.
- The format of AuthenticationRequest: Addressed by the schema field in struct AuthenticationInfo, the schema defines the structure of the AuthenticationRequest object consumed by the authenticator. Additionally, it allows for defining extra fields for the relay service to enable flexible access control.
Relay Service Selection ensures smooth operation, allowing each authenticator to provide a list of relay services. The dApp pulls through this list to find the first workable service, with all relay services under each authenticator adhering to the same schema.
Furthermore, Signature Aggregation supports multisig authentication if multiple AuthenticatorInfos are provided under each smart contract account. In this setup, each authenticator can independently sign and submit user operations to the bundler, and these signatures will be aggregated by the Aggregator defined in ERC-4337.
By fusing these technical elements, EIP-6662 presents a practical and user-centric approach to authentication in the EVM ecosystem This leads us to a question you may be wondering: What does this mean for me, a builder in the EVM ecosystem?
What value does EIP-6662 provide to developers in the EVM ecosystem?
Still relatively underrated, EIP-6662 can provide a lot of value for developers looking to improve the user experience for their dApps and Web3 wallet. Because EIP-6662 is still in the nascent stages, it has a lot of untapped potential–as seen in its community discussions–that developers can contribute their insights and skills to. In terms of value for developers, these are the four key takeaways from EIP-6662 we thought were most important:
1. Enhanced user experience
Through the implementation of the new IAccountMetadata interface and authentication workflow, developers can create dApps and Web3 wallets that are significantly more user-centric for transactions. Users can use an universal interface to login to their dApps and have a more secure experience without exposing their private keys.
2. Chain-agnostic user interface
In the multi-chain EVM ecosystem, it’s imperative for developers to focus on chain-agnostic user interfaces, which makes it easier for their users to interact with dApps. By publishing their authenticator information on-chain to the new IAccountMetadata interface, users enable dApps to intuitively access the necessary data, streamlining the process and removing the need to share information with individual dApps.
3. Smart contract account compatibility
Because EIP-6662 is an extension of ERC-4337, EIP-6662 also enables users to use ERC 4337-compatible smart contract accounts (wallets) as their wallet addresses. We recommend reading this article to learn about the benefits of ERC-4337 and account abstraction. Additionally, we recently released our newly ERC 4337-compatible Blocto Wallet–the quickest way to seamlessly experience account abstraction. Learn more here!
4. Flexible customizability of authentication methods
The IAccountMetadata interface empowers developers to customize authentication methods and separate them from wallet contract logics. This flexibility allows users to easily transfer their account data to other wallets supporting this interface. For dApps, this means Web2 compatibility, enabling users to log in with their Web3 account using Web2 credentials from the account layer.
DApps can verify Web2 credential signatures, retrieve the associated Web3 account address, and seamlessly connect with users’ Web3 accounts, eliminating the need for multiple wallets. Wallets, in turn, transform into dApps, providing users with a seamless asset management experience, decoupled from the wallet’s core functionalities. This user-friendly approach enriches the EVM ecosystem by enhancing the interoperability and ease of access for both developers and users.
End note
In conclusion, developers should consider exploring EIP-6662 within the EVM ecosystem if they are interested in contributing to the development of a new authentication model for a dApp/Web3 wallet or learning more about extensions of ERC-4337. Not only does EIP-6662 provide developers with an opportunity to build dApps with an enhanced UX, chain-agnostic UI, and smart contract account compatibility, it also empowers developers to flexibly customize authentication methods.
Moving forward, developers can also ponder about the extension of the IAccountMetadata interface per various requirements (e.g. defining new avatar field for profile displays) and security considerations like end-to-end data encryption for dApp to authenticator transmissions, which would protect user privacy and prevent malicious attacks.
For further reading on account abstraction, check out these helpful articles:
