Institute of All Things: Exploring the Transformation of Account Systems from Web2 to Web3 through EIP4361

Written by: Wànwù Research Institute Chen Jian Jason

MetaMask officially announced support for EIP-4361 last week, and many friends are confused about this protocol. On the surface, it doesn't seem much different from a regular signature. This article aims to clarify it for everyone. First, it's important to understand that EIP-4361 is actually quite small, but the areas it can extend into are vast.

EIP-4361 is a technical specification proposal related to Ethereum login. Ethereum login SiwE (Sign-in with Ethereum) is a decentralized authentication method that allows users to achieve unified login and control their identity using their Ethereum accounts, rather than relying on traditional username/password authentication used by centralized companies. Vitalik previously mentioned in an interview that he sees three major opportunities for Web3 in 2023, one of which includes Ethereum login. He stated that any technology that helps Ethereum take back login rights from centralized monopolies like Facebook, Google, and Twitter will ultimately enable Ethereum to gain more market dominance in internet applications. Therefore, the login system is an important direction that Vitalik believes is crucial for attracting the next billion users.

In fact, I can sense the internal anxiety within Ethereum right now. Although Ethereum's current position seems unshakeable, the competitive pressure it faces is also very high, especially with high-performance new public chains like Aptos and Sui emerging, as well as the application chain industry represented by Cosmos. This is also why Ethereum must resolutely transition to POS, develop Layer solutions, and implement sharding, optimizing consensus and performance while deepening its engagement in C-end entry-level fields like ENS and login, creating its own moat by binding closely with the C-end. Additionally, it's worth noting that there are three supporting parties behind EIP-4361: the Ethereum Foundation, ENS, and Spruce. Apart from the Ethereum Foundation, the other two are DID companies, which can be said to be establishing industry standards together with the Ethereum Foundation. Therefore, this standard cannot be completely neutral, and it can be seen that the document is deeply tied to ENS, including the ability to resolve ENS domain names. Below is the official website of SiwE: https://login.xyz/

Everyone is already familiar with ENS, but Spruce is relatively unknown, with little coverage and interpretation in the Chinese community. Its mission is to enable users to control their personal data, supported by a host of star investors including A16Z and YC. Its field falls under the broader category of DID, specifically SSI (Self-Sovereign Identity), allowing individuals to control their identity data, including deciding which third-party applications can use it and how. So, if we commonly understand DID as proving who you are through data collection, SSI focuses on the authorization, use, and management of data.

Before discussing Ethereum login SiwE, we need to clarify the traditional account login system and the existing wallet connection signatures to understand the differences and advantages of SiwE.

The traditional account login system uses centralized methods such as phone numbers, emails, and passwords to store user accounts and perform login and verification. User accounts are entirely stored in centralized databases, leading to issues like account cancellation, number transfer, and data leakage. This system has gone through two stages of development. Before the emergence of giant internet companies like Tencent and Alibaba, user account systems were independently maintained by each company or even each product. Generally, there would be a User table to store all account information, including the user's name, password, phone number, and email. Each time a user registered, a new entry would be added to the User table, and subsequent logins would require entering the username and password for matching. Managing a large number of usernames and passwords is cumbersome for users, leading many to set the same password across all products, which results in significant risks. If one product's database is leaked, hackers can use credential stuffing attacks to log into all products. With so many accounts and centralized management, the risk is extremely high. Later, with the widespread use of mobile verification, a painful phase emerged whenever users changed their phone numbers.

As Tencent and Alibaba developed their product matrices and ecosystems, users found it cumbersome to switch between different accounts when logging into various products. The biggest issue was that accounts across different products were isolated, preventing Tencent and Alibaba from fully utilizing user data. For example, if I bought bed sheets on Taobao and ordered takeout on Ele.me, data analysis could label me as a "working single young man." However, because these are two separate products with their own account systems, they cannot determine the relationship between users of these two products. The methods to address this issue include using a unified account for matching identification, such as registering with the same phone number across all products, or implementing single sign-on (SSO) or unified login methods, like the commonly used WeChat login. The following diagram illustrates the WeChat login process, where users can use WeChat as a login method, eliminating the redundant process of re-registering and managing accounts. This lowers the user entry barrier for third-party products, thereby improving customer acquisition. For WeChat, having more users and third-party products logging in through WeChat significantly enhances its competitive barrier.

The toC login system can be addressed by ecosystem-level enterprise solutions like Tencent and Alibaba. The toB login system faces even more complicated issues, as enterprises often use a variety of products, including third-party custom purchases, SaaS vendors, and self-developed solutions. Additionally, with a large number of employees, issues related to permissions and data security arise. Therefore, how to enable thousands of employees to smoothly and securely use hundreds of internal products is also a problem that needs to be solved, with companies like Authing and Okta providing single sign-on solutions for enterprises.

