EIP-6969: ERCおよびNFTメタデータ構築のための新しいアイデア

NFTおよびトークン化された資産がますますコンポーザブルでダイナミックになるにつれて、メタデータはスケーラビリティ、永続性、相互運用性のボトルネックとして浮上しています。今日のメタデータの実践—最も一般的にはHTTP経由で提供されるJSON—は脆弱で、バージョン管理が難しく、ダウンタイムが発生しやすいです。非公式に「EIP-6969」と呼ばれる新しい方向性は、今後10年間、ERCおよびNFTメタデータをどのように構築できるかを探求しています。つまり、コンテンツアドレス指定、検証可能、アップグレード可能、そして設計上チェーンを意識したものです。

この記事では、「EIP-6969 スタイル」のメタデータのための実用的なアーキテクチャの概要を示し、既存の標準でそのほとんどを実装する方法を示し、そしてなぜこれが高スループットのL2とモジュール式アカウントのポスト・カンクン世界で重要なのかを説明します。

メタデータが再考を必要とする理由

基盤となるERC-721やマルチトークンERC-1155を含むオリジナルのNFT標準は、通常オフチェーンJSONに解決されるtokenURIを定義しています。これはシンプルですが、開発者やマーケットプレイスは日常的に以下のような問題に直面しています：

• 中央集権化されたHTTPエンドポイントへの依存による脆弱性とリンク切れ。
• 進化するコレクションにおける信頼できるバージョン管理と出所の欠如。
• メタデータの更新をインデクサーやUIに通知することの難しさ。
• L1/L2エコシステム全体での一貫性のないマルチチェーン解決。
• クリエイターにとって曖昧なロイヤリティとライセンスのシグナル。

すでにいくつかのEIPがこのパズルの断片に取り組んでいます。たとえば、ERC-4906は、インデクサーにメタデータの更新を通知するためのイベントを追加しています。EIP-2981はロイヤリティ情報を標準化しています。EIP-3668 (CCIP-Read)は、信頼を最小限に抑えたオフチェーン読み取りを可能にします。そしてEIP-1014 (CREATE2)は、レジストリとリゾルバーのための決定論的なコントラクトアドレスを可能にします。一方、EthereumのCancun-Denebアップグレード（EIP-4844とともに）は、L2のデータ可用性を大幅に改善し、より多くのオンチェーンまたはセミオンチェーンのメタデータアプローチへの扉を開きました。

「EIP-6969 スタイル」のメタデータとは

EIP-6969を単一のインターフェースとしてではなく、オンチェーンレジストリ、コンテンツアドレス指定されたオフチェーンデータ、そしてウォレットやマーケットプレイスへの強力なシグナルを組み合わせたブループリントと考えてください。

• 決定論的なメタデータレジストリ

  • CREATE2を使用して、予測可能なアドレスにコレクションごとの「メタデータレジストリ」をデプロイします。
  • レジストリは、スキーマコミットメント、デフォルトリゾルバー、フォールバック戦略、およびバージョンタグを格納します。
  • チェーン全体で再現可能なデプロイメントを可能にし、曖昧さとなりすましを減らします。

• デフォルトでのコンテンツアドレス指定ストレージ

  • 可変URLではなくハッシュでメタデータを参照します。IPFSコンテンツアドレッシングまたはArweave Permaweb経由で解決します。
  • パフォーマンスのためにオプションのHTTPミラーが含まれますが、常に検証可能なダイジェストにアンカーされます。

• アップグレード可能でシグナルされたメタデータ

  • トークンレベルまたはコレクションレベルのメタデータが変更されたときにERC-4906イベントを発行し、信頼性の高いリフレッシュを可能にします。
  • スキーマの変更やリゾルバーのアップグレードを示すために、レジストリでセマンティックバージョニングを使用します。

• 検証可能なオフチェーン解決

  • データがオンチェーンに存在できない場合に、信頼を最小限に抑えたオフチェーンフェッチのためにCCIP-Readを採用します。
  • EIP-712型付けデータでメタデータダイジェストに署名します。ウォレットやマーケットプレイスは、コントラクトアカウントに対してEIP-1271を使用して署名を検証できます。

