基于ERC721合约如何实现无重复随机唯一NFT铸造

你当前把随机选取TokenURI的逻辑放在前端DApp、试图在IPFS上标记已用URI的方案从底层逻辑上就行不通：

• IPFS是静态分布式文件存储，不支持动态写入状态，根本不可能实现已用标记的持久化全局同步
• 前端逻辑完全对用户透明，用户可以随意修改代码绕过随机规则、跳过重复校验，不仅没法保证URI唯一性，还会出现用户自选稀有NFT的作弊问题
  所有和NFT资产状态相关的校验、逻辑判断，必须放在链上合约层执行，才具备可信性。

方案1：常规顺序元数据方案（最省Gas，绝大多数NFT项目采用） #

这个方案不需要单独上传存全量TokenURI的文本文件，逻辑最简单：

• 提前把所有NFT的JSON元数据文件按0.json、1.json...{maxSupply-1}.json的序号命名，统一上传到IPFS同一个目录下，拿到该目录的根CID，比如ipfs://QmXYZ123/
• 在ERC721合约里硬编码或初始化设置三个核心变量：

  // 元数据目录基础URI
  string public baseURI;
  // NFT最大总供应量
  uint256 public maxSupply = 1000;
  // 当前剩余可铸造数量
  uint256 public remainingSupply = maxSupply;
  // 可抽取的tokenId池
  uint256[] public availableIds;
  

• 合约部署时初始化availableIds数组，元素依次为0到maxSupply-1的所有序号
• 用户触发铸造时，按以下逻辑执行：
  1. 校验remainingSupply > 0，防止超发
  2. 获取可信随机数（测试/小项目可用当前区块哈希取模，正式项目接入对应公链的VRF随机数预言机），对remainingSupply取模得到随机下标randIndex
  3. 取出availableIds[randIndex]作为本次铸造的tokenId，调用_mint()方法把NFT铸造给用户
  4. 把availableIds[randIndex]和数组最后一个有效元素availableIds[remainingSupply - 1]交换位置
  5. 将remainingSupply减1，被抽中过的tokenId就会被移到数组无效区域，后续永远不会被重复抽到
• 重写合约的tokenURI方法，直接拼接返回baseURI + tokenId + ".json"即可，不需要额外存储每个token对应的URI。

如果要做盲盒效果，只需要在铸造阶段把baseURI设置为统一占位元数据的CID，等铸造全部结束后再由权限地址替换为真实元数据的根CID即可，不需要提前暴露NFT属性。

方案2：全量URI链上存储方案（适合元数据无统一序号规则的场景） #

如果你已经上传完所有元数据、没法按序号重命名文件，可以直接用这个方案：

• 合约部署时把所有TokenURI字符串按数组形式存在链上的allTokenUris数组里
• 随机抽取、已用标记的逻辑和方案1完全一致，只是把抽取对象从tokenId换成数组里的URI，抽中后直接把对应URI和新铸造的tokenId绑定存储即可
• 缺点是字符串上链Gas成本更高，适合总供应量在1000以内的小体量项目。

方案3：默克尔树验证方案（适合万级以上大供应量项目） #

如果总供应量很大，全量URI存链上Gas成本过高，可以用默克尔树降低成本：

• 把所有TokenURI按固定顺序排列，生成默克尔树根存在合约里
• 随机抽取逻辑依然用链上ID池实现，抽中对应序号后，只需要把对应序号的URI和默克尔证明传到合约，验证通过后就可以把URI和tokenId绑定，不需要在合约里存全量URI数据，Gas成本能降低90%以上。

• 绝对不要把随机数生成、重复校验的逻辑放在前端，所有核心规则必须在合约层实现
• 不要直接用用户传入的参数作为tokenId或TokenURI，必须加合约侧的校验逻辑，防止用户恶意传入重复URI铸造
• 不要用纯前端生成的随机数作为铸造随机源，用户可以随意篡改随机结果选走稀有款NFT

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