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

トピックで絞り込む

すべてのタグ (61) →

トラストレスエージェントのための匿名認証情報 (ACTA) - オンチェーンエージェントエコノミーのためのプライバシーレイヤー

35 min read

原文

Anonymous Credentials for Trustless Agents (ACTA) — zulu0echo (2026-05-05)

トラストレスエージェントのための匿名認証情報 (ACTA) - オンチェーンエージェントエコノミーのためのプライバシーレイヤー

フィードバックとレビューをいただいた Davide、Nam、Marco、Thore、Vivian に深く感謝いたします。

2026年5月

TL;DR

  • ERC-8004（トラストレスエージェント）は、AIエージェントとそのクライアント間の永続的で公開されたインタラクショングラフを生成します。すべての評判シグナル、すべての認証情報 (credential) チェック、すべての委任が不変にオンチェーンに記録されます。

  • ERC-8004は透明性が必要なエージェントのデプロイメント (deployment) には有用ですが、「インタラクショングラフ自体が機密データである」ケースでは、プライバシー保護ソリューションが不可欠となるでしょう。

  • ACTAは、匿名認証情報 (Anonymous Credentials) を使用してERC-8004の上に構成可能なプライバシーレイヤーを提案します。これにより、エージェントは基盤となるデータを明らかにすることなく、人物証明、監査スコア、モデルの出所、評判、管轄区域などの主張を証明できます。

  • ACTAは「プリンシパル (principal)」レイヤーにも対処します。エージェントは、パーソンフッド認証情報 (personhood credentials)（Adler et al., 2024）を使用して、検証済みの人間プリンシパルの下で行動していることを証明できます。これにより、ガバナンス (governance) およびDeFiプロトコルは、参加者の実世界の身元を公開することなく、完全に自律的なボットを排除できます。

  • ICircuitVerifier 抽象化は、ACTAを特定の証明システムから意図的に分離します。SNARKs、STARKs、zkVMs、および将来の耐量子 (post-quantum) 構成はすべて、ファーストクラスのバックエンド (backend) であり、ACTAコントラクトを変更することなくポリシーごとに交換可能です。

  • 本稿では、ドラフトを紹介し、今日デプロイ可能な7つの具体的なオンチェーンユースケースを説明し、エコシステム、ビルダー (builder)、DeFiプロトコル開発者、およびERC-8004の著者からの協力を募ります。

はじめに

専門的なAIエージェントを介して実行をルーティングするDeFiプロトコルを考えてみましょう。例えば、流動性ルーティングエージェント、リスク評価エージェント、清算エージェントです。それぞれがERC-8004を介してオンチェーンに登録され、取引が決済されるにつれて検証可能なフィードバックを通じて評判を構築します。ルーティングエージェントは1日に50回リスクエージェントを呼び出します。清算エージェントはブロックごとに品質スコアを受け取ります。これらのインタラクションはすべて、呼び出し元のアドレス、エージェントの識別子、フィードバックスコア、タスクエンドポイントタグを含め、永続的かつ不変に公開されます。イベントインデクサー (event indexer) を実行している人なら誰でも、どのプロトコルがどの実行レイヤーをどのくらいの頻度で、どのような品質の結果で、どのエージェントベンダーが市場を勝ち取っているかを正確に再構築できます。実行戦略が優位性であるプロトコルにとって、そのインタラクショングラフこそがアルファ（優位性）です。それをデフォルトでグローバルな公開台帳に公開することは、プライバシー上の懸念だけでなく、即座の経済的攻撃対象となります。

これはDeFiに限定されません。「参加者がAIエージェントを介して解決クエリをルーティングするオンチェーンインタラクションは、そのワークフローを公開します。」オンチェーンエージェントの信頼を「価値あるもの」にする説明責任の特性、すなわち検証可能な評判、監査可能な認証情報 (credential) の主張、構成可能なフィードバックは、現在のERC-8004設計を多くの実際のオンチェーンユースケースにとって不完全にしている特性でもあります。