• チェーンを意識したマルチリソースURI

  • CAIP-2チェーン識別子をURIとレジストリレコードに組み込み、L1とL2のバリアントを明確にします。これはCAIP-2と一貫しています。
  • 「マルチリソース」設計を優先します。プライマリコンテンツアドレスに加えて、オプションのミラー（例：IPFS CID + HTTPSゲートウェイ + Arweave TX）。

• NFTおよびファングiblesERC用のコンポーザブルスキーマ

  • トレイト構造、属性、メディア関係のスキーマまたはJSON-LDを公開し、インデクサーの曖昧さを減らします。マーケットプレイスのガイダンス（例：OpenSeaのメタデータ標準）を参照してください。
  • ロールベースのビュー（クリエイターvsホルダーvsマーケットプレイス）をサポートしながら、単一のトークン状態ごとに単一の正規ダイジェストを維持します。

• オプションのアカウントの関与

  • クリエイターが更新、ライセンスゲート、またはトークン固有のロジックのためのプログラム可能なポリシーを必要とする場合、EIP-6900（モジュール式アカウント）またはトークンバウンドコントローラー（例：EIP-6551）を介して、モジュール式スマートアカウントとメタデータコントロールを統合します。

現在のEIPでこれを構築する方法

正式なEIPが登場するまで、アーキテクチャのほとんどは、実績のある標準と簡単なパターンを使用して実装可能です。

1. CREATE2でメタデータレジストリをデプロイする

   • 記録するもの：
     • schemaHash（コンテンツアドレス指定スキーマ）
     • resolver（コントラクトまたはCCIPエンドポイント）
     • version（semver文字列）
     • fallbacks（マルチリソースURIの配列）
   • ERC-165によるインターフェース検出。

2. CCIP-Read経由でトークンメタデータを解決する

   • オンチェーンメソッドは、クライアントに許可されたソースからオフチェーンデータを取得するように指示するセレクターを返します。
   • オフチェーンペイロードは、メタデータとEIP-712署名を返します。クライアントは、EOAの公開鍵またはEIP-1271コントラクトに対して検証します。

3. 更新時にERC-4906イベントを発行する

   • トレイトの進化やダイナミックアートを持つNFTコレクションの場合、MetadataUpdate(tokenId)またはBatchMetadataUpdate(fromTokenId, toTokenId)をトリガーします。

4. どこでもコンテンツアドレス指定URIを使用する

   • IPFSまたはArweaveに正規JSONをピン留めし、CID/TXをレジストリレコードに埋め込みます。
   • ミラーはレイテンシを改善できますが、クライアントはダイジェストを信頼する必要があります。

5. スキーマを公開する

   • 属性、メディア関係、アニメーション、エディションを機械可読スキーマ（例：JSON Schema）で文書化し、スキーマハッシュをレジストリに公開します。
   • OpenSeaのメタデータガイダンスのようなマーケットプレイスが期待するデータフィールドに合わせます。

6. ロイヤリティとライセンスのシグナル

   • ロイヤリティのためにEIP-2981を実装し、ライセンス参照をスキーマの一部として公開して、法的なメタデータをポータブルで検証可能に保ちます。

報われるデザインパターン

• 二段階解決

  • フェーズ1：オンチェーンレジストリデータ（バージョン、リゾルバー、コンテンツダイジェスト）を読み取ります。
  • フェーズ2：CCIP-Readまたはオフチェーンフェッチを実行し、リゾルバーの期待signerに対して署名を検証し、ダイジェストを比較します。

• マルチチェーン整合性

  • チェーン固有のレジストリアドレスとともにCAIP-2識別子を使用します。マーケットプレイスとウォレットは、トークンが属するチェーンバリアントを明確に区別でき、クロスチェーンUXを改善します。

• ガバナンスとリカバリ

  • レジストリの更新は、明確に定義されたポリシーによって制御されるべきです。理想的には、モジュール式アカウント（EIP-6900）または時間ロックされたロールを介して行われます。新しいリゾルバーまたはスキーマが遅延後にアクティブになるステージングされた更新を検討してください。

