Ethereum フォーラム 日本語アーカイブ

トピックで絞り込む

すべてのタグ (61) →

トラストレスエージェントプラス (TAP): 分断されたERC8004エージェントの拠点

20 min read

原文

Trustless Agents Plus (TAP) : Home for fragmented ERC8004 Agents — zaryab2000 (2026-05-17)

ERC-8004は、オンチェーンエージェントにとって3つの必須事項を解決しました。

  • アイデンティティを証明する信頼できる方法
  • フィードバックから**レピュテーション（評判）**を蓄積するシステム
  • オンチェーン作業の暗号学的検証のための標準

しかし、複数のチェーンにまたがる分断されたオンチェーンエージェントの解決策はまだ残されています。

現在、23以上のチェーンに約20万のエージェントが登録されており、約19万4千件のレピュテーションフィードバックが個々のチェーンレジストリにロックされています。この規模がギャップを浮き彫りにしています。

私は自分のオンチェーンエージェントを3つの異なるチェーンにデプロイしています。そのアイデンティティは分断されています — 3つの異なるトークンID、3つの異なるレピュテーションスコア、それらが同じエンティティに属するというオンチェーンでの証明はゼロです。このようなケースはすでに多くのチェーンに存在します。

この投稿では、分断の問題を説明し、マルチチェーンWeb3の世界におけるオンチェーンエージェントの解決策を提示します。

ERC-8004が今日止まっている場所

現在の仕様では、エージェントが複数のチェーンで運用する場合に構造的なギャップが残されています。

マルチチェーン規模では、2つの制限が明らかになります。

1. アイデンティティの分断

各チェーンのIdentityRegistryは、個別にチェーンにデプロイされるスタンドアロンのERC-721です。

5つの異なるチェーンにデプロイされたオンチェーンエージェントは、今日、完全に分断されたアイデンティティを持っています。Base上のコントラクトが、エージェント#2065がBSC上のエージェント#5249と同じエンティティであるかどうかを確認したい場合、オンチェーンでそれを行う経路はありません。

5つのチェーン上のエージェントは、5つの無関係なトークンIDを保持します。現在の仕様における唯一のクロスチェーンフックは、エージェント登録ファイル内のオフチェーンのregistrations[]配列です — これはエージェントオペレーターによって自己主張されるものであり、いかなるコントラクトやコンシューマーによってもオンチェーンで検証可能ではありません。

2. レピュテーションのサイロ化

同様に、5つのチェーン上のエージェントは5つの異なるレピュテーションスコアを蓄積します。マルチチェーンのフィードバックから累積スコアを導き出す方法はありません。

現在、約19万4千件のレピュテーションフィードバックは、その発生元のチェーンにロックされています。Ethereumで強力な実績を持ち、Arbitrumでクリーンな記録を持つエージェントは、新しいコンシューマーがBaseでそのエージェントに遭遇しても、どちらの功績もゼロです。

各チェーンのReputationRegistryは閉じたループです — 集約面はなく、コントラクトが「このエージェントが運用するすべてのチェーンでのレピュテーションは何か？」とクエリする方法もありません。

エージェントがすでに23以上のチェーンで運用されていることを考えると、理想的な解決策は次の3つを提供することです。

  1. エージェントが運用するすべてのチェーンにわたる単一の正規アイデンティティ。
  2. すべてのチェーンでのパフォーマンスを反映する集約されたレピュテーションスコア。
  3. エージェントの統一されたアイデンティティとレピュテーションに対する同期的なクロスチェーン読み取り — チェーンごとのサイロ化された情報ではありません。

ERC8004は「トラストレスエージェント」の標準を提供しました。

私はトラストレスエージェントプラス (TAP) を提案します。

トラストレスエージェントプラス (TAP)

TAP — トラストレスエージェントプラス — は、ERC-8004エージェントが運用するすべてのチェーンにわたって、1つの正規アイデンティティと1つの集約されたレピュテーションスコアを提供します。

チェーンごとのレジストリは現状維持されます。ローカル登録、エージェントカード、およびチェーンごとのフィードバックは変更されません。

TAPスマートコントラクト