ゼロ知識証明 (Zero-knowledge proofs) を使用することで、エージェントはスコアの閾値を満たしていること、承認されたモデルハッシュを保持していること、制裁リストの対象外であることをプライベートに証明できます。匿名認証情報スキーム (Anonymous credential schemes) は、評判フィードバックを提出者のアドレスにリンクさせることなく提出することを可能にします。ナリファイア (Nullifier) メカニズムは、身元を明かすことなく二重使用を防ぎます。ACTAは、これらすべてをオンチェーンエージェントエコノミーにもたらす、ERC-8004を修正することなくその上に位置する構成可能なプライバシーレイヤーです。

背景

ERC-8004はインフラのギャップに対処します。すなわち、エージェントとクライアントが既存の関係なしに組織の境界を越えて信頼を確立する方法です。これは3つのオンチェーンレジストリを提案しています。

  1. IDレジストリ (Identity Registry) は、すべてのエージェントにポータブルなERC-721ベースの識別子を提供します。

  2. 評判レジストリ (Reputation Registry) は、フィードバックシグナルを投稿および読み取るための標準インターフェースを提供し、あらゆるスコアリングシステムと構成可能です。

  3. 検証レジストリ (Validation Registry) は、エージェントが出力に対する独立した検証を要求および記録することを可能にします。

オープンで相互運用可能な信頼レイヤーを必要とするエージェントエコノミーにとって、これは適切な基盤です。ACTAはその基盤の拡張です。

プライバシーのギャップ

ERC-8004の現在の設計は、インタラクショングラフが個人的、経済的、または規制上の機密性を持つデプロイメントにおいて、5つの具体的で悪用可能な脆弱性を生み出します。

  1. 永続的な公開インタラクショングラフ。 NewFeedback イベントは、clientAddress、agentId、value、およびタスクタグをプレーンテキストで、不変にオンチェーンに発行します。「攻撃シナリオ」: 競合するDeFiプロトコルはこれらのイベントをインデックス化し、ライバルがどの実行エージェントを、どのくらいの頻度で、どのような品質評価で使用しているかを特定し、リアルタイムでAI実行戦略を再構築します。

  2. セッション間の非リンク性がない。 readAllFeedback() 関数は、特定のクライアントアドレスとエージェントに対するすべてのインタラクションを列挙します。同じクライアントによる複数のインタラクションは簡単にリンク可能であり、取引パターンや分析ワークフローに関する統計的推論を可能にします。

  3. 認証情報の選択的開示がない。 エージェントの agentURI 登録ファイルは、すべての機能、エンドポイント、DID、ENS名、およびウォレットアドレスを同時に公開します。「このエージェントは私の管轄区域で準拠していますか？」と尋ねるカウンターパーティは、商業的に機密性の高い可能性のある詳細を含む、エージェントの完全な運用プロファイルを受け取ります。

  4. シビル耐性 (Sybil resistance) にはレビューアの識別が必要。 ERC-8004は、フィルタリングされていない結果がシビル攻撃 (Sybil attack) のスパムに対して脆弱であるため、getSummary() が空でない clientAddresses[] フィルターを必要とすることを認めています。意図された緩和策は、レビューアがオンチェーンで識別可能であることを要求します。

  5. クロスレジストリでのフィンガープリンティング。 agentId（ERC-721トークン）、agentWallet（オンチェーンで明示的にリンク）、および登録ファイル内のオプションの DID フィールドの組み合わせは、分離されたIDコンテキストを単一の追跡可能なプロファイルに、オンチェーンおよびオフチェーンシステム全体で統合する独自の3次元フィンガープリントを作成します。

コアアイデア: トラストレスエージェントのための匿名認証情報

現実世界での匿名認証情報 (anonymous credentials) では、「この人物の生年月日が、政府発行者によって証明され、述語 age ≥ 18 を満たす」という暗号学的証明 (cryptographic proof) を提示できます。

