はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

今回は、ERC721とERC1155のメタデータJSONにdStorageという項目を追加して、NFTの情報がどの分散ストレージで管理されているかを示す仕組みを提案しているERC5625についてまとめていきます！

以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

概要

ERC5625は、EIP721およびEIP1155で定義されているNFTメタデータのJSONスキーマを拡張し、NFTデータの保存方法を示すdStorageという新しいキーを追加する提案です。
ここでいう「メタデータJSONスキーマ」は、NFTに付随する情報（名前や説明、画像の参照先など）をどの項目名で、どんな形式で書くかを取り決めた“型”のことです。
dStorageは「decentralized storage（分散型ストレージ）」の略で、そのNFTが参照する実体データ（画像・音声・動画などのMIMEタイプのファイル）が、どう保存され、どのように検証できるのかに関する情報を格納する目的のキーです。

動機

NFTは価値の高いデジタルな所有物であり、改ざんされず（不変性）、信頼でき、長期間保管できる（耐久性）ことが求められます。
NFTの所有権はEIP721またはEIP1155のスマートコントラクトによってブロックチェーン上に記録されるため、その点は問題になりにくい一方でNFTが指し示す実体データ（MIMEタイプのファイル）は別です。
理想的には、ブロックチェーン本体よりも大きなデータを扱える、信頼可能で検証可能な分散型ストレージに保存されるべきです。
分散型ストレージとは、特定の管理者に依存せず、保存実体の検証性や可用性を高めるための仕組みを備えた保存手段を指します。

分散型ストレージには、IPFSやArweaveなどがあります。

ERC5625は、NFTの世界における分散型ストレージの採用を後押しするために、NFTメタデータのJSONスキーマに分散型ストレージに関する情報（dStorage）を追加しようというものです。
これにより、メタデータを見ただけで実体データがどこに、どのように保存されているかを理解しやすくなり、信頼性・検証可能性・長期保存性の観点でNFTの品質をより明確に示せるようになります。

あらためて既存のメタデータ標準を整理すると、いずれも実体データの保存情報は扱っていません。
ERC5625は、その欠けていた部分を埋める位置づけです。

標準・仕様	メタデータの参照方法	主なプロパティ（例）	補足
EIP721	`tokenURI`（特定のトークンIDのメタデータJSONの場所を返す関数）	`name`、`description`、`image`	メタデータの形は定めるが、実体データの保存情報は規定なし
EIP1155	`uri`（メタデータJSONの場所を返す関数）	`name`、`decimals`、`description`、`image`、`properties`、`localization`	同上。保存手段や検証情報は含まれない
OpenSea Metadata Standards（マーケットプレイス独自拡張）	―	`image_data`、`external_url`、`attributes`、`background_color`、`animation_url`、`youtube_url` など	事実上の標準（de facto standard）として広く参照されるが、保存情報は含まれない

tokenURI/uriは、「どこにメタデータJSONがあるか」を教えるための関数です。
「MIMEタイプ」は、ファイルの種類を表す標準的な識別子で、画像・音声・動画・3Dモデルなど、NFTが参照する実体データの内容や形式を示します。
「de facto（事実上の）標準」は、公式な規格ではないものの、広く使われているため実質的に標準の役割を果たしているものを指します。

上の表が示すとおり、EIP721/EIP1155の標準スキーマや、OpenSeaなどの拡張スキーマは、名前や説明、表示用の画像や外部リンクのようなメタデータは規定していますが、その背後にある実体データが「どこで、どうやって、どのような検証性のもとで保存されているか」という点は扱っていません。
ここがNFTの不変性・信頼性・耐久性に直結する重要情報であるにもかかわらず、標準化された表現がなかったため、メタデータを見ただけでは保存の質が判断しづらいという課題がありました。

そこでERC5625は、メタデータJSONにdStorageというキーを追加して、保存に関する情報を明示することを目指します。
これにより、NFTの発行者は保存方針を透明化でき、取得者やマーケットプレイスは保存の妥当性や将来の参照可能性をより簡単に評価できます。
最終的には、分散型ストレージの採用が進み、NFT全体の品質表示が標準化されることが期待されています。

仕様

ERC5625では、EIP721およびEIP1155のスマートコントラクトが返すメタデータJSONファイルに、新たにdStorageというプロパティ（項目）を任意で追加できるように定義しています。
このdStorageキーは、NFTやトークンの実体データ（画像・音声・動画など）をどの分散型ストレージに保存しているかを明示的に示すためのものです。

EIP721におけるメタデータJSONスキーマ

EIP721のスマートコントラクトでは、tokenURIメソッドを通じてメタデータJSONファイルを返します。
このファイルに、dStorageプロパティを追加することができます。

以下はEIP721におけるメタデータJSONスキーマの例です。

