トークンメタデータスキーマ

トークンメタデータスキーマとは？

トークンメタデータスキーマとは、暗号資産トークンに関する情報を、ウォレット、分散型アプリケーション（dApp）、エクスプローラー、マーケットプレイス、ゲーム、インデックスツールがどのように記述、保存、読み取りするかを定める構造化フォーマットです。

クリプト分野では、Token Metadata Schemaは通常、NFTやその他のトークン化資産を説明するJSON構造を指します。

スキーマは、

、、、、メディアリンクなど、アプリケーションが想定すべきフィールドを示します。

トークンコントラクトは所有権をオンチェーンで保存し、メタデータはJSONファイルを指すURIを通じて保存する場合があります。

公式のERC-721 standardでは、トークンURIはERC-721 Metadata JSON Schemaに準拠したJSONファイルを指す場合があると規定されています。

公式のERC-1155 standardでは、マルチトークンコントラクト向けにERC-1155 Metadata URI JSON Schemaが定義されています。

メタデータスキーマは、異なるアプリケーションが同じトークンを一貫して表示するのに役立つため重要です。

スキーマがなければ、各プロジェクトがフィールドに異なる名前を付ける可能性があり、ウォレットはどの値が画像、説明、特性を表すのか判断しにくくなります。

初心者にとっては、トークンメタデータスキーマを暗号資産のラベル形式と考えると理解しやすいでしょう。

ブロックチェーンはトークンの存在と所有者を証明し、メタデータスキーマはそのトークンが何を表すかを説明します。

暗号資産においてトークンメタデータスキーマが重要な理由

トークンメタデータスキーマが重要なのは、ユーザーが単なるトークンIDだけを扱うわけではないためです。

ユーザーは画像、名前、説明、特性、レベル、バッジ、レアリティ情報、アンロック可能なコンテンツなど、人が読める情報を扱います。

ウォレットはメタデータの読み方を把握して初めてトークンを適切に表示できます。

ゲームはアイテムの属性やメディアフィールドを理解して初めてアイテムを適切に表示できます。

マーケットプレイスは、特性が予測可能な形で構造化されて初めてコレクションを適切にフィルタリングできます。

NFTを担保として受け入れるレンディングプロトコルでは、評価プロセスを支えるために正確なコレクション、特性、メディア情報が必要になる場合があります。

現実資産プラットフォームでは、文書、発行者、評価、法的条件、検証状況を参照するメタデータフィールドが必要になる場合があります。

トークンゲート型アプリでは、トークンが特定レベルの会員資格へのアクセスを付与するか確認するためにメタデータが必要になる場合があります。

メタデータが明確に構造化されていれば、アプリケーションは自動的に読み取れます。

メタデータが不整然または一貫性に欠ける場合、ユーザーには壊れた画像、欠落した特性、誤った名前、古い資産情報が表示される可能性があります。

このため、メタデータスキーマの設計は開発者だけの詳細ではなく、暗号資産のユーザー体験の一部です。

トークンメタデータスキーマとトークンURI

トークンURIは、トークンメタデータを指すリンクまたは識別子です。

トークンメタデータスキーマは、そのリンク先またはエンコードされた応答内にあるデータの構造です。

例えば、ERC-721コントラクトは

からを返す場合があります。

そのURIにあるJSONファイルは、ウォレットが理解できるようメタデータスキーマに従う必要があります。

トークンURIはメタデータのアドレスです。

トークンメタデータスキーマはメタデータの形式です。

URI内のJSONが無効または分かりにくい場合、URIが機能しているだけでは不十分なため、この違いは重要です。

メタデータファイルに到達できても、フィールドが欠けている、または非標準の名前になっていると、トークンは正しく表示されない場合があります。

逆に、スキーマが正しくても、URIが利用できないストレージを指していれば読み込めません。

優れたNFT設計には、信頼できるトークンURIと整理されたトークンメタデータスキーマの両方が必要です。

ERC-721におけるトークンメタデータスキーマ

ERC-721は、Ethereum系ネットワーク上のユニークなNFTの代表的な規格です。

ERC-721のメタデータ拡張には、

、、が含まれます。

ERC-721規格では、

、、などを含められるシンプルなJSONスキーマでメタデータを説明しています。

このシンプルな構造により、NFTはウォレットやアプリケーションで表示しやすくなりました。

ERC-721トークンは、デジタルアート、ゲームアイテム、会員パス、証明書、仮想土地、IDバッジ、現実資産の記録などを表せます。

各トークンIDは固有のメタデータファイルを持つことができます。

つまり、トークンID 1はトークンID 2とは異なる画像、名前、属性を持つことができます。

