🔥 BRAVE 質押池已上線 — 在錢包搜尋 BRAVE 即可委託
简体

Brave基地

Brave
@47c132035ed7a1105a867946b99d67af Cardano研究小组 公开
讨论 从表单到握手：x402 如何把支付变成互联网的原生协议

从表单到握手：x402 如何把支付变成互联网的原生协议

一、x402：一个支付协议的架构野心

x402 是一个开放支付标准，让任何 HTTP 请求都可以携带支付。它不做钱包，不发币，不建结算网络——它只做一件事：让服务器在响应里报价，让客户端在同一轮请求里付钱。

官网数据（最近 30 天）：

指标数值
交易量75.41M 笔
交易额$24.24M
买家94,060
卖家22,000

仓库状态：x402-foundation/x402，6.5k stars、2.0k forks、1,132 commits、Apache-2.0 协议。SDK 覆盖 TypeScript / Python / Go / Java。

这套数据的核心事实是：它跑在 HTTP 上，跑在别人已经建好的网络上（EVM、Solana、Aptos、Stellar、Hedera、XRPL、Cardano）。x402 没有发明任何一层基础设施，它发明的是连接这些基础设施与互联网的"接口"。

二、支付的演化：从填表到握手

把支付接入互联网这件事，历史上失败过不止一次。演化可以分成四个阶段：

阶段时期核心抽象开发者接口结局
原生微支付1990s电子现金（DigiCash/eCash）专用协议、专用浏览器插件死亡。商户无动力，消费者无需求
账户桥接2000s–2010sPayPal / Stripe表单 + API Key + Webhook存活但昂贵（卡组织抽成 2.9%+30¢）
去中心化账本2009–2020s比特币 / 以太坊地址、gas、RPC、签名——全部暴露给开发者有钱，没有协议。每个接入方各自发明轮子
协议原生支付2025–x402一行 middleware、一个 header进行中

第三阶段的问题最隐蔽：比特币和以太坊证明了"去中心化记账"可行，但它们从未定义"支付"这件事。一个开发者要收款，得自己处理地址、gas、签名格式、链上确认、失败重试——每一个环节都是重新发明。结果是：加密世界有 1.7 万亿美元的钱，却没有一个像 HTTP 一样标准的付钱接口。

x402 的介入点就在这：它把链上细节全部推到 Facilitator（验证/结算服务）身后，让客户端和服务器只需要理解 HTTP。这是它和一切"加密支付 SDK"的本质区别——它不是又一个 SDK，它是传输层的扩展。

三、技术架构拆解：x402 究竟做了什么

3.1 三个角色

  • Client：想访问付费资源的实体（AI Agent、浏览器、curl）
  • Resource Server：持有资源/API 的 HTTP 服务器
  • Facilitator：替双方完成链上验证和结算的中立服务

关键设计：Client 和 Resource Server 都不需要理解区块链。gas、RPC、签名验证、广播交易，全部抽象进 Facilitator。

3.2 一次完整的支付握手

协议的核心循环是 12 步（客户端已知报价时可跳过前两步）：

  1. Client 请求资源
  2. Server 返回 402 Payment Required，附带 PAYMENT-REQUIRED 头（Base64 编码的报价对象）
  3. Client 从报价的 accepts[] 数组里选一个 (scheme, network) 组合，构造签名支付负载
  4. Client 重试请求，附带 PAYMENT-SIGNATURE 头
  5. Server 本地验证，或 POST 到 Facilitator 的 /verify
  6. Facilitator 返回验证结果
  7. 验证通过 → Server 执行资源工作；不通过 → 返回 402
  8. Server 通过 Facilitator 的 /settle 结算
  9. Facilitator 向链上广播交易
  10. 等待链上确认
  11. 返回结算结果
  12. Server 返回 200 OK + 资源 + PAYMENT-RESPONSE 头

整个协议信息只通过三个 HTTP 头传递：

Header方向内容
PAYMENT-REQUIREDServer → Client报价：金额、币种、收款地址、接受的 (scheme, network) 列表
PAYMENT-SIGNATUREClient → Server已签名的支付授权（EIP-712 签名）
PAYMENT-RESPONSEServer → Client结算结果