The above outlines the main evolution of the account identity system in traditional Web2 over the past 20 years. The most intuitive difference for ordinary users in Web3 is that they can use a single wallet to access all Web3 products. This is the most direct way for users to feel the meaning of a globally interconnected network, or to truly realize the concept of the "Internet."

However, due to the nature of on-chain assets, individuals must take responsibility for their own security. Unlike Web2, where there is a third-party platform with responsibilities and obligations to ensure user fund safety, users now face the risk of being exposed to environments filled with phishing websites. Once they perform related signatures and authorizations, their assets may be stolen. Currently, wallets like MetaMask disclose very little information during interactions, and the readability is poor. Most non-technical users often cannot understand what the pop-up content requesting signatures and authorizations means. Therefore, strict standards need to be established for actions that request user signatures and authorizations, fully informing users of the content they are executing.

EIP-4361 clarifies the standard process for how Ethereum accounts can be authenticated through off-chain services. This authentication is performed by signing a standard message format, which is structured using session details, security mechanisms, and scopes, and is presented with standard field parameters. This provides developers with the infrastructure to create a unified identity layer for Web2 and Web3 applications. This process is free for users; they only need to sign the message without needing to transact on the blockchain or pay gas fees to miners.

As stated in the document, "As a web2 company, you will have the opportunity to be the first touchpoint for users entering web3 and help them control their digital identity." SiwE aims to standardize the process of connecting wallets, sending signatures, and completing logins, allowing more Web2 products to integrate and become a login option. Just like when using certain products, we can choose login methods including Google login, Twitter login, and Facebook login, we can also add an Ethereum login option, thereby covering a vast number of Web2 products through this login entry.

The motivation for these Web2 products to integrate SiwE is that they can provide corresponding services based on users' publicly available on-chain assets. For instance, logging in with Google or Twitter only completes the login action, but logging in with Ethereum allows for more specific services based on the user's asset holdings, such as offering a discount if they hold a certain NFT.

The proposal link for EIP-4361 is as follows: https://eips.ethereum.org/EIPS/eip-4361. The following image shows the template message for SiwE, the complete ABNF, and the corresponding pop-up style. It can be seen that it reveals the content the user needs to execute in a very structured and standardized manner: Message, the URI of the login request, the current Version, the Chain ID of the login, a Nonce to prevent replay attacks, the Issued AT time, and the Expires AT time.

The ABNF is the Augmented Backus–Naur Form, a formal system for describing a language as a bidirectional communication protocol. This is also a key point of EIP-4361, standardizing the login process.

As mentioned earlier, EIP-4361 has ENS behind it, so this proposal also includes a deep integration with ENS. Using SiwE can resolve ENS data, including ENS names, ENS avatars, and any resolvable resources specified in ENS documents. As shown in the image below, ENS can bind a wealth of information beyond just its domain name, including wallet addresses, emails, Discord, Twitter, etc.

In addition to standardizing logins, EIP-4361 can also help prevent phishing attacks to some extent. Currently, a large number of users fall victim to phishing websites every day. The login process using EIP-4361 in wallets involves three steps:

1. Verify the message and check if the signature content conforms to the ABNF standard format mentioned above.

2. Verify the domain name. If it meets the EIP-4361 login standard, the wallet will check whether the login URL matches the one submitted in the ABNF, thus avoiding confusion.

3. Then create the Ethereum login pop-up, which must fully present all terms to the user and require them to scroll to the bottom of the page before signing, similar to many app user agreements, ensuring that users nominally read everything before proceeding.

The design specifications mention four points:

1. A human-readable page must be presented, with most content not aimed at machines, such as JSON, hexadecimal code, base encoding, etc. This addresses the issue I mentioned earlier regarding wallet interactions, where non-technical users often do not understand what they are clicking on.

2. The application's backend must provide full support for its terminals without forcing modifications to the wallet. This primarily requires that integrating SiwE does not create an experiential barrier for users.

3. Applications that have already used SiwE should have a simple and direct upgrade path. As mentioned earlier, there will be a version number indicating SiwE, and future upgrades must ensure compatibility.

4. Adequate preparations must be made to prevent replay attacks and malicious signatures.

Additionally, the document also addresses key management issues. SiwE hopes to enable many Web2 products to integrate and bring more off-chain users into the Web3 world. However, mainstream users are already accustomed to the "password recovery" feature of Web2 products. In Web3, if you lose your private key, it cannot be recovered. This presents a high educational barrier for many Web2 users. There is also great anticipation that the popularization of account abstraction (AA) wallets can effectively solve this problem.

The above is an interpretation of the transformation of the account system from Web2 to Web3 based on EIP-4361. In fact, EIP-4361 itself is not as impactful as events like account abstraction or the Shanghai upgrade; it is more about establishing a standardized industry norm. However, it is precisely these subtle optimizations that will gradually enhance the experience for users transitioning from Web2 to Web3.

While writing this article, I consulted several friends and would like to express my special thanks to Zhou Zainan, Yu Xian, Fang Jun, and others for their discussions and insights!