スキーマは、各ユニークトークンを説明するフィールドをクライアントが理解するのに役立ちます。

開発者は、特性、メディア、アニメーション、レアリティ、ライセンス、プロジェクト固有データのために、基本的なERC-721メタデータパターンを拡張することがあります。

こうした拡張は有用ですが、主要フィールドは一般的なWeb3ツールとの互換性を保てるよう、明確にする必要があります。

ERC-1155におけるトークンメタデータスキーマ

ERC-1155は、1つのコントラクト内で代替可能、半代替可能、非代替性トークンを管理できるマルチトークン規格です。

1つのコントラクトに異なる意味を持つ多数のトークンIDを含められるため、ERC-1155のメタデータスキーマは特に重要です。

1つのERC-1155コントラクトは、ゲームコイン、武器、防具、チケット、バッジ、限定版、ユニークなコレクティブルを表せます。

ERC-1155規格では、URIに

プレースホルダーを含めることができます。

クライアントソフトウェアは、メタデータ取得前に

を実際のトークンIDに置き換えます。

公式のOpenZeppelin ERC-1155 Metadata URI documentationでは、メタデータURI拡張が各トークンをERC-1155 Metadata URI JSON Schemaに従うJSONファイルに紐付けることが説明されています。

ERC-1155メタデータには、

、、、、その他のトークン固有データを含められます。

スキーマにより、ウォレットやdAppはトークンIDごとにカスタムロジックを必要とせず、1つのコントラクトから多様な資産タイプを表示できます。

IDの置換を誤ると壊れた表示や誤った表示につながるため、ERC-1155メタデータは慎重に扱う必要があります。

堅牢なERC-1155メタデータ設計では、各トークンIDを解釈しやすく、確実に取得できます。

トークンメタデータスキーマの一般的なフィールド

最も一般的なフィールドは、トークンに人が読めるタイトルを付ける

です。

次に一般的なのは、トークンが何を表すかを説明する

です。

フィールドは通常、ウォレットやマーケットプレイスに表示されるメイン画像を指します。

フィールドは、クライアントが対応している場合、動画、音声、3Dオブジェクト、インタラクティブコンテンツなどのより豊富なメディアを指すことができます。

フィールドは、トークンまたはコレクションについての詳細情報がある公式ページを指すことができます。

フィールドには通常、レアリティ、フィルタリング、ゲームステータス、コレクション整理に使われる特性オブジェクトの配列が含まれます。

フィールドは、資産の表示背景色を提案するために使われることがあります。

フィールドは、ERC-1155形式のメタデータやプロジェクト固有の構造化情報に使われることが多いです。

一部のプロジェクトは、

、、、、などのフィールドを追加します。

カスタムフィールドは有用ですが、アプリケーションが正しく解釈できるよう文書化する必要があります。

基本的なNFTメタデータスキーマの例

シンプルなNFTメタデータファイルは通常、いくつかの明確なフィールドを持つJSONオブジェクトです。

この例では、読みやすい名前、説明、画像参照、2つの属性を示しています。

このスキーマは、ウォレットやdAppが解析するには十分シンプルです。

画像にはIPFS形式のURIが使われており、メディアがコンテンツアドレス指定ストレージを通じて参照されることを意味します。

属性は配列として構造化されているため、フィルタリングツールやレアリティツールを構築しやすくなります。

プロジェクトはより多くのフィールドを追加できますが、互換性を損なう不要な複雑さは避けるべきです。

優れたメタデータは、機械可読であると同時に人にも理解しやすいものです。

Nameフィールド

フィールドはトークンの表示タイトルを設定します。

NFTコレクションでは、コレクション名とトークン番号を使用するのが一般的です。

例として、

があります。

ゲームアイテムでは、

やのような名前を使用する場合があります。

会員トークンでは、

のような名前を使用する場合があります。

名前は安定的で明確であり、誤解を招かないものにすべきです。

偽コレクションは実在プロジェクトの名前をコピーする可能性があるため、ユーザーはnameフィールドだけに依存してはいけません。

表示名よりも公式コントラクトアドレスの方が重要です。

トークンが動的に設計されている場合を除き、開発者は予期せず名前を変更しないようにすべきです。

優れたnameフィールドは、真正性を証明したように装うことなく認識性を高めます。

Descriptionフィールド

フィールドは、トークンが何を表すかを説明します。

明確な説明は、ユーザーが資産の目的、ストーリー、ユーティリティ、会員としての役割を理解するのに役立ちます。

アートNFTでは、説明にコンセプトやコレクションテーマを記載する場合があります。

