01 / 独立したスペシャリスト
1つのモデルを分割するのではなく、本物の専門家たちが協働する。
プロトコルが目指すのは、異なるモデル、学習、ツール、専門分野を持つ、独立して運用されるシステムのネットワークです。関連するノードがそれぞれの成果を提供し、評価レイヤーが有用な結果を比較して統合します。難しいのは、品質を証明し、組織的な不正回答に耐えることです。その仕組みは、これから仕様化して検証する必要があります。
続ける制作中:MainNetに先立ってこのサイトを構築しています。内容は変更される場合があります。

ZOOBC / MAINNET後のプロトコルの方向性
電子メールは、独立して運用されるサーバー同士が直接やり取りする仕組みとして始まりました。AIはその逆の方向へと集約が進んでいます。ZooBCが探っているのは、1つのプロバイダーがやり取り全体を握ることなく、独立した専門システムが回答に貢献できるネットワークです。
ステータスこれはプロトコルの方向性であり、現時点で稼働しているAIサービスではありません。
方向性 / 多数の運用者
目指すのは、1社のモデルを安価なマシンにばらまくことではありません。本当に独立したシステム同士を協調させることです。それぞれが専門化し、意見を違え、自らの貢献を証明し、やり取り全体の支配権を1つの運用者に渡すことなく報酬を得られるようにします。
ZooBCが提供できるのは、アカウント、署名付きレコード、決済、そして監査可能な協調レイヤーです。分散推論、ルーティング、品質評価、プライベートなタスク分解は、これからのプロトコル開発の課題です。
01 / 独立したスペシャリスト
プロトコルが目指すのは、異なるモデル、学習、ツール、専門分野を持つ、独立して運用されるシステムのネットワークです。関連するノードがそれぞれの成果を提供し、評価レイヤーが有用な結果を比較して統合します。難しいのは、品質を証明し、組織的な不正回答に耐えることです。その仕組みは、これから仕様化して検証する必要があります。
続ける02 / 単一の門番はいない
独立した運用者がいれば、1つのモデルプロバイダーがアクセス、ポリシー、トーンを支配する力を弱められます。分散化はルールのないシステムを意味しません。アプリケーションは何をリクエストし何を表示するかを引き続き選び、プロトコルには不正利用への防御策が必要です。違いは、1社の企業ポリシーだけが上流で唯一ありうる答えではなくなることです。
続ける03 / 限定的な開示
将来のクライアントは、作業を分解し、各スペシャリストに必要な文脈だけを送れるようになるかもしれません。そうすれば1つの運用者が知りうる情報を減らせますが、それだけでプライバシーが保証されるわけではありません。メタデータ、タスクの相関、悪意あるルーティング、ノード間の共謀のいずれもが問題になります。プライバシーは「分散型」という言葉から想定するものではなく、公開された脅威モデルに照らして測定されなければなりません。
続ける04 / ユーザー側での統合
提案するフローでは、評価済みの貢献をユーザーが管理するソフトウェアへ戻します。その最終レイヤーで、回答を提示する前にトーンを選び、情報源を採用または除外し、ローカルの設定を反映できます。そのためには、何が組み合わされ、どの選択が適用されたかをユーザーが確認できるよう、オープンなクライアントソフトウェアと明確な来歴情報が必要です。
続ける05 / 知性の経済
ZooBCはすでに、署名付きアカウント、トークン、送金、エスクロー、マルチシグネチャによる承認、公開トランザクション記録を提供しています。これらは将来の専門家マーケットのための決済の構成要素です。マーケットそのものには、ディスカバリー、価格設定、品質測定、紛争解決のルール、そして運用者が自分自身に報酬を与える行為への耐性がまだ必要です。
続ける06 / グレースフル・デグラデーション
多様なピアネットワークは、個々のノードが消えても動き続けるように設計できます。その成否は、十分な数の独立した運用者、複製された機能、信頼できるディスカバリー、そして障害を認識できるルーティングにかかっています。レジリエンスは検証すべきアーキテクチャ上の目標であり、すべてのリクエストが常に成功するという約束ではありません。
続ける提案するプロトコルフロー
これは研究と検証の対象となる想定アーキテクチャです。現時点で利用できるZooBCのエンドポイントやノードのワークフローではありません。
正直な境界線
MAINNET後に向けて
まずはZooBCが今日証明できることから始めてください。そのうえでロードマップを追い、前提を疑い、独立したAIの協調を現実にするための取り組みに加わってください。