XODE センチネル
Gene Son ·
自動化された判断を行うことは簡単です。しかし、その後に何が起きたのかを正確に証明することは、はるかに難しいものです。XODE Sentinelは、すべての判断に暗号学的な証明書を作成し、その証明をチェーンにアンカーし、運営者を単純に信頼することなくユーザー自身が記録を検証できるようにします。
Sentinelが答える問い
自動化されたシステムが報酬を拒否したり、アカウントをブロックしたり、ポリシーを適用したりした場合、ユーザーにできることは通常一つしかありません。システムの説明を信頼することです。
Sentinelはその関係を変えます。内部ログを信頼するようユーザーに求めるのではなく、独立して確認できる記録を提供します。
従来のモデル
運営者を信頼する
運営者が判断を下し、証拠を保存し、その証拠を説明します。ユーザーはすべての段階で同じ主体を信頼する必要があります。
SENTINELモデル
証拠を検証する
判断は暗号学的な証明書となり、XODEにアンカーされるため、過去の記録を独立して検証できます。
10月1日のケース
2026年10月1日、Omniはクールダウンを理由に166件の広告報酬を、1日の上限を理由に37件を拒否しました。
ユーザーは広告を最後まで視聴し、Googleも視聴を確認しており、収益も発生していました。重要なのは、実際にどのような判断が下されたのか、そしてその記録が後から変更できるかどうかを、どのように証明するかということでした。
証拠を信頼するよう求める側が、その証拠を独占的に管理すべきではありません。
Sentinelの仕組み
すべての自動化された判断にはフィンガープリントが付与されます。ウォレット、結果、理由、ポリシー、タイムスタンプを決定論的な記録へ正規化し、暗号学的ハッシュへ変換します。
これらのフィンガープリントは1時間ごとにMerkle Treeへまとめられます。ツリーは1つのルートを生成し、フィンガープリントが1つでも変更されれば、そのルートも変化します。
そのルートは System.remark_with_event を使用してXODEへ送信されます。この時点から、運営者が過去のコミットメントを単純に書き換えることはできません。
01
判断にフィンガープリントを付与
ウォレット、結果、理由、ポリシー、タイムスタンプを1つの決定論的な記録へ正規化し、暗号学的フィンガープリントを生成します。
02
1時間ごとのMerkle Rootを構築
個々のフィンガープリントをMerkle Treeへまとめます。フィンガープリントが1つでも変更されれば、結果として生成されるルートも変わります。
03
ルートをXODEへアンカー
ルートをXODEへ送信します。公開チェーンが過去の記録に対する外部的なコミットメントになります。
確定した時間枠のみを送信します。未確定の時間枠を送信すると、後から到着した判断によって無効になる可能性があります。書き換え可能な送信には証明としての意味がありません。
ユーザーは私たちなしで検証できる
ユーザーは証明書と検証スクリプトを受け取り、自分のコンピューター上で実行できます。
スクリプトは標準ライブラリと公開RPCデータのみを使用します。検証が有効かどうかをXODEアプリケーションサーバーに問い合わせることはありません。
検証プロセスは2つの独立した質問に答えます。
01
ユーザーからの異議申し立て
ユーザーが広告を最後まで視聴したにもかかわらず、報酬を受け取っていないと報告します。
02
サポートによる照会
サポートチームが管理用の照会機能を使って該当する証明書を探します。
03
証明書をユーザーへ提供
証明書と独立した検証スクリプトをユーザーへ提供します。
04
ローカルで実行
ユーザーが標準ライブラリを使用して自分のコンピューター上で検証ツールを実行します。
ローカル計算
記録はそのルートに含まれているか？
検証ツールがローカルで証明を再構築し、ユーザーの記録が記録されたMerkle Rootに含まれているかを確認します。
公開RPC
そのルートはチェーン上に存在するか？
検証ツールが公開RPCデータを確認し、そのルートがXODEブロックチェーン上に実際に存在するかを確認します。
両方のチェックに合格すれば、その判断はそのまま記録されており、その記録が存在するという事実もチェーン上に公開アンカーされています。
サポートチームは判断を説明するだけでなく、証拠を提供できます。検証はユーザーのコンピューター上で実行され、私たちのサーバーはその計算に関与しません。
事後の改ざんは即座に検出される
拒否を承認へ変更したり、理由、タイムスタンプ、対象ウォレット、ポリシー、証拠を変更したりすると、検証に失敗します。
テストでは10個のフィールドをそれぞれ変更し、10件すべての変更が検出されました。
元の記録
証明書がルートと一致
元の判断によって生成されたフィンガープリントは、コミットされたMerkle Rootに含まれています。
改ざん後
証明書が一致しなくなる
保護されたフィールドを変更すると異なるフィンガープリントが生成され、検証に失敗します。
履歴が変わるなら、その証明も変わるべきです。
「その時点でどのルールが使われていたか」も記録される
すべての記録にはポリシーハッシュが含まれています。これは手動で管理するバージョン番号ではありません。
このハッシュは、判断が行われた時点で実際に有効だった設定から自動的に計算されます。
例：1日60回 · 180秒のクールダウン · 月間200/50上限。
後から制限が変更されると、ポリシーハッシュも変化します。そのため、ユーザーが拒否された時点で適用されていたルールを後から隠すことはできません。
手動のバージョン番号は意図的に使用していません。更新を忘れたバージョン番号は、存在しないよりも悪い場合があります。実際にシステムが使用した設定について誤った主張になる可能性があるからです。
Sentinelではないもの
ハッキングを防ぐものではありません。チェーンによってAIがハッキング不可能になるわけではありません。また、プロンプトインジェクションも防ぎません。これらの保護は、アプリ内AIに別途組み込まれた強固なガードレールによって処理されます。
判断が正しかったことを証明するものでもありません。Sentinelが証明するのは、記録が変更されていないということです。ポリシーハッシュも記録されるため、ルールそのものを別途監査できます。
この2つは明確に区別する必要があります。変更できない判断だからといって、その判断が自動的に正しいとは限りません。
検証ツールはSCALEデコードを実行しません。追加ライブラリなしで動作させる代わりに、ブロック内からルートのバイト列を直接探します。
より厳密な検証を行いたい場合は、substrate-interfaceやブロックエクスプローラーを使用して同じブロックを確認し、同じバイト列を見つけることができます。
どのような価値があるのか？
分野 現在 Sentinel導入後 報酬に関する紛争 「私たちのログを信じてください。」 「自分で確認してください。」 — 証明書 + 検証ツールを提供 規制対応 自動化された判断の監査証跡がない 変更不可能な履歴記録として過去の判断を提示できる ファーミング対策 なぜユーザーがブロックされたのかを説明する 制裁判断に検証可能な証拠を付与 企業としての信頼 内部ログだけが唯一の記録 誰でも確認できる公開チェーン上の記録
フィリピンのSECおよびBSPの規制環境では、自動化された判断に監査証跡が存在するかどうかが問われる可能性があります。
そのようなシステムがない状態でその質問に答えることと、すでに実際に稼働しているシステムを示すことには違いがあります。
拡張への道
Sentinelは現在、紛争が最も多い広告報酬の判断から開始しています。
同じ構造を、レコードの kind フィールドを変更することで、ファーミングフラグ、デバイス検証結果、AIアシスタントの応答まで拡張できます。
AIの応答を記録する場合、どのモデルが応答を生成したのか、またどのポリシーテキストがその応答を規定していたのかも保存できます。
01
広告報酬
報酬の承認・拒否の根拠となった理由とポリシーを保存します。
02
ファーミング対策
自動化されたファーミングや不正利用の判断に対して検証可能な証拠を作成します。
03
デバイス検証
デバイスIDおよび検証チェックの結果を保存します。
04
AI応答
どのモデルが応答し、どのポリシーがそのAI回答を規定したのかを記録します。
現在の状態
コレクターは現在、本番環境で稼働しています。新しい報酬判断は発生するたびに台帳へ追加されており、報酬ロジック自体は変更されていません。
コンポーネント 状態 判断コレクター 稼働中 — 実際の広告報酬判断を記録中 正規化 · Merkle Tree · Proof テスト 41/41 合格 独立検証ツール テスト 19/19 合格 毎時送信タイマー · 公開証明書API デプロイ待ち オンチェーン送信 送信アカウントへの資金補充待ち
60件のテストの中で最も重要なのは、ラウンドトリップテストではなく改ざん検出です。
拒否を承認へ変更すること、理由・ポリシー・タイムスタンプ・対象ウォレットを操作すること、証拠を置き換えること、スキーマをダウングレードすることなどをテストしています。
もう一つ重要なテストがあります： コレクターと独立検証ツールは、完全に同一の正規化バイト列を生成するか？
この2つのシステムが異なる結果を出した場合、すでに発行されたすべての証明書を検証できなくなる可能性があります。これはシステムで発生し得る最も重大な障害の一つであるため、直接テストを行っています。
より大きな意味
Sentinelは、ユーザーに自動化システムをより信頼させるために設計されたものではありません。不必要な信頼そのものを重要でなくするために設計されています。
すべての判断がフィンガープリントになります。フィンガープリントがMerkle Rootになります。そのルートがオンチェーンのコミットメントになります。そしてユーザーは結果を独立して検証する方法を得ます。
ユーザーに記録を信頼するよう求めないでください。証明書と証明、そしてチェーンを渡してください。