在 BTX 上开发代理安全工作流

构建必须向代理证明自身的 API。

BTX 为开发者提供了两种特别适合 AI 原生软件的原语：用于准入控制的链绑定新鲜工作挑战，以及面向代理、服务和运营者的钱包支持的后量子身份，帮助他们减少对旧式签名的依赖。

集成指南挑战 RPC

请求路径

已签名的代理请求
挑战信封已发出
本地完成新鲜工作求解
证明兑换并放行

身份 后量子钱包材料

准入 新鲜工作证明

验证 验证成本远低于求解成本

接口面 RPC + 网关流程

用例 AI 代理 CAPTCHA 挑战流程模式画像就绪度网关适配身份启动包标准 FAQ

为什么重要

AI 原生产品需要比 CAPTCHA 更好的准入控制。

纯面向人类的挑战流程并不适合自动化系统、API 客户端和运营工具。BTX 服务挑战让你请求新鲜计算：大规模自动化成本高、验证成本低，并且绑定当前链状态。

公共 API 门控

在昂贵或容易被滥用的端点放行流量之前，要求先完成新鲜工作。与其一开始就向所有调用者收费，这更适合匿名或免费层流量。

AI 推理准入

用挑战难度给机器人压力和推理滥用定价，而不是只依赖配额、CAPTCHA 提示或盲目的速率限制。

代理到工具的验证

向调用方发起挑战，廉价验证证明，并在代理需要访问工具、网关或运营工作流时与签名请求结合使用。

抗垃圾与抗批量注册

在评论、账户创建和公开表单中使用 BTX 服务挑战，适用于那些纯人类 CAPTCHA 体验很差或很容易被外包的场景。

AI 代理 CAPTCHA

为自动化调用者构建的网关模式。

目标不是用谜题打断人类，而是让每个昂贵路由都给出一个实时工作价格，使代理和 API 客户端能够以程序方式满足它，然后在执行前廉价验证。

把路由标记为可挑战

在网关处识别推理、注册、搜索或工具路由，判断其成本和滥用画像是否值得在执行前报价新鲜工作。

发出链绑定的挑战信封

返回按用途、资源和主体定键的 BTX 工作，而不是把调用方送进仅面向人的 CAPTCHA 流程。

要求请求携带证明

客户端或代理在本地求解后，将证明与原始 API 调用以及你要求的任何签名身份材料一起提交。

在昂贵动作开始前先兑换

你的服务器会在模型运行、工作流步骤或特权工具调用开始前先验证新鲜度、重放状态和难度上下文。

挑战流程

一个实用的开发者循环，而不是模糊的未来故事。

发起挑战

使用 getmatmulservicechallenge 将新鲜工作绑定到用途、资源、主体和目标求解时间。

打开相关文档

让客户端本地求解

请求方计算一个绑定当前链状态的 MatMul 证明，因此预计算窗口保持有限。

打开相关文档

兑换并验证

只有当 redeemmatmulserviceproof 确认该证明有效、新鲜且尚未被消费时，才接受请求。

打开相关文档

叠加身份层

当代理或服务需要持久的密码学身份时，在其上叠加 BTX 钱包身份和签名请求标准。

打开相关文档

# Issue a challenge envelope
curl --silent --user "$BTX_RPC_USER:$BTX_RPC_PASSWORD" \
  --data-binary '{
    "jsonrpc":"1.0",
    "id":"issue",
    "method":"getmatmulservicechallenge",
    "params":["ai_inference_gate","model:gpt-x|route:/v1/generate|tier:free","tenant:abc123",2,300,0.25,0.75]
  }' \
  -H 'content-type: text/plain;' \
  http://127.0.0.1:19334/

# Redeem the returned proof
btx-cli redeemmatmulserviceproof CHALLENGE NONCE DIGEST

准入栈对比

BTX 是工作与身份层，而不是整个认证栈。

实际的选择不是“用 BTX”或“用认证”，而是如何将正常认证与一种机器原生的滥用定价方式结合到真正重要的路由上。

仅用 API 密钥

最擅长： 对已知付费用户和稳定的服务器到服务器客户端来说足够简单。

薄弱点： 面对被复制的凭证、被转售的访问，或昂贵路由上的匿名滥用时较为薄弱。

它真正提供的是： 有身份，但没有按路由定价的工作要求。

人类 CAPTCHA

最擅长： 当调用方明确是浏览器里的人类时仍然有用。

薄弱点： 对代理、工具、自动化客户端，以及可被 CAPTCHA 农场外包的流程并不适合。

它真正提供的是： 人为摩擦，而不是机器原生准入。

BTX 挑战 + 签名身份

最擅长： 让调用方证明新鲜度、以计算承担滥用成本，并附带更强的签名材料。

薄弱点： 仍然需要常规认证，以及围绕账户、作用域和业务规则的策略判断。

它真正提供的是： 新鲜工作加持久的机器身份。

部署模式

BTX 在真实 AI 与网关栈中的位置。

网关式系统已经区分设备身份、路由策略和授权。BTX 在此基础上增加一层新鲜工作要求，用于那些昂贵、易受垃圾流量影响或值得保护的路由。

AI 推理网关

匿名或免费层推理请求在模型启动前先被挑战。已知付费流量可以绕过，或采用更轻的策略。

代理工具访问

在代理触达敏感工具或运营工作流之前，同时要求签名身份和绑定到该路由或作用域的新鲜工作。

注册与垃圾控制

评论、注册和公开表单可以用计算来给滥用定价，而不是依赖 CAPTCHA 农场、短信墙或永久余额。