ゲームアイテムでは、アイテムの利用方法を説明する場合があります。

現実資産トークンでは、法的文書を別途参照するよう案内しながら、資産カテゴリーを要約する場合があります。

説明には、価値、保証されたリターン、公式ステータスに関する誤解を招く主張を含めるべきではありません。

ウォレットやdAppは説明をユーザーに直接表示する場合があるため、安全でないリンクや詐欺メッセージはフィッシングリスクを生む可能性があります。

開発者は説明を有用かつ誠実に保つべきです。

ユーザーは、説明がトークン作成者またはメタデータ管理者によって提供されていることを認識する必要があります。

説明は、トークンの品質や正当性を独立して検証するものではありません。

Imageフィールド

フィールドは、トークン用に表示されるメインメディアファイルを指します。

アプリケーションによっては、PNG、JPG、GIF、SVG、その他対応する画像形式を指すことができます。

画像はIPFS、Arweave、HTTPSサーバー、またはメタデータ内への直接エンコードで保存できます。

多くのユーザーがNFTを視覚的に識別するため、imageフィールドは重要です。

オンチェーンの所有権が有効でも、画像リンクが壊れるとトークンが不完全に見えることがあります。

誤解を招く画像により、偽トークンが正規のものに見える可能性があります。

中央集権型の画像URLは、サーバーまたはドメインに問題が起きると消失する可能性があります。

コンテンツアドレス指定画像URIは完全性を高める可能性がありますが、コンテンツはストレージまたはピン留めを通じて利用可能である必要があります。

開発者は長期保有資産に耐久性のある画像ストレージを使うべきです。

ユーザーは高額NFTを信頼する前に画像ストレージの品質を確認すべきです。

Attributesフィールド

フィールドは、特性、レアリティ、ゲーム特性、レベル、ステータス、その他の構造化された機能を説明するために一般的に使われます。

各属性は通常、

とを持つオブジェクトです。

例えば、

が、がとなる場合があります。

ゲームアイテムでは、

が、がとなる場合があります。

マーケットプレイスや分析ツールがフィルタリングやレアリティ順位付けに使用するため、属性構造は重要です。

属性に一貫性がないと、レアリティツールが不正確になる可能性があります。

特性名のスペルミスにより、本来1つであるべきカテゴリーが複数に分割される場合があります。

ツールが正しく比較できるよう、数値属性は一貫した形式で設定すべきです。

動的NFTでは、属性が時間とともに変更される可能性があるかを明確にすべきです。

優れた属性は、ユーザーがトークンのアイデンティティとユーティリティを理解するのに役立ちます。

Propertiesフィールド

フィールドは、基本的な名前、説明、画像データを超える構造化メタデータを保持するためによく使われます。

ERC-1155のメタデータ例では、追加のトークン情報に

がよく使われます。

ゲームアイテムには、レアリティ、クラス、耐久性、クラフト素材などのプロパティを含める場合があります。

チケットトークンには、イベント日、座席レベル、会場、アクセス種別などのプロパティを含める場合があります。

現実資産トークンには、資産カテゴリー、発行者参照、法域、文書ハッシュ、検証状況などのプロパティを含める場合があります。

プロパティは、より豊富なデータモデルを可能にするため強力です。

一方、各プロジェクトが文書化せずに異なる名前や形式を使うと、複雑で扱いにくくなる可能性があります。

開発者はプロパティ名を安定的かつ予測可能に保つべきです。

アプリケーションは、コントラクトロジックまたは信頼できる情報源で検証されるまで、プロパティを信頼されていないデータとして扱うべきです。

プロパティフィールドは資産を説明できますが、その主張が真実であることを自動的に証明するものではありません。

トークンメタデータスキーマとIPFS

IPFSは、トークンメタデータやメディアファイルの保存に広く使われています。

公式のIPFS content-addressing documentationでは、IPFSがコンテンツ自体に基づいてデータを参照するContent Identifier、すなわちCIDを使用することが説明されています。

これは、CIDにより参照先コンテンツが変更されたか確認できるため、メタデータに役立ちます。

JSONメタデータが変われば、CIDも変わるはずです。

これにより、同じアドレスでコンテンツを変更できる通常のサーバーURLよりも強い完全性をユーザーに提供できます。

ただし、IPFSはデータが永久に利用可能であることを自動的に保証しません。

クライアントが取得できるよう、メタデータと画像ファイルはピン留めされるか、ノードから提供される必要があります。

IPFSに保存されたメタデータスキーマでも、誰もコンテンツを利用可能に保たなければ機能しなくなる可能性があります。

開発者はトークンのミント前に、ピン留めと長期ストレージを計画すべきです。