これをオンチェーンAIエージェントに拡大してみましょう。例: DeFiプロトコルのリスク管理コントラクトは、委任しようとしている実行エージェントが十分な監査スコア、承認されたモデルバージョンを持ち、オペレーターがOFACリストに載っていないことを検証する必要があります。匿名認証情報を使用すると:

  1. エージェントは、その認証情報が3つの述語すべてを同時に満たすという証明を生成します。

  2. プロトコルはオンチェーンで証明を検証します。

  3. 1つのイベントが発行されます: 非リンク可能なナリファイア (nullifier) と満たされたポリシーID。

エージェントの実際の監査スコア、モデルハッシュ、および管轄区域はどこにも公開されません。

ACTA: 可能なコンポーネント

認証情報アンカリング (IOpenACCredentialAnchor)。 エージェントが匿名提示証明 (anonymous presentation proofs) を行う前に、その認証情報への暗号学的コミットメント (cryptographic commitment) をオンチェーンに登録します。これは、エージェントのマスターシークレットと認証情報属性を組み合わせたブラインドハッシュ (blinded hash) です。これにより、属性値を明らかにすることなく、認証情報が存在し、有効に発行されたことを証明します。アンカーコントラクトは、正しいコミットメント形成のゼロ知識証明 (zero-knowledge proof) を検証し（オペレーターが選択した ICircuitVerifier を使用）、コミットメントハッシュ、発行者キーコミットメント、認証情報スキーマ識別子、および有効期限タイムスタンプのみを保存します。認証情報の詳細はオンチェーンには表示されません。これは、すべてのダウンストリーム (downstream) の証明フローが依存する前提条件です。

ポリシーレジストリ (IPolicyRegistry)。 検証者（DeFiプロトコル、DAO、オンチェーンコンプライアンスオラクルなど）は、ポリシーをブール述語プログラム (boolean predicate program) として登録します。例: audit_score >= 80 AND operator_jurisdiction_not_in(OFAC_LIST)。ポリシーはハッシュとしてオンチェーンに存在します。PolicyDescriptor には、述語プログラムハッシュ、認証情報スキーマ、発行者コミットメント、有効期間、そして決定的に重要なことに、証明検証に使用する ICircuitVerifier 実装のアドレスが含まれます。ポリシーは一度登録されると不変です。

述語検証 (IPredicateVerifier)。 エージェントが登録されたポリシーを満たす認証情報の証明を提示すると、このコントラクトが呼び出しごとの検証を処理します。IPolicyRegistry から読み取り、検証を登録された ICircuitVerifier に委任し、結果のナリファイアを登録し、ポリシーID、ナリファイア、および有効期限タイムスタンプのみを含む PresentationAccepted イベントを発行します。エージェントのID、属性値、ウォレットアドレスは一切公開されません。

ナリファイアレジストリ (INullifierRegistry)。 ナリファイアはコンテキストスコープです。それぞれは、エージェントのマスターシークレットと、検証者のアドレスおよびセッションノンス (session nonce) を含むコンテキストハッシュを組み合わせて導出されます。同じエージェントの検証者Aに対するナリファイアは、検証者Bに対するナリファイアとは計算上無関係です。単一のセッションコンテキスト内では、二重使用が検出されて拒否され、グローバルな身元開示なしにセッションごとのシビル耐性を提供します。

ZK評判アキュムレータ (IZKReputationAccumulator)。 クライアントは、有効なインタラクション認証情報を保持しており、このコンテキストでまだフィードバックを提出していないことを示すゼロ知識証明として評判フィードバックを提出します。フィードバック値はブラインド化されたマークルツリーの葉 (blinded Merkle tree leaves) として保存されます。これにより、ナリファイア、値にコミットしつつ、イベントログから値を隠します。

アキュムレータは、そのマークルルート (Merkle root) をERC-8004の既存の評判レジストリに、予約されたタグを持つ標準の giveFeedback() インターフェースを使用して書き戻し、ERC-8004対応の評判アグリゲーター (aggregator) との構成可能性を維持します。エージェントは後で、個々のフィードバックエントリを明らかにすることなく、その集計された匿名スコアが閾値を超えていることを証明できます。