{
  "title": "Asset Metadata",
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "description": "このNFTが表す資産の名称を示します。"
    },
    "description": {
      "type": "string",
      "description": "このNFTが表す資産についての説明文です。"
    },
    "image": {
      "type": "string",
      "description": "このNFTが表す資産を示す画像のURIです。mime-typeが image/* であるリソースを指します。推奨される画像サイズは幅320〜1080ピクセル、アスペクト比は1.91:1〜4:5の範囲内です。"
    },
    "dStorage": {
      "type": "object",
      "required": [
        "platform",
        "description",
        "persistence_mechanism",
        "challenge_mechanism",
        "consensus",
        "dstorage_note"
      ],
      "properties": {
        "platform": {
          "type": "string",
          "description": "利用している分散型ストレージ（dStorage）プラットフォーム名です。例: Swarm, Arweave, Filecoin, Crust など。"
        },
        "description": {
          "type": "string",
          "description": "そのdStorageプラットフォームの概要説明です。"
        },
        "persistence_mechanism": {
          "type": "string",
          "description": "データの永続性を保証する仕組みや、インセンティブ構造を記述します。例: 'blockchain-based'（ブロックチェーンベース）, 'contract-based'（スマートコントラクトベース）など。"
        },
        "challenge_mechanism": {
          "type": "string",
          "description": "データの正当性や可用性を検証するチャレンジメカニズムです。例: Arweaveの 'proof-of-access' など。"
        },
        "consensus": {
          "type": "string",
          "description": "dStorageプラットフォームで使用されているコンセンサスアルゴリズム（合意形成メカニズム）です。例: PoW, PoS など。"
        },
        "dstorage_note": {
          "type": "string",
          "description": "NFTの実体データがdStorage上に保存されていることを証明するための注記です。例: Filecoinのdeal idや、Crustのplace_storage_orderトランザクションハッシュなど。"
        }
      }
    }
  }
}

このスキーマでは、dStorageオブジェクトに含まれる各項目が必須(required)として定義されています。
これにより、dStorageを記述する場合には、どのプラットフォームを使い、どのように永続化・検証・合意を行っているかを明確に示すことが求められます。

EIP1155におけるメタデータJSONスキーマ

EIP1155のスマートコントラクトでは、uriメソッドを通じてメタデータJSONファイルを返します。
このスキーマも同様に、dStorageプロパティを任意で追加できるように定義されています。

以下はEIP1155のスキーマ定義です。

{
  "title": "Token Metadata",
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "description": "このトークンが表す資産の名称を示します。"
    },
    "decimals": {
      "type": "integer",
      "description": "トークンの小数点以下の桁数を示します。たとえば18なら、トークン量を1,000000000000000000で割った値がユーザーに表示されます。"
    },
    "description": {
      "type": "string",
      "description": "このトークンが表す資産についての説明文です。"
    },
    "image": {
      "type": "string",
      "description": "トークンの実体を示す画像リソースのURIです。mime-typeが image/* である必要があります。推奨される画像サイズは幅320〜1080ピクセル、アスペクト比は1.91:1〜4:5の範囲です。"
    },
    "properties": {
      "type": "object",
      "description": "任意の追加プロパティを定義できます。値は文字列・数値・オブジェクト・配列のいずれも可能です。"
    },
    "localization": {
      "type": "object",
      "required": ["uri", "default", "locales"],
      "properties": {
        "uri": {
          "type": "string",
          "description": "ローカライズされたデータを取得するためのURIパターンです。このURIには `{locale}` という文字列を含める必要があります。実際のリクエスト前に、適切なロケール値に置き換えられます。"
        },
        "default": {
          "type": "string",
          "description": "ベースJSON内のデフォルトデータに対応するロケールです。"
        },
        "locales": {
          "type": "array",
          "description": "利用可能なロケールの一覧です。これらはUnicode Common Locale Data Repository（http://cldr.unicode.org/）で定義された形式に準拠する必要があります。"
        }
      }
    },
    "dStorage": {
      "type": "object",
      "required": [
        "platform",
        "description",
        "persistence_mechanism",
        "challenge_mechanism",
        "consensus",
        "dstorage_note"
      ],
      "properties": {
        "platform": {
          "type": "string",
          "description": "利用している分散型ストレージプラットフォーム名です。例: Swarm, Arweave, Filecoin, Crust など。"
        },
        "description": {
          "type": "string",
          "description": "dStorageプラットフォームの概要説明です。"
        },
        "persistence_mechanism": {
          "type": "string",
          "description": "データの永続性や報酬構造を支える仕組みです。例: 'blockchain-based' や 'contract-based' など。"
        },
        "challenge_mechanism": {
          "type": "string",
          "description": "データの可用性や正当性を検証するチャレンジメカニズムです。例: Arweaveの 'proof-of-access' など。"
        },
        "consensus": {
          "type": "string",
          "description": "使用されているコンセンサスアルゴリズムを示します。例: PoW, PoS など。"
        },
        "dstorage_note": {
          "type": "string",
          "description": "NFTデータがdStorage上に保存されていることを示す証拠情報です。例: Filecoinのdeal id、Crustのトランザクションハッシュなど。"
        }
      }
    }
  }
}

