如何在ERC721合约中存储每个NFT对应的图片资源？

行业通用标准实现方案 #

对于数千张规模的图片类ERC721 NFT项目，行业通用的实现完全不会选择将像素字节直接存入合约，具体方案如下：

• 遵循ERC721标准中的tokenURI接口设计：链上仅存储tokenID与资源标识符的映射关系，完整的图片文件、属性元数据全部存储在链下存储层，大幅降低链上gas成本，提升可扩展性。
• 链下存储分为两类主流选型：
  • 分布式存储：目前应用最广的是IPFS类的内容寻址存储，资源的访问标识符是基于内容本身生成的哈希，只要网络中存在任意节点存储该资源，就可以永久访问，不存在中心化服务下线的问题。
  • 中心化云存储：部分前期预算有限、需要更快访问速度的项目会选择云服务器存储，但普遍会同步做分布式存储备份规避风险。
• 仅极小部分主打「完全链上」定位的NFT项目会选择将图片编码为SVG格式后直接写入合约，这类方案仅适配小体积、低复杂度的图片，千级以上高清图片的链上存储成本会达到不可接受的程度。

CryptoKitties的存储逻辑 #

CryptoKitties并没有将完整的猫咪图片字节存储在合约中，它的实现逻辑非常典型：

• 链上仅存储每只NFT对应的基因序列数据，以及标准的tokenURI接口。
• 图片可以通过两种方式生成：一种是前端读取链上基因序列后，按照预设的规则实时渲染生成对应的猫咪图片；另一种是通过URI指向中心化服务预先生成的图片资源。
• 这套设计的核心是：NFT的核心资产是链上不可篡改的基因序列和映射规则，图片只是资产的可视化产物，不需要上链存储。

URI失效问题的解决方案 #

你提到的URI失效确实是中心化存储方案的核心缺陷，目前行业已经有非常成熟的规避方案：

• 替换中心化HTTP URI为分布式内容寻址标识符：将资源上传到分布式存储网络后，获取到的CID是基于内容生成的唯一哈希，你可以直接将CID和tokenID的映射关系写入合约，只要资源本身没有被修改，CID就不会变化，不存在因为服务器下线导致资源丢失的问题。
• 多节点冗余备份：不少项目会同时将资源备份到多个分布式存储网络、多个中心化云服务商处，进一步降低资源丢失的概率。
• 完全链上存储：如果项目定位就是完全不可篡改、永久存在，且NFT资源体积足够小，可以选择将所有资源（SVG图片、元数据）全部写入合约，完全不存在资源失效问题，但仅适合小规模NFT集合使用。

内容的提问来源于stack exchange，提问作者PedroD