例: プロトコルフロー

  1. アクター作成: 発行者、エージェント、検証者がそれぞれEthereumアドレスにアンカーされた did:ethr IDを取得します。

  2. スキーマ設定: 発行者は AgentCapabilityCredential が auditScore、operatorJurisdiction、capabilities などのフィールドをどのように含むかを定義します。

  3. 認証情報発行: 発行者はエージェントウォレットに署名付きJWT-VCを発行し、認証情報はオフチェーンに留まります。

  4. オンチェーンアンカー: エージェントは自身の認証情報に対するコミットメントとマークルルートを計算し、それらを OpenACCredentialAnchor に書き込み、証明に使用する ICircuitVerifier 実装を指定します。

  5. 述語構築: 検証者はコンプライアンスルールを構造化された述語（例: auditScore ≥ 80 AND caps ⊇ 'evm-execution'）として定義し、OpenACの generalized-predicates パッケージ [GP-PACKAGE-API: 実際のコンパイラ呼び出しに置き換え] を使用してコンパイルし、決定論的な predicateProgramHash [GP-PACKAGE-API: 実際のハッシュ計算メソッドに置き換え] を導出します。

  6. ポリシー登録: 検証者はオンチェーンで IPolicyRegistry.registerPolicy() を呼び出し、述語ハッシュ、信頼された発行者コミットメント、および選択された ICircuitVerifier のアドレスを policyId の下にロックします。

  7. 提示リクエスト: 検証者はエージェントに policyId、新しい sessionNonce、およびそのアドレスを送信し、証明をこのインタラクションのみにスコープします。

  8. 証明生成: エージェントのOpenACウォレットは generalized-predicates パッケージ [GP-PACKAGE-API] を介して述語をコンパイルし、クライアント側でZK証明を生成します。公開出力は nullifier、contextHash、predicateHash ですが、認証情報の値は含まれません。

  9. 検証済み: 検証者は証明を IPredicateVerifier.verifyPresentation() に提出します。コントラクトは完全に登録された ICircuitVerifier に委任し、ナリファイアを登録し、PresentationAccepted(policyId, nullifier, expiryTimestamp) イベントを発行します。

  10. アクセス許可: エージェントは自身のナリファイアを AgentAccessGate に提示します。初回使用時には許可され、リプレイ時には NullifierAlreadyActive でリバートされます。

*失効 (Revocation) は本稿の範囲外とします。PSEは失効設計戦略に関する広範な研究を行っており、こちらで参照できます。

ユースケース: オンチェーンアプリケーション

DeFiプロトコルにおけるエージェント委任

DeFiプロトコルが専門的なAIエージェントを介して実行をルーティングすることが増えるにつれて、プロトコルのスマートコントラクトがそれらのエージェントをどのように信頼すべきかという問題が喫緊の課題となっています。ERC-8004の下では、プロトコルが行うすべての委任チェックとすべての品質評価は永続的に公開されます。ACTAの下では、プロトコルは IPolicyRegistry に機能ポリシーを登録し、エージェントは IPredicateVerifier を介してそれに対する匿名述語証明 (anonymous predicate proof) を提示します。プロトコルはポリシーを登録する際にZKバックエンドを選択します。verifyPresentation を呼び出すプロトコルコントラクトは、どのバックエンドが選択されたかに関係なく、同じ policyId を読み取り、同じ PresentationAccepted イベントを受け取ります。

検閲耐性のあるエージェント評判

