はじめに
初めまして。 CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！ スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。
代表的なゲームはクリプトスペルズというブロックチェーンゲームです。
今回は、複数メタバースに対応できるメタデータの追加フィールドの提案をしているERC4955についてまとめていきます！
以下にまとめられているものをChatGPTも使用しながら、翻訳・要約・補足してまとめていきます。
ERC721については以下を参考にしてください。
概要
このEIP（Ethereum Improvement Proposal）では、ERC721およびERC1155と呼ばれるEthereumのNFT（非代替トークン）の標準に、新しいフィールド名前空間を追加することを目的としています。
動機
NFTのメタデータを標準化することで、ウォレット、マーケットプレイス、メタバースなどのアプリケーションがどのNFTでも相互運用できるようになることが挙げられます。 つまり、異なるプラットフォームやアプリケーション間でNFTをシームレスに扱うことが可能になります。 例えば、NFTのマーケットプレイスやメタバースのアプリケーションは、カスタムの3D表現や新しい属性を使ってNFTを表示することができるようになります。
さらに、Decentraland、TheSandbox、Cryptoavatarsなどのプロジェクトは、独自の3Dモデルを使用してNFTを表現する必要があります。 しかし、これらのモデルは異なる美学やデータ形式を持っているため、現在の状況では互換性がありません。 このEIPの導入により、これらのプロジェクトも新しいフィールド名前空間を活用して、NFTをより豊かに表現できるようになるでしょう。
このような標準化により、さまざまなNFTの利用がより効果的になり、ユーザーにとってより魅力的な体験が提供されることが期待されています。
仕様
スキーマ
namespacesという新しいプロパティが導入されました。
このプロパティは、以下の例に示すように、1つのプロジェクトにつき1つのオブジェクトを想定しています。
{
"title": "Asset Metadata",
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "Identifies the asset that this NFT represents"
},
"description": {
"type": "string",
"description": "Describes the asset that this NFT represents"
},
"image": {
"type": "string",
"description": "A URI pointing to a resource with mime type image/* representing the asset that this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive."
},
"namespaces": {
"type": "object",
"description": "Application-specific NFT properties"
}
}
}具体的なプロパティの内容は以下になります。
title- オブジェクトのタイトル。
type- このオブジェクトがJSONオブジェクトであることを示す。
properties- このオブジェクトのプロパティを定義。
name- 文字列型のプロパティで、このNFTが表現するアセットを識別する。
- つまり、NFTが何を表しているかを示す名前を格納。
description- 文字列型のプロパティで、このNFTが表現するアセットについての詳細な説明を格納。
image- 文字列型のプロパティで、このNFTが表現するアセットを示すリソースへのURIを格納。
mimeタイプはimage/*として指定。- これにより、NFTが表現するアセットを画像で表すことができる。
- ただし、推奨される画像の幅は
320ピクセルから1080ピクセルの間で、アスペクト比は1.91:1から4:5までの範囲内とする。
namespaces- オブジェクト型のプロパティで、アプリケーション固有のNFTプロパティを格納。
- 各プロジェクトが必要な追加情報をこのプロパティに含めることができる。
これにより、NFTのメタデータに対してアプリケーション固有の情報を追加することが可能となります。
各プロジェクトは、namespacesプロパティを使用して、カスタムのNFTプロパティを定義し、それに基づいてNFTをより豊かに表現できるようになります。
サンプル
{
"name": "My NFT",
"description": "NFT description",
"image": "ipfs://QmZfmRZHuawJDtDVMaEaPWfgWFV9iXoS9SzLvwX76wm6pa",
"namespaces": {
"myAwesomeCompany": {
"prop1": "value1",
"prop2": "value2",
},
"myAwesomeCompany2": {
"prop3": "value3",
"prop4": "value4",
},
}
}
// Or by simply using a `URI` to reduce the size of the JSON response.
{
"name": "My NFT",
"description": "NFT description",
"image": "ipfs://QmZfmRZHuawJDtDVMaEaPWfgWFV9iXoS9SzLvwX76wm6pa",
"namespaces": {
"myAwesomeCompany": "URI",
"myAwesomeCompany2": "URI",
}
}補足
NFTをレンダリングするプロジェクト間には異なる要件や美学が存在していることが述べられています。 特に、DecentralandやTheSandboxのようなメタバースでは、独自のビジョンやエンジンを持っており、これに基づいてNFTをレンダリングする必要があります。 それぞれのメタバースは、アーマチュアと呼ばれるモデルの骨格構造についても異なる設計を持っています。 ただし、人型に対する標準は存在しますが、すべてのメタバースがこの標準を使用しているわけではありません。
このような差異があるため、各メタバースは自身の要件に合わせた独自のNFTのレンダリングを行うことが重要です。
例えば、Decentralandの美学はCryptovoxelsやTheSandboxとは異なるため、同じ3Dモデルであってもこれらのメタバースで適切に表示されるように設計する必要があります。
また、各メタバースが異なるアーマチュアを使用しているため、同じ拡張子（例：GLB、GLTF）を持つ3Dモデルでも、それに合わせた差異を考慮する必要があります。
アーマチュア
これらの要件を満たすために、NFTプロジェクトは自身のメタバースに合った独自の3Dモデルやアセット情報を作成する必要があります。 CryptopunksやBored Apesなどの一部のNFTプロジェクトは、各メタバースに対応した3Dモデルを直接サポートすることで、異なるプロジェクト間でのレンダリングを容易にしています。
結果として、各プロジェクトが自身の個性や目的に合わせたNFTの表示を実現し、利用者により豊かな体験を提供できるようになります。 このようなカスタムのプロパティとアーマチュアにより、NFTがさまざまなプロジェクトやメタバースで効果的に活用され、創造性豊かな表現が可能となります。
引用: メタデータ（表現ファイル）
たとえば、すべてのメタバースは、そのゲームのニーズに応じてエンジン内で動作するように、独自のメタデータ表現ファイルを使用します。
以下はDecentralandのウェアラブルアイテムのJSONです。
"data": {
"replaces": [],
"hides": [],
"tags": [],
"category": "upper_body",
"representations": [
{
"bodyShapes": [
"urn:decentraland:off-chain:base-avatars:BaseMale"
],
"mainFile": "male/Look6_Tshirt_A.glb",
"contents": [
{
"key": "male/Look6_Tshirt_A.glb",
"url": "https://peer-ec2.decentraland.org/content/contents/QmX3yMhmx4AvGmyF3CM5ycSQB4F99zXh9rL5GvdxTTcoCR"
}
],
"overrideHides": [],
"overrideReplaces": []
},
{
"bodyShapes": [
"urn:decentraland:off-chain:base-avatars:BaseFemale"
],
"mainFile": "female/Look6_Tshirt_B (1).glb",
"contents": [
{
"key": "female/Look6_Tshirt_B (1).glb",
"url": "https://peer-ec2.decentraland.org/content/contents/QmcgddP4L8CEKfpJ4cSZhswKownnYnpwEP4eYgTxmFdav8"
}
],
"overrideHides": [],
"overrideReplaces": []
}
]
},
"image": "https://peer-ec2.decentraland.org/content/contents/QmPnzQZWAMP4Grnq6phVteLzHeNxdmbRhKuFKqhHyVMqrK",
"thumbnail": "https://peer-ec2.decentraland.org/content/contents/QmcnBFjhyFShGo9gWk2ETbMRDudiX7yjn282djYCAjoMuL",
"metrics": {
"triangles": 3400,
"materials": 2,
"textures": 2,
"meshes": 2,
"bodies": 2,
"entities": 1
}上記のウェアラブルアイテムのメタデータには、以下のような情報が含まれています：
replaceshidestagscategoryrepresentationsimagethumbnailmetrics
representations内の各要素には、異なる体型やアセットのバリエーションに応じた情報が含まれています。
また、replaces、overrides、hidesなど異なるボディシェイプのレンダリングが正しく行われるために必要な情報も含まれています。
これにより、Decentralandなどのメタバースで3Dアセットを正しく表示するために必要な設定が含まれています。
また、これまでのメタデータ表現方法では、アセットがどのようにレンダリングされるかについてのスタイル情報が存在せず、それぞれのメタバースが独自のアーマチュアや美学を使用しているため、特定のスタイルの標準は存在しません。
したがって、styleフィールドのような情報は含まれていません。
そこで、ERC721のメタデータスキーマを拡張することで、互換性を保ちつつ、各プロジェクトが自身のNFTのレンダリングに必要な情報をnamespacesという仕組みで提供できるようにしています。
namespacesを使用することで、特定のベンダーやサードパーティが必要なモデルにアクセスし、索引化することが容易になります。
具体的には、namespacesはアプリケーション固有のNFTプロパティを格納するためのオブジェクトであり、各プロジェクトが独自のNFT情報をこのフィールドに含めることができます。
これにより、NFTのメタデータに必要な追加情報を提供することができます。
例えば、特定のベンダーやサードパーティがDecentralandでレンダリングするための3Dモデルを必要とする場合を考えてみましょう。
この場合、ベンダーやサードパーティはNFTのメタデータを取得し、その中のnamespacesフィールドを調べることで、自身が必要とするプロジェクト（例：Decentraland）に関連する情報を見つけることができます。
具体的なステップとしては、以下のようになります。
- ベンダーやサードパーティはNFTのメタデータを取得します。
- メタデータの中に含まれる
namespacesフィールドを調べます。 namespacesフィールド内には、さまざまなプロジェクトのための情報が含まれている可能性があります。- ベンダーやサードパーティが必要とする特定のプロジェクト（例：Decentraland）に関連する情報を見つけます。
- 必要な3DモデルのURIや他のアセット情報を
namespacesから取得し、それに基づいてNFTをレンダリングする準備を行います。
このようにして、namespacesを使用することで、特定のベンダーやサードパーティが必要なプロジェクトに関連する情報に簡単にアクセスできるようになります。
各プロジェクトは自身の独自の情報をnamespacesに含めることで、他のプロジェクトとの相互運用性を高め、さまざまなアプリケーションやメタバースにおいてNFTをより効果的に利用できるようになります。
ERC721の既存のメタデータフィールドを利用することで、既存のコントラクトを変更せずに新しい仕組みを導入することができます。 これにより、コントラクトの再デプロイや変更を行う必要がなくなり、時間とコストを節約することができます。 また、JSONメタデータには既に画像を保存するためのフィールドが存在しているため、すべてのアセットのレンダリング情報を同じ場所にまとめることが合理的だと述べられています。
後方互換性
既存のプロジェクトは、メタデータの応答（スキーマ）を変更できない場合でも、新しいスマートコントラクトを作成することで、tokenIdに基づいて更新されたメタデータスキーマを返すことができるかもしれません。
もちろん、他のプロジェクトはこれらのリンクされたスマートコントラクトを有効として受け入れる必要があるかもしれません。
これにより、tokenIdによって異なるメタデータスキーマを返すことができます。
セキュリティに関する考慮事項
ERC721と同様のセキュリティに関する考慮事項が、tokenURIメソッドのhttpゲートウェイまたはIPFSを使用する場合に適用されます。
これらの手法を使用する際には、適切なセキュリティ対策を講じる必要があります。
例えば、httpsプロトコルを使用することや、IPFS上のデータの信頼性を確保するための適切な署名やハッシュを検証する必要があります。
セキュリティの確保はNFTのエコシステムにおいて非常に重要な要素であり、ユーザーの資産を守るために十分な注意が必要です。 特にNFTのメタデータは、アセットの所有権を証明するための重要な情報を含んでいる場合がありますので、安全性に配慮した設計が必要とされます。 したがって、ERC721の実装や拡張に際しては、セキュリティに関する最新のベストプラクティスを遵守することが重要です。
引用
Ignacio Mazzara (@nachomazzara), "ERC-4955: Vendor Metadata Extension for NFTs," Ethereum Improvement Proposals, no. 4955, March 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-4955.
考察
複数のメタバースにおいて使用できるNFTは面白いなと思いました。 1つのメタバースにのみ対応しているより、複数のメタバースに対応している方が使用するユーザーにとっては嬉しいですし、ワクワク感も上がります。 お気に入りのNFTをあっちのメタバースでも、こっちのメタバースでも使用できるとなると夢が広がります。 ただ、果たしてユーザーは複数のメタバースを使用しているのかどうかは疑問が残ります。 そのため、どちらかというと「このNFTはいろんなメタバースに対応しているから好きなメタバースで使ってね」という使われ方なのかなと思いました。 確かに対応メタバースが多いと、NFTを購入したいユーザー数の母数も増えそうです。
最後に
今回は「複数メタバースに対応できるメタデータの追加フィールドの提案をしているERC4955」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
採用強化中！
CryptoGamesでは一緒に働く仲間を大募集中です。
この記事で書いた自分の経験からもわかるように、裁量権を持って働くことができて一気に成長できる環境です。 「ブロックチェーンやWeb3、NFTに興味がある」、「スマートコントラクトの開発に携わりたい」など、少しでも興味を持っている方はまずはお話ししましょう！ ぜひTwitterのDMか上記Wantedlyから連絡ください！