🐶原文： 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 中， o p e r a t o r \mathsf{operator} operator 是一个可以管理 NFT 的 o w n e r \mathsf{owner} owner 的所有资产的实体。换句话说，NFT 的 o w n e r \mathsf{owner} owner 可以将对自己的资产采取行动的权限委托给 o p e r a t o r \mathsf{operator} operator。
针对 setApprovalForAll() 方法：
- 若设置了
_approved参数，则将地址_operator添加到msg.sender授权的 o p e r a t o r \mathsf{operator} operator 集合中； - 若未设置
_approved参数，则将地址_operator从msg.sender授权的 o p e r a t o r \mathsf{operator} operator 集合中移除；
其中 msg.sender 是指 NFT 的
o
w
n
e
r
\mathsf{owner}
owner。
3.2 approve 方法
与可以操作
o
w
n
e
r
\mathsf{owner}
owner 的所有资产的
o
p
e
r
a
t
o
r
\mathsf{operator}
operator 不同，ERC-721 定义了一个
c
o
n
t
r
o
l
l
e
r
\mathsf{controller}
controller 作为被授权操作一个单一资产的实体。approve() 方法将地址 _approved 批准为资产 _tokenId 的
c
o
n
t
r
o
l
l
e
r
\mathsf{controller}
controller。
3.3 transferFrom 方法
o
p
e
r
a
t
o
r
\mathsf{operator}
operator、
c
o
n
t
r
o
l
l
e
r
\mathsf{controller}
controller 或
o
w
n
e
r
\mathsf{owner}
owner 可以调用 transferFrom() 方法将代币 _tokenId 从当前
o
w
n
e
r
\mathsf{owner}
owner 的 _from 地址转移到 _to 地址。
3.4 tokenURI 方法
在创建 NFT 时， c r e a t o r \mathsf{creator} creator 可以选择性地关联一个 URL，这个 URL 被称为 m e t a d a t a _ u r l \mathsf{metadata\_url} metadata_url，它指向一个符合 ERC-721 元数据标准的 JSON 文件。这个 JSON 文件存储了资产的详细信息，例如其名称和描述，并且包含一个名为 i m a g e _ u r l \mathsf{image\_url} 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() 方法来检索所关联的
m
e
t
a
d
a
t
a
_
u
r
l
\mathsf{metadata\_url}
metadata_url。
有趣的是，NFT 的创建和销毁
(
\mathsf{(}
(
m
i
n
t
i
n
g
\mathsf{minting}
minting 和
b
u
r
n
i
n
g
\mathsf{burning}
burning
)
\mathsf{)}
) 并不是标准要求的一部分。通常，mint() 被定义为一个公共函数，仅限于合约的
c
r
e
a
t
o
r
\mathsf{creator}
creator 使用，通过传递
m
e
t
a
d
a
t
a
_
u
r
l
\mathsf{metadata\_url}
metadata_url 作为参数来调用。铸币还可以在合约创建过程中通过调用 mint() 来实现，即通过合约的构造函数。
4 IPFS
IPFS 是一个去中心化、点对点、无需权限的文件系统。任何人都可以加入 IPFS 覆盖网络。每个数据项 d d d 都将被分配一个唯一的不可变地址，该地址被称为「CID，内容标识符」，计算公式如下：
C I D = H ( d ) CID=H(d) CID=H(d)
即 CID 就是文件内容 d d d 的哈希 H H H。因此，当文件内容发生变化时，CID 也会发生变化。
在 IPFS 中存储文件时，文件的内容首先被分成块。所有的存储元素，即目录、目录中的文件以及这些文件中的块，都被存储在一个称为 M e r k l e D A G \mathsf{Merkle DAG} MerkleDAG 的有向无环图结构中。
IPFS 维护一个分布式哈希表 D H T \mathsf{DHT} DHT 存储关于 p r o v i d e r \mathsf{provider} provider 的记录，即这些记录用于定位那些存储了被请求内容的对等节点。要检索数据项 d d d，节点首先在 DHT 中查找 d d d 的提供者 P ( d ) P(d) P(d)，然后节点向提供者 P ( d ) P(d) P(d) 中的一个发出对 d d d 的请求。
这段主要介绍了 IPFS 存储数据、请求数据的方式。
