NFT on 牛哥聊技术

OpenSea Seaport 协议详解

Tue, 20 Aug 2024 16:00:00 +0800

写在前面

OpenSea 长期是 NFT 市场的头部平台——但它早期用的是 ProjectWyvern 协议——一个 2018 年的设计，远不能满足 2022 年的需求。

2022 年 5 月 OpenSea 推出全新的 Seaport 协议，并在 2022 年 6 月切换全平台。Seaport 不是"小修小补"——它完全重新设计了 NFT 交易的链上模型：

多对多交易：一笔订单能涉及多种资产、多个发送方、多个接收方
极致 Gas 优化：单次撮合成本比 Wyvern 低 35%
无需特殊代理合约：用户授权流程大大简化
Order Type 抽象：能表达拍卖、固定价、批量、套件等多种交易模式

理解 Seaport 不只是为了使用 OpenSea SDK——它代表了 NFT 协议设计的现代范式。本文讲清楚 Seaport 的核心机制和它解决的问题。

一、Wyvern 的痛点

Wyvern 是 OpenSea 早期协议的基础。它的核心思想是"让两笔配对的订单互相调用对方"——非常通用，但也有几个硬伤：

每个用户都要部署一个『代理合约』——首次使用要额外支付一次合约部署 Gas（昂贵）
撮合一笔订单要执行 12 个合约调用——Gas 成本高
订单数据格式僵化——无法灵活表达"批量买"、“套件”、“提供其他 NFT 换”
协议升级困难——和 OpenSea 业务深度绑定

2022 年的 NFT 市场已经不止"一个 NFT 换 ETH"那么简单——开发者需要更灵活的协议。Seaport 应运而生。

二、Seaport 的核心抽象：Order

Seaport 把任何交易抽象成一个 Order 结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


struct OrderParameters {
 address offerer; // 提供资产的人
 address zone; // 可选的"裁判"合约
 OfferItem[] offer; // 提供出去的资产清单
 ConsiderationItem[] consideration; // 期望获得的资产清单
 OrderType orderType;
 uint256 startTime;
 uint256 endTime;
 bytes32 zoneHash;
 uint256 salt;
 bytes32 conduitKey;
 uint256 totalOriginalConsiderationItems;
}

关键：

offer：我愿意给出什么（NFT、ERC20、ETH）
consideration：我期望换回什么（同样可以是任意组合）

这种"我给 X，要 Y"的对称结构能表达几乎所有交易类型——固定价、拍卖、套件、批量、租赁、转移……

三、典型订单形态

1. 固定价出售

1
2


offer: [NFT_A]
consideration: [10 ETH]

我（offerer）给出 NFT_A，要求 10 ETH。

2. 收 offer

1
2


offer: [10 ETH]
consideration: [NFT_A]

我给 10 ETH，要求 NFT_A。任何持有 NFT_A 的人可以接受。

3. 套件交易（Bundle）

1
2


offer: [NFT_A, NFT_B, NFT_C]
consideration: [25 ETH]

打包卖三个 NFT，要求 25 ETH。

4. 物物交换

1
2


offer: [NFT_A]
consideration: [NFT_B + 1 ETH]

用我的 NFT_A 换你的 NFT_B 加 1 ETH 找零。

5. 带版税

1
2
3
4
5
6


offer: [NFT_A]
consideration: [
 9 ETH → seller,
 0.75 ETH → marketplace fee,
 0.25 ETH → creator royalty
]

consideration 是数组——支持把"售价"拆给多方。

四、撮合：take 和 fulfill

订单创建后挂在链下（OpenSea 后端数据库）——只在被 fulfill 时才上链。

几种 fulfill 函数

1
2
3
4
5


fulfillBasicOrder() // 最简单的固定价
fulfillOrder() // 标准订单
fulfillAdvancedOrder() // 带 criteria（如"任意 BAYC"）
fulfillAvailableAdvancedOrders() // 批量撮合多个订单
matchAdvancedOrders() // 多个订单互相匹配

fulfillBasicOrder 是最高频的——OpenSea 80% 的交易走它。它对最常见的"NFT 换 ETH/WETH/ERC20"做了特殊 Gas 优化：

减少 storage 读写
跳过不必要的检查
更短的 calldata 编码

五、Conduit：授权管理的核心创新

