ZOOBC / エージェント資金管理インフラ
AIエージェントに資金を。破れない上限はそのままに。
ZooBCは自律エージェントに、支出し、雇い、取引する余地を与えます。ただし、その予算の境界を守らせるのはエージェント自身の自制心ではなく、ネットワークです。依存関係のないPythonリファレンスが、稼働中のTestNetで完全なトランザクションの流れを実証しています。
- 上限
- 事前にロック
- 制御
- 増額には人間の署名
- 記録
- 独立して検証可能
はじめに / 3つのライブリソース
発見から検証済みトランザクションまで。
エージェントや開発者は、ブラウザもSDKも依存関係のインストールもなしに、1つのディスカバリーファイルから確認済みのTestNetトランザクションまで進めます。
エージェントにファイルを1つ渡す。
llms.txtは、稼働中のTestNet、主要なエンドポイント、署名モデル、フォーセット、そしてエージェントが次に読むべきドキュメントを示します。
llms.txtを開く ↗02 / 実装エージェントガイドを通読する。
AGENTS.mdは、トランザクションの構築、スケジュール型の利用枠、期限付きエスクロー、マルチシグによる支出、監査クエリ、既知の課題を文書化しています。
AGENTS.mdを読む ↗03 / 実行動作するリファレンスを実行する。
依存関係のないこのPythonファイルは、鍵の生成、テストコインの請求、手数料の見積もり、署名、送信、確認、そして実際のトランザクションの検証までを行います。
Pythonリファレンスを開く ↗未解決の制御レイヤー
自律に白紙委任は要らない。
AIシステムは、自らのタスク、ツール、購買判断を持ちつつあります。難しいのは、一挙手一投足を見張ることなく資金面の裁量を与えることです。ZooBCは支出の境界をネットワークの状態に変えます。エージェントはその内側では自由に行動できますが、境界そのものを書き換えることはできません。
ソフトウェアが提案し、台帳が強制する。
3つの制御と3つの機能
ネットワークが強制するものと、アプリケーションがその周りに築くもの。
ロックされた利用枠、期限付きエスクロー、マルチシグのしきい値は「制御」です。コマース、トークン決済、申告型のアイデンティティは、ZooBCのトランザクションとデータを組み合わせて実現する「機能」です。
AIエージェントが超えられない利用枠。
資金モード0のスケジュール送金は、作成時に生涯の利用枠全体をロックします。エージェントは各リリースで定められた額を受け取り、総額を引き上げるには所有者が承認した新しいトランザクションが必要です。残額は取り消すことも、別の宛先に割り当て直すこともできます。
支払いはあなたを待てる。資金を閉じ込めることなく。
エージェントは、指名された承認者が承認または拒否するまで保留される支払いを提案できます。タイムアウトは絶対値のUnixタイムスタンプで指定します。応答がないまま期限を過ぎると、金額とコミッションはオンチェーンで自動的に返還されます。
高額な支払いには複数の署名を必須に。
マルチシグ送金は、定められたN-of-Mの署名しきい値が満たされて初めて実行されます。アプリケーションは、少額の取引はエージェントに直接処理させ、大きなコミットメントは独立した承認者を経由させることができます。
エージェントは取引し、検証可能なレシートを残せる。
エージェント間のコマースは、署名付きトランザクションと上記の制御から組み立てるユースケースです。どちらのエージェントの非公開ログにも頼ることなく、誰でもトランザクションハッシュ、ブロックの確認、アカウント履歴、残高の動きを照会できます。
マシン間の少額決済をオンチェーンで。
マイクロペイメントは、ZBC、ユーザー発行トークン、署名付き送金、オンチェーン取引所の上に成り立つユースケースです。アプリケーションはこれらの仕組みを使って、データ照会、API呼び出し、その他のマシン処理の対価を決済しつつ、公開の支払い記録を残せます。
エージェントが何者であるかを公開する。
エージェントは、運用者、目的、機能、エンドポイント、予算スケジュールを記述した署名付きのデータセットレコードを書き込めます。これはアカウントによる検証可能な主張であり、チェーンが強制するアイデンティティの基本機能ではありません。それを信頼するかどうかは、引き続きアプリケーションが判断する必要があります。
1つのエージェント / 2つの経済レイヤー
モデルが消費したものと、エージェントが支出したものを把握する。
役に立つエージェントには2つのメーターがあります。モデルプロバイダーは推論の使用量を計測し、ZooBCアカウントは現実世界で行動する際に支出した価値を記録します。アプリケーションは、同じエージェントとワークフローを軸に両者を突き合わせられます。
プロバイダーが報告するトークン数、呼び出し回数、計算量。
オンチェーンに記録される支払い、エスクロー、スケジュール、手数料、残高の動き。
モデルの使用量を、独立して検証可能なチェーン上の支出と突き合わせます。
強制の境界：ZooBCが強制するのは、チェーン側の利用枠とトランザクションのルールです。推論の計測については引き続きモデルプロバイダーが信頼できる情報源であるため、2つの記録はアプリケーションのコードで結合する必要があります。
実際のトランザクションの流れ
上限付きの支払い：スケジュールから台帳上の証明まで。
これがこのパターンの裏にある実際のZooBCの操作です。どのスペシャリストを選び、作業をどう検証し、どの署名を有効とみなすかは、引き続きアプリケーションのコードが決めます。
- 01 / TXタイプ29
利用枠をロックする。
scheduled-transfer
funding_mode: 0所有者が総額を事前にロックします。生涯の上限を変更するには、新しいトランザクションが必要です。
→ - 02 / エスクロー
支払いを提案する。
zbc-send
--escrow-approverエージェントは承認者を指名し、自動返還のための絶対値のUnixタイムアウトを指定します。
→ - 03 / マルチシグ
しきい値を満たす。
zbc-cli multisig
2 of 3 example高額な支払いでは、アプリケーションが納品を検証し、内側の送金が実行される前に、必要な3つの署名のうち2つを集めます。
→ - 04 / 公開API / TESTNET
決済して検証する。
approve-escrow approval: 0
GET https://zoobc.network/api/v1/transactions/{hash}
GET https://zoobc.network/api/v1/accounts/{address}/history承認されれば資金が解放され、タイムアウトすれば返還されます。どちらの経路をたどったかは、トランザクションとアカウント履歴が証明します。
✓
仕組み
最初のファイルから検証済みトランザクションまで、4つのステップ。
厳しい質問
境界が解決すること、しないこと。
台帳は金銭的な条件を強制できます。しかし、慎重なエージェント設計、アイデンティティの主張、結果の検証に取って代わることはできません。
01支出上限があれば、エージェントは安全ですか？
上限が抑えるのはリスクにさらされる金額であり、すべての購入が賢明であることを保証するものではありません。タスクの権限、取引先の選定、結果の検証、運用の監視は、引き続きウォレットを取り巻くエージェントシステムの役割です。
02エージェントは自分の利用枠を引き上げられますか？
ここで説明している上限付きのパターンではできません。コミット済みの上限を引き上げるには、利用枠を管理するアカウントが承認した新しいトランザクションが必要です。
03提案された支払いが承認されないままだと、どうなりますか？
提案には有効期限を設定できます。その期限までに承認が届かなければ、エスクローされた価値は無期限に保留されるのではなく、設定された返還経路をたどります。
04どのエージェントが操作を承認したかは、何によって証明されますか？
暗号署名は、特定の鍵の保有者がそのメッセージやトランザクションを承認したことを証明します。その鍵の運用者、目的、評判に関する主張については、明確な署名付きレコードと独立した検証が別途必要です。
05これはエージェント向けの製品ですか、それともブロックチェーンの基本機能の集まりですか？
現時点での基盤は、ZooBCのトランザクションレイヤーです：アカウント、署名、エスクロー、マルチシグネチャによる承認、トークン、そして監査可能な台帳。本番環境でエージェントを統合するには、それらの基本機能を個々のワークフローに合わせて組み立てるソフトウェアが引き続き必要です。
TESTNET稼働中
まず実証し、それから境界を加える。
動作するリファレンスから始めて実際のTestNetトランザクションを確認し、その後ワークフローに必要な利用枠、承認、監査の制御を加えましょう。