区块链 | IPFS 相关论文：Dude, where is my NFT: distributed infrastructures for digital art

目录

4  聚焦：在 IPFS 上的存储

4.1  背景知识

4.1.1  数据的下载

4.1.2  数据的添加

4.1.3  数据的检索

4.1.4  数据的请求

4.2  实证研究

4.2.1  CID 编码

4.2.2  数据可用性

---

🦊原文：Dude, where's my NFT: distributed infrastructures for digital art

🦊写在前面：原论文对 NFT 市场的各种模式都进行了调查，只有第四节主要讲采用 IPFS 进行数据存储的市场。本博客主要学习原论文对 IPFS 的原理介绍。

4  聚焦：在 IPFS 上的存储

在以下内容中，我们将详细地检查存储在 IPFS 上的数据。

目前，IPFS 是 NFT 最受欢迎的分布式存储系统，如下表所示：

除开直接在链上存储 (412) 的情况，IPFS (254) 就是最受欢迎的。

此外，我们还利用现有的方法和工具来收集有关存储位置和 IPFS 网络内数据分布的详细信息。

4.1  背景知识

IPFS（InterPlanetary File System，星际文件系统）是一种流行的点对点（P2P）数据存储和检索系统。它使用基于内容地址的内容标识符（CID）进行寻址。

CID 是基于所寻址数据的加密哈希值形成的，因此指向不可变的数据。目录和大型文件以指向哈希块的有向无环图（DAG）的形式被存储。

注意：CID 不等价于数据内容的哈希值，但它包含了数据内容的哈希值。

4.1.1  数据的下载

数据的下载分为两步：

• 首先，通过一次跳转的广播机制和对分布式哈希表（DHT）的搜索来寻找提供者；
• 然后，向提供者发送下载数据的请求；

默认情况下，下载的数据会被存储到本地缓存中，当再次有相同数据的需求时，从缓存中提供该数据。这种机制有效地导致频繁请求的数据在网络中的复制次数增加。

个人理解：随着越来越多的节点缓存了热门数据，网络中能够提供这些数据的有效节点数量显著增加，这显著降低了数据检索的延迟，并提高了数据访问的效率。

4.1.2  数据的添加

当把一个文件夹添加到 IPFS 中时，只需要存储文件夹的 CID，即 DAG 的根。

以下述目录为例：

pics
├── cats
│   ├── 2018-02-23-tabby.png
│   └── 2019-12-16-black.png
└── fish
    ├── 2017-03-05-freshwater.png
    ├── 2018-04-14-tropical.png
    └── 2020-10-02-blowfish.png

注意：目录就是文件夹！其中的 pics 就是文件夹本身，pics 的 CID 包含了文件夹中所有内容的 CID，因此存储 pics 的 CID 就等价于存储了整个文件夹。

这里需要对 Merkle DAG 的知识。简单理解，由于文件夹本身的 CID 是基于文件夹中所有文件的 CID 生成的，因此文件夹本身的 CID 可以代表整个文件夹。

4.1.3  数据的检索

之后，就可以相对于这个文件夹 CID 来寻址单个的文件。例如，集合中每个代币的元数据。

在 IPFS 中检索一个文件夹需要下载它的文件夹块，如下图所示：

假设我们要找的是「tabby.png 文件块」，那么我们需要把「cats 文件夹块」下载下来。

因为在「cats 文件夹块」中，包含了到「tabby.png 文件块」的 CID 链接，只有根据该 CID 链接才能下载「tabby.png 文件块」。这对于存储来说是不理想的，因为这两个块都需要下载。

个人理解：在 Merkle DAG 中，每个节点都被称为块。文章中说的 “这两个块” 分别是指 cats 文件夹块和 tabby.png 文件块。

4.1.4  数据的请求

通常，内容并不是直接通过 IPFS 请求，而是通过一个 HTTP-IPFS 网关，该网关通过 IPFS 获取内容并通过 HTTP 返回。

由于社区提供了公共网关，并且公共网关通常连接良好且快速获取内容，因此用户不需要在本地运行 IPFS 节点。然而，这也创造了对集中式基础设施的依赖。