TAPは現在、Push Chain上の2つの主要なスマートコントラクトのシステムです。

  • TAPRegistry
  • TAPReputationRegistry

  1. **TAPRegistry**は正規アイデンティティ層です。

    エージェントは、任意のエージェントウォレットから任意のチェーンで一度登録します。登録はPush Chainで行われますが、エージェントは選択した任意のチェーンから登録し、ガス代を支払います。

    agentIdは決定論的です — UEAアドレス（エージェントのPush Chain上のスマートアカウント）から直接導出されます (uint256(uint160(ueaAddress)) % 10_000_000)。トークンはソウルバウンド（譲渡不可）です。チェーンごとのERC-8004アイデンティティはbind()を介してリンクされます。これは、エージェントの記録されたオーナーキーに対してEIP-712型付きデータ署名を検証します。ECDSAとERC-1271の両方がサポートされているため、マルチシグとAAウォレットは回避策なしでバインドできます。

  2. **TAPReputationRegistry**はクロスチェーンレピュテーションアグリゲーターです。

    認可されたレポーターは、チェーンごとのレピュテーションスナップショットを提出します。すべての提出はTAPRegistryのバインディングに対して検証されます — レポーターは、エージェントがバインドしたことのないチェーンのレピュテーションを注入することはできません。コントラクトは小数点以下の精度を正規化し、品質、ボリューム、チェーンの多様性、および永続的なスラッシュペナルティを組み合わせて、[0, 10,000] bpsの単一スコアを導き出します。

    集約されたスコアとチェーンごとの内訳の両方が公開されます — コンシューマーは粒度を選択できます。

チェーンごとのERC-8004レジストリ            決済チェーン ( Push Chain )
+------------------+                    +---------------------------+
| Ethereum         | --バインド (EIP-712)-> |        TAPRegistry        |
| boundAgentId=17  |                    |   canonicalId=4_928_371   |
+------------------+                    |   ソウルバウンド、UEAアンカー |
| Base             | --バインド (EIP-712)-> |                           |
| boundAgentId=42  |                    +---------------------------+
+------------------+                    |   TAPReputationRegistry   |
| Arbitrum         | --バインド (EIP-712)-> |   スコア: 7,578 bps       |
| boundAgentId=8   |                    |   3チェーン、1,000フィードバック |
+------------------+                    +---------------------------+
       ^                                              ^
       |                                              |
  ローカルフィードバック                      REPORTER_ROLEスナップショット
  (変更なし)                               + バインディング検証済み

TAPの新しい機能

TAPは、既存の8004標準を改善し、既存のエージェントとシームレスに連携するように設計されています。

その独自の方法は次のとおりです。

1. ソウルバウンドアイデンティティトークン

ERC-8004は譲渡可能なERC-721トークンを発行します。TAPは転送インターフェース全体を上書きし、無条件にリバートさせます。agentId ↔ UEAマッピングは登録後に不変です — レピュテーションを獲得したアイデンティティは、それを獲得していない後継者に売却することはできません。

2. マルチチェーンレピュテーションスコア

ERC-8004は、複合スコアなしでチェーンごとの生の加重平均を保存します。TAPは、多要素式を使用して単一の正規化されたスコアを計算します。

finalScore = (baseScore × volumeMultiplier / 10000) + diversityBonus − slashPenalty
  • ベーススコア (0–7,000): 品質単独では70%が上限です。baseScore = weightedAvgValue × 7000 / (100 × 1e18)。
  • ボリューム乗数 (0.5x–1.0x): 5000 + (log2(totalFeedbackCount) × 500)、上限は10,000です。1つのフィードバックを持つエージェントは半分になり、1,024以上のフィードバックを持つエージェントは完全な乗数を得ます。これは薄い実績をペナルティの対象とします — 2つのフィードバックからの完璧な評価は、数千のフィードバックからの良い評価よりも低いスコアになります。

3. 多様性ボーナス

複数のチェーンで運用するエージェントにはインセンティブがあります — 多様性ボーナスです。

複数のチェーンで運用するエージェントは、レピュテーションデータを持つチェーンごとに500 bpsのボーナスを受け取ります。上限は2,000 bps（4つ以上のチェーン）です。これは真のクロスチェーン参加を奨励し、エージェントが単一の低活動チェーンで高いスコアを稼ぐことをより困難にします。

4. 永続的なペナルティを伴うクロスチェーンスラッシング

ERC-8004にはスラッシングメカニズムがありません。TAPは、累積的な重大度減額（イベントごとに1〜10,000 bps、エージェントごとに最大256レコード）を伴うSLASHER_ROLEを導入します。スラッシュ記録は、関連するバインディングが削除されても永続します。チェーンAでスラッシュされたエージェントは、Aのバインディングを解除して新しくバインドし直すことで減額を回避することはできません — 負のレピュテーションはアイデンティティに紐付けられ、個々のバインディングには紐付けられません。正のレピュテーションはアクティブなリンクに紐付けられます。

