🦊原文： Understanding Security Issues in the NFT Ecosystem
🦊警告： 本文只记录了原文的第 6 节。
1 问题描述
NFT 所指向的数字资产（图片、视频等）必须是可以访问的，这样 NFT 才具有意义。NFT 可以通过以下两种方式链接数字资产：
( i ) (\mathsf{i}) (i) 如果 NFT 合约是 ERC-721 兼容的并且实现了元数据扩展，那么由该合约创建的代币在链上包含一个 m e t a d a t a _ u r l \mathsf{metadata\_url} metadata_url，它指向一个元数据（JSON）。反过来，这个元数据又包含一个 i m a g e _ u r l \mathsf{image\_url} image_url 字段，该字段指向实际的数字资产。
JSON 是指元数据采用的是 JSON 格式。
( i i ) (\mathsf{ii}) (ii) 然而，许多较老的代币不符合标准，并且不包含任何链上的 i m a g e _ u r l \mathsf{image\_url} image_url。相反，它们使用一些临时的、链下方案来链接一个资产。对于这样的 NFT，NFT 市场（NFTM）实施自定义支持，以便它们能够生成有效的图片 URL 。
NFTM 的全称是 NFT Marketplace
由于元数据和数字资产都存储在链下，它们并不享受与 NFT 本身相同的不可篡改性保证。当任何 URL 变得无法访问时，就会打破 NFT 与相应数字资产之间的链接。实际上，这些 URL 通常指向分布式存储服务（例如 IPFS），或者是中心化存储（例如一个网页域名或 Amazon S3 存储桶）。
不知道这段说的是第二种方式，还是都有在说？
对于 IPFS URL，如果 NFT 所有者有所意识，TA 可以通过固定资源（即持续存储它）来保持 NFT "活跃"。即使这样做，也可能会有问题，因为 NFT 并不存储实际资源的哈希值，而是存储指向 IPFS 网关 Web 服务的 URL 。如果网关变得不可用，NFT "断裂"。总的来说，包含指向 NFT 所有者控制之外域名的 URL 的 NFT，在相应的域名消失时有失效的风险。
2 定量分析
我们进行了一次分析，以量化由于上述原因而 "丢失" 的 OpenSea NFT 的数量。
截至 2021 年 6 月 15 日，我们从 OpenSea 获得的 12 , 215 , 650 \mathsf{12,215,650} 12,215,650 个资产中，只有 3 , 175 , 644 \mathsf{3,175,644} 3,175,644 个资产具有有效的 m e t a d a t a _ u r l \mathsf{metadata\_url} metadata_url 字段。通过查询 OpenSea 的 API，我们获得了 8 , 363 , 550 \mathsf{8,363,550} 8,363,550 个具有非空 i m a g e _ u r l \mathsf{image\_url} image_url 字段的资产。
具有有效 m e t a d a t a _ u r l \mathsf{metadata\_url} metadata_url 的才 3 , 175 , 644 \mathsf{3,175,644} 3,175,644 个，怎么 i m a g e _ u r l \mathsf{image\_url} image_url 非空的都有 8 , 363 , 550 \mathsf{8,363,550} 8,363,550 个？
剩下的 3 , 860 , 607 \mathsf{3,860,607} 3,860,607 个资产没有 i m a g e _ u r l \mathsf{image\_url} image_url 字段，这意味着它们是直接托管在 OpenSea 上的（内容创作者可以选择留空 i m a g e _ u r l \mathsf{image\_url} image_url 字段，在这种情况下 OpenSea 处理托管）。
OpenSea 处理托管应该是指，将数字资产存储在 OpenSea 的集中式数据库中。
我们首先检查图像和元数据 URL 是否指向托管在 IPFS 上的资源。接着，我们检查 URL 是否仍然可以访问。为此，我们执行一个 HTTP HEAD 查询。如果查询返回的响应代码不是 200(OK)，我们接下来执行一个 HTTP GET 查询。如果那个查询也返回一个非 200 的响应代码，我们将那个 URL 标记为不可访问。我们采取两步方法是为了优化性能，避免因为一些不支持 HEAD 查询的 Web 服务器而产生假阴性（false negatives）。
HTTP HEAD 用于检查网页是否更新，并不获取资源的实际内容。
此外，托管资产的服务器在测试时可能掉线，但后来又恢复在线。为了考虑这种可能性，我们在 15 天的时间内重复了上述 URL 检查三次。每次都只测试前一次尝试中被标记为不可访问的资产。只有当三次尝试都一致认为资产不可访问时，该资产才会最终被标记为不可访问。
上图报告了我们的发现。两个重要的观察结果是：
( i ) (\mathsf{i}) (i) 在我们数据集中的 6 月至 12 月期间，只有 3.91 \mathsf{3.91} 3.91% 托管在 IPFS 上的资产（图像）和 9.04 \mathsf{9.04} 9.04% 托管在 IPFS 上的元数据记录消失了；如预期的那样，托管在 IPFS 上的 NFT 比那些托管在非 IPFS 域名上的 NFT 更不可能消失。
( i i ) (\mathsf{ii}) (ii) 尽管 IPFS 应该更能抵抗资产消失，但大多数资产 URL（ 88.71 \mathsf{88.71} 88.71%）以及元数据 URL（ 80.69 \mathsf{80.69} 80.69%）都是托管在非 IPFS 域名上。查看所有丢失的 NFT，它们通过 118 , 294 \mathsf{118,294} 118,294 笔交易产生了惊人的收入，总额达到 1.60761805 \mathsf{1.60761805} 1.60761805 亿美元。不仅如此，由于我们在第 5 节中讨论的缓存问题，它们中的一部分可能仍然在流通中。正如这项分析所示，持久性是 NFT 领域的一个紧迫问题。
3 补充：缓存问题
无效缓存： 在展示正在销售的 NFT 时，OpenSea 和 Rarible 使用本地缓存层来避免重复请求获取关联的图片。如果图片被更新，或者消失了，缓存就会不同步。这可能会误导买家购买一个资产不存在，或者与 NFT 显示的资产不同的 NFT，因为他们使用了过时的缓存。
定量分析： 为了了解这个缓存问题可能的潜在影响，我们测量了在我们 OpenSea 数据集中有多少个 i m a g e _ u r l \mathsf{image\_url} image_url 无法被访问，但 OpenSea 仍然提供相应的缓存版本。
在总计 12 , 215 , 650 \mathsf{12,215,650} 12,215,650 个 NFT 中，有 3 , 945 , 231 \mathsf{3,945,231} 3,945,231 个（ 32.30 \mathsf{32.30} 32.30%）代币的 i m a g e _ u r l \mathsf{image\_url} image_url 无法访问。然而，OpenSea 仍然缓存了其中 2 , 691 , 030 \mathsf{2,691,030} 2,691,030 个（ 68.21 \mathsf{68.21} 68.21%）无法访问的图片，从而创造了资产仍然存在的错觉。这样一个损坏的系列是Gods Unchained，这是一个经过验证的系列，其总体交易量为 19.8 \mathsf{19.8} 19.8K 以太币。