重要 开放协议的信任陷阱：x402 为何需要中心化责任层？

BiRun 消息，撰文：Jun 编译：AididiaoJP，Foresight News CryptoSlate 的 Akiba（@akibablade）近日发表文章，标题为《 新发现的 31 个漏洞让 99% 的 x402 加密支付面临资产盗窃和免费购物风险 》。 这篇文章基于一篇题为《 当 HTTP 402 遇上区块链：新兴 x402 支付的风险 》的论文。该论文已被接受，将在 USENIX Security 2026 会议上发表。 论文重点研究了 x402 如何将支付证明验证和链上结算委托给第三方 facilitator（支付促进者）。这种设计把信任和验证逻辑集中到多个独立商家共用的支付基础设施上。一旦某个 facilitator 出现漏洞，就可能影响大量服务。 研究者还定义了 facilitator 应遵守的八条安全规则。违反这些规则会引发四类攻击：免费购物、资产盗窃、服务拒绝和 Gas 滥用。他们对 15 家主要 facilitator 进行了评估，发现了 49 项规则违规和 31 个此前未知的漏洞。研究结果已私下披露给相关运营方。部分问题已得到修复，其余问题的修复工作正在进行中。 这项研究之所以能开展，是因为 x402 从一开始就作为开放协议开发。其协议规范和参考 SDK 均公开，研究者得以从中推导出支付流程的安全规则。他们使用开源 SDK 和自己搭建的测试商家完成了研究。 开源并不能消除漏洞，但它提供了一条路径，让外部发现的缺陷可以转化为共享的安全标准。x402 协议已于 4 月 2 日移交 Linux 基金会，x402 Foundation 也于 7 月 14 日正式启动运营，拥有 40 名成员。这为在规范和参考实现层面讨论发现结果提供了官方论坛，而不再局限于单个供应商的补丁。 研究者还发布了 x402scope 的公开版本，已移除敏感的利用代码。他们正与 Coinbase 及其他主要生态参与者讨论，如何将其规则检查整合进开发和部署前验证流程。 协议成熟度的讨论到此为止。我想从这些发现中再提出一个更基础的问题。 与其把 x402 本身中心化，一个开放协议是否需要一个中心化的问责层，来强制执行验证标准，并承担安全事件带来的结算成本和损失？ 中心化并不自动等于安全。但在支付领域，行使权力的一方，也应该承担失败的代价。 看看 x402 的实际运作方式。任何人都可以运营服务器或成为 facilitator。但系统并非完全无信任。论文也把 facilitator 定义为「承担信任的中介」。一旦验证和结算被委托出去，用户就必须对 facilitator 投入相当程度的信任。 问题在于，信任被集中了，协议却没有要求相应的资本、问责机制或支付确定性。这一缺口体现在设计的三个部分。 第一，verify（验证）更像是在预测「此时结算仍然可行」，而不是像信用卡授权那样。它检查签名、余额、nonce 和过期时间，但既不锁定资金，也不消耗 nonce。 第二，verify → 业务逻辑 → settle（结算）的分离本意是保护消费者和商家。协议没有机制通过共享状态把验证和结算绑定在一起。如果商家基于 facilitator 的验证结果采取行动，而后续结算失败，商家就要承担全部损失。 第三，许多 facilitator 会赞助链上结算成本。攻击者可以操纵执行路径，让 facilitator 支付由此产生的 Gas 费用。在 Solana 上，攻击者甚至可能诱导 facilitator 为攻击者控制的账户支付租金。 信用卡支付也分离了授权和扣款。区别在于，发卡行在授权时会预留持。