palon7/gist:7c08c52219f7779f3fdb74a6744a9be2

## gistfile1.md

      
    Raw
  

              gistfile1.md
            
          
    Monaparty上の画像NFT規格に関する提案

注意

本提案はドラフト段階です。議論や意見を広く歓迎します。
概要

本文書では、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)  。
JSON Schema

{
  "type": "object",
  "properties": {
    "image": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string"
        },
        "desc": {
          "type": "string"
        },
        "cid": {
          "type": "string"
        }
      },
      "required": [
        "name",
        "cid"
      ]
    }
  },
  "required": [
    "image"
  ]
}
実際のJSONの例

{
  "image": {
    "name": "モナコインちゃん",
    "desc": "モナコインちゃんのNFTです。",
    "cid": "bafkreifzjut3te2nhyekklss27nh3k72ysco7y32koao5eei66wof36n5e",
  }
}
name

アセットを識別する名前。
desc

アセットの説明文。この項目は省略してもよい。 (OPTIONAL)
cid

アセットと紐付く画像ファイルのIPFS上のcid。バージョンはv1を使用したほうがよい (SHOULD)。
画像ファイルのMIME typeはimage/*でなければならない (MUST)。image/png, image/apng, image/jpeg, image/gif形式を使用した方がよい (SHOULD)。それ以外の形式の場合、アプリケーションは表示を拒否してもよい (MAY)。
画像のサイズは短辺を300px以上、かつ長辺を1920px以下にしたほうがよい (SHOULD)。
理論的根拠

IPFS

本規格では画像の保存先をIPFSに限定している。これは、IPFSには次の利点があるためである。

分散型システムであるため、一つのサーバ/個人/企業に依存する必要がない。
データの保持にはpinningが必要だが、これはアセットの発行者だけではなく誰でも行うことができる。
IPFSのハッシュ値はファイルに依存しているため、オフチェーンで画像データを書き換えることは不可能である。
一度IPFS上からデータが失われたとしても、元のファイルがあれば再アップロードすることで再度アセットと画像の紐付けを証明できる。

画像のファイル形式

本規格は一般的な画像ファイルを想定しているため、MIME typeをimage/*に限定した。また、image/png, image/gif, image/jpegはインターネット上で広く使われており、image/apngは高画質のアニメーションに対応した形式の中で多くの環境に対応しているため、これらを推奨する形式とした。
懸念点

IPFS上のファイルの消失リスク

本規格では画像の保存先をIPFS上に限定しているが、IPFS上のファイルは適切にpinningされない限り消滅してしまうリスクが高い。
もっとも、EthereumなどのNFTでも共通する問題であり、IPFS以外に保存した場合でも発生しうるリスクではある。
細工された画像ファイルによるリスク

SVGファイルにはJavascriptを埋め込むことができ、ウォレット等が提供するサーバで画像をキャッシュしてから表示する場合、XSSが発生するリスクがある。
また、IPFS Gatewayへの直接リンクを開いた場合に任意のスクリプトが実行されるリスクがある。
本規格に沿った実装をする場合は「svg形式の画像を不用意に同一URLから提供しない」「svg形式の画像を表示しない」「ユーザに注意喚起する」などの対応をする必要があると考えられる。
参考: SVGを利用したXSS - WESEEK Tips wiki
descriptionの書き換えリスク

現在、アセットのdescriptionはownerならいつでも書き換えることができる。
書き換えた履歴はissuanceとしてチェーン上に残るが、単純な実装ではこれを検知できず、持っているアセットの画像データが書き換えられる可能性がある。
これを防ぐためには、以下のような対策が考えられる。

issuerは価値の証明のため、事前に所有権をBurnアドレス（MMonapartyMMMMMMMMMMMMMMMMMMMUzGghなど）にtransferしておく。
画像データを参照する際にアセットのissuanceの履歴を検索し、description内のimageが書き換えられていないかを確認する。

著作権

本文書はCC0でライセンスされる。