Virtuals がイーサリアム財団と共同で ERC-8183 を発表：信頼を必要としないオンチェーン商業プロトコル
TechFlow厳選深潮セレクト
Virtuals がイーサリアム財団と共同で ERC-8183 を発表：信頼を必要としないオンチェーン商業プロトコル
ERC-8004は信頼性のため、ERC-8183は商業目的のため。
Web3業界の深掘り報道に専念し潮流を洞察著者： Virtuals Protocol
翻訳編集： TechFlow
TechFlow 解説： Virtuals Protocol は、イーサリアム財団の dAI チームと共同で ERC-8183 標準提案を発表しました。その核心的なアイデアは、AI Agent 間の経済的インタラクションのための、非信頼型（trustless）なオンチェーン商業プロトコルを構築することです。
これは単なる支払いプロトコルではありません。タスク仕様、エスクロウ（第三者保管）、納品物検証、評価認証を含む、一連の商業インフラストラクチャ全体です。
以前に発表された ERC-8004（Agent のアイデンティティと評判）と組み合わせることで、両標準は完全なフィードバックループを形成します：発見 → トランザクション → 評判の蓄積 → より良い発見 → より多くの非信頼型取引。
AI Agent 経済のオンチェーン実装への道筋にご関心がある方には、ぜひ通読をお勧めします。
本文全文：
Virtuals Protocol とイーサリアム財団 dAI チームによる共同開発
標準仕様：https://eips.ethereum.org/EIPS/eip-8183
議論掲示板：ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
ビルダー・コミュニティに参加：https://t.me/erc8183
商業：分散型 AI の前提条件
もし私たちが AI Agent を誰もが利用可能で、分散化され、単一プラットフォームによる支配や単一プロバイダーへの依存を避け、単一障害点（SPOF）を持たないものにしたいと考えるなら、商業は不可欠です。商業は後付けで考えられるものではなく、インフラストラクチャそのものでなければなりません。そしてこの商業は、常にオープンかつパーミッションレス（許諾不要）でなければなりません。まさにこれが @ethereum が創出しようとしている「所有者がいない共有デジタル空間」です。
なぜでしょうか？ AI および Agent 層における分散化には、多数の独立した Agent とサービスが必要だからです。たとえば、画像生成を実行できる Agent がただ一つしか存在せず、それがサービスを停止した場合、それがどんなプロトコル上で動作していたとしても、画像生成は中心化されたものになってしまいます。取引の実行を制御するプロバイダーがただ一人しかいなければ、資金管理はその単一当事者の運用意思に左右されます。決済インフラストラクチャを制御するプラットフォームがただ一つしかなければ、すべてのプロバイダーおよびすべての顧客は、そのプラットフォームのルールに従わざるを得ません——たとえそのプラットフォーム上に千の Agent が存在しても同様です。
そこで必要なのは「オープンな商業」です。すなわち、いかなる Agent もサービスを購入でき、いかなる Agent もサービスを提供できるという状態です。ゲートキーパーもなければ、ウォールドガーデン（閉じられたエコシステム）もなければ、強制的な中間業者もありません。
なぜブロックチェーンなのか
重要なのは、商業が機能するためには、関係者全員が「取引が確実に履行される」と信頼できることが必須であるということです。顧客が先に支払った場合、プロバイダーが納品するかどうかをどうやって保証できるでしょうか？ 逆に、プロバイダーが先に納品した場合、顧客が支払うかどうかをどうやって保証できるでしょうか？ 誰かが資金を一時的に保管し、作業が完了したかどうかを追跡し、結果に基づいて処理を実行しなければなりません：完了時には支払いを解放し、失敗時には返金するのです。こうした「信頼（あるいは不信）」こそが、根本的に中心化されたエンティティやゲートキーパーを生み出す原因です。
従来のアーキテクチャでは、この「誰か」がプラットフォームです。ある企業がエスクロウ資金を管理し、ステートマシンを制御し、誰がいつ報酬を得るかを決定します。この方式は一時的には機能しますが、いつまで機能し続けるかは保証されません。プラットフォームはルールを変更したり、資金を凍結したり、プロバイダーを削除したり、サービスを停止したりできます。すべての参加者は、プラットフォームが継続的に善意で行動することに依存しています。これはプロトコルレベルでの中心化ではなく、実行レベルでの中心化です。これは間違いだとは言えませんが、信頼のないシステムにおいては、これが必要不可欠な手段です。我々の目標は「全支配の解体（de-totalization）」——すなわち、いかなる単一エンティティも Agent 間の取引方法を完全に支配できないようにすること——です。私たちは実際に目撃してきました：開発者が望んでいるのは、信頼できるが、同時に特定のプラットフォームの善意に依存する必要がないインフラストラクチャです。
分散化されたブロックチェーン上のスマートコントラクトこそが、この課題に対する解決策の試みです。エスクロウ、ステートマシン、評価者認証はすべて、公開的で不変であり、誰のものでもないコード内に存在します。コントラクトは中立的な実行者であり、それによって各当事者の評判にとって意味のあるシグナルが生成されます。
オンチェーン決済は、中心化プラットフォームが提供できないものをもたらします：移植可能で、検証可能で、改ざん不能な記録です。完了した各タスク、各評価者による認証、各納品物のハッシュはすべてブロックチェーン上に記録され、どの Agent、どのプラットフォーム、どのインターフェースからでも閲覧可能です。これらの記録は、評判システムおよび Agent アイデンティティを養うための原材料です。オンチェーン決済がなければ、検証可能な履歴は存在しません。検証可能な履歴がなければ、移植可能な評判も存在しません。移植可能な評判がなければ、すべての Agent 間インタラクションはゼロトラストから始まらざるを得ません。
だからこそ、オンチェーン標準が必要なのです。エスクロウ、ステート遷移、認証——これらは中立的で、安全で、実行可能なものでなければなりません。
発見、交渉、通信は、オンチェーンでもオフチェーンでも、最も自然なインターフェースを用いて行われます。Agent は HTTP を介して x402 インターフェースプロトコルを使って相互にやり取りでき、標準的な API や HTTPS リクエストと同様のユーザーエクスペリエンスを提供します。Agent が直接ブロックチェーンと接続する必要はありません。Agent はメッセージに署名し、ファシリテーター（調整者）がオンチェーン決済および標準の処理を代行します。あるいは、Agent が MCP や A2A を介して直接やり取りすることも可能です。インターフェースは柔軟ですが、コアとなる決済は非信頼的で、プログラム可能で、オンチェーンであるべきです。これは、その支配力を弱めるために、中心化システムが自ら提供しないインフラストラクチャです。
Agent 経済
AI モデルおよび Agent は、毎月急速に進化し、より高度になっています。1 年前には人間の専門知識を要していたタスク——本番環境向けコードの作成、専門的なメディアコンテンツの生成、金融データの分析、多段階ワークフローの調整など——が、今や Agent によって同等、あるいはそれ以上の品質で遂行されています。しかもその能力はさらに加速的に向上しています。AI の進化軌道は、新たな経済の誕生を必然的に導きます。
Agent がより高度になると、それらが担う仕事の価値も高まります。プロフェッショナルな写真と区別がつかない画像を生成できる Agent は、有料サービスとして十分に価値があります。投資ポートフォリオを分析し、最適化された取引を実行できる Agent は、現実の資金を管理しています。法務文書をレビューしリスクを指摘できる Agent は、人間が時給数百ドルで行う仕事をしています。
これが鍵となる転換点です：AI および Agent は、価値を創造し、サービスを提供する経済主体へと変貌しつつあります。
AI が誰もが利用できるようになり、個人、組織、デバイスのそれぞれが Agent を通じて活動するようになると、経済は変容します。Agent は人類とのインタラクションやサービス提供のみならず、互いにインタラクションし、互いにサービスを提供するようになります。例えば、マーケティングキャンペーンを調整する Agent は、コンテンツ作成 Agent、配信 Agent、分析 Agent を契約します。経済は、機械の速度で動き、グローバルな規模で拡張する Agent 対 Agent の取引ネットワークへと変わります。
Agent が価値ある仕事を遂行できるようになり、誰もが Agent を持つようになると、結果として、大部分の商業活動が自律的システムを経由する経済が実現します。それが、私たちが今まさに構築しようとしている未来です。
課題：Agent 間の非信頼型商業
Agent 経済には Agent 商業が必要です。そして、これまで一度もインタラクションしたことのない、異なる組織やチェーンに属する Agent 同士の商業は、非信頼型でなければなりません。
人間が取引を行い、互いに雇用したりサービスを利用したりする際には、信頼が核となります。このような状況では、信頼はプラットフォーム、レビューシステム、法制度、社会規範によって仲介されます。しかし、Agent が他の Agent を雇用する場合、こうしたメカニズムはいずれも適用できません。参照可能な社会的評判はなく、機械的な取引スピードに対応できる法的・評判的救済措置もなく、執行を担うプラットフォームや規制当局も存在しません。
そこで問題はこうなります：どうすれば Agent 間の商業を非信頼型にできるのか？
単にトークンを送金して、その後の進行を祈るだけではいけません。トークンの送金は商業ではなく、保証のない単なる支払いにすぎません。何が約束されたかを記録したものもなく、納品が満足いくまで資金を留保するメカニズムもなく、他の Agent が参照できる評価シグナルもなく、プロバイダーが納品しなかった場合の救済措置もありません。
必要なのは、構造化された協働メカニズムです：資金は、プログラマブルで分散化された中立的なエスクロウによって保管され、作業は検証可能な成果物として提出され、評価者が納品物が条項に適合しているかを証明し、その結果は確定的でなければなりません。納品が完了した時点で資金は解放され、拒否された場合は返金され、期限切れになった場合は回収可能です。これらすべては、関係者のアイデンティティおよび評判に影響を与え、あるいは貢献します。
ERC-8183：Job 原語（プリミティブ）
我々は @ethereumfndn dAI チームと緊密に協力し、これを標準として形式化しました。ERC-8183: Agentic Commerce は、オープンでパーミッションレスな Agent 商業アプリケーションのための標準であり、エスクロウおよび評価者認証は、オンチェーンスマートコントラクトとしてプログラミングされます。
ERC-8183 は、コアとなる単位「Job（ジョブ）」を定義します。各 Job は、クライアント（Client）、プロバイダー（Provider）、評価者（Evaluator）の三者で構成されます。各当事者は、そのウォレットアドレスのみによって定義されるため、この原語は非常に広範な用途に適用可能です。
Job 原語の背後にある主要コンポーネントおよび原則には以下が含まれます：（i）タスク仕様および説明——支払いと紐づけられたタスク、サービス、または作業の明確な記録；（ii）支払いそのもの——中立的かつプログラマブルなエスクロウで終了状態まで保管され、プログラムによって解放される；（iii）記録され、検証可能で、追跡可能な納品物の提出——クライアントおよびプロバイダーの双方を保護する；（iv）評価者認証——当事者のアイデンティティおよび評判に帰属可能なシグナルを生成し、非信頼型決済を促進するインセンティブを整える。
これらは、非信頼型取引を保証するための、Job の 4 つの主要な状態遷移を駆動します：
Open → Funded → Submitted → Terminal（Completed / Rejected / Expired）
まとめると：クライアントがプロバイダーとの Job を作成し、その後資金を注入して支払いをエスクロウにロックします。プロバイダーが作業を完了すると submit を呼び出し、納品物（またはその参照）をチェーン上に登録します。評価者が提出内容を審査し、complete（プロバイダーへの支払い解放）または reject（クライアントへの返金）を呼び出します。期限日までにプロバイダーおよび評価者のどちらもアクションを起こさなかった場合、Job は期限切れとなり、クライアントが資金を回収します。
この標準は意図的に最小限に設計されており、原子的な原語を形成しています。交渉プロセス、料金構造、紛争解決、通信プロトコル、発見メカニズムについては一切規定していません。それは、非信頼型 Agent 商業のための最小限の実現可能な表面（minimum viable surface）である、コアの Job ライフサイクルのみを規定しています。
評価者（Evaluator）
ERC-8183 の鍵となる概念および設計上の決定事項の一つが、「評価者（Evaluator）」です。評価者は単にアドレスとして定義されます。常に Agent であり、その定義は最も広義のものです。
ライティング、デザイン、分析などの主観的タスクに対しては、評価者は AI Agent であり得ます。これは提出された内容を読み取り、要求と照合して判断を下します。計算、証明生成、データ変換などの決定論的タスクに対しては、評価者は ZK 検証器をラップしたスマートコントラクトです。プロバイダーが証明を提出すると、評価者はチェーン上で検証し、自動的に complete または reject を呼び出します。高リスクなシナリオでは、評価者はマルチシグ、DAO、またはステーキング支援型の検証者となることも可能です。
この標準はこれらを区別しません。あるアドレスが complete または reject を呼び出します。そのアドレス上で実行されているのが LLM Agent か ZK 回路かは、プロトコルにとっては関係ありません。これにより、同一のインターフェースが、0.1 米ドルの画像生成タスクから 10 万米ドルの資産運用タスクまで、幅広く対応できます。
Hooks：モジュラーな拡張性
Job 原語は意図的に最小限に設計されています。しかし、商業はそうではありません。実際のアプリケーションでは、カスタマイズされた検証、評判の更新、手数料分配、資金移転、入札メカニズム、およびユースケースに応じたドメイン固有のロジックが必要です。コンテンツ評価タスク、トークン交換、予測市場のポジションなどは、それぞれ根本的に異なるロジックを必要とします。
ERC-8183 は、この課題を Hooks（フック）で解決します。Hook は、Job 作成時に付与されるオプションのスマートコントラクトです。各操作の前後でコールバックを受け取り、コアのライフサイクルを変更せずに、周辺にカスタムロジックを実行できます。Hook は単一のファンクションセレクター（どの状態遷移が発生しているか）によって識別され、関連するパラメータを受信します。これは、事前条件のチェック、無効な操作の阻止、副作用のトリガー、追加のトークン転送の実行などを、コアの状態変更と同じトランザクション内で実行できます。
Hook が設定されていない場合、コントラクトは通常通り実行されます。Hook を実装していないものも、完全に ERC-8183 に準拠しています。Hooks は付加的であり、必須ではありません。この設計により、コアコントラクトは簡潔に保たれ、インターフェースは安定しています。新しいユースケースは、新しい Hook コントラクトによってサポートされ、拡張ロジックは、コアと同様に、オンチェーンで、プログラム可能で、非信頼型のまま維持されます。
商業アプリケーションの例
コアの Job は、直接的なサービス取引——支払い、納品、評価——を処理します。しかし、Agent が稼働する経済は単純ではありません。一部の Job は、単なる手数料の徴収ではなく、顧客の資本を管理することを含みます。また、プロバイダーを割り当てる前に入札を行う必要がある Job もあります。さらに、外部の評判データを参照して信頼性をチェックする Job もあります。これらは根本的に異なる経済モデルであり、Hooks により、同一のコア Job インターフェースでこうした多様性をサポートできるため、ERC-8183 は汎用的な商業原語となっています。
サービス型 Job はベースラインであり、Hook を必要としません。クライアントは、コンテンツ生成、データ分析、コードレビューなどに対して支払います。コアのエスクロウおよび評価プロセスで完全に処理されます。
資金移転型 Job は、サービス料の範疇を超えています。クライアントが資本（交換するトークン、投資する資金）を提供し、プロバイダーがそれを変換し、出力を返却する必要があります。Hook は、コアのエスクロウに加えて、このような双方向の資本フローを管理し、Job 完了前にプロバイダーが出力トークンを預託することを保証できます。これは、収益耕作、トークン交換、ポートフォリオ再均衡化など、幅広いユースケースをカバーします——つまり、プロバイダーが顧客の資金を処理したり、タスク遂行のための初期資本を必要とする Job であって、単に手数料を稼ぐだけではない場合です。
入札型 Job では、割り当てモデルが反転します。クライアントが事前にプロバイダーを選択するのではなく、プロバイダーが価格で競い合います。Hook は、割り当て時に暗号化署名付きの入札を検証し、選ばれたプロバイダーが表明した価格を実際に約束したことを証明します。当事者のいずれもが条項を偽造または否認することはできません。
評判ゲート制御型 Job は、プロトコルレベルで信頼を実施します。Hook は、操作を許可する前に ERC-8004 を照会し、評判が低いプロバイダーをブロックしたり、未検証の Agent にはより厳しい条件を課したりします。
プライバシー保護型 Job は、Hooks を活用してデータの露出なしに商業を実現します。プライバシー Hook は、「提出」フィールドに、機密性の高いタスクデータをチェーン上に公開せずに、ゼロ知識証明（ZKP）または TEE（Trusted Execution Environment）などの暗号化環境の参照を含めるよう要求できます。これにより、支払いは非信頼的かつ公開的である一方で、実際の知的財産や個人データは「避難所」として保護され、承認された Agent のみがアクセス可能です。
リスク評価／引き受け型 Job は、Hooks を使ってプロトコルレベルで引き受けを実施できます。Hook は、プロバイダーまたは引き受け人が担保をステーキングすること、割り当て前に ERC-8004 の評判スコアおよびその他の関連指標をチェックすること、評価が失敗した場合にペナルティ（slash）が課される保証金を実行すること、または外部のリスクオラクルを照会することを要求できます。こうした従来は不透明だった承認プロセスを、透明で、プログラム可能で、競争的なものに変えることができます。
上記の各アプリケーションは、異なる Hook コントラクトとして実装でき、コア機能および Job 原語の標準はそのまま維持されます。新しい経済モデル、商業アプリケーション、カスタムロジックのバリエーションは、すべて新しい Hooks として実装されます。我々は最初のいくつかの Hooks を導入しましたが、これらは可能性を示すための単なる例にすぎず、まだその表面しか scratched していないと認識しています。最も興味深い Hooks は、まだ誰も書いていません。保険、クリエイティブなコラボレーション、サプライチェーンの調整といった分野で、Agent 商業はどのような形をとるのでしょうか？ 我々にはまだわかりません。それがまさに要点なのです。Agent 商業は、我々が完全には予見できない方法で進化していくでしょう——新しい経済モデル、新しい信頼メカニズム、新しい機械間協働の形態。この標準は、こうした進化に伴って成長することを意図しており、それを制約するものではありません。この標準は、オープンな中で構築されるべきであり、そうあるべきなのです。なぜなら、最高のアイデアはエコシステムから生まれるものであり、我々は皆でそれらを発見することを楽しみにしているからです。
ERC-8004 との共生関係
ERC-8183 は孤立して存在するものではありません。それは、イーサリアムにおける Agent のアイデンティティ、評判、検証のための標準である ERC-8004（「Trustless Agents」）と、共生的な関係にあります。
ERC-8004 は、発見および信頼の課題を解決します：Agent が互いを見つけ、その信頼性を評価する方法です。しかし、そのレジストリの価値は、記録される活動に依存します。商業活動や実際の行動のないアイデンティティは、空虚なアーカイブにすぎません。評判は、実際のインタラクションによって測定される必要があります。検証は、定義された納品物を照合することで初めて可能になります。
ERC-8183 は、ERC-8004 の信頼レイヤーを養う商業活動を提供します。各 Job は評判のシグナルであり、各提出は評価者が評価可能な納品物であり、各評価は他の Agent が参照可能な認証です。
両標準は、非信頼型インタラクションを通じて Agent がより高度な自己組織化を達成できるような、循環的な関係を形成します：
発見（8004）→ 商業（8183）→ 評判（8004）→ より良い発見 → より多くの非信頼型商業
どちらか一方が欠けても成立しません。両者が統合されることで、非信頼型 Agent 商業およびインタラクションの基盤が構築されます。
支払いを超えて
ERC-8183 は支払いプロトコルではなく、商業のための標準です。
支払いは金銭の移動を行いますが、商業が求められるのは、それだけではありません。商業とは、支払いを信頼可能かつ機能可能にするための、支払いを取り巻くすべての要素です：何が約束されたか、作業が完了したかどうか、誰がそれを検証したか、完了しなかった場合の対応策は何か。伝統的な世界では、商業が機能するのは、支払いを取り巻くこうした補完的要素があるからです：加盟店が支払いを受け入れる前にリスク評価および引き受けが行われる、信用供与により買主が資金の準備が整う前に取引できる、数十億件の取引からリアルタイムで不正行為を検出する、サービスが失敗した際に買主を保護する返金および紛争処理メカニズム、そして繰り返しのインタラクションを通じて蓄積される評判システム。こうした機能こそが、決済処理業者、カード組織、プラットフォームの価値であり、単なる資金の移動そのものではありません——むしろ、それを取り巻く信頼インフラストラクチャです。
商業がオンチェーンに移行するとき、こうした機能は消滅しません。むしろ、非信頼型・プログラム可能・オープンな方法で再構築される必要があります。それが ERC-8183 が行おうとしていることです。
Job 原語のエスクロウおよび評価者認証モデルは、プログラマブルで、事前に定義された決済条件を持つ返金メカニズムに類似しています。ERC-8004 のオンチェーン評判およびその他のオンチェーン評判指標を ERC-8183 の一部として使用することは、移植可能で検証可能な履歴を持つ専有の引き受けに類似しています。Hooks は、モジュラーで競争的かつ監査可能なロジックによって、中心化されたリスク評価を置き換え、あらゆるファシリテーターが展開できます。その結果は、単なるオンチェーンでの資金移動手段ではなく、完全な商業信頼インフラストラクチャの再構築——オープンでパーミッションレスなもの——です。
既存の支払いプロトコルおよびインターフェース——伝統的な処理業者であれ、x402 のような安定コイン送金プロトコルであれ——は、資金移動を滑らかに行うインターネットネイティブなエクスペリエンスを提供しています。ERC-8183 は、支払いを非信頼型取引へと変えるための、完全なライフサイクル——仕様、エスクロウ、納品物提出、評価者認証、確定的決済——を管理します。Agent はインターフェース層で x402 や HTTP を通じて相互にやり取りし、一方で、基盤となる決済は ERC-8183 を通じてオンチェーンで処理されます。これらは互いに補完的です。
不可逆性、エスクロウ、返金問題
独立した支払いに関するもう一つの懸念は、その不可逆性です。クレジットカードが請求され、サービスに満足しなかった場合、消費者は異議申し立てを行い、請求を取消すことができます。しかし、支払いが一旦送金されれば、お金は戻ってきません。原始的な支払いおよび送金に関しては、これは現実的で妥当な反論です。
ERC-8183 は、コントラクト構造の中でこのコア概念を保持しています。資金は、評価者が納品物が約束された条項に適合していることを証明するまで、エスクロウに留保されます。拒否された場合のパスでは、クライアントに返金されます。期限切れとなった場合のパスでは、自動的に回収されます。これは、カードビジネスを成立させている「承認-キャプチャー（authorization-capture）」モデルの、プログラマブルで非信頼型な等価物です——ただし、その条項は事前にコードに記述され、コードによって実行される点が異なります。つまり、後に自身の利益を追求するネットワークが裁定するのではなく、コードが裁定するのです。
金額が不確定な事前承認——ホテルのデポジット、範囲が拡大する可能性のあるサービス——については、Hooks の柔軟性を活用して、最大金額をロックし、完了時に検証可能な入力に基づいて最終金額を決済するように設計できます。このアーキテクチャは、カードビジネスの柔軟な信頼モデルおよび行動をサポートしつつ、決済の透明性、オープン性、非信頼性、およびオンチェーン性を維持します。
新たな経済主体の波
AI の波は、これまで以上に速いペースで新たな経済主体——買い手と売り手——を創出しています。数百万の開発者および非開発者が、AI プログラミングアシスタントを用いてマイクロサービス、API、ツールを構築・公開しており、多くは法的実体を持たず、ウェブサイトを持たず、取引履歴を持ちません。テクノロジー企業およびオープンソースフレームワークから提供される Agent は、個人の AI Agent やアシスタントを通じて、数百万のユーザーを獲得しています。
従来の支払いシステムは、こうした売り手をサービス提供するのが困難です。技術的に不可能というわけではなく、支払い処理業者が売り手を承認する際、その売り手に起因するリスク——詐欺、返金、紛争——を負担することになるからです。記録がなく、実体がなく、履歴のない売り手は、引き受けリスクが高すぎて、承認できません。
ERC-8183 は、パーミッションレスな設計になっています。売り手とは単にウォレットアドレスです。登録も、引き受けも、ゲートキーパーも必要ありません。Job 原語は、こうした売り手に、単なる支払い受領手段だけでなく、完全な商業ライフサイクル——仕様、エスクロウ支払い、検証可能な納品物提出、評価者認証——を提供し、信頼できる取引の基盤を築きます。
新規売り手の引き受けができないことは、一時的なギャップと見なされるかもしれません。しかし、オープンな標準は、そのタイムラインを構造的に短縮します。ファシリテーターは今日から ERC-8183 を展開できます。エコシステムは、機関による合意ではなく、実験を通じて進化します。しかし、より根本的には、ERC-8183 と ERC-8004 の併用は、引き受けギャップを埋めるだけでなく、その根本原因にも対処します。支払い処理業者が新規売り手を引き受けられない理由は、検証可能な履歴の欠如です。ERC-8183 は、この履歴を生成します。完了した各 Job は、納品物ハッシュ、評価者認証、結果とともにブロックチェーン上に記録されます。この履歴は、移植可能で、検証可能で、誰のものでもありません。
重要なのは、この記録が単一のプラットフォーム内に閉じ込められていないことです。現在、プラットフォーム A はあなたの返金率を知り、プラットフォーム B はあなたの売り手評価を知っていますが、あなたはこれらの記録をどこにも持ち運べません。ERC-8183 上では、評判は売り手自身の移植可能な資産であり、あらゆるファシリテーター、あらゆるチェーン、あらゆるこの標準を読み取れるインターフェースから閲覧可能です。ERC-8183 は、オンチェーンのアイデンティティおよび評判（ERC-8004）を養い、引き受けデータを提供します。
共に Agent 商業および分散型 AI の未来を築こう
ERC-8183 は、オープンな非信頼型 Agent 商業のための標準です。以下のように参加できます：
ERC-8183 を用いて構築しましょう。 ファシリテーターになってください！ あなたのチェーン上に ERC-8183 を展開してください。SDK、ラッパー、スキャナー、トラッカーを構築してください。ERC-8183 を用いた、オンチェーンで安全かつ検証可能な決済を実現する新しいインターフェースおよびエクスペリエンスを構築してください。この標準とネイティブにインタラクションする Agent フレームワークを作成してください。
Hooks の探求・実験・構築に取り組みましょう。 マイルストーン支払いまたは紛争解決が必要ですか？ それらを Hooks として構築してください。ここが、創造性と多様なアプリケーションの進化が起こる場所です。
評価者の構築および登録に取り組みましょう。 評価者は、安全で非信頼型の Agent 商業を保証する鍵となる部分ですが、現在は深刻な不足状態にあります。特定のドメイン向けの評価者、特に完全に検証可能な領域およびサービス向けの評価者を構築し、ERC-8004 上に登録してください。Agent の評判およびアイデンティティに有意義な貢献をしてください。
貢献およびフィードバックを提供しましょう。 これは集団的な標準です。広範な実験、実世界での利用、率直なフィードバック、および反復的な改善を通じてのみ、この標準は、それが果たすべき役割を果たせるようになります。何かが欠けていると感じたら、声を上げてください。何かが間違っていると感じたら、疑問を呈してください。仕様はオープンであり、コードベースはオープンであり、議論はオープンです。これは、共に進化させていく必要があります。
Agent 経済は、オープンな標準の上に築かれるか、あるいはウォールドガーデンの上に築かれるかのどちらかです。我々は、オープンな標準を選択します。共有のデジタル空間です。
信頼には ERC-8004 を。商業には ERC-8183 を。残りは、あなたが築いてください。
関連リンク：
- ERC-8183 仕様：https://eips.ethereum.org/EIPS/eip-8183
- ERC-8004 仕様：eips.ethereum.org/EIPS/eip-8004
- ERC-8183 に関する議論：ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
- Telegram コミュニティ：https://t.me/erc8183
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@virtuals_io
