# NFTとIPFSストレージ①

**Published by:** [John K](https://paragraph.com/@john-k/)
**Published on:** 2022-02-21
**URL:** https://paragraph.com/@john-k/nft-ipfs-2

## Content

NFTのことが怪しいとWeb2のブログ界隈で評判なので NFTとは何なのか？ について個人的にリサーチしました。 かなりコードベースで記載いただいていたのははてなブログの下記の投稿で ここを出発点にしたらわかりやすいと思いますのでここを出発点にします。 ソフトウェアエンジニアなら3秒で理解できる NFT 入門 記事を読み進めると OpenZeppelinのEIP-721 の実装においてはOwnerのアドレスにトークンを結びつける処理がされており ブロックチェーン上のアドレスにこのトークンが結び付けられていることが所有者の証明とされているということの様です。contract ERC721 is Context, ERC165, IERC721, IERC721Metadata { // Mapping from token ID to owner address mapping(uint256 => address) private _owners; function ownerOf(uint256 tokenId) public view virtual override returns (address) { address owner = _owners[tokenId]; require(owner != address(0), "ERC721: owner query for nonexistent token"); return owner; } ... } さらに読み進めていくと下記のようにURIかもしくはJson形式のメタデータをさすことでデータの場所を指定しているというものがOpenZeppelinでのNFTの実装の実態のようで、このURIを指定したTokenをOwnerのアドレスと紐づけることで NFTの所有が記録される仕様になっているようです。このように、実は NFT のメタデータはブロックチェーン上には記録されていない。代わりに、メタデータが置かれている外部の URI (tokenURI) を記録する。これは、コントラクトに書き込むデータ量が増えるほど「ガス代」が嵩むので、それを節約する目的がある。*5 この tokenURI は “ERC721 Metadata JSON Schema” に従う JSON を指してもよい (may) とされており、以下に示す name, description, image の三つのプロパティが定められている:{ "title": "Asset Metadata", "type": "object", "properties": { "name": { "type": "string", "description": "Identifies the asset to which this NFT represents" }, "description": { "type": "string", "description": "Describes the asset to which this NFT represents" }, "image": { "type": "string", "description": "A URI pointing to a resource with mime type image/* representing the asset to which 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." } } } おそらく多くの読者は下記の部分、機械可読な記述は標準化されてない点がNFTに対する不信の原因となるのではないでしょうか？これを見ると、意外なことに、EIP-721 では NFT を紐付けたデジタル作品を特定するための機械可読な記述は標準化されていないことが分かる。image がそうなんじゃないの？と思うかもしれないが、該当項目の説明に「幅 320〜1080 ピクセルで 1.91:1 か 4:5 の画像」と書かれている通り、これは明らかにサムネイルの URI を記述するためのものだ。*6 では、実際に流通している NFT は、どのように自身と作品と紐付けているのだろうか。これは、NFT を実際に発行・流通しているマーケットプレイスに依存するというのが実情のようだ。例えば、NFT オークションサイトの最大手 OpenSea では、自サービスで解釈できる独自の NFT メタデータ仕様を定めている。 これを見ると、高解像度の画像を「NFT 化」するには、external_url に作品の本体をホストするサイトへの URI を書き込んでマーケットプレイスから誘導するしかない。以下の図は OpenSea のドキュメントより引用（赤丸は筆者）:僕が一番ひっかかったのはこの点で 著者の方含めてWeb2界隈の読者の方はこのNFTのデータの保存先が分散ストレージになっているという認識がなく、 クラウドストレージやローカルに保存したファイルのURLが記入されていると認識されているのではないでしょうか？ OpenSeaのmetadata standardのページには下記のように記載されています。 IPFS and Arweave URIsOpenSea supports the storage of NFT metadata in decentralized file networks, so that they can’t be modified by a central party. If you use IPFS to host your metadata, your URL should be in the format ipfs://. For example, ipfs://QmTy8w65yBXgyfG2ZBg5TrfB2hPjrDQH3RCQFJGkARStJb. If you plan to store on IPFS, we recommend Pinata for easily storing data. Here's a tutorial by Chainlink for getting started: https://blog.chain.link/build-deploy-and-sell-your-own-dynamic-nft/. Arweave's equivalent is ar://. For example, ar://jK9sR4OrYvODj7PD3czIAyNJalub0-vdV_JAg1NqQ-o. 分散型のストレージであるArweave の IPFS上にデータを保存する仕組みについて解説されていますが クラウドストレージやローカルストレージに保存をするmetadataについての説明は見当たりません OpenSeaでは基本としてNFTは分散型ストレージに保存するというのが基本仕様とされているのだと思います。 NFTのデータの改ざんが容易かどうか、詐欺的なものであるかどうかはこのIPFSストレージの対改竄性にかかっていると思います。 多分続く

## Publication Information

- [John K](https://paragraph.com/@john-k/): Publication homepage
- [All Posts](https://paragraph.com/@john-k/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@john-k): Subscribe to updates