Wyvern 让每个用户部署独立代理合约——首次使用又贵又慢。Seaport 用 Conduit 解决：

flowchart LR
 User[用户] -->|approve once| Conduit[共享 Conduit]
 Seaport -->|on fulfill| Conduit
 Conduit -->|safeTransferFrom| Token

Conduit 是共享合约——多个用户共用一个 Conduit
用户只需 approve 一次 Conduit——之后所有 Seaport 交易都走它
合约部署费用全市场用户共担

OpenSea 自己有个官方 Conduit，但任何人可以创建自己的 Conduit——这是 Seaport 设计可扩展性的体现。

六、Zone：可选的"裁判"

zone 字段允许订单挂一个可选的裁判合约——成交前 Seaport 会调用 zone 的 validateOrder：

1
2
3


function validateOrder(
 ZoneParameters calldata zoneParameters
) external returns (bytes4 validOrderMagicValue);

zone 能做：

白名单检查——只允许 KYC 用户成交
价格保护——市场价剧烈波动时拒绝成交
延时撮合——某条件未达到时阻止
链下签名验证——用户最后确认才放行

zone 让 Seaport 可以扩展协议行为而不改 Seaport 本身——是关键的"开放性"设计。

七、Offerer = 0：开放成交

Seaport 支持一种特殊设计——offerer 写成 address(0)：

1
2
3


offerer: 0x0
offer: [10 ETH]
consideration: [NFT_A]

这表示"任何提供 NFT_A 的人，10 ETH 是给你的"——OpenSea 的『接收 offer』功能就是这么实现的。

八、为什么 Seaport 比 Wyvern 省 Gas

	Wyvern	Seaport
个人代理	必须部署	共享 Conduit
撮合调用次数	12+	4-6
Calldata	大量重复	紧凑编码
storage 读写	多	少
实际 Gas	~250K	~150K

OpenSea 上线 Seaport 的第一周——用户节省了上千万美元 Gas。

九、安全设计

Seaport 经过多次审计（OpenZeppelin、Trail of Bits 等）+ 公开 bug bounty——但仍有一些值得关注的设计点：

1. 订单签名

订单是 EIP-712 签名——可读签名内容，但用户仍要小心钓鱼网站让你签复杂订单。

2. nonce 管理

每个订单有 nonce——取消的方式有两种：

调用 incrementCounter()——一次性把所有未成交订单作废
单独 cancel(orderHash)

历史上有用户误调 incrementCounter 把所有挂单作废——成本是一次 Gas。

3. 无限授权

approve Conduit 时通常是无限授权——Conduit 被攻破的话所有授权用户都受影响。OpenSea 的 Conduit 经过严格审计但用户应该知道这个风险。

4. zone 的双刃剑

恶意 zone 可以任意拒绝合法成交——用户接受订单时要确认 zone 是可信的。

十、Seaport 1.x 之后的演进

OpenSea 持续迭代 Seaport：

Seaport 1.4 / 1.5：引入"协议版本"管理、性能优化
Seaport 1.6：原生支持 ERC-2981 版税
未来：跨链交易、链下撮合 + 链上结算

Seaport 协议本身完全开源（MIT 协议）——任何项目都能直接用，不绑定 OpenSea。Blur、LooksRare 等竞争对手都在用 Seaport 或它的衍生版。

十一、对开发者的意义

如果你做 NFT 相关产品：

直接用 Seaport SDK——@opensea/seaport-js 已经封装好所有细节
理解 Order 结构——能让你设计出更灵活的业务（套件、订阅、租赁）
学习 Conduit + Zone 设计——是协议级"模块化"的范例
关注 EIP-712 签名规范——前端怎么 sign，后端怎么 verify

如果你做协议设计——Seaport 是当代 Solidity 设计的最佳学习材料之一：

Gas 优化的极致追求
模块化扩展能力（zone、conduit）
复杂业务的简洁抽象

小结

把全文压一句：

Seaport 用『offer / consideration』的对称模型 + Conduit 共享授权 + Zone 可扩展裁判，把 NFT 交易的灵活性和 Gas 效率推到了新的高度。

工程要点：

任何 NFT 业务都可以用 Order 结构表达
Conduit 解决了"每用户部署代理合约"的痛
Zone 让协议可扩展而不需要改 Seaport 本身
fulfillBasicOrder 是高频路径，专门优化过
EIP-712 签名让用户能看清自己签了什么

