ERC-8183の詳細解説：イーサリアムがAIエージェント間の相互信頼問題に挑む答え

オリジナル | Odaily (@OdailyChina)

著者｜Azuma (@azuma_eth)

3月10日、イーサリアム財団傘下で「人工知能（AI）とブロックチェーンの深い統合」の推進に焦点を当てるdAIチームは本日、Virtuals Protocolと共同で新しい標準規格ERC-8183を発表しました。

イーサリアム財団AI責任者のDavide Crapis氏はこの標準について、ERC-8183はイーサリアムコミュニティが構築中のオープンなAgent経済システムに欠けていたコンポーネントの一つであり、この標準はx402およびERC-8004と組み合わせて使用でき、Agent間の安全な相互作用においてインフラとしての役割を果たすと述べました。dAIチームはERC-8183の採用を支援し、中立な標準となることに尽力します。

ERC-8183は何を解決しようとしているのか？

Virtuals Protocolが公開した紹介記事によると、ERC-8183はAI Agent間の商業取引のために設計されており、この標準は一連のオンチェーンルールを定義し、互いに信頼関係のない2つのAgentが、中央集権的なプラットフォームに依存することなく「雇用-納品-決済」というビジネスプロセスを完了できるようにします。

ERC-8183が解決しようとしている核心的な問題は、Agentが互いに雇用・協力する際に、プラットフォームも法律も人的仲裁もない状況で、どのように取引を完了させるかということです。

例を挙げると、あるマーケティング志向のAgent Aが、別の画像生成志向のAgent Bを雇って一連のマーケティングポスターを作成してほしい場合、ここにはビジネス上の信頼問題が存在します。双方は互いを知らず、信頼の基盤もありません。いつ支払うべきでしょうか？もしAが先に支払えば、Bはサボったり不合格の作業結果を返したりする可能性があります。もしBが先に作業をすれば、Aが報酬の支払いを拒否する可能性もあります…

従来のインターネット世界でも、ユーザーと事業者は同様のビジネス上の信頼問題に直面し、プラットフォームが重要な仲介役を担っています。プラットフォームはAの資金を預かり、Bのサービスが完了したかどうかを判断し、最終的な資金の引き渡しを担当します。私たちがよく知る淘宝、京東、美団、滴滴は、本質的にこのようなプラットフォーム型仲介です。

イーサリアム財団とVirtuals Protocolが目指しているのは、ERC-8183を通じてプラットフォームの機能をオンチェーンプロトコルとして抽象化し、スマートコントラクトによって実行させることで、Agent経済において分散型の仲介役を担うことです。

ERC-8183の仕組み分解

ERC-8183の動作メカニズムは複雑ではありません。この標準は、Job（「タスク」と理解してよい）という新しい概念を導入しています。各Jobは一つの完全な商業取引と見なすことができ、以下の三つの異なる役割を含みます：

• Client：「クライアント」、簡単に言えば様々なタスクを発注するAgentです。
• Provider：「サービスプロバイダー」、タスクを完了する責任を負うAgentです。
• Evaluator：「評価者」、最も特殊な役割で、タスクが完了したかどうかを判断する責任を負います。

ここで特に説明が必要なのはEvaluatorです。この役割の導入がERC-8183の最も核心的な設計です。この標準では、Evaluatorは単にオンチェーンアドレス（address）として定義されていますが、より広義には、このアドレスの背後には様々な異なる実行形態が対応し得ます。

• 執筆、デザイン、分析など主観性を伴うタスクの場合、EvaluatorはAI Agentであり、提出された結果を読み取り、当初のタスク要求と比較して判断を下すことができます。
• 計算、証明生成、データ変換など決定論的なタスクの場合、Evaluatorはゼロ知識検証器（ZK verifier）をカプセル化したスマートコントラクトとすることができます。Providerが証明を提出し、Evaluatorがオンチェーンで検証を行い、「complete」または「reject」を自動的に呼び出してタスクを完了または拒否します。
• 高価値または高リスクのタスクシナリオでは、Evaluatorはマルチシグアカウント、DAO、またはステーキングメカニズムによって支えられた検証クラスターとすることもできます。

ERC-8183はこれらの異なる形態を区別しません。プロトコル層が関心を持つのは一点だけです——あるアドレスが「complete」を呼び出すか「reject」を呼び出すかです。そのアドレスの背後で動作しているのがLLM駆動のAI AgentであろうとZK回路であろうと、プロトコルが関心を持つ範囲外です。

Jobの話に戻ります。各Jobのライフサイクルには以下の四つの状態があり、これらはERC-8183が動作する際の異なるプロセスに対応しています。

• Open：Clientがこの期間にJobを作成し、タスクを発注して要求を明確にします。
• Funded：ClientはコミッションをProviderに直接渡すのではなく、スマートコントラクトのエスクローアドレスに転送します。
• Submitted：Providerが作業を完了し、証明を提出します。
• Terminal（Completed / Rejected / Expired）：Evaluatorがタスクの審査を担当し、審査結果に基づいてタスクが完了したかどうかを判断し（CompletedまたはRejected）、資金をそれぞれClientまたはProviderに振り込みます。時間内にProviderが応答またはタスクを完了しなかった場合、資金はClientに返還されます。

上記の標準プロセスに加えて、ERC-8183はモジュール化された拡張機能Hooksを通じて、より多くの派生機能を実現し、現実世界の複雑なビジネスユースケースに対応することができます。HooksはJob作成時に付加されるオプションのスマートコントラクトであり、Jobの各ライフサイクルの前後にカスタムロジック（例えば信頼スコアの閾値、入札メカニズム、手数料配分、その他の特殊な要求など）を実行できます。

ERC-8183とx402、ERC-8004はどう違うのか？

x402からERC-8004、そして現在のERC-8183まで、あまり詳しくない読者は混乱し、なぜしばらくすると新しいものを作らなければならないのかと疑問に思うかもしれません。しかし実際には、これら三つはAI Agent経済システムの三つの異なる段階に位置し、解決しようとしている問題もそれぞれ異なります。

x402はHTTP支払いプロトコルであり、解決しようとしているのはAI AgentがAPIを呼び出すように直接支払いを行えるようにすることです。ERC-8004はAI Agentのアイデンティティとレピュテーション（評判）の標準であり、解決するのはあるAgentが信頼できるかどうかを判断する方法です。ERC-8183は商業取引の段階に焦点を当て、信頼関係のない二つのAgentがどのように取引を完了させるかという難題に挑戦しようとしています。

一言でまとめると、x402は「どうやって支払うか」を担当し、ERC-8004は「相手が誰で、どれだけ信頼できるか」を知ることを担当し、ERC-8183は「どうやって安心して取引するか」を処理することを担当します。

これら三つは競合関係ではなく、補完関係にあります。それらは同じ目標——分散型で自律的に運転するAI Agent経済システムの構築——を共同で目指しています。