5. グローバルバインディングの重複排除

バインドされたアイデンティティタプル(chainNamespace, chainId, registryAddress, boundAgentId)は、一度に1つの正規UEA（Push上のエージェントのスマートアカウント）にのみリンクできます。エージェントAがEthereumのレジストリでエージェントID 42にバインドした場合、エージェントBは同じバインディングを主張することはできません — トランザクションはBindingAlreadyClaimedでリバートします。これにより、2つの正規エージェントが同じチェーンごとのエンティティであると主張するなりすましを防ぎます。

さらに、ERC-8004にはクロスチェーンアイデンティティバインディングの概念がありません。TAPはbind()を導入します。ここでは、UEAのオーナーがEIP-712型付きデータメッセージに署名し、別のチェーンのERC-8004レジストリで同じキーを制御していることを証明します。

8004エージェント vs 8004 TAPエージェント

ERC-8004エージェントとERC-8004 TAPエージェントの比較

設計上の決定とトレードオフ

1. 譲渡可能よりもソウルバウンド

ERC-8004は譲渡可能なERC-721トークンを発行します。

TAPはソウルバウンドトークンを選択しました。なぜなら、アイデンティティの転送は信頼の不連続性を生み出すからです — エージェント#42が2年間で8,000 bpsのレピュテーションを獲得し、そのアイデンティティを売却した場合、新しいオーナーは稼いでいない信頼を継承します。 さらに：

  1. コスト：セカンダリマーケットと転送による明示的な委任はなくなります。
  2. 軽減策：エージェントカードは、アイデンティティ自体に触れることなく、委任されたオペレーターをエンコードできます。

2. 他の相互運用層よりもPush Chainを選択

代替案は、既存のL1にTAPをデプロイし、LayerZero、CCIP、またはHyperlaneを介してバインディングイベントをリレーすることでした。私はPush Chainを選択しました。そのインフラストラクチャがエージェントビルダーにとってクロスチェーンの摩擦を排除するからです。

  • UEAはエージェントのアイデンティティをエンドツーエンドで保持します: UEAは、Push Chain上の外部チェーンエージェントを表すプロキシスマートアカウントです。ほとんどのクロスチェーンアーキテクチャでは、ゲートウェイコントラクトがユーザーに代わって呼び出しを行います — msg.senderはゲートウェイであり、ユーザーではないため、アイデンティティが失われます。UEAを使用すると、ユーザー自身の口座が呼び出しを行います。TAPはUEAアドレスからagentIdを決定論的に導出し、正規アイデンティティをエージェントオペレーターの実際のクロスチェーンアイデンティティに固定し、仲介者ではありません。
  • 手数料とウォレットの抽象化: エージェントオペレーターは、既存のウォレット（MetaMask、Phantom）を介してネイティブトークン（ETH、SOL）を使用します。Push Chainはソースチェーンの署名を検出し、それをUEAにマッピングし、トランザクションをルーティングします。ブリッジングなし、新しいウォレットなし、ガス代トークンの取得なし。（ドキュメント）
  • ソースチェーンからの呼び出し: ユニバーサルゲートウェイにより、EthereumまたはBase上のエージェントはネットワークを切り替えることなくTAPコントラクトを呼び出すことができます。

最終的な効果：エージェントビルダーは、既存のウォレットを使用し、ネイティブトークンでガス代を支払い、アイデンティティをエンドツーエンドで保持したまま、登録、バインド、レピュテーションのクエリを行うことができます。

トレードオフ：Push Chainは現在、ETH、Arbitrum、BNB、Base、Solanaのみをサポートしています。

3. クエリごとの読み取りよりも決済チェーンでの集約

TAPは決済チェーンでレピュテーションを一度集約し、他のすべての場所で同期的なオンチェーン読み取りを公開します。

トレードオフ：集約されたレピュテーションは最終的に一貫性があり、レポーターの更新頻度に依存します。

利点：Push Chain上の任意のコントラクトは、追加コストなしで集約されたスコアを同期的に読み取ります。古さはlastUpdated(agentId)とisFresh(agentId, maxAge)を介して明示的に公開されるため、呼び出し元は独自の鮮度しきい値を設定できます。

これは、@spengrahがスレッドで提起した非同期の信頼最小化オラクルにもどこかでつながります — TAPは設計空間の異なる点から同じ問題に対処します。

4. チェーンごとの粒度を持つ集約スコア

単一の集約レピュテーションスコアは、大雑把な手段です。

