原文
ERC-8004 Validation Network Interface — extension for multi-validator networks — Traciecmyers (2026-05-31)
これは、ERC-8004 (エージェントIDレジストリ)のドラフト拡張であり、検証ネットワークのための標準コントラクトインターフェースを定義します。検証ネットワークとは、ERC-8004のValidation RegistryにおけるvalidatorAddressが単一の当事者ではなく、独立した検証者（バリデータ）のネットワークである実装を指します。
ドラフト仕様: https://github.com/pokt-network/erc-8004-vni
解決しようとしている問題
ERC-8004のValidation Registryは、誰が検証を行うかについて意図的に意見を持たず、それは正しいことです。しかし、この表面的な設計は、実装ごとに2つの異なるセキュリティ上の疑問を残しており、どちらにもポータブルな答えがありません。
1. 検証者自体はどのように信頼されるのか？
単一のvalidatorAddressは単一の信頼の基点 (trust anchor) です。もしその当事者が侵害される、買収される、または検証されるエージェントと共謀した場合、検証は無価値になります。そしてERC-8004は、より高価な評判エントリの書き込み方法に還元されてしまいます。実際には3つのパターンが出現していますが、どれもポータブルではありません。
-
単一検証者のアドレス — 運用はシンプルですが、ERC-8004が緩和しようと設計された中央集権的な信頼の仮定を再導入します。
-
TEEベースのアテスター — 強力な暗号学的保証を提供しますが、ハードウェアの信頼性への依存と、限られた適格オペレーターセットを伴います。
-
特注の閾値スキーム — 各チームが独自の選択ルール、アテステーション（証明）形式、および検証パスを構築します。複数のネットワークと統合するクライアントは、ネットワークごとに接着コード (glue code) を記述します。
今日の共有インターフェースでは、クライアントが「少なくともD個の異なるオペレーターから選ばれたN個の検証者を、Tの期限で提供し、署名されたアテステーションの検証可能なバンドルを返せ」と指示することはできません。この特性を構築するすべてのチームは、ゼロから構築しています。
2. 作業はどのように信頼されるのか？
マルチ検証者の選択は必要ですが、十分ではありません。ネットワークがD個のオペレーターにわたってN個の検証者を呼び出したと主張したとしても、依拠する当事者 (relying party) は、ネットワークが実際にそれらの検証者を選択し、作業を実行し、返されるアテステーションを収集したという証拠を依然として必要とします。その証拠がなければ、マルチ検証者ネットワークはアグリゲーターの言葉に帰着し、運用上は単に名前のリストを公開する単一の検証者よりも強力ではありません。
この2番目の疑問には、様々な回答があります。署名のみのアテステーション（誰でも署名を検証できますが、選択は信頼に基づきます）、インデクサーが証明する選択（検証者ネットワークの状態のサードパーティインデクサーが選択が正当であったことを保証します）、イーサリアム上の基盤となるネットワークのコンセンサス状態のライトクライアント検証（サードパーティは不要）、選択と検証のZKまたはTEE実行証明などです。適合するネットワークはどれもそのスペクトル上のどこかに位置し、インターフェースはその配置をクライアントに暗黙的ではなく可視化すべきです。
この拡張がすること
ERC-8004に厳密に加法的な3つの要素：
-
IValidationNetwork— 既存のValidation Registryをラップするコントラクトインターフェース。適合するネットワークは、選択を実行し、選択された検証者からのオフチェーンアテステーションを受け入れ、集約し、ERC-8004の既存のvalidationResponseを通じて書き戻します。submit()における宛先検証 (addressee verification) は、第三者が自分宛ではないリクエストでネットワークのリソースを消費するグリーフィングパスを閉じます。 -
SelectionPolicy— オペレーター多様性 (minOperators) を第一級フィールドとして、selectionSize、minResponses、deadlineSeconds、verdictModeと並んで持つ規範的なポリシー構造体。ネットワークは選択時にminOperatorsを強制します。実効オペレーター数がポリシーを満たせないネットワークは、静かに劣化するのではなく、supports()を通じてそれを拒否しなければなりません。 -
EIP-712アテステーションプロファイルエンベロープ — 各検証者がオフチェーンで署名する型付きデータ構造で、集約されたバンドルは規範的な (JCS) JSONとしてValidation Registryの
responseURIに書き込まれます。同じ検証コードが、適合する任意のネットワークで機能します。
Validation Registryコントラクトは変更されません。単一アドレスの検証者は変更なく機能し続けます。パーミッションレスRPCネットワーク、リステーキングベースのAVS、TEEコンソーシアム、分散型オラクルネットワークなど、十分に分散化された基盤であれば、このインターフェースを実装できます。
v0.1がまだ指定していないこと
公開前のレビューで1つの大きなギャップが浮上しました。v0.1はアテステーション形式を定義していますが、検証モデルは暗黙のままです。上記の信頼スペクトルの異なる点にあるネットワークは、コントラクトの表面上ではすべて同じに見えます。v0.2で追加される可能性が高いのは、verificationModel()ビュー（そしておそらくoperatorModel()ビュー）であり、これにより依拠する当事者は、送信する前に何を信頼しているのかを内省できます。適切な列挙と粒度についてご意見をいただければ幸いです。
未解決の疑問
-
検証モデルの表面化。 インターフェースはネットワークに検証モデルの宣言を要求すべきか、また適切な列挙は何か？（上記参照）
-
ポリシーのスキーマ。 不透明な
extensionsフィールドを持つ固定の規範的構造体か、このレイヤーでレジストリ定義可能で拡張可能か？（現在の傾向: 固定） -
検証ネットワークレジストリコントラクト。 必要か否か？（現在の傾向: 不要 — クライアントは
validatorAddressを直接ERC-8004に渡し、発見はエージェント/インデクサー層で行われる） -
EIP-7702フックによるスポンサー付き検証 — v1の範囲内か、それとも後続の拡張か？
-
コスト発見。
quote()からの単一のuint256で表現は十分か、それとも価格設定に構造が必要か？ -
スペクトル判定 (
verdictMode = mean) — 後続の拡張かv1か？
ドラフトの「Open Questions」セクションに完全なリストがあります。
ご意見を伺いたい方々
エージェントエコシステムは、ERC-8004 (エージェントIDレジストリ)を信頼層のプリミティブとして定着させつつあり、マルチ検証者の問題は現在、本番環境で解決されつつあります。私たちは、互換性のない複数のインターフェースよりも、1つのポータブルなインターフェースを持つことを望んでいます。
特に、TEEコンソーシアム、リステーキングAVS、分散型オラクルネットワーク、パーミッションレスRPCネットワークを運営するチームからのフィードバックに関心があります。このインターフェースは、皆様を対等な立場で受け入れるように設計されており、それが実際に当てはまるかを確認したいと考えています。共同執筆者も歓迎します。
6投稿 - 2参加者