ユーザーは、コンテンツアドレス指定が完全性を高める一方、可用性にはストレージの支援が必要であることを理解すべきです。

トークンメタデータスキーマとHTTPストレージ

一部のプロジェクトは、標準的なHTTPSサーバーにメタデータを保存しています。

これにより、メタデータの更新、生成、迅速な提供が容易になる場合があります。

これは、動的NFT、ゲーム資産、リビール機能、稼働中のバックエンドシステムに依存する資産で一般的です。

欠点は、HTTPメタデータがサーバー稼働時間、ドメイン管理、ホスティングセキュリティ、プロジェクト運営に依存することです。

サーバーがオフラインになると、ユーザーインターフェースからトークンメタデータが消える場合があります。

ドメインが失効すると、メタデータエンドポイントは安全でなくなるか、利用できなくなる可能性があります。

サーバー運営者がJSONを変更すると、オンチェーンの変更なしにユーザーに異なるコンテンツが表示される可能性があります。

HTTPメタデータが自動的に悪いわけではありませんが、明確に開示すべきです。

開発者は、メタデータが変更可能か、ストレージをどの程度維持するかを説明すべきです。

ユーザーは、中央集権型メタデータサーバーに全面的に依存する高額資産には、より慎重になるべきです。

トークンメタデータスキーマとオンチェーンメタデータ

オンチェーンメタデータとは、トークンメタデータをスマートコントラクトに直接保存または生成することです。

これにより、外部ストレージシステムへの依存を減らせる場合があります。

コントラクトは、エンコードされたメタデータを含む

URIを返す場合があります。

メタデータにはオンチェーンSVG画像やジェネラティブアートのロジックが含まれる場合があります。

データがブロックチェーンの状態と結び付くため、オンチェーンメタデータは耐久性を高める可能性があります。

一方、オンチェーンでのデータ保存や生成にはリソースコストがかかるため、高額になる可能性があります。

オンチェーンメタデータは変更しにくい場合があり、永続性には有用ですが、ゲームや動的な認証情報には不向きなことがあります。

開発者は、柔軟性よりも永続性とトラスト最小化が重要な場合にオンチェーンメタデータを選ぶべきです。

コントラクトが許可していればオンチェーンメタデータも動的になり得るため、ユーザーは引き続きコントラクトロジックを確認すべきです。

オンチェーンメタデータはストレージモデルであり、品質を自動的に保証するものではありません。

トークンメタデータスキーマと動的NFT

動的NFTは、イベント、時間、ゲームプレイ、オラクルデータ、ガバナンス決定、ユーザー操作に応じてメタデータが変化するトークンです。

動的メタデータはNFTの実用性とインタラクティブ性を高める可能性があります。

ゲームキャラクターはレベルアップできます。

会員パスは有効から期限切れに変わることがあります。

認証情報は、ユーザーが新しい実績を達成した後に更新される場合があります。

現実資産トークンは、検証状況または文書参照を更新する場合があります。

メタデータスキーマでは、動的フィールドを明確にすべきです。

ユーザーは、どのフィールドが変更可能か、誰が変更を管理するかを把握すべきです。

動的NFTは、曖昧なメタデータ表現の裏に恣意的な管理者権限を隠すべきではありません。

優れた動的メタデータは、予測可能で文書化され、意味のあるトークンの動作と結び付いています。

トークンメタデータスキーマとメタデータ更新

メタデータ更新は、リビール、ゲーム進行、資産検証、誤りの修正で一般的です。

公式のERC-4906 metadata update extensionでは、NFTメタデータが変更された際にクライアントへ通知するイベントが定義されています。

ウォレットやインデクサーは速度向上のためにメタデータをキャッシュすることが多いため、これは重要です。

メタデータが変わっても更新シグナルが発行されなければ、ユーザーには古い情報が表示され続ける可能性があります。

メタデータスキーマは明確な更新動作と組み合わせるべきです。

リビールでは、プレースホルダーメタデータが最終メタデータに変更される時期をプロジェクトが説明すべきです。

動的資産では、どのイベントがメタデータ変更のトリガーとなるかをプロジェクトが説明すべきです。

管理者が制御する更新では、誰がどの条件でメタデータを変更できるかを開示すべきです。

透明性のあるメタデータ更新は信頼構築につながります。

隠されたメタデータ更新は不確実性を生み、トークン価値を損なう可能性があります。

トークンメタデータスキーマとコントラクトレベルのメタデータ

トークンレベルのメタデータは特定のトークンIDを説明します。

コントラクトレベルのメタデータはコントラクトまたはコレクション全体を説明します。

