如何为 NFT 收藏创建预披露机制

在推出新的 PFP  NFT 集合（la Bored Ape Yacht Club）时，为每个铸造的 NFT 使用占位符图像，并且仅在铸造所有 NFT 后才显示最终的 NFT，这已成为一种常见的做法。

这是一项重要的实践，因为没有它，狙击手可以根据通过元数据暴露的特征的稀有性来选择要铸造的 NFT。

在开始构建此功能之前，让我们扩展一下我们的业务需求：

• 隐藏tokens和元数据，直到所有tokens都被铸造

• 一旦用户铸造了tokens，就向他们发送一个“预披露”版本的tokens

• 允许合约所有者“揭示”集合中的所有tokens

我们的智能合约负责返回每个tokens metadata.json文件所在的 URL。

我们可以解决上述问题的方法是创建一个“pre-reveal”元数据文件并将其上传到某个地方（例如：https ://example.org/pre-reveal.json ）。这个“pre-reveal URI”是我们想要为每个tokens返回的，直到显示发生。

披露后，我们希望能够使用新 URL 更新智能合约，该 URL 可用于生成正确的tokens URI。

例如，如果我们已将所有代币上传https://exmaple.org/tokens/:tokenId到响应.baseURIhttps://example.org/tokens/tokenURIbaseURI

有了这些知识，我们可以将问题重新定义为对智能合约的更具体的要求：

• 当集合尚未显示时，它应该返回通用元数据

• 它应该允许合约所有者更新 baseURI

• 显示tokens时，它应该返回正确的元数据

我们如何实现它？

假设我们正在为 NFT 集合开发一个智能合约，该集合扩展了通常的 OpenZeppelinERC721实现。

如果你检查ERC721.sol合约，你会发现tokenURI那里实现了一个功能。

在这里，供你参考：

OpenZeppelin 对 tokenURI 的实现

它们的实现（上图）将自动连接基本 URI（返回自_baseURI()——我们稍后需要记住）与正在检索的tokens ID。

这对于 AFTER 显示非常有用——但对于 pre-reveal，我们需要重写此函数以返回我们的 pre-reveal URI：

tokenURI 函数

你会注意到我们引用了几个全局变量：_isRevealed和_preRevealURI. 你可以随心所欲地实现这些，但最简单的是，你可以简单地在合同顶部定义它们：

接下来，我们需要创建一个函数来“显示”tokens。

上面的reveal函数会将传递的baseURI保存到一个名为的全局变量_postRevealBaseURI中，并将_isRevealed布尔值设置为true.

我们几乎完成了，将_isRevealed布尔值设置为true，然后tokenURI我们之前编写的函数将推迟到父类的实现。

如果你还记得，这个实现调用一个_baseURI函数来检索基本 URI。

如果我们检查该实现，我们可以看到它实际上可以被覆盖：

让我们强制 OpenZeppelin 并重写该_baseURI函数以返回正确的基本 URI！

结论

你已经学习了一种简单、安全且有效的方法来实现 NFT 预揭示机制。