TAPは集約スコア（getReputationScore(agentId)が0〜10,000 bpsを返す）を計算しますが、getChainReputation()とgetAllChainReputations()を介して完全なチェーンごとの内訳も公開します — 生のフィードバック数、ポジティブ/ネガティブの分割、最終更新タイムスタンプなどです。

単一のゲートとしてスコアを使用したいコンシューマーはスコアを使用します。コンテキスト固有の信頼を求めるコンシューマーは基礎となるデータを利用できます。スコアリング式は完全にオンチェーンであり、監査可能です。

@daniel-ospinaがスレッドで懸念した単一の集約スコアが独占的な行動を助長するという点は、まさにチェーンごとの内訳が存在する理由です。

TAPをここで探索する

デプロイされたTAPコントラクト

コントラクトプロキシアドレスエクスプローラー
TAPRegistry0xa2B09263a7a41567D5F53b7d9F7CA1c6cc046CE2エクスプローラーで表示
TAPReputationRegistry0x591A56D98A14e8A88722F794981F00CabB328a91エクスプローラーで表示

TAPの今後の方向性

  1. クロスチェーンレピュテーション読み取り

    サポートされている任意のチェーン上の任意のコントラクトは、TAPScoreOracle.getScore(agentId)のようなものを呼び出し、集約されたレピュテーションを取得できます。任意のチェーン上のコントラクトは、TAPスコアしきい値に基づいて関数呼び出しをゲートします。例：DeFiボールトは、スコアが7,000 bps以上のエージェントからの戦略のみを受け入れます。

    これにより、TAPは受動的なレジストリから能動的なパーミッション層へと変化します — プロトコルが構成する「エージェントの信用スコア」となります。実装：クロスチェーン呼び出しまたはキャッシュされたオラクルを介してスコアを読み取る軽量のTAPGateモディファイアコントラクト。

  2. エージェント間の信頼グラフ（委任と構成）

    他のエージェントを保証または委任するエージェントは、TAPアイデンティティの上に有向信頼グラフを作成します。例：「ポートフォリオマネージャー」エージェントは、実行を専門の「スワップ」および「ブリッジ」エージェントに委任し、その行動に自身のレピュテーションを賭けます。委任されたエージェントがスラッシュされた場合、委任者は比例したペナルティを受けます。

    これにより、インセンティブが一致した構成可能なエージェント階層が可能になります。

  3. 非EVMチェーンのバインディング（Solana、Cosmos、Move）

    BindProofTypeをECDSA/ERC-1271を超えて拡張し、Ed25519（Solana）、異なるアドレス導出を持つSecp256k1（Cosmos）、およびMoveネイティブ署名をサポートします。

    ストレージはすでにネームスペースに依存しない（CAIP-2文字列）ため、ギャップは純粋に署名検証にあります。これにより、TAPは真にユニバーサルなエージェントレジストリとなります — マルチEVMだけでなく、マルチエコシステムにも対応します。

未解決の質問:

  1. レピュテーションはソースチェーンで同期的に消費可能であるべきか？ TAPはPush Chainで集約しますが、Base上のDeFiプロトコルがエージェントアクセスをゲートする場合、Push Chainではなくそこにスコアが必要です。プルベースのクロスチェーン読み取り（ユニバーサルゲートウェイ経由）とプッシュベースのスコアキャッシュ（リレーヤーが更新するチェーンごとのコントラクト）は、信頼性/レイテンシ/コストの異なるトレードオフを表します。検討に値する第3のモデルはあるか？
  2. バインディング証明はソースチェーンでも検証可能であるべきか？ソースチェーンごとの小さな検証コントラクトがあれば、Base上のERC-8004フックがクロスチェーン読み取りなしで、特定のboundAgentIdが正規アイデンティティを持っていることを確認できます — 追加のデプロイと、同期を維持するための2番目の検証インターフェースというコストを伴うが？
  3. 非EVMバインディング証明に関して：理想的には、これを非EVMチェーンにも拡張したいと考えています。ストレージはネームスペースに依存しない（CAIP-2文字列）が、署名検証は現在EVMのみ（ECDSA + ERC-1271）です。BindProofTypeをEd25519（Solana）またはMove署名に拡張することは、スキームごとに単純ですが、プリコンパイルの表面積を拡大します。スキームを1つずつ追加するのではなく、汎用的なマルチスキーム署名検証標準として連携する価値のあるより良い代替案はあるか？

1投稿 - 1参加者

トピック全体を読む

グラフビュー