使用CID为文件夹哈希的baseURI实现NFT随机性的可选方案问询

现有两类常见方案：1. 开售前设置baseURI：该模式下用户可提前知晓自己将获得的NFT内容；2. 售卖结束后设置baseURI：该模式下用户无法提前预知将获得的NFT内容，但用户完成铸币后无法立刻查询到所获NFT的具体类型。

除上述两种基础方案外，目前行业内已经有两类成熟的可落地方案，兼顾了随机性、透明性与用户体验：

Commit-Reveal 双阶段校验方案 #

这是目前头部NFT项目使用最广泛的方案，核心逻辑是通过前置哈希存证避免项目方作弊，同时控制内容公开时机：

• 前置存证阶段：开售前项目方将包含全量NFT元数据的文件夹CID、自定义随机盐组合后生成哈希值，将哈希值keccak256(abi.encodePacked(baseCID, salt))提前上链固化，全程不公开原始CID和盐值，避免用户提前反推全量NFT内容。
• 铸币阶段：用户付费铸币时直接分配唯一TokenID，链上实时记录用户地址与TokenID的绑定关系，无需等待全量NFT售罄。
• 公开 Reveal 阶段：项目方在提前公示的时间节点（可设置为开售结束后固定时长，或全量铸币完成后立即）将原始baseCID和盐值同步上链，合约自动校验二者生成的哈希是否与前置存证的哈希一致，校验通过后自动生效baseURI，用户可实时查询对应TokenID的NFT内容。
• 方案优势：完全规避项目方事后篡改NFT元数据的风险，既不会出现用户提前预知内容的问题，也不会让用户等待过长时间才能查询结果，时间节点可提前公示，透明度更高。

单文件存证+铸币时随机映射方案 #

该方案不需要依赖统一的文件夹baseURI，适合对即时查询需求较高的场景：

• 前置存证阶段：项目方提前将所有NFT的元数据拆分为独立单文件分别上传IPFS，得到每个元数据对应的唯一CID，再将所有CID生成默克尔根上链存证，全程不公开CID与TokenID的对应关系。
• 铸币阶段：用户铸币时，合约直接调用当次交易的区块哈希、用户钱包地址、TokenID三个参数生成随机数，用该随机数映射到未被分配的元数据CID，直接将CID与TokenID的绑定关系写入链上合约。
• 查询阶段：用户铸币完成即可通过绑定的CID直接访问NFT元数据，无需等待全量售罄或统一Reveal。
• 方案优势：随机数在铸币时才生成，完全杜绝用户提前预知内容的可能，也不会出现铸币后等待查询的空窗期，所有元数据提前通过默克尔根存证，项目方无法事后篡改内容。

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