予測市場 (prediction markets)、レンディングプロトコル (lending protocols)、およびエージェントの品質シグナルに依存するあらゆるシステムは、同じ問題に直面します。ERC-8004の下では、意味のある評判は識別されたレビューアによってのみ提出できます。getSummary() がシビル攻撃 (Sybil attacks) を防ぐために空でない clientAddresses[] フィルターを必要とするため、匿名ソースは貢献できません。支配的なプロトコル、豊富なリソースを持つ競合他社など、レビューアを特定して圧力をかけることができるアクターは、そのフィードバックを完全に抑制できます。不正行為を特定するのに最も適した参加者は、発言することが経済的に自己破壊的であるため沈黙させられます。例えば、偏った解決エージェントを指摘する予測市場の参加者は、自身のアドレス、ひいては未決済のポジションを永久にリンクさせてしまいます。ACTAのZK評判アキュムレータ (ZK reputation accumulator) はこれを直接解決します。任意の認証情報 (credential) ホルダーは、自身のアドレスがオンチェーンに表示されることなくフィードバックを提出できます。ナリファイア (nullifier) メカニズムは二重投票を防ぎ、アキュムレータのルートは構成可能なシグナルとしてERC-8004の評判レジストリにアンカーされます。

エージェント間およびエージェントとプロトコル間のインタラクションにおけるプライベートな認証情報検証

AIエージェントが人間のプリンシパル (principal) に代わってオンチェーントランザクション（スワップ、ローン、送金、コントラクト呼び出し）を実行し始めると、規制されたプロトコルは新たなコンプライアンス上の課題に直面します。トランザクションで行動する「エージェント」が、認証情報チェックを通過し、許可された管轄区域で運営され、制裁リストに載っていないオペレーターを持っていることを、エージェントがトランザクションごとにオペレーターの身元をチェーン全体にブロードキャストすることなく、どのように検証するのでしょうか？ERC-8004の下では、これに対するメカニズムはありません。エージェントの公開登録は、その agentId をオペレーターのウォレットに直接リンクさせます。ACTAを使用すると、エージェントは準拠したIDプロバイダーによって発行された認証情報をアンカーし、operator_jurisdiction_not_in(sanctionsList) AND credential_tier >= required_tier を要求する機能ポリシーを登録し、検証可能なコンプライアンスのために規制されたプロトコルに匿名述語証明を提示します。これは、FATFのトラベルルールが、新たなガイダンスの下で自律エージェントにどのように適用されると予想されるかに直接対応します。

プロトコルをまたがる自己主権型エージェントID

Uniswapのエージェント委任フレームワークで動作する認証情報検証済みエージェントは、Aaveや他のERC-8004互換プロトコルに、インタラクション履歴を各プロトコルごとにゼロから再構築することなく、その評判とコンプライアンス証明を持ち運べるべきです。ERC-8004の下では、このクロスプロトコルポータビリティは存在しますが、agentId をレジストリ間で相関させることで、エージェントのすべてのプロトコルにわたる完全なインタラクション履歴を誰にでも公開してしまいます。エージェントの運用履歴、ベンダー関係、認証情報プロファイルは永久に読み取り可能になります。ACTAの下では、エージェントは各プロトコルに、コンテキスト固有のナリファイア (nullifier) によってスコープされた新しい匿名述語証明を提示します。各プロトコルは必要な検証を得られますが、チェーンデータからクロスプロトコルインタラクショングラフを構築することはできません。エージェントのIDは、そのプリンシパル (principal) が最終的な決定権を持ち、さらに重要なことに、リンク可能であることなくポータブルです。

パーミッションレスなエージェント評判のブートストラップ

ERC-8004エコシステムに参入する新しいエージェントは、コールドスタート問題に直面します。評判がなく、履歴がなく、ソーシャルプルーフ (social proof) もありません。現在の解決策である公開フィードバックの蓄積は、エージェントが意味のある市場での地位を保護する前に、その初期のインタラクション履歴全体を永続的なインデックス化に公開して、公に取引することを要求します。ACTAの下では、エージェントは最初のインタラクションからZKアキュムレータ (ZK accumulator) を通じて評判をブートストラップでき、永続的なインタラクショングラフを公開することなく、匿名的だが検証可能な評判シグナルを蓄積できます。エージェントが後で、その集計スコアが信頼閾値を超えていることを将来のDeFiプロトコルに証明する場合、その証明は、基盤となるフィードバックがERC-8004の公開モデルの下で提出されたか、ACTAの匿名モデルの下で提出されたかに関係なく有効です。なぜなら、アキュムレータのマークルルート (Merkle root) は、標準のフィードバックシグナルとしてERC-8004の評判レジストリにアンカーされるからです。

