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

By: rootdata|2026/07/30 11:00:31

x402 支付协议曝 31 个新漏洞，99% 交易面临资产盗窃风险。

撰文：@Jun__Yoo

编译：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 为攻击者控制的账户支付租金。

信用卡支付也分离了授权和扣款。区别在于，发卡行在授权时会预留持卡人的部分信用额度或资金。网络规则随后为商家提供一定程度的支付确定性。如果出问题，还有授权撤销、拒付、商家制裁和争议处理程序可用。

x402 没有发卡行来锁定资金并担保支付。服务器因此通过 verify 检查支付可行性，执行业务逻辑，然后再调用 settle。问题在于，两端并不共享状态。验证之后，余额、nonce 或有效期都可能发生变化。如果服务器在结算前执行了不可逆操作，商家就可能蒙受损失。如果 facilitator 提交了被操纵的交易，它可能损失 Gas 或自己控制的资产。

卡网络通过发卡行资本和风险管理团队承担了这种信任成本，再通过手续费收回。x402 移除了那个角色，却没有移除成本。

因此，实际路径是否需要在开放协议之上建立一个问责层？

这里的中心化并不意味着把整个 x402 协议交给单一运营方。每条支付路由都应有明确的责任主体。多个运营方仍可在同一开放标准下竞争，用户也能切换 facilitator。这种结构集中了运营责任，同时保留了协议开放性和提供商之间的竞争。

Cloudflare 的 Monetization Gateway 就是一个可能的例子。它保留了 x402 的可编程支付格式，同时在单一控制层处理支付策略、验证和访问控制。另一条路径是使用专业 facilitator，提供服务等级协议、Gas 限额、结算前再验证和事件响应。

ERC-8004 和声誉系统看似提供了替代方案。但声誉只是评估风险的额外信号，它既不预留资金，也不提供支付担保。我认为单靠声誉无法填补问责缺口。

这一视角也要求重新审视发现层的角色和结构。该层可以超越单纯列出可用服务，成为信任和路由层，筛选哪些资源和 facilitator 符合既定安全标准。如果需要支付担保，它可以明确区分提供担保的中心化运营方和支付路由。从这个角度看，有两个关键玩家值得关注：

CDP（@CoinbaseDev）的整合策略把 Agentic Wallet、CDP Facilitator 和 Bazaar 结合在一起，在一个技术栈中提供钱包、支付、合规和发现功能。

Orthogonal（@orthogonal_sh）的整合策略把服务发现、API 密钥池、响应标准化和计费统一在一个账户、一个余额和一张发票下。它支持 credits、x402 和 MPP。这把管理多个提供商和支付方式的复杂性放进了中央网关。

这些策略目前还谈不上支付担保或损失吸收。但它们把碎片化的钱包、验证、计费和发现功能置于单一运营方之下，为中心化问责层提供了基础。

如果中心化问责层变得普遍，支付结构本身也可能改变。一种可能的模型是把 verify → 业务逻辑 → settle 替换为 verify → settle → 业务逻辑。

当前顺序保护消费者，前提是结算不可逆。一旦运营方接受退款和争议处理责任，这一假设就会改变。可以先确认结算，消除商家的未付款风险。如果后续执行失败，运营方可以退款给消费者。运营方则需承担最终结算前的流动性需求和结算义务，这让其资本和问责结构变得更加重要。

这种模型并不遵循 x402 当前的逐笔结算流程。x402 将继续作为沟通支付条款和授权数据的开放接口。运营方会聚合实际资金流动，并在链上完成最终结算。单笔支付记录保留在运营方内部账本，区块链则记录聚合后的最终结算。因为内部账本可逆，这种结构降低了不可逆支付的问题。运营方也可以像发卡行一样处理退款和争议。

有人可能会问：

这不就是把区块链当成共享支付数据库吗？

是的。

更准确地说，区块链会成为记录运营方之间最终余额的共享结算账本。单笔支付则留在链外。至少在这个市场中，可靠地扮演这一角色或许已经足够。系统仍可利用低结算成本和可编程货币的优势.