：：ERC-8128 评述 加密货币的真正扩展性意味着什么？ 我认为这不仅仅意味着处理更多交易；更重要的是，加密账户开始自然而然地成为网络上的默认身份单元。 目前的架构仍然支离破碎。我们通过钱包结算链上支付，却需要通过单独的登录信息和 API 密钥来验证链下 API 调用。层级分离，身份碎片化，授权和结算分别位于完全不同的系统中。其结果并非统一的信任模型，而是一堆松散连接的机制。 如果一个以太坊账户能够将 Web 请求、授权检查和支付统一地锚定，那么跨层级（包括链上和链下环境）的无需许可交互将成为可能。 ERC-8128 正是这一尝试的体现： “在 HTTP 层实现这种转变”。 相比之下，传统的 HTTP 身份验证依赖于服务器颁发的秘密凭证——JWT 和 API 密钥即使泄露也可以重用；基于会话的模型需要服务器端状态；OAuth 依赖于中心化的身份提供商和复杂的握手过程。 最终，信任模型取决于这些密钥的存储和管理安全性。 ERC-8128 颠覆了这种模式——客户端不再依赖服务器颁发的共享密钥，而是直接使用其以太坊密钥对每个 HTTP 请求进行签名，而服务器仅验证签名。身份验证从凭证颁发模型转变为加密证明模型——请求绑定、显式且可独立验证。 其结构刻意简洁： 来源：http:/erc8128.slice.so 对于智能合约账户，验证通过 ERC-1271 的 isValidSignature() 接口执行；对于以太坊应用账户 (EOA)，签名恢复（例如 ecrecover）即可满足要求。可以通过 nonce 跟踪或 TTL 强制执行来缓解重放攻击。 至关重要的是，身份验证实际上变成了无状态的，服务器不再需要颁发、轮换或存储密钥。 当与 ERC-8004 结合使用时，该架构的功能更加强大： 如果 ERC-8128 证明“此请求源自此地址”，那么 ERC-8004 则定义了“该地址被允许执行的操作”。因此，身份验证和授权融合为一个基于地址的单一流程，并自然地延伸到执行以及（在相关情况下）结算。 无论参与者是代理、用户还是后端系统，策略执行和服务交互都基于相同的加密身份。 从这个意义上讲，ERC-8128 的意义远不止于改善登录用户体验。它代表着一次基础设施的转变——将以太坊账户提升为一种原生 Web 身份原语。用于链上支付的同一地址可以验证链下 API 调用；反过来，服务器可以解析链上状态以确定资格和权限。无需单独的登录层、令牌发行或会话管理，单一的加密身份即可将跨层交互绑定在一起。 ERC-8128 通过将加密身份层直接插入 Web2 基础设施，提出了一种模型，在该模型中，链上和链下系统不再是相互隔离的领域，而是统一信任架构的组成部分——该架构至少在原则上支持跨层的免许可交互。 #ERC8004 #ERC8128