网站后台模板 jquery/南京seo报价

🐶原文： Understanding Security Issues in the NFT Ecosystem

🐶写在前面： 本博客只摘取了原论文的第二、三节。

技术背景知识

在本节中，我们将介绍以太坊生态系统的构建模块，重点关注「NFT，非同质化代币」以及围绕它们成长起来的经济体系。

1 以太坊区块链

以太坊是推动加密货币「ETH，以太币」和数千个「dApp，去中心化应用程序」的技术。以太坊区块链是一个分布式、公共账本，其中交易由解决「PoW，加密工作量证明」挑战的矿工挖掘到区块中。

早在 2022 年，以太坊就从工作量证明过渡到权益证明了。

在这个生态系统中，一个账户是由一个地址表示的实体，能够提交交易。以太坊中有两种类型的账户：

• 外部所有账户（EOA）：由持有相应私钥的任何人控制；
• 合约账户：其中包含可执行的代码片段，称为智能合约；

智能合约是由「EVM，以太坊虚拟机」运行的程序，它利用区块链来存储其持久状态。交易是账户之间资金的转移，或对合约的公共方法的调用。发送资金或与合约交互的地址表示为 msg.sender。

2 非同质化代币 NFT

在以太坊中，代币是基于区块链的数字资产。不同于以太坊区块链本地的、内置的加密货币以太币，代币是通过专门的智能合约实现的。代币主要有两种类型：同质化代币和非同质化代币。

一方面，同质化代币的所有副本通常是符合 ERC-20 接口的，都是相同的且可以互换。另一方面，非同质化代币的所有副本通常是符合 ERC-721 接口的，都是独一无二的，每个代币代表某人对特定数字资产的所有权，例如 ENS 域名和 CryptoKitties，或者实体资产，如金条。

ENS 类似于中心化网络中的 DNS，都是用于提高地址的可读性，区别在于 ENS 针对的是去中心化网络。

3 ERC-721

ERC-721 是目前在以太坊上实现非同质化代币的最受欢迎的标准。这个标准接口定义了一组必须实现的和可选的 API 方法，用于代币合约。与我们的讨论相关的几个 API 方法如下：

/// 授予地址_operator具有所有NFT的控制权
setApprovalForAll (address _operator, bool _approved) external/// 授予地址_approved具有_tokenId控制权
approve (address _approved, uint256 _tokenId) external payable/// 地址_from将对tokenId的所有权转移给地址_to
transferFrom (address _from, address _to, uint256 tokenId) external payable/// 获取_tokenId的元数据链接
tokenURI (uint256 _tokenId) external view returns (string)

智能合约应该是用 Solidity 语言编写的，可惜 CSDN 没有这款语言的语法高亮。

每个 NFT 都有它自己的 ID，ID 用于追踪这些独特的代币，这个 ID 被称为 _tokenId。

3.1 setApprovalForAll 方法

在 ERC-721 中，$\mathsf{operator}$ 是一个可以管理 NFT 的 $\mathsf{owner}$ 的所有资产的实体。换句话说，NFT 的 $\mathsf{owner}$ 可以将对自己的资产采取行动的权限委托给 $\mathsf{operator}$。

针对 setApprovalForAll() 方法：

• 若设置了 _approved 参数，则将地址 _operator 添加到 msg.sender 授权的 $\mathsf{operator}$ 集合中；
• 若未设置 _approved 参数，则将地址 _operator 从 msg.sender 授权的 $\mathsf{operator}$ 集合中移除；

其中 msg.sender 是指 NFT 的 $\mathsf{owner}$。

3.2 approve 方法

与可以操作 $\mathsf{owner}$ 的所有资产的 $\mathsf{operator}$ 不同，ERC-721 定义了一个 $\mathsf{controller}$ 作为被授权操作一个单一资产的实体。approve() 方法将地址 _approved 批准为资产 _tokenId 的 $\mathsf{controller}$。

3.3 transferFrom 方法

$\mathsf{operator}$、$\mathsf{controller}$ 或 $\mathsf{owner}$ 可以调用 transferFrom() 方法将代币 _tokenId 从当前 $\mathsf{owner}$ 的 _from 地址转移到 _to 地址。

3.4 tokenURI 方法

在创建 NFT 时，$\mathsf{creator}$ 可以选择性地关联一个 URL，这个 URL 被称为 $metadata\_url$，它指向一个符合 ERC-721 元数据标准的 JSON 文件。这个 JSON 文件存储了资产的详细信息，例如其名称和描述，并且包含一个名为 $image\_url$ 的字段，它是指向资产的 URL 。以下是一个示例：

{"title": "Asset Metadata","type": "object","properties": {"name": {"type": "string","description": "Identifies the asset to which this NFT represents",},"description": {"type": "string","description": "Describes the asset to which this NFT represents",},"image": {"type": "string","description": "A URI pointing to a resource.",}}
}

如此一来，NFT 就将资产与记录其所有权的记录连接起来了。给定一个 _tokenId，可以通过合约的 tokenURI() 方法来检索所关联的 $metadata\_url$。

有趣的是，NFT 的创建和销毁 $($$\mathsf{minting}$ 和 $\mathsf{burning}$$)$ 并不是标准要求的一部分。通常，mint() 被定义为一个公共函数，仅限于合约的 $\mathsf{creator}$ 使用，通过传递 $metadata\_url$ 作为参数来调用。铸币还可以在合约创建过程中通过调用 mint() 来实现，即通过合约的构造函数。

4 IPFS

IPFS 是一个去中心化、点对点、无需权限的文件系统。任何人都可以加入 IPFS 覆盖网络。每个数据项 $d$ 都将被分配一个唯一的不可变地址，该地址被称为「CID，内容标识符」，计算公式如下：

$$CID=H(d)$$

即 CID 就是文件内容 $d$ 的哈希 $H$。因此，当文件内容发生变化时，CID 也会发生变化。

在 IPFS 中存储文件时，文件的内容首先被分成块。所有的存储元素，即目录、目录中的文件以及这些文件中的块，都被存储在一个称为 $\mathsf{MerkleDAG}$ 的有向无环图结构中。

IPFS 维护一个分布式哈希表 $\mathsf{DHT}$ 存储关于 $\mathsf{provider}$ 的记录，即这些记录用于定位那些存储了被请求内容的对等节点。要检索数据项 $d$，节点首先在 DHT 中查找 $d$ 的提供者 $P(d)$，然后节点向提供者 $P(d)$ 中的一个发出对 $d$ 的请求。

这段主要介绍了 IPFS 存储数据、请求数据的方式。