理解 Seaport，理解的不只是 OpenSea——是 2024 年 NFT 协议设计的范式。

NFT 标准选型与场景实践

Thu, 23 Jun 2022 16:00:00 +0800

两个标准都叫"NFT"，但它们解决的问题不同

新人接触 NFT 时常被这两个标准的并存搞晕：

ERC-721：CryptoPunks、Bored Ape、CryptoKitties 都是这个标准
ERC-1155：Decentraland 道具、Enjin 卡牌、OpenSea 创作工具

它们都是 NFT，但底层模型完全不同：

ERC-721 一个合约管理一系列独一无二的 token，每个 tokenId 唯一。

ERC-1155 一个合约管理多种 token，每种 token 可以有多个——既可以是 NFT，也可以是 SemiFungible，甚至 Fungible。

理解这两个标准的边界，决定了你写 NFT 项目时该选哪个、为什么选。

一、ERC-721：经典的"单一 NFT"

ERC-721 由 Dieter Shirley、William Entriken 等人于 2018 年提出（EIP-721）。核心理念——每个 token 唯一：

1
2
3
4
5
6
7


interface IERC721 {
 function ownerOf(uint256 tokenId) external view returns (address);
 function balanceOf(address owner) external view returns (uint256);
 function transferFrom(address from, address to, uint256 tokenId) external;
 function approve(address to, uint256 tokenId) external;
 // ... 其他
}

每个 tokenId 对应一个独一无二的资产。一只 BAYC 猴子、一张 CryptoKitty——对应一个 tokenId。

数据结构

1
2


mapping(uint256 => address) private _owners; // tokenId → owner
mapping(address => uint256) private _balances; // owner → 持有数量

典型操作

1
2
3
4
5
6
7
8


// 铸造一个 token
_owners[tokenId] = to;
_balances[to] += 1;

// 转账
_owners[tokenId] = newOwner;
_balances[from] -= 1;
_balances[to] += 1;

ERC-721 的特性

每个 tokenId 唯一——一个 owner，不存在"持有多少"
每个 token 一段元数据——通过 tokenURI(tokenId) 取
批量操作要循环 N 次——转 100 个 NFT 要 100 次 transferFrom

二、ERC-1155：多代币 + 半同质

ERC-1155 由 Enjin 团队 2018 年提出（EIP-1155），针对 ERC-721 的几个痛点：

痛点 1：游戏里有大量同种道具

ERC-721 模型下，“100 把同样的剑"要 100 个不同 tokenId、100 次铸造、100 次转账——Gas 成本爆炸。

痛点 2：合约碎片化

每个游戏出一种 NFT 都要部署一个新合约——以太坊上充斥着 1 万个仅区分一个游戏内物品的合约。

痛点 3：不能批量

ERC-721 没有 safeBatchTransferFrom——电商场景里"一键购买 5 件商品"做不到。

ERC-1155 的解法

一个合约管理多种 id，每种 id 可以有多份。

1
2
3
4
5
6


interface IERC1155 {
 function balanceOf(address account, uint256 id) external view returns (uint256);
 function balanceOfBatch(address[] accounts, uint256[] ids) external view returns (uint256[]);
 function safeTransferFrom(address from, address to, uint256 id, uint256 amount, bytes data) external;
 function safeBatchTransferFrom(address from, address to, uint256[] ids, uint256[] amounts, bytes data) external;
}

注意 balanceOf 多了 (account, id)——同一个 id 可以有多份。

数据结构

1
2


mapping(uint256 => mapping(address => uint256)) private _balances;
// _balances[tokenId][owner] = 持有数量

三、能力对比表

	ERC-721	ERC-1155
token 模型	每 id 唯一	每 id 可有多份
适合 NFT	✓	✓ （amount = 1 等于 NFT）
适合 Fungible	✗	✓
批量转账	✗（要循环）	✓ `safeBatchTransferFrom`
批量查询余额	✗	✓ `balanceOfBatch`
Gas（批量场景）	高	显著更低
metadata	tokenURI(id)	uri(id)（可用 {id} 占位符）
approve 粒度	单 token	全合约（setApprovalForAll）
钱包/工具支持	几乎全部	主流支持，部分老钱包不支持
适用场景	头像、艺术、收藏品	游戏道具、批量、组合资产

四、Gas 成本：ERC-1155 的杀手级优势

铸造 100 个相同道具：

1
2
3
4
5
6
7


// ERC-721
for (uint i = 0; i < 100; i++) {
 _mint(player, nextTokenId++); // 100 次 SSTORE
}

// ERC-1155
_mint(player, ITEM_SWORD, 100, ""); // 1 次 SSTORE（balance = 100）

实测对比（铸造 100 件相同道具）：

方案	Gas 消耗
ERC-721	~3,500,000
ERC-1155	~80,000

差距 40 倍。批量转账的差距类似。

这是为什么链游、批量市场几乎都选 ERC-1155——同等业务，Gas 成本压到几十分之一。

五、适用场景

选 ERC-721 的场景

每个 token 独一无二：头像、PFP、艺术品、稀有收藏
每个 token 元数据完全不同：CryptoPunks 每个都不一样
品牌效应：BAYC、Doodles 这种"个体认知度"项目——单合约、单 tokenId

选 ERC-1155 的场景

游戏道具：剑、药水、卡牌——同种物品多份
门票 / 凭证：演唱会门票每张相同但要发几千份
批量操作：电商商品、物流凭证
混合资产：一个合约里既有可堆叠物品，又有独一无二的稀有 NFT
组合金融产品：一个合约里管理 N 种衍生品

一些灰色地带

限量版艺术品（一种艺术 100 个相同复制品）：ERC-1155 更合适
演唱会门票（每张序列号不同）：ERC-721 更合适
Loot 这种链上随机生成：ERC-721 元数据 on-chain 更合适

判断关键：“这种 token 会有多份吗？"——会就 ERC-1155，不会就 ERC-721。

六、metadata 的差异

ERC-721 的 tokenURI

每个 tokenId 一个 URI：

1
2
3


function tokenURI(uint256 tokenId) public view returns (string memory) {
 return string(abi.encodePacked(baseURI, tokenId.toString()));
}

返回的 JSON：

1
2
3
4
5
6


{
 "name": "BAYC #4521",
 "description": "...",
 "image": "ipfs://Qm.../4521.png",
 "attributes": [{"trait_type": "Background", "value": "Gold"}]
}

ERC-1155 的 uri

支持 {id} 占位符：

1
2
3


function uri(uint256 id) public view returns (string memory) {
 return "https://example.com/api/{id}.json";
}

客户端拿到后用 64 位 hex（补全 0x 前缀）替换 {id}——这样一个 URI 模板能服务所有 id，省心。

但实际上很多 ERC-1155 项目仍然给每个 id 单独配 URI——尤其是游戏道具，每种道具一段元数据。

七、approve 模型差异

ERC-721

approve(to, tokenId)：授权某地址转某个 token
setApprovalForAll(operator, true)：授权某地址操作所有 token

ERC-1155

没有单 token approve——只能 setApprovalForAll
这意味着用户必须信任整个 operator（如交易市场）能动他全部 1155 资产

这是 ERC-1155 在用户安全侧的劣势——授权范围更大、撤销更重要。

八、写一个 ERC-1155 合约

OpenZeppelin 提供了一行能用的实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract GameItems is ERC1155, Ownable {
 uint256 public constant SWORD = 0;
 uint256 public constant SHIELD = 1;
 uint256 public constant POTION = 2;
 uint256 public constant LEGENDARY = 3;

 constructor() ERC1155("https://example.com/api/{id}.json") {
 _mint(msg.sender, SWORD, 100, "");
 _mint(msg.sender, SHIELD, 200, "");
 _mint(msg.sender, POTION, 500, "");
 _mint(msg.sender, LEGENDARY, 1, ""); // 唯一稀有 NFT
 }

 function mint(address to, uint256 id, uint256 amount) external onlyOwner {
 _mint(to, id, amount, "");
 }

 function mintBatch(address to, uint256[] memory ids, uint256[] memory amounts)
 external onlyOwner {
 _mintBatch(to, ids, amounts, "");
 }
}

注意 LEGENDARY 的 amount = 1——这相当于在同一个合约里用 ERC-1155 表达 NFT。这是 ERC-1155 的灵活性。

九、踩坑提醒

1. `safeTransferFrom` 接收方要实现钩子

如果接收方是合约，必须实现 onERC721Received / onERC1155Received，否则转账 revert。

1
2
3
4


function onERC1155Received(address, address, uint256, uint256, bytes calldata)
 external pure returns (bytes4) {
 return this.onERC1155Received.selector;
}

2. ERC-1155 的 transfer 必须带 amount

1
2
3
4
5


// ERC-721 的语法
contract.transferFrom(from, to, tokenId);

// ERC-1155 的语法
contract.safeTransferFrom(from, to, id, amount, "");

NFT 性质的 token 永远 amount = 1。

3. metadata 占位符兼容

{id} 占位符是 ERC-1155 标准里规定的——实际平台支持参差不齐。OpenSea / 区块链浏览器多数支持，但小钱包可能不识别——保险起见每个 id 单独配 URI。

4. 不要混用模型

同一个项目里要么用 ERC-721 要么用 ERC-1155，不要在一个集合里两种都发。买家会困惑：

“为什么这个 NFT 在我的钱包里看不到？”
“为什么我数量是 5 但只能转 1？”

5. 老钱包可能不支持 ERC-1155

Trust Wallet、imToken 较新版本支持，但 5 年前的老钱包可能识别不出 1155——目标用户群里要有市场调研。

十、其他相关标准

NFT 生态的相关标准还有：

ERC-2981：版税标准——让 NFT 在二级市场卖出时自动扣版税给原作者
EIP-2535：Diamond 合约标准——超大合约的模块化升级
ERC-4907：可租赁 NFT
ERC-721A：Azuki 优化的批量铸造 ERC-721（Gas 比标准 721 低很多）

🔥 ERC-721A 在某种程度上是对 ERC-1155 的"反击”——保留 ERC-721 的语义但优化批量铸造 Gas，是大量 PFP 项目的选择。

小结

把全文压一句：

ERC-721 表达『每个唯一』，ERC-1155 表达『多种 + 多份』。一个合约一个项目就用 721；多类型批量场景必上 1155。

工程选型：

PFP / 艺术 / 收藏 → ERC-721（或 ERC-721A）
游戏 / 批量 / 多种 → ERC-1155
混合需求 → ERC-1155（amount=1 表 NFT，amount>1 表数量）
二级市场版税 → 配 ERC-2981

NFT 生态还在演进，理解这些标准的边界比追新更重要——搞清"业务场景该用哪个”，远比"哪个最先进"实用。

NFT on 牛哥聊技术

OpenSea Seaport 协议详解

写在前面

一、Wyvern 的痛点

二、Seaport 的核心抽象：Order

三、典型订单形态

1. 固定价出售

2. 收 offer

3. 套件交易（Bundle）

4. 物物交换

5. 带版税

四、撮合：take 和 fulfill

几种 fulfill 函数

五、Conduit：授权管理的核心创新

六、Zone：可选的"裁判"

七、Offerer = 0：开放成交

八、为什么 Seaport 比 Wyvern 省 Gas

九、安全设计

1. 订单签名

2. nonce 管理

3. 无限授权

4. zone 的双刃剑

十、Seaport 1.x 之后的演进

十一、对开发者的意义

小结

NFT 标准选型与场景实践

两个标准都叫"NFT"，但它们解决的问题不同

一、ERC-721：经典的"单一 NFT"

数据结构

典型操作

ERC-721 的特性

二、ERC-1155：多代币 + 半同质

痛点 1：游戏里有大量同种道具

痛点 2：合约碎片化

痛点 3：不能批量

ERC-1155 的解法

数据结构

三、能力对比表

四、Gas 成本：ERC-1155 的杀手级优势

五、适用场景

选 ERC-721 的场景

选 ERC-1155 的场景

一些灰色地带

六、metadata 的差异

ERC-721 的 tokenURI

ERC-1155 的 uri

七、approve 模型差异

ERC-721

ERC-1155

八、写一个 ERC-1155 合约

九、踩坑提醒

1. safeTransferFrom 接收方要实现钩子

2. ERC-1155 的 transfer 必须带 amount

3. metadata 占位符兼容

4. 不要混用模型

5. 老钱包可能不支持 ERC-1155

十、其他相关标准

小结

1. `safeTransferFrom` 接收方要实现钩子