公式のERC-7572 contract-level metadata standardでは、名前、説明、画像などの豊富なコントラクトレベル情報のために

が標準化されています。

コレクションにはロゴ、バナー、説明、手数料情報、ソーシャルリンク、プロジェクトレベルの画像が必要になる場合があるため、これは有用です。

コレクション内の1つのNFTには独自のトークンメタデータスキーマがあり、コレクションには別にコントラクトレベルのメタデータスキーマがある場合があります。

両方のレイヤーがユーザー体験に重要です。

トークンメタデータが正しくてもコレクションメタデータが誤っていれば、ユーザーには依然として混乱を招く情報が表示される可能性があります。

コレクションメタデータが正しくてもトークンメタデータが壊れていれば、個別トークンは適切に表示されない可能性があります。

開発者は、関連する場合、トークンレベルとコントラクトレベルの両方のメタデータをサポートすべきです。

ユーザーは、これらが関連しつつも異なるメタデータレイヤーであることを理解すべきです。

トークンメタデータスキーマとERC-1046

ERC-1046は、基本的なNFTのユースケースを超えてトークンURIの考え方を拡張します。

公式のERC-1046 tokenURI interoperability proposalでは、ERC-20向けのトークンURIサポートが追加され、トークンタイプ間のメタデータ相互運用性が拡張されています。

代替可能トークンにもメタデータが必要になる場合があるため、これは重要です。

代替可能トークンには、ロゴ、説明、発行者情報、公式リンク、コンプライアンス上の注意、文書参照などが必要になる場合があります。

標準化されたメタデータは、ウォレットやアプリケーションが代替可能トークンをより明確に表示するのに役立ちます。

ただし、ユーザーはメタデータフィールドを正当性の証拠として扱うべきではありません。

詐欺トークンでも見栄えのよいロゴや説明を提供できます。

コントラクトアドレス、発行者、流動性、セキュリティ、トークノミクス、公式情報源は引き続き重要です。

ERC-1046は、メタデータスキーマがコレクティブル画像だけのものではないことを示しています。

これはトークン情報の相互運用性を高める、より広い取り組みの一部です。

トークンメタデータスキーマとERC-5625

ERC-5625は、NFTの分散型ストレージ情報に関連する提案済みのメタデータ拡張です。

公式のERC-5625 NFT Metadata JSON Schema dStorage Extensionでは、資産ストレージ情報をより明確に説明できるよう、NFTメタデータに分散型ストレージのプロパティを追加します。

メタデータはブロックチェーン外に保存されたファイルを指すことが多いため、これは重要です。

トークンは耐久性があるように見えても、そのメディアは不明確なストレージ体制に依存する可能性があります。

ストレージ関連メタデータを追加すると、ユーザーとアプリケーションは資産データの保存先を理解しやすくなります。

また、コンテンツがIPFS、Arweave、その他の分散型ストレージシステムのどれに保存されているかを特定する助けにもなります。

ストレージメタデータだけで永続性が保証されるわけではありません。

これは、アプリケーションがストレージに関する前提をより明確に説明・確認する方法を提供します。

高額NFTでは、分散型ストレージの詳細がデューデリジェンスの重要な要素となる場合があります。

資産が何であるかに加え、そのデータがどのように保存されるかを説明することで、メタデータスキーマはより堅牢になります。

スキーマ検証

スキーマ検証とは、メタデータが想定された構造に従っているかを確認することです。

バリデーターはJSONが有効か確認できます。

必要なフィールドが存在するか確認できます。

imageフィールドが有効なURIか確認できます。

attributesが配列として形式化されているか確認できます。

数値が一貫した形で保存されているか確認できます。

メディアフィールドが対応するファイルタイプを指しているか確認できます。

スキーマ検証は、壊れたウォレット表示やマーケットプレイスのエラー防止に役立ちます。

また、開発者がミントまたはリビール前にミスを見つけるのに役立ちます。

プロジェクトは、分散型ストレージにメタデータを恒久的に公開する前に検証すべきです。

メタデータスキーマとレアリティ

レアリティツールは、NFTメタデータ内の

フィールドに依存することが多いです。

属性に一貫性がなければ、レアリティ計算は不正確になる可能性があります。

例えば、一部のツールは

、、を異なる値として扱う場合があります。

あるトークンが

を使用し、別のトークンがを使用すると、レアリティツールは特性カテゴリーを分割する可能性があります。

一部のトークンに特性が欠けている場合、レアリティ計算は予期せず変化することがあります。

プロジェクトはコレクション全体で一貫した特性名と値を使用すべきです。

