🐶原文： Preventing Content Cloning in NFT Collections

🐶写在前面： 这是一篇 2023 年的 CCF-C 类，本博客只记录其中提出的方法。

${\mathbf{F}}_{\mathbf{CollNFT}}$ and ERC-721 NFTs

在以太坊这样的区块链上，NFT 是通过实现 ERC-721 标准的智能合约创建和交易的。

智能合约可以执行的主要操作有：

• 铸币 $\mathsf{mint}$：创建一个新的代币并将其分配给发行者；
• 转账 $\mathsf{transfer}$：从当前所有者那里转移一个代币到一个指定的账户；

只有当发出交易的账户是智能合约的部署者时，铸币 $\mathsf{mint}$ 操作才会成功。只有当发出交易的账户是 NFT 的当前所有者，或者是被所有者委托过的账户时，转账 $\mathsf{transfer}$ 操作才会成功。

因此，ERC-721 符合 $P1$ 和 $P2$。

ERC-721 智能合约通过在智能合约实例的状态内维护一个键值对映射来追踪所生成的代币。当代币 $\mathsf{t}$ 属于某个集合时，在该集合中 $t.id$ 是键值对的键，$(t.owner,t.data)$ 是键值对的值。然而，ERC-721 标准并没有阻止映射中存在两个不同的键 $t.id$ 和 ${\mathsf{t}}^{\prime }.id$，但是关联到相同的数据 $t.data={\mathsf{t}}^{\prime }.data$。

由此可见，ERC-721 智能合约通常不能安全地实现 ${\mathsf{F}}_{\mathsf{CollNFT}}$ 功能，因为 $P3$ 可能无法得到保证。因此，我们提出了一种不同的实现 ERC-721 智能合约的两步方法。

首先，我们要求 $t.id=sha256(t.data)$。然后，如果键尚未存在于键值对映射中，那么新创建的代币可以成功地添加到映射中。基于这一机制，调用 mint 函数创建一个克隆品 ${\mathsf{t}}^{\prime }$ 将会失败，因为 ${\mathsf{t}}^{\prime }.id$ 已经存在于映射中。这保证了集合中数据的唯一性 $P3$，且仍处于 ERC-721 合约的要求之内。

Discussion on the Implementation of ${\mathbf{F}}_{\mathbf{CollNFT}}$

这一小节探讨了如何具体实现与 ${\mathsf{F}}_{\mathsf{CollNFT}}$ 兼容的一组图像。

图像可以根据不同的编码方案表示。最常用的方案之一是 RGB 颜色模型，这是一个加色模型，其中红、绿和蓝三种光的原色以各种方式相加，以重现广泛的颜色。具体来说，图像中的每个像素都用一个表示红、黄和蓝分量的三个值的元组来表示。因此，一个 RGB 图像是一个宽度为 $\mathsf{M}$ 像素、高度为 $\mathsf{N}$ 像素的矩阵，每个单元格有 $3$ 个值。

作为一个玩具示例，我们考虑一个宽度为 $16$ 像素、高度为 $9$ 像素的图像集合，其中每个颜色分量的值可以设置在 $0$ 到 $255$ 之间。因此，每个图像是一个维度为 $16\times 9\times 3=432$ 的字节数组。

每个图像都与一个记录了创建时间的元数据相关联，该时间使用 $\mathsf{UNIX}$ 时间戳表示，可以用 $4$ 字节的无符号整数表示。总的来说，这个集合中的每个收藏品 $\mathsf{c}$ 都将包含一个 $432$ 字节的 $c.artwork$ 图像和 $4$ 字节的 $c.meta$。

为了获得符合 ${\mathsf{F}}_{\mathsf{CollNFT}}$ 标准的集合，我们直接将 $\mathsf{c}$ 上传到智能合约中，这将强制图像遵守 RGB 格式，即验证对于 $\mathsf{M}\times \mathsf{N}$ 矩阵的每个单元格都有三个值在 $[0,255]$ 的区间内，并且有指定的尺寸。然后，智能合约设置 $t.data=\mathsf{c}$，计算 $\mathsf{c}$ 的哈希值，并将其作为 $t.id$ 的值。

