Original title: 《 Wanwu Research Institute: From EIP4361, explore the transformation of Web2 to Web3 account system 》
Original author: Chen Jian Jason, Wanwu Research Institute
MetaMask announced its support for EIP-4361 last week. Many friends are confused about this protocol. On the surface, it is not much different from ordinary signatures. This article interprets it for everyone. First of all, we must understand that EIP-4361 is actually a small matter, but the field that can be extended from it is very large.
EIP4361 is a technical specification standard proposal related to Ethereum login. Ethereum login SiwE (Sign-in with Ethereum) is a decentralized identity authentication method that enables users to use their Ethereum accounts to achieve unified login and control identity, rather than relying on traditional username/password authentication used by centralized companies. In a previous interview, Vitalik once proposed the three biggest opportunities for Web3 in 2023, including Ethereum login. He said that any technology that helps Ethereum take login rights away from centralized monopolies such as Facebook, Google, and Twitter will eventually enable Ethereum to gain more market dominance in Internet applications, so the login system is what Vitalik believes is an important direction for competing for the next billion people.
In fact, for Ethereum, I can feel its internal anxiety now. Although Ethereum's current position seems unshakable, the competitive pressure it faces is also very large, especially with high-performance new public chains such as aptos and sui in front, and application chain industry chains represented by cosmos in the back. This is why Ethereum must be so determined to switch to POS, engage in Layer, and do sharding, and optimize consensus and performance. On the other hand, it is also facing C-end entry-level fields such as ENS and login. Go deeper, deeply bind with the C-end to build its own moat. It is also worth noting that there are three supporters behind EIP4361, namely the Ethereum Foundation, ENS and Spruce. In addition to the Ethereum Foundation, the other two are DID To some extent, it can be said that the two DID companies and the Ethereum Foundation jointly established industry standards, so the standard cannot be completely neutral. It can be seen that the binding with ENS in the document is also quite deep, including the ability to resolve ENS domain names.
Among them, everyone is already familiar with ENS, but is relatively unfamiliar with Spruce, which is rarely reported and interpreted in the Chinese area. Its mission is to enable users to control their personal data, and it has received support from a number of star capitals including A16Z and YC. Its field is classified as SSI self-sovereign identity under the DID category, which enables individuals to control their own identity data, including deciding which third-party applications can use it and how to use it. So if we often understand that DID is to prove who you are after collecting data, then SSI focuses on authorization, use and management at the data level.
The traditional account login system uses mobile phone numbers, email addresses, passwords, etc. to centrally save user accounts and log in and verify them. User accounts are completely stored in centralized databases, so there are problems such as cancellation, transfer, and data leakage. It has gone through two stages of development. Before the emergence of giant Internet companies with their own ecosystems represented by Tencent and Alibaba, the user account system was independently maintained by each company or even each product. Generally speaking, there will be a User table to store all the user's account information, including the user's name, password, mobile phone number, email address, etc. When a user registers, a piece of data will be stored in the User table, and the user name and password will be entered for corresponding matching when logging in later.
Later, as Tencent and Alibaba had their own product matrices and ecosystems, users had to log in between their own products and switch between different accounts, which was very troublesome. The biggest problem was that the accounts between each product were isolated, which prevented Tencent and Alibaba from fully "utilizing user data." For example, if I bought bed sheets on Taobao and ordered takeout on Ele.me, then through data analysis I could actually be labeled a "working single youth." However, because these are two products, each with its own account system, there is no way of knowing the relationship between the users of the two products.
The method is either to match and identify through a unified account, such as using a mobile phone number to register, so that all products that use the same mobile phone number are the same person, or to use a single sign-on or unified login method, such as the most commonly used WeChat login. The following figure is a flowchart of WeChat login. Users who use WeChat as a login method are exempted from the redundant process of re-registering and managing accounts, which reduces the user's usage threshold for third-party products and better acquires customers. For WeChat, if more users and third-party products use WeChat as the account login entrance, it can greatly enhance its competitive barriers.
The toC login system can use ecological-level enterprise solutions such as Tencent and Alibaba. The toB login system also faces more troublesome problems, because with the development of the enterprise, the internal products used will be varied, including third-party customized procurement, SaaS manufacturers, self-research, etc., plus the large number of employees involves a large number of permissions, data security and other issues, so how to enable tens of thousands of employees to use hundreds of internal products smoothly and safely is also a problem that needs to be solved. Companies such as Authing and Okta provide single sign-on solutions for enterprises.
The above is the main evolution of the account identity system of traditional Web2 in the past 20 years. The most intuitive difference in the experience of Web3 for ordinary users is that all Web3 products can be used with one wallet. This is the most direct way for users to feel the meaning of the global network of blocks, or to truly realize the "interconnection" network.
However, due to the characteristics of on-chain assets, everyone is responsible for their own security. Unlike Web2, there is no third-party platform that has the responsibility and obligation to ensure the security of user funds. As a result, users will be exposed to a large number of phishing websites. As long as relevant signatures and authorizations are made, assets may be stolen. In particular, the information disclosed during wallet interactions represented by metamask is too little, and the readability is very poor. People with non-technical backgrounds often don’t even understand what the pop-up content requiring signatures and authorization means. Therefore, it is necessary to formulate strict standards for the action of requesting user signatures and authorizations, and fully tell users what to execute.
EIP-4361 clarifies the standard process for how Ethereum accounts are authenticated by off-chain services, so that authentication is performed by signing a standard message format, which is structured using session details, security mechanisms, and scopes, that is, it will be displayed with standard field parameters, providing developers with the infrastructure to create a unified identity layer for Web2 and Web3 applications. This process is free for users, and only requires signing the message, without the need to trade with the blockchain or pay Gas to miners.
As stated in the document, "As a web2 company, you will have the opportunity to become the first point of contact for users to enter web3 and help them control their digital identity." SiwE hopes to standardize the process of connecting wallets, sending signatures, and completing logins, so that more Web2 products can be connected and become a login option, just like when we use certain products, we can choose login methods including Google login, Twitter login, and Facebook login. Now we can put an Ethereum login, and embed the login entry to cover a large number of web2 products for users.
The motivation for these web2 products to access SiwE is that they can provide corresponding services based on the user's public on-chain assets. That is, if you log in with Google or Twitter, you only complete the login action, but if you log in with Ethereum, you can provide more specific services based on the assets held by the user, such as holding a certain NFT and getting a 20% discount.
The proposal link for EIP-4361 is as follows: https://eips.ethereum.org/EIPS/eip-4361 The figure below shows the template message of SiwE, the complete ABNF and the corresponding pop-up window style. It can be seen that the content Message to be executed by the user, the URL URI for requesting login, the current version Version, the chain Chain ID to be logged in, the Nonce to prevent replay attacks, the effective time Issued AT and the end time Expires AT of login are revealed in a very structured and standardized way.
ABNF is the Augmented Backus–Naur form, which is a formal system for describing a language as a two-way communication protocol. This is also the focus of EIP-4361, which standardizes the login process.
As mentioned above, EIP-4361 is backed by ENS, so the proposal also includes a deep embedding of ENS. SiwE can be used to parse ENS data, including ENS names, ENS avatars, and any resolvable resources specified in the ENS document, as shown in the figure below. In addition to its own domain name, ENS can also bind a lot of information including wallet addresses, email addresses, discord, twitter, etc.
In addition to standardized login, EIP-4361 can also prevent phishing attacks to a certain extent. Currently, a large number of users have their assets stolen by phishing websites every day. EIP-4361 has three steps in the process of wallet login
1. Verify the message and check whether the signature content conforms to the ABNF standard format mentioned above
2. The backend of the application needs to provide fully available support for its terminal, and there is no need to force the wallet to be modified. This is mainly to require that there should be no experience threshold for users when accessing SiwE
In addition, the document also mentions the key management issue, that is, because SiwE hopes to have many Web2 products that can be connected and bring more non-circle users into the world of Web3, but mainstream users are already accustomed to the "retrieve password" function of Web2 products. In Web3, if your private key is lost, it cannot be retrieved. Therefore, this issue has a high educational threshold for a large number of Web2 users. In fact, we also look forward to the popularization of account abstraction AA wallets to truly and effectively solve this problem.
The above is an interpretation of the change in the account system from Web2 to Web3 based on EIP-4361. In fact, EIP-4361 itself is not an event with a huge impact like account abstraction and Shanghai upgrade. It is more about establishing a standardized industry standard, but it is precisely this kind of silent optimization that will gradually improve the experience of Web2 and Web3 users.
Original link
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia