LOREWORD
Ethereum learning path 第十三章 · 第一课 / 13.01

Chapter 13 · NFT

人人都能复制图片，为什么 NFT 还能有“所有者”？

因为 NFT 不是“防复制图片”。它是一套由智能合约维护的可识别、可授权、可转移的链上记录； 图片、元数据、版权与市场，只是与这条记录连接的不同层。

  • 13.01
  • 约 80 分钟
  • 4 个互动图示
  • 从零到机制
NFT anatomynot one object
01
Token identity网络 · 合约地址 · tokenId
identify
02
On-chain stateowner · balance · approval · events
control
03
MetadatatokenURI · JSON · attributes
describe
04
Media / rights图片 · 文件 · 许可 · 服务承诺
interpret
01 / OWNERSHIP

链上拥有，是某地址按合约规则控制代币记录。

它可以被全网验证，但不自动等于拥有图片文件、现实物品或著作权。

02 / STANDARD

ERC 标准统一的是接口，不是价值、真实性或稀缺性。

钱包和市场因为读得懂相同函数与事件，才可以共同展示和转移不同项目的 NFT。

03 / MARKET

市场撮合的是一组条件，结算才真正改写所有权。

挂单签名、合约授权和购买交易是三件事；每一步承担不同风险。

本课目录 · 10 节
  1. 00 · 先画总地图
  2. 01 · 非同质化
  3. 02 · 四层所有权
  4. 03 · ERC-721
  5. 04 · ERC-1155
  6. 05 · 元数据与存储
  7. 06 · NFT 市场
  8. 07 · 边界与风险
  9. 08 · 验证清单
  10. 09 · 复盘与自测
00

Mental model

先别看图片，先画出 NFT 的完整数据路径

当钱包展示一张 NFT 图片时，你看到的是多套系统合作后的结果，不是“图片被放进钱包”。

钱包先连接以太坊节点，读取某个 NFT 合约的状态；合约告诉它某个 tokenId 由谁控制， 还可能返回一条元数据 URI；钱包再取得 JSON 元数据，最后根据其中的 image 或 animation_url 加载媒体。

从地址控制到屏幕显示

五个环节 · 四种不同保证
01钱包 / 地址私钥或账户逻辑决定谁能发起授权与转移。
02NFT 合约执行 ERC 接口，维护 owner、balance 与 approval。
03代币身份网络 + 合约地址 + tokenId 才能定位一枚代币。
04元数据URI 指向描述名称、属性和媒体位置的 JSON。
05媒体 / 权利文件是否可用、许可给了什么，需要分别验证。
区块链直接保证的是合约状态如何按规则更新。越往右，越可能依赖内容存储、前端索引、发行方承诺与法律协议。

本课最小定义： NFT 是智能合约中一个可被识别并按规则转移的代币记录。 “非同质化”说的是记录的身份与替代关系，不是在宣称它天然稀有、昂贵、原创或永远可用。

Identity NFT 身份 = chainId + contract address + tokenId
课程边界：页面中的合约地址、tokenId、价格与订单均为固定教学示例。 本页不连接钱包、不读取链上实时数据、不发起交易、不保存任何访客数据，也不构成投资或法律建议。
01

Fungibility

“非同质化”究竟非在哪里？

同质化讨论“数量”；非同质化讨论“哪一个”。

你的一枚 ETH 与别人的一枚 ETH，在协议记账时可以按相同单位相加。NFT 则需要 tokenId 来区分具体记录：一张编号座位、一份证书、一个游戏角色或一项会员资格， 都可能因为身份、历史与属性不同而不能被任意一枚同类代币等价替换。

问题同质化资产非同质化资产
核心查询这个地址有多少单位？这个具体 tokenId 由谁控制？
最小状态balance[address] = amountowner[tokenId] = address
互换关系同一标准单位通常等价每个身份可以有不同属性、历史或权利
价值含义标准只定义记账与转移接口，不定义市场价格。

Interactive · Identity

图片相同、编号相同，就一定是同一枚 NFT 吗？

切换条件，观察真正决定身份的字段

NFT A
网络
Ethereum
合约
0xA1…C9
tokenId
42
媒体 CID
bafy…art
控制地址
0xAlice
NFT B
网络
Ethereum
合约
0xA1…C9
tokenId
42
媒体 CID
bafy…art
控制地址
0xAlice

同一枚 NFT：网络、合约地址与 tokenId 都相同；媒体和当前所有者不是身份主键。

两个反直觉结论：不同合约可以发行相同 tokenId；不同 NFT 也可以指向完全相同的图片。 所以“编号 42”或“我见过这张图”都不能单独证明身份、来源或真伪。
02

