公開 API のゲーティング
高価または乱用されやすいエンドポイントがトラフィックを受け入れる前に、新鮮な作業を要求します。すべての呼び出し元に前払いを求めるより、匿名または無料層のトラフィックに適しています。
BTX 上で開発 エージェント安全なワークフロー
エージェントが自らを証明しなければならない API を構築する。
BTX は AI ネイティブなソフトウェアに特に適した2つの原語を開発者に提供します。入場制御のためのチェーン拘束型の新鮮な作業チャレンジと、エージェント、サービス、オペレーター向けのウォレット支援型ポスト量子アイデンティティです。レガシー署名への依存を減らしたいチームに適しています。
リクエスト経路
- 署名済みエージェント要求
- チャレンジ封筒を発行
- 新鮮な作業をローカルで解く
- 証明を償還して許可
アイデンティティ PQウォレット素材
入場 新鮮な作業証明
検証 解くコストに対して検証は安価
サーフェス RPC + ゲートウェイフロー
なぜ重要か
AI ネイティブ製品には CAPTCHA 以上の入場制御が必要です。
人間専用のチャレンジフローは、自動化システム、API クライアント、オペレーターツールには適しません。BTX のサービスチャレンジを使えば、新鮮な計算を要求できます。大規模自動化には高コストで、検証は安価、しかも現在のチェーン条件に結び付いています。
AI 推論の入場制御
ボット圧力や推論乱用に対して、クォータや CAPTCHA、盲目的なレート制限だけに頼るのではなく、チャレンジ難易度で価格を付けます。
エージェントからツールへの検証
呼び出し元にチャレンジを課し、証明を安価に検証し、エージェントがツール、ゲートウェイ、運用フローへアクセスするときには署名付きリクエストと組み合わせます。
スパムと登録乱用への耐性
コメント、アカウント作成、公開フォームで、人間専用 CAPTCHA が使いにくかったり外注されやすかったりする場面に BTX サービスチャレンジを使います。
AIエージェント CAPTCHA
自動化された呼び出し元向けに作られたゲートウェイパターン。
目的は人間をパズルで止めることではありません。目的は、すべての高コスト経路に対して、エージェントや API クライアントがプログラム的に満たせるライブの作業価格を提示し、実行前に安価に検証することです。
そのルートをチャレンジ対象として印付ける
ゲートウェイで、推論、登録、検索、ツールの各ルートのうち、コストと乱用プロファイルから実行前に新鮮な作業を提示する価値があるものを特定します。
チェーン拘束のチャレンジ封筒を発行する
呼び出し元を人間専用 CAPTCHA に通す代わりに、目的・リソース・主体に鍵付けられた BTX 作業を返します。
リクエストと一緒に証明を要求する
クライアントやエージェントはローカルで解き、その証明を元の API 呼び出しや必要な署名付きアイデンティティ素材と一緒に送信します。
高価なアクションの前に償還する
サーバーはモデル実行、ワークフローステップ、特権ツール呼び出しが始まる前に、新鮮さ、リプレイ状態、難易度文脈を検証します。
チャレンジフロー
曖昧な未来話ではなく、実用的な開発者ループ。
1
2
3
4
アイデンティティを重ねる
エージェントやサービスが持続的な暗号学的アイデンティティを必要とするとき、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 ファームや SMS の壁、恒久的な残高モデルではなく、計算で乱用に価格を付けられます。
運用コントロールプレーン
高リスクの管理経路では、ポスト量子ウォレットアイデンティティに加えてチェーン拘束の作業を要求でき、リプレイや外注乱用を大きく難しくできます。
参照アーキテクチャ
自分の製品に合うルート形状から始める。
これは抽象的なペルソナではありません。ゲートウェイ、公開 API、エージェントフローへそのまま持ち込める具体的な BTX チャレンジ形状であり、その後に自分の脅威モデルへ合わせて締めていけます。
公開 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 を使う
エージェントまたはツールゲートウェイ
推奨バインディング
- 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 を使う
匿名の公開送信
推奨バインディング
- 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 は最終送信時だけに行う
- redeem path: モデレーションキューをまとめる場合を除き redeemmatmulserviceproof を使う
本番準備状況
何が今すぐ安全に使え、何にルーティング規律が必要で、BTX の境界がどこにあるかを示す。
BTX のサービスチャレンジは実際の admission-control サブシステムとして扱います。まず単一ノードから始め、実際の判断点で redeem し、この証明が何を示し何を示さないかを明確にします。
今すぐ使える: 単一ノードの保護ルート
文書化されている本番経路は、同じ BTX ノードが同じチャレンジレジストリに対して issue と redeem を行う形です。多くの推論、登録、ゲートウェイルートは、まずこれで十分に運用できます。
スケール時の注意: マルチノードはアフィニティか共有状態が必要
issue と redeem が別の BTX ノードに着地し得るなら、チャレンジレジストリは運用上の依存になります。横に広げても安全と言う前に、sticky routing か共有 challenge ファイルを入れてください。
受け入れ規則: 本番は redeem、診断は verify
verify は証明がチャレンジに一致するかを示すだけです。redeem は proof を一度だけ消費するリプレイ安全な受け入れイベントであり、ゲートウェイに権威ある accept / reject 結果を返します。
信頼境界: BTX が証明するのは作業であって、認証全体ではない
BTX はチェーンに結び付いた新鮮な作業を証明でき、ウォレットアイデンティティともきれいに組み合わさりますが、業務上の認可、人間の意図、モデル応答の正しさまでは決めません。それらのチェックはゲートウェイとプロダクト層に残してください。
実装メモ: BTX は fresh-work レイヤーであり、ポリシースタック全体ではありません。マルチノード構成では sticky routing か共有チャレンジ状態が引き続き必要で、業務上の認可は証明の外側に残ります。
スコープ付きゲートウェイパターン
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 アイデンティティ層
最初からポスト量子で始まるウォレット支援型アイデンティティ。
最初からポスト量子ウォレット設計
BTX ウォレットはディスクリプタベースで、当初から ML-DSA と SLH-DSA を軸に設計されています。これにより、中核のアイデンティティ素材を後回しの移行案件として扱う可能性を減らせます。
ソースを見るチャレンジフローは生きた難易度に結び付く
サービスチャレンジとマイニング RPC は、乱用価格付けのための生きた作業プロファイル、目標解決ウィンドウ、新鮮なチェーン拘束コンテキストを公開します。
ソースを見るエージェント協調サービス向けに構築されている
プロトコル文書はすでに、BTX を単一の共有ランタイムではなく、ブリッジ、サービス、エージェント協調レイヤーの上にある狭い決済基盤として位置付けています。
ソースを見る 開発起動キット
まずルートを作り、次に運用を固める。
これらの束は、API チームがよく辿る順番でドキュメントを並べています。チャレンジルートを試作し、アイデンティティを結び付け、制御プレーンへ載せ、実運用の状態を監視します。
ライブチャレンジを発行して償還する
最小の有用なループから始めます。チャレンジを発行し、解き、守りたいルート上で償還します。
呼び出し元の識別をウォレット素材へ結び付ける
明示的な呼び出し元識別の上に BTX work を重ね、入場制御と強い署名前提を一緒に進化させます。
BTX をサービス面へ接続する
チャレンジループが動いたら、サービスがすでに運用している RPC とウォレットの面へ接続します。
難易度とチャレンジ条件を見る
他の本番依存と同じようにチャレンジコストとネットワーク健全性を露出し、推測ではなく調整で保護を最適化します。
標準とエコシステム
スタック全体が、より強いエージェントアイデンティティとチャレンジフローへ進みつつあります。
2024-08-13
NIST が最初の PQC 標準を確定
BTX は、標準の世界がすでに進み始めている方向から出発している。ポスト量子署名と、後ではなく今の移行圧力である。
RFC 9421 / 9449署名付きリクエスト標準は十分に成熟している
HTTP Message Signatures と DPoP は、認証済みで proof-of-possession 的な API トラフィックに対する強い標準隣接フレームを提供する。
2025-03-26MCP は本物の認可と安全性の課題をエージェントツールへ持ち込む
エージェントシステムには今や適切な認可、スコープ付きアクセス、安全なツール利用が必要であり、BTX はその周囲の作業・アイデンティティ層として適合する。
OpenClawゲートウェイ型エージェントシステムは既に署名済みデバイス素材を使っている
OpenClaw のゲートウェイドキュメントは、署名済みデバイストークンとスコープ対応ロールを示している。BTX は高リスクルートに新鮮な作業要件を重ねて補完できる。
2025-09-18NIST は組織に今すぐ PQC 移行計画を始めるべきだと述べる
NCCoE の CSWP 48 草案は、PQC 移行を将来の節目まで先送りする課題ではなく、今のガバナンスと統制マッピングの課題として捉えている。
開発者 FAQ
BTX の challenge flow を試作するときにチームが確認すること。
ここでの回答は、現在の RPC とウォレットのドキュメントに沿っています。BTX は既存の認証を補完し、高価なルートに新鮮な work pricing を追加し、AI ネイティブなシステムに post-quantum identity の経路を与えます。
BTX は API キー、OAuth、またはゲートウェイのポリシーを置き換えますか？
いいえ。BTX は既存の認証スタックを補完するときに最も効果を発揮します。identity、scope、policy はそのまま維持し、乱用、コスト、リソース競合が重要なルートにだけ BTX work を求めてください。
関連ドキュメントを開くchallenge は AI やエージェントのワークフローのどこに入りますか？
通常は通常の request identification の後で、高価なアクションが走る前です。サーバーが live challenge envelope を発行し、呼び出し側がそれを解き、サービスが GPU 時間やモデル枠などの希少資源を使う前に proof を redeem します。
関連ドキュメントを開くなぜウォレットベースの post-quantum identity をこの流れに入れるのですか？
BTX では、同じシステムの中で fresh work とより強い signing material を一緒に扱えます。すでに post-quantum 移行を計画しているチームにとって、identity と admission を別々の将来課題ではなく一緒に評価しやすくなります。
関連ドキュメントを開くOpenClaw や MCP 系のゲートウェイスタックにも合わせられますか？
アーキテクチャ上は可能です。既存の role、scope、device trust モデルを維持したまま、BTX を route-level work requirement として重ねます。これはこのページで説明している適合の話であり、BTX が現在 native な OpenClaw 統合を提供しているという主張ではありません。
関連ドキュメントを開く 次の一歩
製品に乱用問題、無料層、またはエージェント層があるなら、BTX は設計レビューに入るべきです。
サービスチャレンジガイドから始め、ウォレットモデルを読み、アイデンティティと作業の両方を要求するエージェント安全なルートを試作してください。