3.3 支付方案（schemes）：一个协议，四种钱怎么动

x402 定义的不是一种支付方式，而是一族。scheme 字段决定"钱怎么动"：

Scheme语义典型场景
exact精确金额，一次一付读一篇文章付 $1
upto授权上限，按实际用量结算LLM 调用：先授权 \(1，按 token 消耗结算\)0.03
batch-settlementescrow + 离线凭证，批量上链高频微支付：攒 1000 笔 $0.001 一次结算
auth-capture预授权后捕获订阅/信用额度场景

3.4 一行代码集成

卖家端：

app.use(paymentMiddleware({
  "GET /weather": {
    accepts: [...],          // 想支持多少网络/方案都行
    description: "Weather data",
  },
}));

买家端一个函数。官方对集成的目标定义写得很直接："1 line for the server, 1 function for the client"。

3.5 多链与 SDK 矩阵

网络支持：EVM（所有兼容链）、Solana、Aptos、Stellar、Hedera、XRPL、Cardano、Keeta。SDK 按网络拆分：@x402/evm、@x402/svm、@x402/avm、@x402/aptos、@x402/stellar、@x402/tvm、@x402/hedera、@x402/keeta。框架适配：Express、Fastify、Hono、Next.js；客户端适配：axios、fetch、curl。

四、范式移转：从"应用层记账"到"协议层握手"

x402 之前的加密支付，本质上都是应用层记账：每个平台自己维护账户、余额、API Key、订阅状态。x402 把支付变成了协议层握手——像 TCP 的 SYN/ACK 一样，是请求-响应周期的一部分。

维度旧模型（API Key / 订阅）新模型（x402）
接入注册账户 → KYC → 预充值 → 管 Key无账户，收到 402 直接签名付款
定价订阅套餐，用不完浪费，超了断供按次微支付，upto 按实际用量
支付主体人类（在浏览器填表单）人类 + AI Agent（在 HTTP 头里签名）
结算速度分钟级到 T+1秒级（链确认后即回）
成本卡组织 2.9% + 30¢/笔，微支付不可行仅链上 gas，$0.01 也可付
收款方平台（商户号、结算周期）任何拥有钱包地址的开发者
信任平台信用背书加密签名 + 链上可验证

这不是量变，是质变：支付从"产品的功能"变成了"网络的属性"。

这个选择的标志性动作是复活 HTTP 402。402 Payment Required 在 RFC 7231 里被保留了几十年，从没有人定义过它的语义。x402 文档用了一个 Marc Andreessen 的说法——"absolves the internet of its original sin"（赎清互联网的原罪）。互联网的原罪是：信息想要免费，但服务器要付电费。 这个矛盾逼出了广告模式和订阅模式——两种都是"免费内容 + 第三方买单"的扭曲结构。x402 是第一种让服务器直接对请求者收钱、且收的是微支付的标准。

协议层面还有两个容易被忽视的决策：

第一，信任最小化。 协议原则原文："all payment schemes must not allow for the facilitator or resource server to move funds, other than in accordance with client intentions"——Facilitator 是见证者，不是保管者，任何时候都不能动客户的钱。这让第三方 Facilitator（包括 Coinbase 的 CDP Facilitator）可以安全存在。

第二，默认后置结算。 x402 的默认支付流是 authorization：先干活、后结算。需要前置锁资金的场景用 upfront 或 escrow（Cardano 的 Masumi scheme 就是 escrow + 退款）。这是金融基础设施的正确默认——把"跑单风险"设计进协议，而不是丢给业务方。

五、主权个人的基础设施

x402 对"个人主权"的意义，可以从四个维度验证：

数据控制权。 没有账户 = 没有档案。协议不要求任何身份信息，客户端用一个自持钱包签名即完成支付。没有 KYC、没有邮箱、没有"您的购物偏好"。

计算环境控制权。 Facilitator 是标准接口，不是强制服务。官方文档明示三条生产路径：用第三方 Facilitator、自己跑一个、或者 self-facilitate（在自己的资源服务器内嵌验证逻辑）。整条支付链可以完全自托管，不依赖任何托管方。

