来源 | blog.spruceid.com
作者 | Rocco
“使用以太坊登录” (Sign-In with Ethereum, SIWE) 颠覆了用户在互联网上的选择。
用户不再需要向一些大型中间商妥协，现在可以使用控制其区块链账户的同一个私钥直接登录 (不需要经过中间商)。通过 SIWE，我们开辟了另一条道路，大公司不再能剥夺用户访问服务的能力，也不能监视他们的行为。
SIWE 是一个完全公开的认证标准，通过与 dapp、app、钱包、安全公司等社区成员的公开讨论来实现。你可以在网站 login.xyz 上找到所有的会议记录和笔记。这种方法与科技巨头或政府供应商的专有身份系统的封闭式开发大相径庭 (受到隐私和数字权力倡导者的抗议)。
相比之下，Sign-In with Ethereum (EIP-4361) 为以太坊账户定义了一种开放的知识共享 (creative commons, CC) 签名格式，以安全地验证任何基于网络的服务。SIWE 由社区构建，获得以太坊基金会和 ENS 的直接支持，并且 Spruce 于去年年底开始负责该项目。我很高兴能在这里讨论 “使用以太坊登录” 的意义，以及对于 Web3 的所有构建者来说它是如何超越 “连接钱包” 的。
连接钱包 vs. 使用以太坊登录
“连接钱包” 这个按钮是现在 dapp 的主要功能。点击这个按钮，用户就开始了与 Web3 和区块链交互的旅程。
通过连接钱包，应用程序可以知道你使用的是哪个账户；然而，仅此而已。你的钱包更容易了解你想用哪个账户来与智能合约互动、发送加密货币，甚至通过 dapp 对信息进行签名。连接钱包的功能非常简单 —— dapp 对你 “毫无记忆”，只是为简单的交互搭建了一个平台。
当应用程序想要和用户进行更丰富的情境交互 (contextual interactions) 时，比如加载用户的偏好或隐私聊天讯息，我们首先需要确保我们是在和该账户背后的实际私钥持有者对话，而不是某个假装对账户持有控制权的人。“连接钱包” 不提供这种保证，但 SIWE 可以。换句话说，我们需要对用户进行身份验证，以便与他们建立一个 session，然后安全地读写他们的数据。为了说明两者的区别，我举了以下两个例子 —— 连接钱包的 Carl 和建立 session 的 Sam：
(译者注：Session 在是一种用来在客户端与服务器端之间保持状态的解决方案。其基于思路是：客户端第一次访问时，服务器端生成一个 session id 返回给客户端，当然服务器端也会把这个 session id 存在内存中，客户端得到这个 session id 后，在后续的每个请求中会把这个 session id 传回服务器，这样服务器查询自己内存就知道这个客户端曾经访问过。Session 可以用来实现用户的登录认证。服务器端生成的 session id 传回客户端后，往往会保存在 cookie 中，所以 Session-based 认证也称为 Cookie-Based 认证。来源)
Carl 使用 dapp 并有一个很好的体验。他可以在 Uniswap 上进行交易，在 Aave 上借贷，甚至在 OpenSea 上购买 NFT。进行这几项操作只需要连接他的钱包。Carl 的操作一直都挺顺利的，直到有一天，他遇到了这样的问题：他希望这些 dapp 能够记住他的一些情况，以便在他第三次、第四次和第五次使用这些 dapp 时，能给他更好的体验。
Carl 在想，如果 Uniswap 能自动导入他的优先清算权，Aave 能够记住他最喜欢的借贷市场，甚至 OpenSea 能记住他的名字而不是 0x2Fe1a3... 这样的账户，他的体验会好很多。Carl 每次连接他的钱包时都要从头开始。
Sam 就不会有这样的问题了。Dapp 对其进行了认证并且建立了 session 之后，相关信息就会被保存下来。即便 Sam 断开连接并且重新进行认证，session 也会从他离开时的状态继续，应用程序仍然记得与他相关的一切。他的信息甚至可以保存在他控制的一个远程数据库中。
使 SIWE 一元化
纵观 Web3 领域，你会发现许多现有的服务提供某种形式的 "Sign-In with Ethereum"，但没多少能达到标准的。他们通常会使用它来和用户建立一个基于 cookie 的 session，该 session 可以管理该账户相关的专有元数据。比如，如果你想要给用户权限在你的网站上自定义他们自己的个人档案 (像 OpenSea 那样)，你应该在用户可以做出任何更改之前对他们进行身份验证，以确保只有用户可以编辑他们自己的个人档案。工作流程如下所示：
连接钱包后的第一步是给用户提供人类可读的消息，这样他们才能理解自己进行了什么交互。在很多案例中，用户看到的是 "LOGIN" (登录) 字样，或者一些让你登录的文字，甚至有时只是一个任意的数字 (在这里，对这个随机的疯狂的字母和数字集合签名吧)。那么相反，我们可以根据现有实践确定一组必需的字段、设定好许多良好的安全措施和一个在人类可读和安全运行之间平衡的严格语法。此外，钱包不需要改变它们现有界面和实践，至少可以继续为用户提供这类信息。
首先，我们可以接收所有这些混乱的 “SIWE” 信息，并以一种可接受的通用方式向用户提交请求：
共享信息 - 共享界面
对签名信息格式达成一致后，应用程序和钱包现在可以说同一种语言了。当应用程序向用户提交签名请求时，钱包可以检查该请求，检查它是否与 EIP-4361 (SIWE) 信息相符，并让用户知道他们正在登录一个网站。
在这一点上，钱包可以呈现一个友好的程式化的界面，让用户体验更佳，并且不对用户将要采取的行动产生任何怀疑。而不是给用户一个任意的文本块来签名。用户现在只需点击一个确认对话框来 “登录”，因为钱包能够 “理解” 签名请求。为了实现完全透明，EIP-4361 规范中声明所有信息和字段仍然必须在其他子界面 (如详细视图) 中可用。
从 EIP-4361 的信息中，我们可以得到一个更清晰的界面：
该规范还为钱包引入了额外的安全要求，例如引入域绑定以防止钓鱼攻击；引入 nonces 以防止重放攻击，用户在整个过程中得到了进一步的保护。比如，如果钱包发现一个有效的 SIWE 信息，但是用户正在对example.com进行签名 (但实际上是在exampie.com)，钱包可以警告用户该情况：
身份验证之外
SIWE 信息也可以被理解为访问特定资源的授权，或者对 session 私钥的委托，以提高 dapp UX 的功能性和易用性。例如，想象一下，在这样一个世界里，用户可以使用他们保留的数据来丰富他们自己的 session，而不是应用程序保存用户的数据。想要了解更多信息，强烈建议大家看看这篇文章：
From Sign-In with Ethereum to Session Keys：
https://blog.spruceid.com/from-sign-in-with-ethereum-to-session-keys/
我很快就会发布关于本文的第二部分，敬请关注！在那之前，去实现 SIWE 吧！