パーソンフッド認証情報とエージェントの背後の人間問題

上記のユースケースはすべて「エージェント」の認証情報、すなわちその監査スコア、モデルの出所、管轄区域のコンプライアンスに関するものです。しかし、プリンシパル (principal) レイヤーには並行して、同様に緊急な問題があります。DeFiプロトコル、予測市場 (prediction market)、またはDAOガバナンス (governance) コントラクトは、トランザクションを提出するエージェントが、背後に説明責任を負うプリンシパル (principal) のいない完全に自律的なボットではなく、実際の人間を代表して行動していることをどのように知るのでしょうか？Adler、Hitzig、Jainら（2024）は、これをパーソンフッド認証情報 (personhood credential) 問題と定義しています。パーソンフッド認証情報 (PHC) は、ACTAがエージェントの機能主張に適用するのと同じ非リンク可能な仮名性 (unlinkable pseudonymity) とゼロ知識証明 (zero-knowledge proof) の特性を使用して、その保持者が実際の人物であることを、それ以上の識別情報を明らかにすることなく証明します。この論文は、AIエージェントへの検証済み委任をPHCの3つの主要なユースケースの1つとして特定しています。

  1. プリンシパル (principal) は、自身のパーソンフッド認証情報 (personhood credential) を自身が制御するエージェントにリンクさせます。

  2. エージェントは、その人間が誰であるかを明らかにすることなく、実際の人間がエージェントの行動に責任を負っていることをサービスに証明できます。

これは今日のガバナンスにとって非常に重要です。投票権や提案権を自律的なボットではなく、実際の人間によって裏付けられたエージェントに制限したいDAOは、現在、これを強制するためのプライバシー保護メカニズムを持っていません。