また、コレクションを変更不可とする場合は最終メタデータを凍結すべきです。

リビール期間中はレアリティデータがまだ安定していない場合があるため、ユーザーは注意すべきです。

メタデータスキーマの品質は、コレクターによるNFT評価に直接影響する場合があります。

特性ベースの価格設定を行うコレクションでは、クリーンなメタデータが特に重要です。

メタデータスキーマとゲーム資産

ゲーム資産では、シンプルなアートNFTよりも豊富なメタデータスキーマが必要になることがよくあります。

ゲームアイテムには、レベル、耐久性、攻撃力、防御力、レアリティ、クラス、属性、クールダウン、アップグレード状況、装備スロットのフィールドが必要になる場合があります。

キャラクターNFTには、経験値、スキル、インベントリ、勢力、体力、視覚状態のフィールドが必要になる場合があります。

これらのフィールドの一部はゲームプレイ中に変化する場合があります。

開発者は、どの値をオンチェーンに置き、どの値をメタデータに置くかを決めるべきです。

重要なゲームプレイロジックは、未検証のオフチェーンメタデータだけに依存すべきではありません。

ゲームコントラクトまたはサーバーは、高額な操作を許可する前に重要な値を検証すべきです。

メタデータは表示を改善できますが、ゲームルールは信頼できるロジックで保護すべきです。

ユーザーは、アイテムの価値がゲームの継続運営に依存するかを理解すべきです。

メタデータスキーマはゲーム資産を説明できますが、そのユーティリティを与えるのはゲームエコシステムです。

メタデータスキーマと現実資産

現実資産トークンは、オフチェーン資産を説明するためにメタデータスキーマを使用する場合があります。

例には、不動産記録、商品、請求書、債券、ファンド持分、コレクティブル、カーボンクレジット、ID連携認証情報などがあります。

メタデータスキーマには、発行者、資産カテゴリー、文書URI、評価日、法域、カストディアン、検証状況、文書ハッシュのフィールドが含まれる場合があります。

これらのフィールドはユーザーの理解に役立ちますが、法的所有権を自動的に作り出すものではありません。

法的権利は、発行者文書、契約、カストディ体制、法域、償還ルールに依存します。

現実資産のメタデータスキーマは、マーケティング情報と法的に重要な参照情報を分けるべきです。

検証できない曖昧な主張は避けるべきです。

可能な場合、ハッシュまたは耐久性のあるストレージを通じて文書の完全性を維持すべきです。

ユーザーは現実資産メタデータに依存する前に、公式の法的文書を読むべきです。

メタデータは開示を支援できますが、法的デューデリジェンスの代わりにはなりません。

メタデータスキーマとセキュリティリスク

ウォレットやdAppが外部ソースからデータを取得して表示するため、トークンメタデータはセキュリティリスクを生む可能性があります。

悪意あるメタデータファイルには、フィッシングリンク、偽の報酬メッセージ、誤解を招く画像、危険な外部URLが含まれる可能性があります。

スパムNFTがウォレットに表示され、偽の請求ページにアクセスするようメタデータでユーザーを誘導する場合があります。

偽コレクションは、本物のコレクションの名前、画像、属性をコピーする場合があります。

侵害されたメタデータサーバーは、後から安全そうなメタデータを悪意あるコンテンツに変更する可能性があります。

ウォレットやdAppはメタデータを信頼されていない入力として扱うべきです。

メタデータ内のスクリプトを実行すべきではありません。

可能な限り、外部リンクとメディアコンテンツをサニタイズすべきです。

メタデータで指示されても、ユーザーはシードフレーズ、秘密鍵、ウォレットバックアップを入力してはいけません。

見た目が整ったメタデータスキーマは、トークンの安全性を証明するものではありません。

メタデータスキーマと変更可能性

変更可能性とは、トークンのミント後にメタデータを変更できることを指します。

トークンが動的であるため、変更可能性を必要とするプロジェクトもあります。

他方で、メタデータが恒久的で変更されないことを約束するプロジェクトもあります。

メタデータスキーマはプロジェクトの約束と一致すべきです。

コレクションが変更不可能なアートとして販売される場合、メタデータを無制限の管理者権限下に置いたままにすべきではありません。

トークンがゲームアイテムなら、動的メタデータが想定される場合があります。

トークンが認証情報なら、更新が必要な場合がありますが、監査可能であるべきです。

ユーザーは、誰がメタデータ更新を管理するか確認すべきです。

開発者は、メタデータが変更不可能、動的、管理者制御、ガバナンス制御のどれであるかを文書化すべきです。

隠された変更可能性は、NFTメタデータにおける最大の信頼リスクの一つです。

