学習サンプル、重みファイル、推論呼び出し——誰が報酬を受け取るべきなのでしょうか。従来のプラットフォームは自前の台帳と紙の契約で答えますが、貢献者はそれを簡単に検証することも、強制することもできません。権利の欠如はまずエンジニアリングと制度のギャップであり、スローガンのギャップではありません。本稿では、権利を実行可能にする仕組みと、Bitroot 関連の設計が決済とトラステッドコンピューティングの上にどう位置づけられるかを概観します。
三つの不透明な台帳
データ：一度プラットフォームに渡してしまうと、貢献者は自分のサンプルをどのモデルが使ったかを証明できず、モデルが収益を上げたときに取り分を請求することはなおさらできません。データは追跡可能な資産ではなく、使い捨ての原材料になってしまいます。
モデル：パラメータと構造はデジタル資産ですが、共通の権利・ライセンス・呼び出しの計量がありません。重みが一箇所にあると、外部の者は呼び出し回数や収益を独立に確認できず、設計者はプラットフォームの決済表を受け入れることになります。
収益：たとえプラットフォームに意欲があっても、手作業の監査とオフライン契約に頼らざるを得ず、遅く紛争も起きやすい。データ・モデル・計算の当事者には、書かれたとおりに動く共通の支払い状態機械がありません。
「オンチェーン化」それ自体はこうしたギャップを消し去りません。チェーンが提供するのは、プログラム可能で監査可能な実行環境にすぎません。信頼ギャップの全体像については、Web3 と AI の融合を参照してください。
プラットフォームの帳簿から検証可能なパイプラインへ
以下の図は、プラットフォームによる一方的な会計と、インデックス＋暗号技術＋コントラクトによる価値フローの考え方を対比したものです（例示であり、財務上の約束ではありません）。
オンチェーンに置くのはメタデータであり、コーパス全体ではない
妥当なアプローチは、ファイルのハッシュ、バージョン、サイズ、差分ダイジェストをオンチェーンに登録し、本体のペイロードは分散ストレージやオブジェクトストレージに置くというものです。シャード配信と Merkle チェックでダウンロードの完全性を検証します。取得したシャードが登録内容と一致することを誰でも確認でき、チェーンが生のコーパスをホストする必要はありません。これは「データセットを画像のようにミントする」こととは別物です。
アクセス制御：閾値鍵＋任意の TEE 監査
商用データとモデルにはアクセス制御が必要です。閾値暗号化／MPC は鍵を分割し、復号や署名に定足数を要求することで、単一ノードからの盗難リスクを小さくします。アクセスと認可の変更はオンチェーンに記録を残すべきです。機密性の高いスライスは TEE 内で実行し、ハードウェアに境界づけられた利用監査を行うこともできますが、サイドチャネルとサプライチェーンのリスクは受け入れることになります。役割分担についてはトラステッドコンピューティング・フレームワークを参照してください。
モデルの重み：取り出せないが使える
モデル資産における難しい問題の一つは、どの単一の相手にも完全な重みを与えることなく、ノードに推論を提供させることです。エンジニアリング上の道筋は (t, n) 閾値シャーディングです。任意の t 個のシェアで推論結果の集約に寄与でき、t 個未満では使える重みは得られません。ノードはローカルのシェア上で計算し、MPC で集約し、出力の完全性を確認するために ZK 制約を付加することもできます。
利用権と完全な所有権は技術的に分離できますが、法的な著作権とライセンスには依然として契約と法域が必要です。オンチェーンのルールがすべての著作権法に取って代わるわけではありません。
スマートコントラクトによる分配：状態機械としての取り分
呼び出しが収益を生むと、コントラクトは事前登録された取り分に基づいて支払いを実行します。データ貢献者、モデル設計者、計算提供者のそれぞれがオンチェーン上の比率を持ち、すべての決済が監査可能になります。これが答えるのは「ルールが実行されるかどうか」であり、「比率が公正かどうか」（それは依然としてガバナンスと交渉の領域）ではありません。
ソーシャルログイン／閾値セッション鍵は秘密鍵の UX ハードルを下げますが、カストディとリカバリを MPC 参加者集合にさらします。この脅威モデルは明示的に記述すべきです。
決済と計算との接点
権利と支払いの状態機械には、予測可能な確認と十分なスループットが必要です。特に高頻度の推論課金や複数コントラクトにまたがる分配ではなおさらです。楽観的並列 EVM を決済基盤とする場合、性能の数値はテストネット／エンジニアリング上の目標として読み、コンフリクトのホットスポットが並列性を崩さないかどうかに注目してください（並列 EVM アーキテクチャ概要と性能指標の用語集を参照）。ジョブの受け入れと支払いのインターフェースについては分散 GPU とエッジコンピュート、能力の境界については AI ネイティブ・ブロックチェーンを参照してください。
本稿は、いかなる利回りや投資リターンについても論じたり示唆したりするものではありません。
よくある三つの設計上の落とし穴
所有権が表示専用で、取り消しや分配の状態遷移がないこと。異議を唱えられない計量が課金を再中央集権化すること。ファインチューニングや蒸留におけるバージョン／ライセンスの継承を無視すること。より安定した MVP は、ハッシュ登録＋シンプルな呼び出し単位の分配＋取り消し可能なライセンスであり、複雑な閾値スキームよりも先に紛争処理が機能するようにします。仕組みの話と利回りの想像は切り離しておくべきです。決済がマイクロペイメントの分配に耐えるかどうかについてはマルチエンジン並列実行の設計を参照してください。
法域をまたぐ場合、オンチェーンのルールが提供できるのはせいぜい「当事者が合意した自動実行プログラム」であり、プラットフォーム外のコピーを消し去ったり、学習コーパスが権利侵害に当たるかどうかを裁定したりはできません。ドキュメントには、システムが保証すること（ハッシュ、ライセンスイベント、分配の実行）と保証しないこと（世界的な著作権の帰属、利回り水準）を明記すべきです。アクセス保護についてはトラステッドコンピューティング・フレームワーク、信頼ギャップについては Web3–AI の融合を参照してください。
分配に多数の小さな高頻度支払いが含まれる場合は、アカウント抽象化、バッチ決済、オフチェーンチャネルも検討し、ガスと確認のゆらぎが分配そのものを食いつぶさないようにしてください。これらは決済能力の上に成り立つアプリケーション・アーキテクチャの選択であり、L1 がすべての分配を補助すべき理由にはなりません。これは投資や利回りに関する助言ではありません。
計量・取り消し・紛争：権利の後半部分
ハッシュ登録は始まりにすぎません。実行可能な権利には、二重計上を防ぐ計量、ライセンス失効や違反時の課金停止、取り分変更のためのマルチシグ／ガバナンス、そして著作権紛争時に監査証跡を壊さずにフローを凍結する能力も必要です。こうした状態機械がなければ、オンチェーンのインデックスは高価な主キーにすぎません。
コンピュートネットワークに接続する際、ジョブの受け入れが自動的に「支払い可能」と等しくなってはなりません。呼び出し側には依然として有効なライセンスが必要です。並列決済レイヤー上の高頻度マイクロ分配はガスとコンフリクト面を増幅するため、異議申し立て可能な詳細コミットメントを伴うオフチェーン集約が必要になる場合があります。コンフリクトについてはコンフリクトのホットスポットとワークロード、スタック内の位置づけについては分散型 AI スタックを参照してください。
プライバシーと公開監査の緊張関係
権利は監査可能性を求め、商用データは機密性を求めます。閾値シャーディングと TEE は助けになりますが、「誰もがすべての推論を検証できる」と「重みが信頼された集合から決して出ない」を同時に、ほぼゼロコストで提供することはできません。プロダクトは主要な対象者を選ぶ必要があります。規制当局の監査、貢献者による支払い確認、公的な検証可能推論のいずれかであり、それぞれコスト曲線が異なります。
完全なプライバシー、完全な公開検証可能性、ほぼゼロコストを同時に示唆することは避けてください。誠実なレイヤリングとは、オンチェーンでの計量と分配、認可されたオフチェーンの詳細、紛争時の最小限の証拠です。トラステッドコンピューティングの役割についてはトラステッドコンピューティング・フレームワークを参照してください。
まとめ
実行可能な権利には、検証可能なメタデータ、閾値鍵と閾値重み、監査可能なアクセス、自動支払いコントラクトが必要であり、それらはトラステッドコンピューティングと決済の上に積み重なります。これにより「誰が何を、どのルールの下で貢献したか」がプラットフォームのブラックボックスから検証可能な状態機械へと移ります。ただし著作権紛争を自動で解決するわけでも、コンピュートネットワークを利回り商品に変えるわけでもありません。関連資料を読む際は、脅威モデルと受け入れフローを優先してください。