对第三方的依赖程度。 残余依赖只有两个：稳定币发行方（Circle）和所选链的网络。前者是协议外的现实约束（见第六节），后者可以通过多网络支持对冲。

可退出成本。 协议承诺向后兼容、不废弃已支持网络；SDK 按网络拆包，迁移是换一个包的事。从一套结算网络迁移到另一套的成本，低于从 Stripe 迁移到 Adyen。

连接当下生态，x402 已经是一个交叉点而非孤岛：

  • B.AI（TRON/孙宇晨）把 x402 作为 AI Agent 的支付标准集成
  • Masumi（Cardano）把 x402 扩展成带 escrow 退款 + 决策日志的官方 scheme
  • OpenRouter 支持用 x402 支付模型调用
  • Firecrawl、epik 用它按次售卖网页抓取和 AI 图像生成
  • Cardano 基金会与 Coinbase、Cloudflare、Google、Visa、Mastercard 同属 x402 Foundation 成员

x402 不只是"AI 支付协议"——它是目前最具体的"互联网原生计费层"方案，也是第一个让个人开发者和小型服务器能以接近零边际成本进入全球市场的支付标准。

六、局限与挑战

不加约束层的分析不可信。以下每条都可验证：

1. 稳定币依赖，绕不开 Circle。 主流资产是 USDC。USDC 由 Circle 发行，合约内置黑名单与冻结功能（合规所迫，但确实存在）。链上可验证 ≠ 资产不可没收。

2. Gas 波动侵蚀微支付经济性。 EVM 主网 gas 高峰时，$0.01 的微支付在结算层就可能不经济。EIP-3009（免 gas 授权）和 L2 缓解了这个问题，但每个网络的手续费下限是硬约束。这也是 batch-settlement 方案存在的原因——承认逐笔结算不可行。

3. 冷启动问题。 卖家需要买家，买家需要卖家。x402.org 的 94K 买家 / 22K 卖家（30 天）在加密世界里是真实但小的数字。社区目录（x402scan.com、Agentic.Market、Pay.sh）是早期尝试，但"发现市场"本身还在草创期。

4. 链上透明的另一面。 无 KYC 不等于匿名：每笔支付是公开的链上记录，地址聚类技术可以反推交易图谱。对于希望支付行为完全私密的场景，x402 目前没有原生的隐私方案。

5. 监管不确定性。 无许可、无 KYC 的支付标准与全球反洗钱框架（Travel Rule、稳定币立法）处于张力中。协议本身"not tied to any specific network"，但监管对象是链和稳定币，不是协议——风险在结算层。

6. 争议解决是方案级的，不是协议级的。 核心协议默认 authorization 流没有退款机制；只有 escrow 类 scheme（如 Cardano 的 Masumi）提供。卖家用 exact 收钱后不交付，买家没有内置追索路径。

7. Facilitator 是集中化的实际单点。 协议允许 self-facilitate，但主流路径是 CDP Facilitator 这类托管服务。它不能动钱（信任最小化），但它如果拒绝验证/结算，支付就停了——可用性依赖，而非资产依赖。

8. 签名与钱包 UX 仍是门槛。 对 AI Agent 无感，但对普通人来说，EIP-712 签名、钱包余额、私钥管理依然是障碍。x402 解决的是"机器付钱"，"人付钱"的体验改进靠上层钱包产品，协议本身不承诺。

七、小结

x402 的赌注是：支付应该是 HTTP 的属性，而不是 SaaS 的功能。 它没有发明新网络、新货币、新身份体系，它发明的是把三者缝合进既有互联网协议的接口层。

判断它的标准不是交易量（\(24.24M/月对 Visa 是零头），而是**它是否成为机器经济的默认计费接口**。目前唯一的同类竞争者不是 Stripe 或 PayPal，而是"API Key + 订阅"这个默认习惯本身。x402 已经跑通了三个此前不可行的场景：\)0.01 的 API 调用、LLM 的按 token 结算、Agent 无注册付款。

方向是否成立，看一件事就够：HTTP 402 是 1997 年保留的状态码，2025 年才有人给它定义了语义。 定义它的不是银行，不是卡组织，而是一个开放标准 + 一套参考实现 + 一群互不隶属的链。这在支付史上是第一次。

参考资源