Ownership layers

你买到的不是“一层东西”

“我拥有这个 NFT”至少可能混合四个不同命题。先拆层，才知道哪一层由谁保证。

链上所有权是最明确的一层：标准合约可以回答某个 tokenId 的 owner，或某地址对某类 ERC-1155 代币的余额。至于名称、图片、文件可用性、商用许可、线下兑换与会员服务， 都要沿着数据和协议继续检查。

Interactive · Failure path

如果某一层出问题，其他层会怎样？

“NFT 还在”与“内容还能看”可以同时一真一假

L1
链上代币状态owner / balance / approval / Transfer events
可验证
L2
元数据描述tokenURI 返回的 JSON 名称、属性与媒体指针
可读取
L3
媒体内容图片、视频、音频、3D 文件或链上生成结果
可取得
L4
法律权利与服务版权许可、会员准入、兑换承诺、现实资产关系
另行约定

四层目前都可用，但它们仍由不同机制保障：共识、合约代码、内容存储和外部协议不能画成等号。

CHAIN

代币控制权

通常由合约状态与账户签名决定，可以通过节点独立查询。

CONTENT

内容完整性与可用性

URI、内容哈希和存储节点分别回答“指向哪里”“字节是否相同”“现在能否取得”。

RIGHTS

许可与现实承诺

要看许可证、发行条款与适用法律；代币转移本身不自动写出这些权利。

美国版权局与美国专利商标局的 NFT 研究报告明确区分了 NFT 所有权、关联资产与版权利益； 是否转移或许可相关权利，要看有效协议与具体行为。这里采用这一普遍适用的分析方法，不把代币所有权直接等同于版权。 [8]
03

ERC-721

一枚独立代币，怎样在合约里活一生？

ERC-721 统一了“查询、授权、转移与事件”这组接口，让任何兼容钱包和市场都能用同一种语言操作不同 NFT 合约。

标准的核心不是图片，而是 ownerOf(tokenId)： 它返回当前被合约认可的所有者地址。balanceOf(owner) 只告诉你这个地址持有几枚， 不告诉你分别是哪几个 tokenId；枚举通常需要事件索引或可选扩展。 [1]

tokenId #42 的状态转换

铸造 → 授权 → 转移 → 销毁
01 / MINT

从不存在到 Alice

实现通常把 #42 的 owner 写成 Alice，并发出从零地址来的 Transfer 事件。

Transfer(0x0, Alice, 42)
02 / APPROVE

允许市场移动

owner 不变；只是给某地址单枚权限，或给 operator 该集合的管理权限。

approve(Market, 42)
03 / TRANSFER

从 Alice 到 Bob

调用者必须是 owner、单枚获批者或已获批 operator；转移后单枚 approval 被清除。

Transfer(Alice, Bob, 42)
04 / BURN

从 Bob 到不存在

burn 不是 ERC-721 核心函数名要求，但实现常用转往零地址的事件语义表示销毁。

Transfer(Bob, 0x0, 42)
Transfer 事件让索引器追踪变化；最终状态仍应以合约当前查询结果为准。事件记录历史，状态回答“现在”。
ownerOf(id)

谁是当前 owner？

对有效 tokenId 返回一个地址，是 ERC-721 所有权判断的核心入口。

safeTransferFrom

能否安全交给合约？

接收方若是合约，需要返回规定的接收确认值，否则交易回滚，避免代币被锁进不兼容合约。

approve

只授权这一枚

给一个地址移动指定 tokenId 的权限；该单枚授权在转移时被重置。

setApprovalForAll

授权整个集合

允许 operator 管理该 owner 在这一个 NFT 合约内的全部代币，不是整个钱包的所有 NFT。

tokenURI(id)

去哪里读元数据？

属于可选元数据扩展；返回 URI，不保证 URI 内容不可变或永久在线。

supportsInterface

实现了哪些接口？

通过 ERC-165 查询接口支持情况，帮助应用识别 ERC-721、元数据扩展等能力。

授权不是转移，但授权创造了转移能力。 setApprovalForAll 的范围可能覆盖你在同一集合合约里的每一枚代币。 签名前必须核对 operator 地址、合约地址与撤销路径；“只是连接钱包”不需要这种权限。
safe 不等于没有市场风险。 safeTransferFrom 只检查接收合约是否按接口表示“会接收”， 不验证交易价格、公平性、项目真实性、元数据质量或版权。
04

ERC-1155

一个合约，怎样同时装下独一件与一千份？

ERC-1155 不再假设“一个 tokenId 只对应一个 owner”，而是记录“某地址持有这个 id 的多少份”。

同一合约里，id 100 可以代表只发行 1 份的传奇道具，id 200 可以代表发行 500 份的入场券， id 300 还可以代表可堆叠的 20 瓶药水。标准允许同一合约管理同质化、半同质化与非同质化资产， 但不会替项目替你定义每个 id 的经济含义。 [2]

ID 100

创世钥匙

项目约定总量为 1，可作为非同质化对象使用。

Alice × 1
ID 200

年度通行证

同一批次 500 份；每份在当前规则下可以互换。

Alice × 3
ID 300

能量药水

可堆叠消耗品；合约直接记录每个地址的数量。

Alice × 20

Interactive · State model

同样叫 token，两个标准到底怎样记账？

切换标准，比较身份、余额与转移参数

STATE

一个 id → 一个 owner

查询 #42 时，核心问题是 ownerOf(42) 返回哪个地址。

ownerOf[42] = Alice
TRANSFER

移动具体一枚

函数参数包含 from、to 与 tokenId，不包含“转几份”。

safeTransferFrom(Alice, Bob, 42)

ERC-721 的非同质化来自每个 tokenId 的独立身份；同一 tokenId 在正常状态下只有一个 owner。

维度ERC-721ERC-1155
核心状态ownerOf(id)balanceOf(account, id)
一个 id 的持有人一个当前 owner可以有多个地址，各自持有不同数量
一个合约的资产类型通常一个 NFT 集合可以包含多种 id 与多种数量模型
批量操作核心标准没有批量转移提供 safeBatchTransferFrom 与 balanceOfBatch
接收保护ERC721Receiver 回调ERC1155TokenReceiver 单笔或批量回调
授权粒度单枚 approve + 集合 operator标准核心采用 operator 全局授权（针对该 1155 合约）
批量接口可以减少多次独立调用的重复开销，但“ERC-1155 一定更省 Gas”不是无条件定律。 实际成本还取决于合约实现、存储布局、转移数量、接收方逻辑与 calldata。
05

Metadata & storage

图片究竟在哪里？“上了 IPFS”又保证了什么？

多数 NFT 合约不把原始图片字节直接塞进每个 token 的链上存储，而是返回一条元数据 URI。

ERC-721 的可选元数据扩展定义了 tokenURI(tokenId)； 这条 URI 可以指向 JSON，JSON 再用 image 指向媒体。 因此“合约在链上”不能自动推出“图片也在链上”。 [1]

ERC-1155 使用元数据扩展的 uri(id)。返回模板如果含有 {id}，客户端必须把它替换成不带 0x、使用小写字母、左侧补零到 64 位的十六进制 token id。例如十进制 42 会以末尾 …002a 的 64 位形式进入 URI。这个规则让同一合约的不同 id 能共用一套路径模板。 [2]

一次元数据解析

ERC-721 示例 · 函数 → URI → JSON → 媒体
01

合约查询

tokenURI(42)

02

元数据地址

ipfs://bafy…/42.json

03

JSON 描述

name · description · image · attributes

04

媒体内容

ipfs://bafy…/art.png

市场和钱包可能通过自己的网关、缓存与索引数据库加速显示，因此两个前端的刷新时间和呈现结果也可能不同。 
{
  "name": "Orbit Key #42",
  "description": "一枚教学示例 NFT",
  "image": "ipfs://bafy…/art.png",
  "attributes": [
    { "trait_type": "Tier", "value": "Genesis" }
  ]
}
HTTPS

位置寻址

容易部署与更新，但域名、服务器、权限或文件路径变化会影响访问；同一 URL 的内容也可能被替换。

IPFS

内容寻址

CID 由内容产生，字节改变通常意味着 CID 改变；但 CID 不是存储位置，也不保证永远有人提供这些字节。

ON-CHAIN

链上数据

把元数据或生成逻辑直接写入链上，能减少外部存储依赖，但通常更昂贵，也仍需检查升级与渲染逻辑。

IPFS 的 CID 回答“这些字节应当是什么”，持久化与 pinning 回答“谁继续保存并提供这些字节”。 内容完整性和内容可用性是两个问题。 [5][6]
“冻结元数据”必须由证据支持。 需要检查 tokenURI/baseURI 是否还能由管理员修改、合约是否可升级、媒体 URI 是否指向不可变内容， 以及所谓 freeze 是否真的由代码强制，而不只是前端标签。

动态 NFT 并不矛盾

非同质化指的是代币身份，不要求画面永远不变。同一枚 token 可以按链上状态、游戏进度或外部数据改变元数据。 关键不是“会不会变”，而是谁能触发变化、依据什么数据、变化规则是否可验证、管理员能否绕过规则。

06

NFT marketplace

点下“购买”之后，市场怎样同时交付 NFT 与付款？

一个 NFT 市场不是一份“商品数据库”，而是前端、索引器、订单系统与结算合约的组合。

常见设计里，挂单是一份由卖家签名的订单：它可以在链下传播，不会立即转移 NFT。 买家提交履约交易后，结算合约才验证签名、所有权、授权、时间与订单状态， 并在同一笔交易里交换 NFT 与付款。具体协议也可能采用链上挂单、托管或拍卖，所以不要把一种流程当成唯一实现。 [7]

Interactive · Settlement

逐步走完一次固定价成交

挂单不是转移 · 结算才改状态

STEP 00 / INDEX

市场先重建“现在有什么”

索引器读取合约事件与当前状态，取得 tokenId、owner 和元数据，再把可搜索页面展示给用户。页面不是所有权来源。

NFT ownerAlice
Approval未授权
Signed order不存在
Payment在 Bob 钱包
1 / 6
连接钱包

只建立通信

网站能请求账户信息；单纯连接本身不应给出 NFT 转移权限。

授权 operator

创造转移能力

通常是链上交易，需要 Gas；范围与撤销方式由代币标准和合约决定。

签署订单

承诺一组条件

许多协议把订单签名放在链下，因此挂单本身可能不花 Gas，但签名仍有法律与资产安全含义。

履约交易

触发链上结算

结算合约检查订单尚未过期、取消或成交，并验证 owner 与 approval 仍满足条件。

原子交换

一起成功或一起回滚

在同一笔交易中移动 NFT 与付款；任一关键检查失败，整个调用回滚。

事件索引

前端刷新结果

成交后市场根据 Transfer 与协议事件更新页面；显示延迟不改变链上最终状态。

钱最终去了哪里？

成交金额可能被拆成卖家所得、市场费用与创作者版税。ERC-2981 只标准化 royaltyInfo(tokenId, salePrice) 的查询方式，告诉市场“建议付给谁、多少”； 标准本身不能强制每次普通转移都支付版税，因为转移不一定代表销售。 支付仍依赖市场是否实现并尊重该机制。 [4]

取消前先问“在哪里取消”。 某些订单可以由市场前端不再展示，另一些需要链上计数器、nonce 或取消交易才能使签名失效。 “页面看不见了”不一定等于订单在所有撮合渠道都已失效。
07

Claims & boundaries

NFT 能证明什么，又不能自动证明什么？

区块链擅长证明“某合约按自己的规则记录了什么”，不擅长凭空证明现实世界的作者、真品、版权与价格。

CLAIM 01

“ownerOf 返回我的地址。”

可推出：该合约当前把这一 tokenId 记在你的地址下。

链上可验证
CLAIM 02

“图片在 IPFS，所以永久存在。”

CID 能校验内容，但仍要有人继续保存与提供数据。

结论过度
CLAIM 03

“我买了 NFT，所以拥有版权。”

是否获得复制、改编、商用等权利取决于许可或转让协议。

需外部协议
CLAIM 04

“图片一模一样，所以是假 NFT。”

图片可复制；应核对网络、合约、tokenId、发行方与铸造来源。

身份不足
CLAIM 05

“供应量只有 1，所以一定稀缺。”

还可能有其他合约、相同媒体、衍生版本或可改变的铸造权限。

范围不足
CLAIM 06

“版税写了 5%，每次都会收到。”

版税信息可被标准化表达，但支付是否发生仍依赖成交路径与市场执行。

不自动强制
01 / PROVENANCE

来源风险

仿冒合约可以复制名称、图片和描述；品牌官网、已知部署地址与铸造历史才是额外证据。

02 / AUTHORIZATION

授权风险

恶意 operator、钓鱼签名或危险订单可获得转移能力；连接、签名与链上授权必须分别识别。

03 / IMPLEMENTATION

合约风险

代码漏洞、升级代理、管理员权限、铸造上限与暂停开关都会改变“规则不会变”的假设。

04 / METADATA

内容风险

服务器下线、未 pin 的 IPFS 内容、可变 baseURI 或渲染服务失效，会让代币仍在但展示改变。

05 / MARKET

订单风险

货币单位、价格小数、有效期、费用、买卖方向或捆绑资产理解错误，都可能造成不可逆成交。

06 / LIQUIDITY

价格风险

链上所有权不创造买家。地板价、历史成交与挂单深度都不保证你能按预期价格退出。

更精确的“数字所有权”： 你能够用账户授权去控制一条公开状态记录，第三方可以按相同合约规则独立验证， 并且这条记录可以被其他兼容应用读取与转移。它是可验证的协议控制权，不是对一切关联事物的总括所有权。