运营控制平面

高风险管理路径可以要求后量子钱包身份加链绑定工作，使重放和外包式滥用明显更难。

参考架构

从最接近你产品的路由形态开始。

这些不是抽象画像，而是可以直接搬进网关、公开 API 或代理工作流里的 BTX 挑战形态，然后再按你的威胁模型继续收紧。

推理 API

公开 AI 推理 API

推荐绑定

purpose: ai_inference_gate
resource: model:gpt-x|route:/v1/generate|tier:free
subject: tenant:abc123 或 api_key:key-42

挑战策略

target_solve_time_s: 免费或匿名流量建议 2-4 秒
expires_in_s: 60-180 秒，尽快让旧信封失效
redeem path: 如果请求会排队或扇出到共享工作节点，使用 redeemmatmulserviceproofs

打开文档: AI 推理画像打开文档: 发起挑战 RPC 打开文档: 批量兑换 RPC

代理网关

代理或工具网关

推荐绑定

purpose: api_gate
resource: tool:calendar.write|route:/mcp/tools/calendar.write
subject: wallet:agent-42 或 device:devtok_abc123

挑战策略

target_solve_time_s: 交互式工具调用建议 1-2 秒，特权路由可以更高
expires_in_s: 30-120 秒，让签名请求与工作保持紧耦合
redeem path: 在网关边缘按请求逐个准入时使用 redeemmatmulserviceproof

打开文档: 代理网关画像打开文档: 受保护路由契约打开文档: 兑换证明 RPC

公开提交

匿名公开提交

推荐绑定

purpose: rate_limit
resource: signup:/v1/messages 或 comment:/v1/posts/:id
subject: ip:203.0.113.0/24 或 user:[email protected]

挑战策略

target_solve_time_s: 1-3 秒，让正常用户能完成，同时抬高垃圾成本
expires_in_s: 60-300 秒，并且只在最终提交时兑换
redeem path: 除非你在批处理审核任务，否则使用 redeemmatmulserviceproof

打开文档: 公开提交画像打开文档: 核心流程指南打开文档: 兑换证明 RPC

生产就绪度

告诉构建团队哪些现在可以安全上线，哪些需要路由纪律，以及 BTX 的边界在哪里。

把 BTX 服务挑战当作真正的准入控制子系统来部署：先从单节点开始，在真正的决策点兑换，并明确这种证明能证明什么、不能证明什么。

现阶段可用：单节点受保护路由

文档里的生产路径是同一台 BTX 节点负责 issue 与 redeem，并共享同一个挑战注册表。对很多推理、注册和网关路由来说，这已经够用，不必先引入额外协调层。

单节点部署受保护路由契约兑换证明 RPC

扩展注意：多节点需要黏性或共享状态

一旦 issue 与 redeem 可能落到不同的 BTX 节点，挑战注册表就会变成运维依赖。要先加好 sticky routing 或共享 challenge 文件，才能把这条路由视为横向安全。

多节点部署失败语义网关监控

准入规则：生产用 redeem，诊断用 verify

verify 只回答证明是否匹配挑战。redeem 才是带回放保护的准入事件，会一次性消耗证明，并给网关一个权威的接受或拒绝结果。

verify 与 redeem 验证证明 RPC 兑换证明 RPC

信任边界：BTX 证明工作，不替你完成全部鉴权

BTX 可以证明链绑定的新鲜工作，并与钱包身份自然配合，但它不会替你决定业务授权、人类意图，或模型输出是否正确。这些检查仍然要留在网关和产品层。

BTX 证明了什么创建钱包后量子地址格式

实现说明：BTX 是新鲜工作层，不是整个策略栈。多节点集群仍需要粘性路由或共享挑战状态，业务授权也仍然在证明之外。

带作用域的网关模式

BTX 适合与已经使用角色、作用域和设备信任的网关并行工作。

已发布的 OpenClaw 网关文档就是一个例子：客户端在握手时声明角色和作用域、签署服务器提供的挑战 nonce，并接收按角色和作用域限制的设备令牌。BTX 适合作为该栈之上的路由级工作要求，用于昂贵或易受滥用的动作。

在带作用域的网关里，握手状态已经存在

OpenClaw 已发布的网关协议就是一个例子：客户端在 WebSocket 握手期间声明角色和作用域，这正是判断后续路由是否应要求新鲜工作的自然位置。

设备身份与设备令牌可以保持不变

在这种模型里，签名设备身份、配对和按设备发放的角色令牌都可以保持不变。BTX 不会替代这一层；当某条路由还需要反滥用的工作定价时，它会补充这一层。

服务器 nonce 加上 BTX 挑战是一个干净的栈

网关可以保留自己的连接挑战和请求签名规则，只在随后的昂贵推理、工具或运营动作上发出 BTX 工作要求。

最终形成的策略对代理来说更原生

角色、作用域、设备信任和新鲜工作都可以一起评估，而不必退回到仅面向人的 CAPTCHA 或永久预付余额模型。

# Pseudocode: gateway route protected by BTX work
POST /v1/generate
Authorization: Signature keyId="btx-wallet:agent-42",...
X-Device-Token: devtok_...
X-BTX-Challenge-Id: chal_...
X-BTX-Proof-Nonce: ...
X-BTX-Proof-Digest: ...

# Server sequence
1. validate role + scope + device token
2. verify request signature
3. redeem BTX proof for this route
4. only then run the expensive action

受保护路由契约 OpenClaw 网关协议 MCP 授权

身份层