• キャッシュと再検証

  • クライアントはコンテンツアドレス指定ペイロードをキャッシュし、ERC-4906イベントまたはバージョン変更時に再検証します。これにより、帯域幅が削減され、データが最新の状態に保たれます。

セキュリティ上の考慮事項

• 信頼境界

  • 「誰がメタデータに署名できるか」と「誰がリゾルバーをアップグレードできるか」を明確に分離します。別個のキーを使用し、レジストリに公開します。

• 署名の衛生

  • ドメイン分離、チェーンID、有効期限、およびノンスを備えたEIP-712を優先し、リプレイ攻撃やクロスドメインの混乱を防ぎます。

• ゲートウェイとミラー

  • HTTPSミラーを使用する場合は、クライアント側でダイジェストチェックを強制します。認証のためにゲートウェイの可用性に依存せず、コンテンツアドレッシングに依存します。

• 後方互換性

  • 最小限の互換性のためにレガシーtokenURIを維持しますが、コンテンツアドレス指定ダイジェストを指し、高度なクライアントのためにレジストリ参照を含めます。

ユーザーとマーケットプレイスにとっての意味

コレクターにとって、EIP-6969スタイルのメタデータは、壊れた画像が少なくなり、リフレッシュが速くなり、出所がより明確になることを意味します。マーケットプレイスにとって、決定論的なレジストリと強力なシグナルは、オフチェーンのヒューリスティクスを削減し、インデックス作成の精度を向上させ、ロイヤリティやライセンスに関する紛争を減らします。クリエイターにとって、プログラム可能なポリシーは実用的になります。ミント後にトレイトを進化させたり、エディションを分岐させたり、モジュール式アカウントを介して更新をゲートしたりできます。検証可能性を犠牲にすることなく。

標準の収束はツールにも役立ちます。インデクサーはERC-4906イベントに依存できます。ウォレットはEIP-1271で署名を検証できます。マルチチェーンdappsは、一貫したクロスチェーンコレクションを表示するためにCAIP-2に準拠できます。そしてIPFSまたはArweaveを介したコンテンツアドレッシングは、正規レコードを改ざん防止のままにします。

2025年対応ロードマップ

• コレクションをコンテンツアドレス指定URIに移行し、スキーマハッシュを公開することから始めます。
• シンプルなCREATE2レジストリコントラクトを追加し、更新時にERC-4906を発行します。
• オンチェーンに完全には存在できないダイナミックデータのためにCCIP-Readを実装し、ペイロードにEIP-712で署名します。
• L2での新規ミントについては、Cancun対応のデータ可用性（概要）を活用して、より多くのメタデータをオンチェーンまたはブロブに格納し、オフチェーンペイロードをチェーン状態にアンカーします。
• プログラム可能な更新ポリシーが必要な場合は、モジュール式アカウント制御（EIP-6900）を検討します。

締めくくりと実用的なヒント

メタデータが検証可能、コンテンツアドレス指定、モジュール式設計へと移行しても、1つの定数は変わりません。署名が信頼の根源であるということです。スキーマ変更を公開するクリエイターであっても、CCIP-Readペイロードを検証するマーケットプレイスであっても、安全なEIP-712署名とキーの分離は不可欠です。

より強力なキーセキュリティのためにハードウェアウォレットを好む場合、OneKeyはオープンソースファームウェア、堅牢なセキュアエレメント保護、および人気のあるdappsにおけるEIP-712などの最新の署名フローの円滑なサポートを提供します。メタデータアーキテクチャが明確で検証可能な署名にますます依存するにつれて（特にCCIP-ReadとEIP-1271を介したコントラクトベースの検証）、ワークフローに信頼性が高く監査可能な署名を持つことは、クリエイターとコレクターの両方にとって実用的なアップグレードです。

これらの「EIP-6969 スタイル」のパターンを今日採用することにより、エコシステムはERCおよびNFTメタデータをより耐久性があり、相互運用可能で、将来性のあるものにすることができます。これは、EthereumとそのL2が着実に提供しているマルチチェーン、高スループットの世界に対応できるものです。