区块链 | 由外部实体导致的 NFT 安全问题

2024-04-30 17:12

本文主要是介绍区块链 | 由外部实体导致的 NFT 安全问题,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

🦊原文: 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 以太币。

这篇关于区块链 | 由外部实体导致的 NFT 安全问题的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/949442

相关文章

解决jupyterLab打开后出现Config option `template_path`not recognized by `ExporterCollapsibleHeadings`问题

《解决jupyterLab打开后出现Configoption`template_path`notrecognizedby`ExporterCollapsibleHeadings`问题》在Ju... 目录jupyterLab打开后出现“templandroidate_path”相关问题这是 tensorflo

如何解决Pycharm编辑内容时有光标的问题

《如何解决Pycharm编辑内容时有光标的问题》文章介绍了如何在PyCharm中配置VimEmulator插件,包括检查插件是否已安装、下载插件以及安装IdeaVim插件的步骤... 目录Pycharm编辑内容时有光标1.如果Vim Emulator前面有对勾2.www.chinasem.cn如果tools工

最长公共子序列问题的深度分析与Java实现方式

《最长公共子序列问题的深度分析与Java实现方式》本文详细介绍了最长公共子序列(LCS)问题,包括其概念、暴力解法、动态规划解法,并提供了Java代码实现,暴力解法虽然简单,但在大数据处理中效率较低,... 目录最长公共子序列问题概述问题理解与示例分析暴力解法思路与示例代码动态规划解法DP 表的构建与意义动

Java多线程父线程向子线程传值问题及解决

《Java多线程父线程向子线程传值问题及解决》文章总结了5种解决父子之间数据传递困扰的解决方案,包括ThreadLocal+TaskDecorator、UserUtils、CustomTaskDeco... 目录1 背景2 ThreadLocal+TaskDecorator3 RequestContextH

关于Spring @Bean 相同加载顺序不同结果不同的问题记录

《关于Spring@Bean相同加载顺序不同结果不同的问题记录》本文主要探讨了在Spring5.1.3.RELEASE版本下,当有两个全注解类定义相同类型的Bean时,由于加载顺序不同,最终生成的... 目录问题说明测试输出1测试输出2@Bean注解的BeanDefiChina编程nition加入时机总结问题说明

关于最长递增子序列问题概述

《关于最长递增子序列问题概述》本文详细介绍了最长递增子序列问题的定义及两种优化解法:贪心+二分查找和动态规划+状态压缩,贪心+二分查找时间复杂度为O(nlogn),通过维护一个有序的“尾巴”数组来高效... 一、最长递增子序列问题概述1. 问题定义给定一个整数序列,例如 nums = [10, 9, 2

Spring AI Alibaba接入大模型时的依赖问题小结

《SpringAIAlibaba接入大模型时的依赖问题小结》文章介绍了如何在pom.xml文件中配置SpringAIAlibaba依赖,并提供了一个示例pom.xml文件,同时,建议将Maven仓... 目录(一)pom.XML文件:(二)application.yml配置文件(一)pom.xml文件:首

解决JavaWeb-file.isDirectory()遇到的坑问题

《解决JavaWeb-file.isDirectory()遇到的坑问题》JavaWeb开发中,使用`file.isDirectory()`判断路径是否为文件夹时,需要特别注意:该方法只能判断已存在的文... 目录Jahttp://www.chinasem.cnvaWeb-file.isDirectory()遇

修改若依框架Token的过期时间问题

《修改若依框架Token的过期时间问题》本文介绍了如何修改若依框架中Token的过期时间,通过修改`application.yml`文件中的配置来实现,默认单位为分钟,希望此经验对大家有所帮助,也欢迎... 目录修改若依框架Token的过期时间修改Token的过期时间关闭Token的过期时js间总结修改若依

MySQL的cpu使用率100%的问题排查流程

《MySQL的cpu使用率100%的问题排查流程》线上mysql服务器经常性出现cpu使用率100%的告警,因此本文整理一下排查该问题的常规流程,文中通过代码示例讲解的非常详细,对大家的学习或工作有一... 目录1. 确认CPU占用来源2. 实时分析mysql活动3. 分析慢查询与执行计划4. 检查索引与表