コミュニティへの未解決の質問

  • 匿名性セットのサイズ決定。 述語証明 (predicate proof) の匿名性保証は、同じ述語を満たす他のエージェントの数によって制限され、ポリシー内の追加の属性制約は問題を悪化させ、個々の制約が無害に見えてもエージェントを非匿名化する可能性があります。異なるリスクコンテキストにおいて、どのような最小閾値が適切でしょうか？有望な方向性の1つは、VOPRFネットワーク（検証可能な秘匿擬似乱数関数 (Verifiable Oblivious Pseudorandom Function)）の使用です。

  • プライバシー保護型代理 (on-behalf-of, OBO) 委任。 OpenID Foundationの2025年エージェントAIアイデンティティに関するホワイトペーパーは、エージェントのなりすましから明示的な委任権限への移行を、この分野で最も緊急な未解決問題として特定しています。適切なOBOフローには、2つの異なるID（委任する人間プリンシパル (principal) と行動するエージェント）をエンコードする認証情報 (credential) が必要ですが、両方を公開チェーンに永久に公開すると、委任グラフ自体が機密データとなってしまいます。ACTAの principal_vc_satisfies() 述語はZKパスを提供します。エージェントは、その委任するプリンシパル (principal) がポリシーを満たす有効な認証情報を保持していることを、そのプリンシパル (principal) が誰であるかを明らかにすることなく証明します。これは、オフチェーンの既存のOAuth 2.0トークン交換 (Token Exchange) フローとどのように相互作用すべきでしょうか？再帰的な委任（エージェントがサブエージェントに委任する場合）の場合、信頼できる仲介者なしにチェーン全体を検証するために必要な述語の表現力はどの程度でしょうか？

  • 発行者のブートストラップと中央集権化リスク。 実際には、誰が AgentCapabilityVCs を発行するのでしょうか？監査法人やTEE (Trusted Execution Environment) アテステーションサービス (attestation services) が明白な候補ですが、少数の信頼された発行者はすぐに信頼のボトルネックとなり、中央集権的な発行者は発行をログに記録することで認証情報 (credential) ホルダーを非匿名化できます。エージェント機能認証情報 (agent capability credentials) の分散型発行者レジストリ (decentralised issuer registries) へ、レジストリレイヤーで信頼できる当事者を再導入することなくシビル耐性 (Sybil-resistant) を維持する信頼できる道筋はあるのでしょうか？分散型認証情報発行 (decentralized credential issuance) の潜在的なアプローチは何でしょうか？

  • 閾値復号 (Threshold decryption) を標準拡張として。 ACTAはデフォルトで完全に匿名です。オンチェーンのナリファイア (nullifier) は、エージェントのマスターシークレットなしにはそのエージェントにリンクできません。これは正しいデフォルトですが、悪用ケースに対するギャップを生み出します。匿名で活動する悪意のあるエージェントには、説明責任メカニズムがありません。ACTAは、閾値委員会による非匿名化 (threshold-committee de-anonymisation) の標準拡張を定義すべきでしょうか？これは、指名された受託者間のマルチシグ (multi-sig) または閾値署名スキーム (threshold signature scheme) が、実証された悪用のオンチェーン証明に基づいて、特定のナリファイア (nullifier) の背後にあるエージェントを明らかにできるというものです。中央集権化を再構築することなく、委員会を選択し、ローテーションさせるガバナンス (governance) メカニズムは何でしょうか？

  • 非リンク性を伴うクロスチェーン認証情報ポータビリティ。 認証情報 (credential) のマークルルート (Merkle root) をチェーン間で素朴にブリッジすると、リンク可能性ベクトルが再作成されます。同じルートが複数のチェーンに表示されると、元のアンカリングトランザクションと相関させることができます。非リンク性を維持するクロスチェーン認証情報ポータビリティ (cross-chain credential portability) の健全な設計はあるのでしょうか？

  • クライアントサイド証明 (Client-side proving): ACTAのユースケースにおいて、zkVMベースの ICircuitVerifier 実装が回路ベースの実装よりも好ましい実用的な閾値（証明サイズ、オンチェーン検証ガス、プロバー (prover) レイテンシ）は何でしょうか？

  • エージェント間インタラクションのためのプライベートな信頼グラフ。 ACTAの現在の認証情報 (credential) モデルはエージェント中心です。AgentCapabilityVC は単一のエージェントが「何であるか」を証明します。しかし、マルチエージェントエコノミーでは、信頼はますます2つのエージェントが「互いにとって何であるか」に依存します。例えば、以前に検証されたインタラクションがあるか、委任された関係があるか、共通のプリンシパル (principal) がいるかなどです。興味深い未解決の質問は、そのようなプライベート認証情報 (private credentials) のネットワークが、各エージェントがその直接的な関係のみを証明しつつ、グローバルには非リンク性を維持するように、信頼グラフを形成できるかどうかです。これにより、オブザーバーはより広範なネットワークトポロジーを再構築できません。これらの認証情報 (credentials) は誰によって、どのように発行され、どのような失効モデルの下で運用されるべきでしょうか？

アクションへの呼びかけ

ERC-8004の著者へ: ACTAは競合ではなく補完を意図しています。設計の互換性に関する懸念は、今提起されるのが最も良いでしょう。

DeFiプロトコル開発者、予測市場チーム、インフラビルダーへ: 本稿の6つのユースケースは、需要がどこにあるかについての私たちの最善の推測ですが、あなた方には明白な特定のデプロイメント (deployment) 阻害要因を見落としている可能性があります。「エージェントが述語を証明し、プロトコルがオンチェーンで検証し、身元は開示されない」というモデルが、実際のアーキテクチャや規制上の制約に合わない場合、そのフィードバックは最終レビュー段階よりもドラフト段階でより価値があります。議論スレッドにご参加ください。

プロトコル設計に関する提案や提出物を募集しています。PSEのPrivate Provingチームにご連絡いただくか、以下にコメントしてください。

参考文献

2投稿 - 2参加者

トピック全体を読む

グラフビュー