08

Verification checklist

分析任何 NFT，按十步把它拆开

不先问“会涨吗”，先问“我究竟在验证哪一层”。下面这张清单既适合购买前，也适合研究项目时使用。

你的验证进度 0 / 10

从第一项开始。勾选只在当前页面内计算，不会保存。

真正的验证通常需要区块浏览器、合约源码、节点查询、内容网关、发行方文档与许可证共同参与。 市场页面可以作为入口，但不应成为唯一事实来源。
09

Synthesis

把整课压缩成一条因果链

  1. 先需要一个稳定身份网络、合约地址与 tokenId 让不同应用指向同一条代币记录。
  2. 再需要公开的状态接口ERC-721 或 ERC-1155 让应用用统一方法查询余额、所有者、授权与转移。
  3. 显示内容依赖元数据路径tokenURI、JSON 与媒体存储把链上记录解释成人能理解的名称、属性与画面。
  4. 权利必须另行定义版权许可、会员服务与现实资产关系不会因为 token 转移而自动生成。
  5. 市场把意愿变成可验证订单授权创造转移能力，签名表达成交条件，履约交易才触发原子结算。
  6. 所以 NFT 是一组依赖关系合约状态可以仍然正确，同时图片、许可、市场价格或发行承诺已经失效。

六题校准

1. 哪组字段最接近一枚 NFT 的完整链上身份？

2. ERC-721 的 ownerOf(42) 返回 Alice，最准确的结论是？

3. ERC-1155 相比 ERC-721 的关键状态差异是什么？

4. IPFS CID 最直接保证什么？

5. 在常见的链下签名挂单模型里，NFT 何时真正从卖家转给买家？

6. ERC-2981 能直接保证哪件事？

最小术语表

NFT
Non-Fungible Token，具有可区分身份的代币记录。
tokenId
合约内用于识别 token 或 token 类型的整数标识。
ERC-721
跟踪并转移单个非同质化 token 的标准接口。
ERC-1155
在一个合约中管理多种 token id 与数量的多代币标准。
ownerOf
ERC-721 查询指定 tokenId 当前 owner 的函数。
operator
被 owner 授权，可代表其操作某合约内代币的地址。
tokenURI
返回 token 元数据位置的函数或结果 URI。
metadata
描述名称、属性、媒体位置等信息的数据，常为 JSON。
CID
IPFS 的内容标识符，由内容产生，不等于存储服务器位置。
mint
创建或发行代币状态，通常伴随从零地址发出的事件。
burn
让代币失效或减少供应，常以转往零地址的事件语义表示。
royalty
二级销售中建议支付给创作者或权利人的版税；是否执行取决于成交机制。

一手资料与标准原文

  1. ERC-721 · Non-Fungible Token StandardownerOf、balanceOf、授权、转移、接收回调、事件与可选元数据扩展的规范原文。
  2. ERC-1155 · Multi Token Standard多 token 类型、数量模型、批量转移、接收规则与事件追踪的规范原文。
  3. ethereum.org · ERC-721 介绍用合约地址与 tokenId 理解 NFT 唯一身份、接口和典型用途的官方教程。
  4. ERC-2981 · NFT Royalty Standard版税接收者与金额的标准查询方式，以及版税支付为何不能由普通转移强制。
  5. IPFS Docs · Content AddressingCID、内容寻址以及“内容标识不是存储位置”的官方说明。
  6. IPFS Docs · Persistence, permanence and pinning内容持久化、永久性与 pinning 之间区别的官方说明。
  7. Seaport Docs · Order Models一个现行 NFT 市场协议如何表达订单、验证签名、设置授权与链上确认的第一方文档；用于说明常见模型，不代表唯一实现。
  8. USPTO & U.S. Copyright Office · NFT and Intellectual Property ReportNFT 转移、关联资产与版权利益需要区分的官方联合研究。
  9. ERC-165 · Standard Interface Detection合约声明并查询所实现接口的标准机制。
  10. ethereum.org · How to Write & Deploy an NFT从 ERC-721 实现、ownerOf 到 tokenURI 元数据 JSON 的官方开发教程。

13.01 · Complete

NFT 不是不可复制的图片，而是可验证的身份、状态与授权关系。

真正成熟的判断不是问“这张图是真是假”，而是依次核对： 这是什么链上的哪个合约与 tokenId，合约允许谁做什么，元数据与媒体由谁保存， 相关权利如何约定，市场订单又会怎样改变状态。

← 回顾上一课 · DeFi 核心应用如何协作