ERC8004 とはイーサリアム上のプロトコル規格であり、一連の標準を定義しています。これにより、エージェントがブロックチェーンを基盤に信頼関係を築くことができ、A2A(Agent to Agent)の物語とWeb3の物語を融合させることが可能になります。この記事では、このWeb3+AIの大きな物語がどのような論理で構成されているのか見ていきましょう。 プロトコルのアドレス 8月に作成され、現在もレビュー段階です。この記事では、このプロトコルが解決しようとしている問題について解説し、わかりやすく標準規格を解釈し、最後にこの規格の意義について展望します。全文所要時間は約15分です。ぜひブックマークしてください。解決しようとしている問題まず、このプロトコルが何を解決しようとしているのか見てみましょう。 簡単に言えば、A2A(エージェントがエージェントを呼び出す)過程における信頼の問題の解決です。例えば、私には「小A」というAIアシスタントがおり、これはエージェントです。彼に信頼できる出前を頼みたいとします。しかし、私のエージェントはこの部分が得意ではありません(結局、出前員や店舗と連携するのも大規模な作業であり、小さなAIアシスタントだけでは対応できません)。では、どうすれば良いのでしょうか? その場合、他のエージェントに協力を依頼できます。では、私のエージェントがどうやって信頼できる別のエージェントを見つけるのか?信頼機関が必要なのではないか?実は人間も同じです。例えば、淘宝(タオバオ)を通じて取引します。淘宝は中心化された信頼機関です。しかし、中心化された信頼機関には限界があります。エージェント時代では、この問題がより顕著になります。エージェントの効率性を最大限に発揮するためには、すべてを人や中央集権的な機関に頼るのではなく、AIを基盤とした信頼機関、あるいは分散型の信頼機関を活用する必要があります。そうすれば、AIの性能を最大限に引き出せるのです。 したがって、信頼できる分散型のデータを持ち、信頼できるエージェントを見つけることができれば、作業効率は格段に向上します。そこで、8004プロトコルが登場します。 なるほど、非常に理にかなっているように見えますね。次に、この論理に基づいて、ERC8004がどのように設計されているのか見てみましょう。プロトコルの具体的な仕組みの解説こちらは具体的な技術仕様の解説です。ただし、詳細なコントラクトのインターフェースやパラメータについては省略し、誰でもわかりやすいように解説します。詳細は標準文書を参照してください。ここでは、プロトコルの内容に基づき、私たちが提示した問題をどのように解決するのかをわかりやすく説明します。技術的に言えば、ERC8004は本質的に三種類のコントラクトインターフェース規格を定義しています。Identity Registry(アイデンティティ登録簿):ERC721(非代替性トークン、通称NFT)をベースにしたエージェント登録用のコントラクトです。各エージェントはNFTとして表現され、このNFTを通じてエージェントの情報を取得できます。Reputation Registry(評判登録簿):エージェントの評価や評判を管理します。Validation Registry(検証登録簿):エージェントの検証や認証を行います。簡単に言えば、これら三つのコントラクトはブロックチェーン上で動作する三つの機関と理解できます。第一の機関:エージェントがアカウントを作成し、いわば飲食店を開くようなものです。第二の機関:これらのエージェントの評価・評判を集約し、管理します。例えるなら、大衆評価やマップ情報のようなものです。第三の機関:検証や認証を行うサードパーティの調査機関です。品質監査局や衛生局のような役割です。🌐 具体的なワークフロー例として、出前のケースを想定します。「小A」があなたの代わりに出前を注文する場面です。協力者の探索:「小A」はまずアイデンティティ登録簿を検索し、評価の高い出前店「小B」を見つけ、その過去の評価を確認します。初期信頼の構築:「小A」は次に評判登録簿をチェックし、他の協力者の「小B」への評価を見て、雇用するか決めます。実行と検証:「小A」やあなたは、さらに検証登録簿の独立した検証者「小C」を雇うこともできます。「小C」は「小B」の報告内容の正確性や要求適合性を検証し、その結果を公開します。決済とフィードバック:あなたはx402プロトコル(オンチェーンとオフチェーンの活動を連結するレシートメカニズムについては以前の記事も参照ください)を通じて、「小A」に報酬を支払います。「小A」は「小B」や「小C」に支払いを行います。最後に、「小A」と「小B」のサービスに対して良い評価を残し、これらの支払いと行動は、それぞれの登録簿内の評判に反映されます。要約すると、ERC-8004は、この3つのコントラクトの相互呼び出しと連携を通じて、AIアシスタント同士が分散型で信頼できる協力環境を構築し、市場のように自由かつ安全にサービスと価値の交換ができる仕組みを提供します。アイデンティティ登録簿このコントラクトは基本的にはNFTコントラクトであり、ERC721の転送などの標準規格を含みます。ただし、NFTのメタ情報ファイルを新たに拡張定義しています。具体的には、エージェントの名前、画像、説明、対応するポートアドレスを提供します。また、登録方法(「register」)や関連イベントも規定しています(ERC721の標準にはミントメソッドの規定はありませんが、この登録メソッドはERC8004の独自メソッドです)。評判登録簿このコントラクトは、デプロイ時にNFTコントラクトをコンストラクタに渡す必要があります。つまり、唯一のアイデンティティ登録簿と関連付けられます。いくつかのメソッドを定義しています:giveFeedback:評価を付与します。NFTのTokenID(agentId)に対して0〜100点で評価可能です。このメソッドの呼び出しには、「feedbackAuth」という署名が必要です。これはエージェントがタスクを受諾したときに署名されたものです。revokeFeedback:評価の取り消し。appendResponse:追加情報を提供可能(フォーマット要件あり)。オフラインの住所と検証用のハッシュ値を渡すことができます。その他、関連する評価情報を取得できる読み取り用のメソッドもあります。追加情報のフォーマット要件は:検証登録簿評判登録簿と同様に、構築時に省庁登録簿のコントラクトアドレスを渡す必要があります。これも唯一のアイデンティティ登録簿と関連付けられます。このコントラクトは、NFTの所有者(owner)が呼び出します。以下のメソッドを提供します:validationRequest:検証を要求します。validationResponse:検証に対する応答を行います。詳細な内容についてはここでは割愛します。基本的に、ERC8004は、三つのコントラクト規格を定義することで、ブロックチェーン上に透明かつ分散型のエージェント評価メカニズムを構築し、エージェントがより良い協力先を見つけやすくし、A2Aに対してWeb3の信頼解決策を提供しています。私たちの実践ERC-8004の設計を踏まえ、PharosとJovayネットワークにおいて、Web3向けのTrustlessサービスを構築しています。これにより、ユーザーはWeb3世界の「信頼できるアイデンティティAgent DID」を配分できるほか、従来の金融レベルのTEE/ZK検証能力も拡張しています。今後は、機械取引向けの金融シナリオにおけるより高い安全性の検証強化もサポート予定です。未来展望外見は素晴らしいものの、多くの課題も伴います。だが、これらの課題はまた新たな機会でもあります。今後の展望について見ていきましょう。 まず、データはブロックチェーン上にあり、透明性と改ざん防止が保証されますが、実際にそのデータが真実で信頼できるのかという問題もあります。そこで、信頼度の高い検証者が重要となります。彼らは背後の権威ある機関を代表します。信頼できる検証者は、ブロックチェーンの履歴データなどを駆使し、より信頼性の高い情報を提供します。例えば、新規アカウントを使って悪意ある低評価をつける行為は信用を失います。 この論理に基づき、プロトコルを取り巻くさまざまな応用が考えられます。あなたは、エージェントの上链化サービスを提供するプラットフォームを構築できます。例えば、あなたのエージェントのためにコントラクトをデプロイし、この規格に基づくさまざまな操作を可能にするサービスを提供します。また、ブロックチェーン上にレストラン街を構築し、エージェントとして登録させることも可能です。例えば、私が唐揚げ専門店(AIロボットの唐揚げ店)を開き、そこにエージェントを登録させる、といった具合です。流量が多ければ登録料を徴収できます。これは、今のENS(イーサリアムドメイン名)と似ています。ENSも一種の登録簿であり、拡張可能です。さらに、ブロックチェーン上にレストラン評価サイト(ミシュラン評価も可能)を作り、他者の評価や採点を行うこともできます。もちろん、少額の報酬を得ることも可能です。要するに、これまでのオフラインで行っていたことをすべてブロックチェーン上に移し、エージェントがブロックチェーンの世界で働く時代が到来します。皆さんはどう思いますか?少なくとも筆者は非常に面白いと感じています。 この記事はZANチーム(Xアカウント @zan_team)のFisher(Xアカウント @yudao1024)によって執筆されました。
Web3 新手系列:ERC8004:この Web3+AI のストーリーは、あなたにホットな出前を味わせることができます
ERC8004 とはイーサリアム上のプロトコル規格であり、一連の標準を定義しています。これにより、エージェントがブロックチェーンを基盤に信頼関係を築くことができ、A2A(Agent to Agent)の物語とWeb3の物語を融合させることが可能になります。この記事では、このWeb3+AIの大きな物語がどのような論理で構成されているのか見ていきましょう。
プロトコルのアドレス 8月に作成され、現在もレビュー段階です。この記事では、このプロトコルが解決しようとしている問題について解説し、わかりやすく標準規格を解釈し、最後にこの規格の意義について展望します。全文所要時間は約15分です。ぜひブックマークしてください。
解決しようとしている問題
まず、このプロトコルが何を解決しようとしているのか見てみましょう。
簡単に言えば、A2A(エージェントがエージェントを呼び出す)過程における信頼の問題の解決です。例えば、私には「小A」というAIアシスタントがおり、これはエージェントです。彼に信頼できる出前を頼みたいとします。しかし、私のエージェントはこの部分が得意ではありません(結局、出前員や店舗と連携するのも大規模な作業であり、小さなAIアシスタントだけでは対応できません)。では、どうすれば良いのでしょうか?
その場合、他のエージェントに協力を依頼できます。
では、私のエージェントがどうやって信頼できる別のエージェントを見つけるのか?信頼機関が必要なのではないか?実は人間も同じです。例えば、淘宝(タオバオ)を通じて取引します。淘宝は中心化された信頼機関です。しかし、中心化された信頼機関には限界があります。エージェント時代では、この問題がより顕著になります。エージェントの効率性を最大限に発揮するためには、すべてを人や中央集権的な機関に頼るのではなく、AIを基盤とした信頼機関、あるいは分散型の信頼機関を活用する必要があります。そうすれば、AIの性能を最大限に引き出せるのです。
したがって、信頼できる分散型のデータを持ち、信頼できるエージェントを見つけることができれば、作業効率は格段に向上します。そこで、8004プロトコルが登場します。
なるほど、非常に理にかなっているように見えますね。次に、この論理に基づいて、ERC8004がどのように設計されているのか見てみましょう。
プロトコルの具体的な仕組みの解説
こちらは具体的な技術仕様の解説です。ただし、詳細なコントラクトのインターフェースやパラメータについては省略し、誰でもわかりやすいように解説します。詳細は標準文書を参照してください。ここでは、プロトコルの内容に基づき、私たちが提示した問題をどのように解決するのかをわかりやすく説明します。
技術的に言えば、ERC8004は本質的に三種類のコントラクトインターフェース規格を定義しています。
Identity Registry(アイデンティティ登録簿):ERC721(非代替性トークン、通称NFT)をベースにしたエージェント登録用のコントラクトです。各エージェントはNFTとして表現され、このNFTを通じてエージェントの情報を取得できます。
Reputation Registry(評判登録簿):エージェントの評価や評判を管理します。
Validation Registry(検証登録簿):エージェントの検証や認証を行います。
簡単に言えば、これら三つのコントラクトはブロックチェーン上で動作する三つの機関と理解できます。
第一の機関:エージェントがアカウントを作成し、いわば飲食店を開くようなものです。
第二の機関:これらのエージェントの評価・評判を集約し、管理します。例えるなら、大衆評価やマップ情報のようなものです。
第三の機関:検証や認証を行うサードパーティの調査機関です。品質監査局や衛生局のような役割です。
🌐 具体的なワークフロー
例として、出前のケースを想定します。「小A」があなたの代わりに出前を注文する場面です。
協力者の探索:「小A」はまずアイデンティティ登録簿を検索し、評価の高い出前店「小B」を見つけ、その過去の評価を確認します。
初期信頼の構築:「小A」は次に評判登録簿をチェックし、他の協力者の「小B」への評価を見て、雇用するか決めます。
実行と検証:「小A」やあなたは、さらに検証登録簿の独立した検証者「小C」を雇うこともできます。「小C」は「小B」の報告内容の正確性や要求適合性を検証し、その結果を公開します。
決済とフィードバック:あなたはx402プロトコル(オンチェーンとオフチェーンの活動を連結するレシートメカニズムについては以前の記事も参照ください)を通じて、「小A」に報酬を支払います。「小A」は「小B」や「小C」に支払いを行います。最後に、「小A」と「小B」のサービスに対して良い評価を残し、これらの支払いと行動は、それぞれの登録簿内の評判に反映されます。
要約すると、ERC-8004は、この3つのコントラクトの相互呼び出しと連携を通じて、AIアシスタント同士が分散型で信頼できる協力環境を構築し、市場のように自由かつ安全にサービスと価値の交換ができる仕組みを提供します。
アイデンティティ登録簿
このコントラクトは基本的にはNFTコントラクトであり、ERC721の転送などの標準規格を含みます。ただし、NFTのメタ情報ファイルを新たに拡張定義しています。
具体的には、エージェントの名前、画像、説明、対応するポートアドレスを提供します。
また、登録方法(「register」)や関連イベントも規定しています(ERC721の標準にはミントメソッドの規定はありませんが、この登録メソッドはERC8004の独自メソッドです)。
評判登録簿
このコントラクトは、デプロイ時にNFTコントラクトをコンストラクタに渡す必要があります。つまり、唯一のアイデンティティ登録簿と関連付けられます。
いくつかのメソッドを定義しています:
giveFeedback:評価を付与します。NFTのTokenID(agentId)に対して0〜100点で評価可能です。このメソッドの呼び出しには、「feedbackAuth」という署名が必要です。これはエージェントがタスクを受諾したときに署名されたものです。
revokeFeedback:評価の取り消し。
appendResponse:追加情報を提供可能(フォーマット要件あり)。オフラインの住所と検証用のハッシュ値を渡すことができます。
その他、関連する評価情報を取得できる読み取り用のメソッドもあります。
追加情報のフォーマット要件は:
検証登録簿
評判登録簿と同様に、構築時に省庁登録簿のコントラクトアドレスを渡す必要があります。これも唯一のアイデンティティ登録簿と関連付けられます。このコントラクトは、NFTの所有者(owner)が呼び出します。以下のメソッドを提供します:
validationRequest:検証を要求します。
validationResponse:検証に対する応答を行います。
詳細な内容についてはここでは割愛します。基本的に、ERC8004は、三つのコントラクト規格を定義することで、ブロックチェーン上に透明かつ分散型のエージェント評価メカニズムを構築し、エージェントがより良い協力先を見つけやすくし、A2Aに対してWeb3の信頼解決策を提供しています。
私たちの実践
ERC-8004の設計を踏まえ、PharosとJovayネットワークにおいて、Web3向けのTrustlessサービスを構築しています。これにより、ユーザーはWeb3世界の「信頼できるアイデンティティAgent DID」を配分できるほか、従来の金融レベルのTEE/ZK検証能力も拡張しています。今後は、機械取引向けの金融シナリオにおけるより高い安全性の検証強化もサポート予定です。
未来展望
外見は素晴らしいものの、多くの課題も伴います。だが、これらの課題はまた新たな機会でもあります。今後の展望について見ていきましょう。
まず、データはブロックチェーン上にあり、透明性と改ざん防止が保証されますが、実際にそのデータが真実で信頼できるのかという問題もあります。そこで、信頼度の高い検証者が重要となります。彼らは背後の権威ある機関を代表します。信頼できる検証者は、ブロックチェーンの履歴データなどを駆使し、より信頼性の高い情報を提供します。例えば、新規アカウントを使って悪意ある低評価をつける行為は信用を失います。
この論理に基づき、プロトコルを取り巻くさまざまな応用が考えられます。
あなたは、エージェントの上链化サービスを提供するプラットフォームを構築できます。例えば、あなたのエージェントのためにコントラクトをデプロイし、この規格に基づくさまざまな操作を可能にするサービスを提供します。
また、ブロックチェーン上にレストラン街を構築し、エージェントとして登録させることも可能です。例えば、私が唐揚げ専門店(AIロボットの唐揚げ店)を開き、そこにエージェントを登録させる、といった具合です。流量が多ければ登録料を徴収できます。これは、今のENS(イーサリアムドメイン名)と似ています。ENSも一種の登録簿であり、拡張可能です。
さらに、ブロックチェーン上にレストラン評価サイト(ミシュラン評価も可能)を作り、他者の評価や採点を行うこともできます。もちろん、少額の報酬を得ることも可能です。
要するに、これまでのオフラインで行っていたことをすべてブロックチェーン上に移し、エージェントがブロックチェーンの世界で働く時代が到来します。
皆さんはどう思いますか?少なくとも筆者は非常に面白いと感じています。
この記事はZANチーム(Xアカウント @zan_team)のFisher(Xアカウント @yudao1024)によって執筆されました。