ERC-8128：你的 Ethereum 钱包可能很快就会成为唯一的登录方式。
Source: Dev.to
（请提供您希望翻译的正文内容，我将为您翻译成简体中文，并保留原始的格式、Markdown 语法以及技术术语。）
介绍
让我从一直困扰我多年的事情说起。
我经常使用 API。每次我启动一个涉及任何 Web3 功能的新项目时，我都会陷入一种尴尬的舞蹈——我的用户使用钱包在链上进行身份验证，而我 也 必须为他们颁发 JWT 或 API 密钥来处理链下的事务。两个独立的身份系统。两个独立的信任模型。两个可能出问题的东西。
这感觉不对。而且显然，我不是唯一这么认为的人。
进入 ERC‑8128
在 2026 年 1 月，一个提案悄然出现在 Ethereum ERCs 仓库中。如果它获得广泛关注，可能会从根本上改变我们对 Web3 应用中身份验证的认知。
ERC‑8128 提出了一个 使用以太坊账户对 HTTP 请求进行签名 的标准。它不仅仅是像 Sign‑In with Ethereum 那样只签署一次登录信息，也不仅仅是证明钱包所有权。每一个 HTTP 请求——都使用你的以太坊密钥签名，由服务器验证，且不涉及存储凭证。
该规范基于 RFC 9421 构建，后者是 IETF 为 HTTP 消息签名制定的标准。因此，这并不是从头发明轮子，而是将一个成熟的 Web 标准与以太坊账户提供的加密后盾相结合。
我们今天的认证方式到底有什么问题
在讨论具体机制之前，先思考一下为什么这件事很重要。
传统的 HTTP 认证在设计上就有一个根本缺陷：它是 基于凭证 的。无论你使用 API Key、JWT、会话还是 OAuth，底层模型都是一样的——服务器给你一个秘密（secret），你在后续请求中提供这个秘密，服务器因为你拥有该秘密而信任你。
把问题说出来就很明显：秘密可能被窃取并被重复使用。
- JWT 在传输过程中可能被拦截。
- API Key 可能被提交到 GitHub。
- OAuth 令牌可能从浏览器存储中被导出。
一旦发生这种情况，攻击者不需要冒充你——只要拥有你的凭证就行。服务器无法分辨差别。
基于会话的认证还有一个额外的问题：需要服务器端状态。你的认证系统必须维护一个活跃会话的数据库，这会成为单点故障并带来扩展上的头疼。
OAuth 可以说是这些方案中最复杂的，但它引入了对集中式身份提供者的依赖，以及一个相当繁琐的授权流程——每次实现时我都得从头重新学习。
ERC‑8128 如何颠覆模型
与服务器签发凭证让客户端随后出示不同，ERC‑8128 让客户端直接使用其私钥对每个请求进行签名。服务器只需验证签名。
当你按照此标准发起请求时，客户端会附加三个额外的 HTTP 头部：
Signature-Input– 描述签名覆盖请求的哪些部分（方法、路径、头部、正文哈希、时间戳等）。Signature– 对这些组件进行的实际加密签名。Content-Digest– 请求正文的哈希，用于确保在传输过程中不被篡改。
服务器接收这些头部，从 Signature-Input 中的 keyid（格式为 erc8128::）解析出你的以太坊地址，并据此验证签名。
- 对于普通的外部拥有账户（EOA），这仅仅是 ECDSA 签名恢复——与在链上提交交易时的过程相同。
- 对于智能合约账户（SCA），验证会通过 ERC‑1271 的
isValidSignature()接口进行，这意味着账户抽象钱包、多签以及其他高级账户类型都能原生支持。
我一直反复强调的一点是：服务器永远不会存储你的任何信息。没有凭证数据库。没有会话表。没有需要撤销的令牌。如果你停止发送签名请求，你就会变成未认证状态。认证成为请求本身的属性，而不是某处维护的有状态会话。
重放攻击与随机数
此时显而易见的问题是：有什么办法阻止有人拦截已签名的请求并再次发送？
ERC‑8128 通过以下几种方式来解决：
- 时间戳 / TTL 可以包含在签名的组件中，这样旧的请求会自动失效。
- 随机数（Nonce） 可以被加入，使每个请求成为一次性授权——如果验证者跟踪已见过的随机数，重放已捕获的请求将会失败。
实际上，提案中围绕这一点还有一个有趣的未解之谜。严格基于随机数的重放防护要求服务器维护状态（即已见随机数的集合），这与该授权模型本应保持的无状态特性相冲突。提案承认了这种张力：你可以拥有强大的重放防护 或 轻松的水平扩展，而这种权衡是显式而非隐藏的。
我很欣赏作者们直面这一问题，而不是假装已经解决。这也是在 Ethereum Magicians 讨论线程中列出的开放问题之一，类似的情况往往会通过实际实现的反馈逐步得到解决。
更大的图景：ERC‑8128 + ERC‑8004
这就是对于任何构建 Web3 应用的人来说真正令人兴奋的地方。
ERC‑8128 回答了一个问题：“此请求是否来自该以太坊地址？”
但与 ERC‑8004 结合后，它还能回答第二个问题：“该地址被允许做什么？”
ERC‑8004 是一个关于链上状态解析的提案——例如与地址关联的声誉、角色和权限。当两者结合时，你将拥有一个完整的身份验证 和 授权流程，锚定在单一的加密身份上，授权规则存于链上，透明且可审计。
ERC‑8128 所启用的应用
- 按请求计费的 API – API 可以验证签名并在链上结算付款，而无需管理计费账户。
- DAO 工具 – 可以通过读取链上治理状态来强制执行权限。
- AI 代理 – 自主代理可以在每次 API 调用中携带用户的以太坊身份；服务器在链上解析权限，因此代理永不持有任何凭证。
那种情形尤为引人注目，因为自主 AI 代理正变得越来越普遍。如今，代表您调用 API 的 AI 代理要么需要存储您的 API 密钥（风险大），要么您必须从头构建委托系统（痛苦）。使用 ERC‑8128，代理使用委托密钥签署请求，服务可以在链上验证您已授权该委托。
SIWE 的不足之处（以及 ERC‑8128 的不同之处）
如果你在以太坊领域已经活跃了一段时间，你的第一反应可能是：“这不就是 Sign‑In with Ethereum（SIWE）已经在做的事吗？”
SIWE 很棒——它解决了一个真实的问题：让用户使用钱包而不是密码来登录网页应用。但 SIWE 本质上是一个 登录机制。你签署一次消息，获取一个会话，从此以后你又回到了传统的基于凭证的模型。会话可以过期或被窃取，就像普通会话一样。
ERC‑8128 并不是取代 SIWE——它们解决的是不同的问题。
| 方面 | SIWE | ERC‑8128 |
|---|---|---|
| 目标 | 登录体验（一次性握手） | 对每个 API 请求提供持续的加密证明 |
| 使用场景 | 人与网页的交互 | 程序化、机器对机器的通信，AI 代理 |
| 凭证模型 | 登录后获得会话令牌 | 每次请求都基于签名的身份认证 |
仍在讨论的事项
如果把它呈现为已完成、可直接部署的标准，那是不诚实的。这是一份草案提案，仍有若干未决问题。
keyid 格式
当前提案使用的是：
erc8128::关于是复用已有的 eip155: 命名空间，还是采用更明确的复合格式（例如）仍存在争论：
erc8128;eip155::命名空间指示验证语义；若使用不当，可能导致歧义和安全问题。
签名算法多样性
以太坊账户未来可能支持除 ECDSA 之外的算法（例如 P‑256）。标准需要优雅地处理这些情况，避免产生算法混淆漏洞。
重放保护权衡
是否应强制执行严格的 nonce 机制以满足合规要求，亦或仅使用 TTL 的方式可以视为有效（尽管较弱）的实现？此问题仍在讨论中。
这些并非致命问题——它们正是 ERC 过程中的细节讨论。若您今天基于此进行开发，请记住规范仍可能会更改。
我的看法
我认为 ERC‑8128 以简洁的方式解决了一个真实的问题。洞察到 HTTP Message Signatures（现有的 IETF 标准）是将以太坊身份验证附加到的正确层级，这很聪明——这意味着我们并不是要求网络采用全然陌生的概念，而是对已有的东西进行扩展。
从凭证式认证向签名式认证的转变确实意义重大，不仅是安全性的提升，也是概念层面的进步：
- Credential‑based：身份由服务器授予。
- Signature‑based：身份是你已经拥有的——你的私钥，服务器只需验证它。
这在哲学上与以太坊链上运作方式相契合，将其引入 HTTP 层感觉更像是自然演进，而非额外的附加。
它是否能被广泛采用将取决于钱包支持、开发者工具、客户端库实现等因素，以及生态系统是趋向此标准还是其他替代方案。该提案深思熟虑，用例真实，鉴于 AI 代理和自主系统的兴起，时机也恰当。
值得关注。
ERC‑8128 草案已在 GitHub 上发布，讨论正在 Ethereum Magicians forum 进行中。如果你有想法或实现反馈，现在是参与的时机——正是社区意见真正塑造规范的阶段。