这种方法的局限性在于它需要将 $\mathsf{c}$ 完整上传。在我们的示例中，即使 $c.artwork$ 很小，但我们仍然需要 $432$ 字节来表示它。

请注意，微小的 NFT 也是存在的，甚至还有人提出的单比特 NFT 。

参见：https://foundation.app/@aaa/foundation/42796

然而，图像通常具有更大的尺寸，宽度和高度达到数千像素。因此，图像在许多区块链中不能上链，即使可能的话，大文件也会影响交易费用。以下是解决这一问题的可能的方案。

1 方案一

一种常见的做法是依赖于在 IPFS 上上传收藏品 $\mathsf{c}$，IPFS 是一个点对点网络，用于通过计算在它们内容上的信息（即文件的 $sha256$）来共享文件。在代币 $\mathsf{t}$ 上，我们设置

$$t.id=t.data=\mathsf{add}{\mathsf{r}}_{\mathsf{IPFS}}=sha256(\mathsf{c})$$

然而，这并不能防止恶意铸币者铸造一个新的代币 ${\mathsf{t}}^{\prime }$：

$${\mathsf{t}}^{\prime }.id={\mathsf{t}}^{\prime }.data=\mathsf{add}{\mathsf{r}}_{\mathsf{IPFS}}^{\prime }=sha256({\mathsf{c}}^{\prime })$$

其中，${\mathsf{c}}^{\prime }.artwork=c.artwork$ 和 ${\mathsf{c}}^{\prime }.meta\ne c.meta$。换句话说，数字艺术品 ${\mathsf{c}}^{\prime }.artwork$ 和 $c.artwork$ 相同，而关于它们的描述 ${\mathsf{c}}^{\prime }.meta$ 和 $c.meta$ 不同。在 $c.meta$ 不必要的上下文中，可以通过设计删除它，使得这种攻击无法执行。

简而言之，$\mathsf{c}$ 包含 $c.artwork$ 和 $c.meta$ 这两部分。只要 $c.meta$ 不同，那么都有 $\mathsf{c}\ne {\mathsf{c}}^{\prime }$。因此，这可能会掩盖 $c.artwork$ 和 ${\mathsf{c}}^{\prime }.artwork$ 相同的事实，即数字艺术品惨遭克隆。

2 方案二

可以合理地假设数字资产在其生成时由其创作者 $\mathsf{creator}$ 签名，以保证其起源的真实性。

资产创作者 $\mathsf{creator}$ 通过密码学对资产进行签名，生成 $\sigma$。我们可以设置 $t.id=\sigma$，以保持代币的独特性，因为尝试添加相同创作者 $\mathsf{creator}$ 的相同 $t.data$ 将会产生相同的 $\sigma$。

那让另一个创作者 $\mathsf{creator}$ 使用相同 $t.data$ 就不会有问题了？

然而，创作者始终可能被攻陷，例如：攻击者窃取秘密密钥来产生 $\sigma$。如方案一所述，攻击者将能够产生克隆体，即改变 $c.meta$ 后再次进行签名。

3 方案三

铸币 $\mathsf{mint}$ 交易可以携带一个证明，证明 $t.id$ 的简洁值是资产 $c.artwork$ 的密码学哈希。这可以通过简洁的非交互式知识论证 $\mathsf{SNARKs}$ 来实现。

在我们的案例中，铸币者需要上传一个密码学哈希 $\mathsf{s}$（将作为 $t.id$）和一个 $\mathsf{SNARK}\pi$，证明对 $c.artwork$ 的知识，其中：

$$\mathsf{s}=sha256(c.artwork)$$

且 $c.artwork$ 是一张使用 RGB 颜色模型的图片。

约束约束 $\pi =sha256(\mathsf{c})$ 避免了恶意铸币者随意设置 $c.meta$，正如方案一中讨论过的情况一样。智能合约验证 $\pi$ 是否正确，然后设置：

$$t.id=t.data=sha256(c.artwork)$$

以确保 $t.data$ 在集合中的独特性。

使用 $\mathsf{SNARKs}$ 来证明 $sha256$ 的抗图像的效率过于低效，但实际上可以考虑使用其他密码学哈希函数，如 $\mathsf{Poseidon}$，这些函数旨在允许更高效地实例化证明此类声明的 $\mathsf{SNARKs}$。