メタデータスキーマとキャッシュ

キャッシュとは、アプリケーションがトークンをより速く読み込めるよう、メタデータを一時的に保存することです。

ウォレット、マーケットプレイス、エクスプローラー、インデクサーはメタデータをキャッシュすることが多いです。

各メタデータファイルを繰り返し取得すると遅くなるため、キャッシュは有用です。

問題は、キャッシュされたメタデータが古くなる可能性があることです。

リビール中、最終メタデータが公開された後も、一部のアプリケーションにはプレースホルダー画像が表示され続ける可能性があります。

動的更新中、一部のアプリケーションにはキャッシュが更新されるまで古い属性が表示される場合があります。

メタデータ更新規格は、クライアントがキャッシュデータを更新する時期を把握するのに役立ちます。

開発者は、メタデータの変更が想定される場合に更新イベントをサポートすべきです。

ユーザーは、表示の遅延がトークンの不具合ではなくキャッシュに起因する場合があることを理解すべきです。

堅牢なメタデータスキーマは、適切なキャッシュ更新動作と組み合わせたときに最も効果を発揮します。

メタデータスキーマとインデクサー

インデクサーはブロックチェーンデータを収集し、アプリケーション向けに整理します。

トークンメタデータでは、インデクサーは

を呼び出し、JSONファイルを取得し、属性を解析し、画像をキャッシュし、APIレスポンスを提供する場合があります。

インデクサーが効率的に機能するには、予測可能なメタデータスキーマが必要です。

各プロジェクトが通常と異なるフィールド名を使用すると、インデクサーはカスタムロジックを構築する必要があります。

メタデータファイルが無効または遅い場合、インデクサーは資産を適切に表示できない可能性があります。

イベントなしにメタデータが変更されると、インデクサーは古いデータを表示する場合があります。

このため、スキーマの一貫性はWeb3エコシステム全体に役立ちます。

開発者は、ローンチ前に一般的なインデクサーの動作でメタデータをテストすべきです。

ユーザーは、各ウォレットのインデクサーが異なる時点で更新される場合、異なるメタデータが表示される可能性があることを認識すべきです。

インデクサーは目に見えにくいものの、トークンメタデータの使いやすさにおいて重要な要素です。

開発者向けベストプラクティス

、、、など、広くサポートされるメタデータフィールドを使用してください。

すべてのトークンURIから有効なJSONを返してください。

コレクション全体で安定した特性名と値を使用してください。

メタデータとメディアファイルには耐久性のあるストレージを使用してください。

IPFSファイルをピン留めするか、信頼できる長期ストレージ計画を使用してください。

メタデータが変更可能、変更不可能、動的のどれであるかを文書化してください。

メタデータが変更される場合は、メタデータ更新イベントを発行してください。

メタデータを恒久的に公開する前に検証してください。

ウォレット、エクスプローラー、dAppでの表示動作をテストしてください。

編集可能なメタデータ内だけに重要な法的約束を記載することは避けてください。

ユーザー向けベストプラクティス

トークンメタデータがIPFS、サーバー、Arweave、オンチェーンのどこに保存されているかを確認してください。

トークン名や画像を信用するのではなく、公式コントラクトアドレスを確認してください。

外部リンクや報酬に関する主張を含むメタデータには注意してください。

メタデータを見るだけのためにトランザクションへ署名しないでください。

トークンメタデータからリンクされたページにリカバリーフレーズを入力しないでください。

メタデータを管理者が変更できるか確認してください。

NFTのリビール期間中は属性を慎重に確認してください。

表示された画像が真正性を証明するわけではないことを理解してください。

現実資産トークンでは、メタデータファイル外の法的文書を読んでください。

メタデータは有用な情報として扱い、価値や安全性の独立した証拠として扱わないでください。

よくあるトークンメタデータスキーマのミス

1つ目のミスは、無効なJSONを公開することです。

2つ目のミスは、トークン間で一貫性のない属性名を使用することです。

3つ目のミスは、imageフィールドを利用できないファイルに設定することです。

4つ目のミスは、開示なしに中央集権型サーバーへ依存することです。

5つ目のミスは、明確なルールなしにミント後のメタデータを変更することです。

6つ目のミスは、ERC-1155の

置換要件を忘れることです。

7つ目のミスは、代替画像なしに非対応のメディア形式を使用することです。

8つ目のミスは、説明的な情報に過ぎないメタデータを法的拘束力があるものとして扱うことです。

9つ目のミスは、メタデータ変更時に更新イベントを発行しないことです。

10つ目のミスは、ユーザーをフィッシングにさらす可能性のある安全でないリンクを含めることです。