ERC5625の目的は、NFTやマルチトークン（EIP1155）において、実体データがどのように保存されているかを標準化された形式で示すことです。
dStorageプロパティを導入することで、利用者・マーケットプレイス・開発者が、NFTの保存方法の信頼性を簡単に確認できるようになることが期待されています。

これにより、以下のようなメリットが得られます。

NFTが「どの分散ストレージ上で」、「どのような保証のもとに」、「どのように保存されているか」を一目で把握できる。
分散ストレージの選定や評価が容易になり、透明性の高いNFTエコシステムの形成に寄与する。
NFTの耐久性や検証可能性がメタデータ段階で明確になり、より信頼性の高い資産として扱えるようになる。

補足

ERC5625では、dStorage（分散型ストレージ）情報をNFTメタデータに追加する方法として、「スマートコントラクトのインターフェースを拡張する」案ではなく、「JSONスキーマを拡張する」案を採用しています。
この選択には、以下のような理由があります。

インターフェース拡張とJSONスキーマ拡張の選択理由

もしEIP721やEIP1155のコントラクトインターフェース（＝関数定義など）を拡張して新たな情報を扱う場合、開発者は新しい関数を実装したり既存のコントラクト構造を変更したりする必要が生じます。
このアプローチは以下の問題を引き起こします。

項目	インターフェース拡張を採用した場合の問題
実装コスト	新しい関数を追加・実装する必要があり、余分なコードが増える
運用リスク	既にデプロイ済みのNFTコントラクトには反映できず、既存プロジェクトがこの仕様を利用できない
標準との整合性	本質的にNFTメタデータはオフチェーン情報であるため、オンチェーンの関数拡張は過剰で非効率

これに対し、ERC5625が採用するJSONスキーマの拡張は、既存の仕組みを壊すことなく、メタデータの形式を安全に拡張できます。
すなわち、NFTのスマートコントラクトを再デプロイしたり、コードを書き換えたりすることなくメタデータファイルのJSON構造を少し拡張するだけで対応が可能です。
この方法により、すでに運用中のNFTプロジェクトでも、tokenURIやuri関数が返すメタデータJSONにdStorageフィールドを追加するだけで対応できます。

このように、JSONスキーマ拡張方式は軽量・柔軟・後方互換性に優れ、NFT業界全体で採用しやすいという点が選択理由として挙げられます。

互換性

ERC5625は、既存のEIP721およびEIP1155標準との完全な互換性を維持しています。

dStorageは任意項目として定義されているため、必ずしも追加する必要はありません。
既存のEIP721/EIP1155準拠コントラクトはこれまでどおり動作します。
新しいdStorage項目がない場合でも、メタデータの読み取りやトークンの取引に支障はありません。
すでにデプロイ済みのスマートコントラクトも変更不要です。
tokenURIやuriが返すメタデータJSONに追加のキーを含めるだけでよく、スマートコントラクトレベルの変更を必要としません。

セキュリティ

ERC5625は、新たなセキュリティリスクを導入しません。

dStorageはあくまでメタデータJSON内の情報フィールドに過ぎず、NFTのスマートコントラクトロジックには一切影響を与えません。
また、スマートコントラクトが持つ実行ロジックやトランザクションの有効性検証などには関与せず、表示・参照用の補足情報としてのみ機能します。
したがって、この項目が追加されても、トークンの所有権移転、Mint、BurnなどのNFT操作やトランザクション処理に影響を与えることはありません。

つまり、dStorageの追加は「情報の拡張」であって「機能の改変」ではないため、セキュリティ面での脆弱性を引き起こすことはないということです。

また、メタデータの読み取り側（ウォレットやマーケットプレイス）が新しいdStorage項目に対応していない場合でも、問題なく既存項目を読み取ることができるため、安全かつ段階的な導入が可能です。

引用

Gavin Fu (@gavfu), Leo Wang (@wanglie1986), Bova Chen (@appoipp), Guang Han (@pangwa), Brian Wu (@wuhaixian1984), "ERC-5625: NFT Metadata JSON Schema dStorage Extension," Ethereum Improvement Proposals, no. 5625, September 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5625.

最後に

今回は「ERC721とERC1155のメタデータJSONにdStorageという項目を追加して、NFTの情報がどの分散ストレージで管理されているかを示す仕組みを提案しているERC5625」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

Twitter @cardene777

他の媒体でも情報発信しているのでぜひ他も見ていってください！