目录
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)到公共网关服务器,形式为:
http:///ipfs/
而不是普通的 URI,形式为:
ipfs://
虽然采用 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 。因此,进一步的研究是必要的。