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

著者：Azuma，Odaily 星球日报

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

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

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

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

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

例えば、あるマーケティング志向のエージェントAが、画像生成に特化したエージェントBにマーケティングポスターを制作してもらいたいと考えた場合、ここには商業的な相互信頼の問題が存在します ------ 双方は互いに知らず、信頼の基盤もないため、いつ支払うべきか？もしAが先に支払った場合、Bは仕事を放棄したり、不適切な成果物を返したりする可能性があります；もしBが先に作業を行った場合、Aも報酬を拒否する可能性があります......

伝統的なインターネットの世界では、ユーザーと商人も同様の商業的な相互信頼の問題に直面し、プラットフォームがその中で重要な仲介の役割を果たしています ------ プラットフォームはAの資金を保管し、Bのサービスが完了したかどうかを判断し、最終的な支払いを行います。私たちがよく知っている淘宝、京东、美团、滴滴は、本質的にこのようなプラットフォーム型の仲介です。

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

ERC-8183の作業方案の分解

ERC-8183の運用メカニズムはそれほど複雑ではなく、この標準は「Job（タスク）」という新しい概念を導入しています。各Jobは完全な商業取引と見なすことができ、3つの異なる役割が含まれます：

• Client：「クライアント」、簡単に言えば、さまざまなタスクを発注するエージェント；
• Provider：「サービスプロバイダー」、タスクを完了するエージェント；
• Evaluator：「評価者」、最も特異な役割で、タスクが完了したかどうかを判断します。

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

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

ERC-8183はこれらの異なる形態を区別しません。プロトコル層はただ一点に関心を持っています ------ あるアドレスが「complete」を呼び出すのか「reject」を呼び出すのか、そしてそのアドレスの背後で動いているのがLLM駆動のAIエージェントであるのか、ZK回路であるのかは、プロトコルが関心を持つ範囲ではありません。

Jobに戻ると、各Jobのライフサイクルには以下の4つの状態があり、これは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まで、あまり馴染みのない読者は混乱するかもしれません。なぜしばらくおきに新しいものを作る必要があるのか疑問に思うかもしれません。しかし、実際には、これら3つはAIエージェント経済システムの異なる3つの段階に位置しており、解決しようとしている問題も異なります。

x402はHTTP支払いプロトコルであり、AIエージェントがAPIを呼び出すように直接支払うことを可能にすることを目指しています；ERC-8004はAIエージェントのアイデンティティと評判の標準であり、エージェントが信頼できるかどうかを判断する問題を解決します；ERC-8183は商取引の段階に焦点を当て、信頼しない2つのエージェントが取引を完了させる方法を解決しようとしています。

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

この3つは競争関係ではなく、補完関係にあり、共通の目標に向かっています ------ 分散型で自律的に運営されるAIエージェント経済システムを構築することです。