FAQ

Token Metadata Schemaとは何ですか？

Token Metadata Schemaとは、通常はJSONで、暗号資産トークンのメタデータを説明するために使われる構造化フォーマットです。

Token Metadata SchemaはNFT専用ですか？

いいえ。NFTで最も一般的ですが、メタデータスキーマは代替可能トークン、現実資産トークン、アプリケーション固有トークンにも使用できます。

NFTメタデータで一般的なフィールドは何ですか？

一般的なフィールドには、

、、、、、があります。

Token URIとToken Metadata Schemaの違いは何ですか？

Token URIはメタデータを指し、Token Metadata Schemaはそこにあるメタデータの構造を定義します。

ERC-721 Metadata JSON Schemaとは何ですか？

トークンURIを通じて返されるNFTメタデータのために、ERC-721で説明されている基本メタデータスキーマです。

ERC-1155 Metadata URI JSON Schemaとは何ですか？

を通じたトークンID置換をサポートする、ERC-1155トークン用メタデータスキーマです。

トークンメタデータをIPFSに保存できますか？

はい。トークンメタデータは、コンテンツ完全性の検証に役立つコンテンツ識別子を使ってIPFSに保存できます。

IPFSはメタデータが常に利用できることを保証しますか？

いいえ。IPFSはコンテンツアドレス指定を改善しますが、ユーザーが取得できるようファイルはピン留めまたは提供される必要があります。

トークンメタデータはミント後に変更できますか？

はい。プロジェクトが動的メタデータ、変更可能なサーバー、管理者制御のベースURI、更新可能なリゾルバーロジックを使用する場合、メタデータは変更できます。

動的トークンメタデータとは何ですか？

動的トークンメタデータとは、時間、ゲームプレイ、ユーザー活動、オラクルデータ、コントラクト状態、プロジェクト更新に基づいて変化するメタデータです。

ERC-4906は何に使われますか？

ERC-4906は、NFTメタデータを更新すべきタイミングをウォレットやアプリケーションに知らせるメタデータ更新イベントを定義します。

ERC-7572は何に使われますか？

ERC-7572は、コレクション名、説明、画像などのコントラクトレベルメタデータ用に

を標準化します。

メタデータは悪意あるものになり得ますか？

はい。メタデータにはフィッシングリンク、偽の報酬主張、誤解を招く画像、安全でない外部参照が含まれる可能性があります。

NFTの特性が誤って表示されることがあるのはなぜですか？

属性の不一致、欠落、スペルミス、キャッシュ、またはクライアントが理解できない形式により、NFTの特性が誤表示される場合があります。

優れたToken Metadata Schemaの条件は何ですか？

優れたToken Metadata Schemaは、有効で、一貫性があり、耐久性があり、文書化され、一般的なツールと互換性があり、メタデータの変更可能性を明確にしています。

結論

トークンメタデータスキーマは、ウォレット、dApp、エクスプローラー、ゲーム、マーケットプレイス、インデクサーに対し、暗号資産トークンの情報をどのように読むかを示す構造化フォーマットです。

NFTでは特に重要です。NFTの所有権はオンチェーンに保存される一方、名前、画像、特性、説明、メディアはメタデータファイルを通じて保存されることが多いためです。

ERC-721とERC-1155はいずれも、アプリケーションがトークン情報を一貫して解決・表示するのに役立つメタデータパターンを定義しています。

優れたメタデータスキーマは、トークンの理解、フィルタリング、取引、検証、アプリケーション内での利用を容易にします。

不十分なメタデータスキーマは、壊れた画像、欠落した特性、古いデータ、フィッシングリスク、ユーザーの混乱につながる可能性があります。

重要なフィールドには、

、、、、、プロジェクト固有のプロパティがあります。

IPFS、HTTPS、Arweave、オンチェーンデータなどのストレージ選択は、永続性、変更可能性、コスト、信頼に影響します。

特にリビール、動的NFT、ゲーム資産、認証情報、現実資産トークンでは、メタデータ更新を透明に行うべきです。

開発者はメタデータを検証し、耐久性のあるストレージを使用し、変更可能性を文書化し、更新イベントを発行し、一般的なWeb3ツールでテストすべきです。

ユーザーはコントラクトアドレスを確認し、不審なメタデータリンクを避け、ストレージリスクを理解し、メタデータを絶対的な証拠ではなく説明情報として扱うべきです。

暗号資産用語集において、Token Metadata Schemaは、暗号資産トークンに人が読める意味を与え、Web3エコシステムがトークン情報を一貫して安全に表示できるようにするデータ形式として理解すべきです。