由于内容是直接从网络上的节点下载的，只要至少有一个在线且可发现的节点持有它，它就会一直可用。一些公司提供付费固定服务，即用户在他们的节点上存储内容，使内容对 IPFS 网络可用。

GPT 说：本文中的网关指的是一种服务，它允许用户通过 HTTP 协议访问 IPFS 网络中的内容。即使用户不直接运行 IPFS 节点，也可以通过公共网关访问 IPFS 上的资源。

4.2  实证研究

我们主要关注样本中使用 IPFS 存储元数据和资产的 254 件 NFT 数字艺术品。

4.2.1  CID 编码

原则上，一个基于 CID 寻址的原始二进制数据的哈希值只有 32 个字节，即只需要 32 个字节就能存储完整的数据内容。只有在需要时，才会生成有效的 CID 字符串形式。

这里需要对 CIDv0 和 CIDv1 的知识。简而言之，CID 是由数据内容的哈希值和一些前缀构成的。为了节省存储空间，我们完全可以只存储数据内容的哈希值。

然而，我们发现所调查的 254 个 NFT 都使用了普通的文本编码 IPFS URI，所需的链上存储空间超过 50 个字节。

个人理解：IPFS URI 是指 CID 的字符串形式。原则上应该存的是二进制形式，但实际上存的是字符串形式，从而导致存储空间的浪费。

此外，许多合约使用一个硬编码的统一资源定位符（URL）到公共网关服务器，形式为：

https://<gateway>/ipfs/<cid>

而不是普通的 URI，形式为：

ipfs://<cid>

虽然采用 URL 形式使得用户更容易地访问所引用的元数据和数字资产，但在链上存储方面却很浪费。此外，当用户仅通过公共 HTTP 网关解析 IPFS CID 时，可预期的一致性和可用性水平会降到云存储的水平。

GPT 说：通过公共 HTTP 网关访问 IPFS 内容，用户可能会失去一些去中心化网络的固有优势，体验可能更接近于使用传统的中心化云存储服务。

4.2.2  数据可用性

我们从所有 51 个考虑的 NFT 智能合约中提取出所有 IPFS 元数据的 URI，我们将这些 URI 解析以获取 254 件 NFT 样本的所有元数据和数字资产的 CID 。然后，我们进行了一次测量研究，以确定这些数据项的可用性和复制情况。

具体来说，我们尝试识别在为期一周的时间内，每隔六小时一次，所有引用数据项的提供者。我们通过搜索 DHT 来实现，使用一个位于德国、连接良好且未经过 NAT（网络地址转换）的节点。

值得注意的是，DHT 并不是 IPFS 中唯一的发现机制，还有一种通过 Bitswap 协议实现的一跳广播机制。我们计划在未来的研究中扩展这里所呈现的研究，包括 Bitswap 发现结果。

我们考虑了所有测量得到的 (peer ID，CID) 元组，并调查了 CID 在所有元组中出现的频率，即 CID 被复制的次数。结果如下图所示：

以离散计数的直方图以及经验累积分布函数（ECDF）的形式呈现。

灰柱是直方图，看左和下坐标轴；黑线是经验累积分布函数，看右和下坐标轴。

可以看到 50% 的 CID 的副本少于 10 个，即提供它们的节点少于 10 个。甚至有 33 个 CID，通过 DHT 无法发现任何提供它们的节点。如下图所示：

根据我们的经验，OpenSea 等 NFT 平台通常不会向用户透露，某些 NFT 可能在超出当前平台缓存的范围就无法被获取。

个人理解：NFT 平台通常会设置一个缓存层来优化 NFT 的访问效率，但这样的机制有可能导致一些已经无效的 NFT 仍然在缓存层中存在。

除此之外，我们的结果可能暗示了 IPFS 的 DHT 层存在问题，即对于给定的 DHT，某些提供者只能通过一跳广播来发现。我们在第 2 节的结果也支持这一结论，在那里我们有 7 个无法被解析的 CID 。因此，进一步的研究是必要的。