本提案はドラフト段階です。議論や意見を広く歓迎します。
本文書では、Monaparty上で発行されるアセットのdescriptionを利用したメタデータ規格について提案する。 この提案ではアセットと画像データを紐付け、表示するための規格を提供する。
本提案では画像データの永続性、信頼性等を確保する方法については言及しない。
NFTアートの人気に見られるように、画像と紐付くトークンはトークンプラットフォームにおける重要な存在である。しかし現在Monapartyには、自由な大きさの画像データをトークンに紐付けられる規格が存在しない。自由なメタデータを持たせる仕組みとしてはXMPIP-0019が計画されているが、現時点では実装されていない。
一方、Monacardはアセットのdescription欄にJSONを記載するという方法でメタデータを記録した。この方法だと発行時のトランザクションのサイズが肥大化することになるが、現状のMonacoinの手数料水準では問題ないと考えられる。 そこで、同手法を用いてMonapartyアセットに自由な画像を紐付ける規格を提案する。
本文書中のキーワードMUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL
はRFC 2119に沿って解釈される。
本規格に準拠するアセットは、以下のJSON Schemaに準拠したJSONをアセットのdescriptionとして記載しなくてはならない (MUST) 。JSONには本規格にはないプロパティを記載してもよい (MAY)。
アセットのdescriptionにはJSONとして解析できない文字列を記載してはならない (MUST NOT) 。
{
"type": "object",
"properties": {
"image": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"desc": {
"type": "string"
},
"cid": {
"type": "string"
}
},
"required": [
"name",
"cid"
]
}
},
"required": [
"image"
]
}
{
"image": {
"name": "モナコインちゃん",
"desc": "モナコインちゃんのNFTです。",
"cid": "bafkreifzjut3te2nhyekklss27nh3k72ysco7y32koao5eei66wof36n5e",
}
}
アセットを識別する名前。
アセットの説明文。この項目は省略してもよい。 (OPTIONAL)
アセットと紐付く画像ファイルのIPFS上のcid。バージョンはv1を使用したほうがよい (SHOULD)。
画像ファイルのMIME typeはimage/*
でなければならない (MUST)。image/png
, image/apng
, image/jpeg
, image/gif
形式を使用した方がよい (SHOULD)。それ以外の形式の場合、アプリケーションは表示を拒否してもよい (MAY)。
画像のサイズは短辺を300px以上、かつ長辺を1920px以下にしたほうがよい (SHOULD)。
本規格では画像の保存先をIPFSに限定している。これは、IPFSには次の利点があるためである。
- 分散型システムであるため、一つのサーバ/個人/企業に依存する必要がない。
- データの保持にはpinningが必要だが、これはアセットの発行者だけではなく誰でも行うことができる。
- IPFSのハッシュ値はファイルに依存しているため、オフチェーンで画像データを書き換えることは不可能である。
- 一度IPFS上からデータが失われたとしても、元のファイルがあれば再アップロードすることで再度アセットと画像の紐付けを証明できる。
本規格は一般的な画像ファイルを想定しているため、MIME typeをimage/*
に限定した。また、image/png
, image/gif
, image/jpeg
はインターネット上で広く使われており、image/apng
は高画質のアニメーションに対応した形式の中で多くの環境に対応しているため、これらを推奨する形式とした。
本規格では画像の保存先をIPFS上に限定しているが、IPFS上のファイルは適切にpinningされない限り消滅してしまうリスクが高い。
もっとも、EthereumなどのNFTでも共通する問題であり、IPFS以外に保存した場合でも発生しうるリスクではある。
SVGファイルにはJavascriptを埋め込むことができ、ウォレット等が提供するサーバで画像をキャッシュしてから表示する場合、XSSが発生するリスクがある。 また、IPFS Gatewayへの直接リンクを開いた場合に任意のスクリプトが実行されるリスクがある。
本規格に沿った実装をする場合は「svg形式の画像を不用意に同一URLから提供しない」「svg形式の画像を表示しない」「ユーザに注意喚起する」などの対応をする必要があると考えられる。
参考: SVGを利用したXSS - WESEEK Tips wiki
現在、アセットのdescriptionはownerならいつでも書き換えることができる。 書き換えた履歴はissuanceとしてチェーン上に残るが、単純な実装ではこれを検知できず、持っているアセットの画像データが書き換えられる可能性がある。 これを防ぐためには、以下のような対策が考えられる。
- issuerは価値の証明のため、事前に所有権をBurnアドレス(
MMonapartyMMMMMMMMMMMMMMMMMMMUzGgh
など)にtransferしておく。 - 画像データを参照する際にアセットのissuanceの履歴を検索し、description内の
image
が書き換えられていないかを確認する。
本文書はCC0でライセンスされる。
概要を追加。この提案が扱うスコープを明示した。