区块链 | 由外部实体导致的 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

相关文章

解决IDEA报错:编码GBK的不可映射字符问题

《解决IDEA报错:编码GBK的不可映射字符问题》:本文主要介绍解决IDEA报错:编码GBK的不可映射字符问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录IDEA报错:编码GBK的不可映射字符终端软件问题描述原因分析解决方案方法1:将命令改为方法2:右下jav

MyBatis模糊查询报错:ParserException: not supported.pos 问题解决

《MyBatis模糊查询报错:ParserException:notsupported.pos问题解决》本文主要介绍了MyBatis模糊查询报错:ParserException:notsuppo... 目录问题描述问题根源错误SQL解析逻辑深层原因分析三种解决方案方案一:使用CONCAT函数(推荐)方案二:

Redis 热 key 和大 key 问题小结

《Redis热key和大key问题小结》:本文主要介绍Redis热key和大key问题小结,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录一、什么是 Redis 热 key?热 key(Hot Key)定义: 热 key 常见表现:热 key 的风险:二、

IntelliJ IDEA 中配置 Spring MVC 环境的详细步骤及问题解决

《IntelliJIDEA中配置SpringMVC环境的详细步骤及问题解决》:本文主要介绍IntelliJIDEA中配置SpringMVC环境的详细步骤及问题解决,本文分步骤结合实例给大... 目录步骤 1:创建 Maven Web 项目步骤 2:添加 Spring MVC 依赖1、保存后执行2、将新的依赖

Spring 中的循环引用问题解决方法

《Spring中的循环引用问题解决方法》:本文主要介绍Spring中的循环引用问题解决方法,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录什么是循环引用?循环依赖三级缓存解决循环依赖二级缓存三级缓存本章来聊聊Spring 中的循环引用问题该如何解决。这里聊

Spring Boot中JSON数值溢出问题从报错到优雅解决办法

《SpringBoot中JSON数值溢出问题从报错到优雅解决办法》:本文主要介绍SpringBoot中JSON数值溢出问题从报错到优雅的解决办法,通过修改字段类型为Long、添加全局异常处理和... 目录一、问题背景:为什么我的接口突然报错了?二、为什么会发生这个错误?1. Java 数据类型的“容量”限制

关于MongoDB图片URL存储异常问题以及解决

《关于MongoDB图片URL存储异常问题以及解决》:本文主要介绍关于MongoDB图片URL存储异常问题以及解决方案,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐... 目录MongoDB图片URL存储异常问题项目场景问题描述原因分析解决方案预防措施js总结MongoDB图

SpringBoot项目中报错The field screenShot exceeds its maximum permitted size of 1048576 bytes.的问题及解决

《SpringBoot项目中报错ThefieldscreenShotexceedsitsmaximumpermittedsizeof1048576bytes.的问题及解决》这篇文章... 目录项目场景问题描述原因分析解决方案总结项目场景javascript提示:项目相关背景:项目场景:基于Spring

解决Maven项目idea找不到本地仓库jar包问题以及使用mvn install:install-file

《解决Maven项目idea找不到本地仓库jar包问题以及使用mvninstall:install-file》:本文主要介绍解决Maven项目idea找不到本地仓库jar包问题以及使用mvnin... 目录Maven项目idea找不到本地仓库jar包以及使用mvn install:install-file基

JAVA保证HashMap线程安全的几种方式

《JAVA保证HashMap线程安全的几种方式》HashMap是线程不安全的,这意味着如果多个线程并发地访问和修改同一个HashMap实例,可能会导致数据不一致和其他线程安全问题,本文主要介绍了JAV... 目录1. 使用 Collections.synchronizedMap2. 使用 Concurren