以太坊 on 牛哥聊技术

常见 EVM 提案速查：ERC 与 EIP 的核心标准

Sat, 14 Feb 2026 15:30:00 +0800

写在前面

Web3 生态里 ERC 和 EIP 提案多到眼花缭乱——

ERC-20 / 721 / 1155 是耳熟能详的代币标准
EIP-1559 改变了以太坊的费用模型
EIP-712 让钱包能展示可读签名
ERC-2981 解决了版税问题

新人看到这些数字号就头疼——每个具体在做什么？哪些重要哪些次要？

本文给一份能查的清单——按用途分类，每个标准用一段讲清楚是什么、为什么重要、典型用法。适合放到 Notion / Obsidian 里作为日常查询。

一、ERC vs EIP

先把概念分清：

EIP（Ethereum Improvement Proposal）：以太坊改进提案——任何关于以太坊的改进都是 EIP
ERC（Ethereum Request for Comments）：EIP 的一类子集，专门用于应用层标准（代币、签名、接口等）

简单理解：所有 ERC 都是 EIP，但不是所有 EIP 都是 ERC。

二、代币标准

ERC-20：可替代代币

最经典的代币标准。USDC、USDT、UNI、所有 DeFi 代币都是 ERC-20。

核心接口：

1
2
3
4
5
6
7
8
9


function totalSupply() external view returns (uint256);
function balanceOf(address) external view returns (uint256);
function transfer(address to, uint256 value) external returns (bool);
function approve(address spender, uint256 value) external returns (bool);
function allowance(address owner, address spender) external view returns (uint256);
function transferFrom(address from, address to, uint256 value) external returns (bool);

event Transfer(address indexed from, address indexed to, uint256 value);
event Approval(address indexed owner, address indexed spender, uint256 value);

最重要的标准——不可替代。

ERC-721：非同质化代币（NFT）

每个 token 唯一。CryptoPunks、BAYC、CryptoKitties 都是 ERC-721。

1
2
3
4
5


function ownerOf(uint256 tokenId) external view returns (address);
function safeTransferFrom(address from, address to, uint256 tokenId) external;
function approve(address to, uint256 tokenId) external;
function setApprovalForAll(address operator, bool approved) external;
function tokenURI(uint256 tokenId) external view returns (string);

每个 tokenId 一段独立元数据。

ERC-1155：多代币标准

一个合约管理多种 token，每种可以有多份。游戏道具、批量场景的事实标准。

1
2
3


function balanceOf(address account, uint256 id) 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;

支持批量操作——比 ERC-721 在多 token 场景下省 40 倍 Gas。

ERC-777：增强版 ERC-20（争议）

试图改进 ERC-20——支持 hooks（接收方能拦截转账）、operator 等。

但重入攻击风险高——一些项目（imBTC）因为它被攻击。社区主流是不用 ERC-777——直接 ERC-20 + ERC-2612 更安全。

ERC-4626：代币化金库（Tokenized Vault）

标准化"存款进 vault 拿 share token"的接口。Yearn、Aave V3 等收益策略合约用它。

1
2
3
4


function asset() external view returns (address);
function totalAssets() external view returns (uint256);
function deposit(uint256 assets, address receiver) external returns (uint256 shares);
function withdraw(uint256 assets, address receiver, address owner) external returns (uint256 shares);

所有 yield aggregator / lending protocol 都应该实现 ERC-4626——可组合性大增。

三、接口与发现

ERC-165：标准接口检测

让合约能查询"另一个合约是否实现某个接口"。

1
2
3
4
5
6


interface IERC165 {
 function supportsInterface(bytes4 interfaceId) external view returns (bool);
}

// 用法
IERC165(addr).supportsInterface(0x80ac58cd); // 是否是 ERC-721

interfaceId 是接口所有函数 selector 的 XOR——编译时计算。

ERC-721、ERC-1155 都强制实现 ERC-165。

ERC-1820：通用注册表

像 ERC-165 但更通用——支持"为某地址绑定接口实现"。

1

ERC1820Registry.setInterfaceImplementer(addr, interfaceHash, implementer);

ERC-777 用它做 hook 注册——但因为 777 不流行，1820 也只在少数场景用。

四、签名标准

EIP-712：结构化数据签名

让钱包能显示可读的签名内容，而不是一串十六进制 hash。

老的 eth_sign：

1

请签名：0xa1b2c3d4e5f6...

EIP-712：

1
2
3
4
5
6


请签名：
 Permit:
 owner: 0xAlice...
 spender: 0xUniswap...
 value: 100 USDC
 deadline: 2026-12-31

所有现代 dapp 的签名都用 EIP-712——不仅可读，还防钓鱼。

EIP-2612：Permit（无 Gas approve）

用 EIP-712 签名替代 ERC-20 的 approve 调用——用户不付 approve 的 Gas。

1
2
3
4


function permit(
 address owner, address spender, uint256 value,
 uint256 deadline, uint8 v, bytes32 r, bytes32 s
) external;

用户线下签 permit，dapp 把签名 + 操作打包成一笔 tx——省一笔 approve Gas + 改善体验。

新代币几乎都实现 EIP-2612。

EIP-1271：合约签名验证

让"智能账户合约"也能"签名"——isValidSignature 让合约模拟 EOA 签名。

1

function isValidSignature(bytes32 hash, bytes memory signature) external view returns (bytes4);

ERC-4337 智能账户、Safe 多签都用它。

五、版税与市场

EIP-2981：NFT 版税标准

标准化 NFT 二级市场的版税分配。

1

function royaltyInfo(uint256 tokenId, uint256 salePrice) external view returns (address receiver, uint256 royaltyAmount);

OpenSea、Blur、LooksRare 等市场调用这个接口确定版税收款方和金额。

新 NFT 项目必实现 EIP-2981——否则只能依赖每个市场各自的版税设置。

六、Gas 与费用

EIP-1559：基础费 + 优先费

2021 年伦敦升级——改变了以太坊的费用模型。

老模型：完全拍卖，gasPrice 用户出多少都行——网络拥堵时 gas 飙升不可预测。

EIP-1559 模型：

baseFee：每个 block 由协议算出，会被 burn 销毁
priorityFee（tip）：用户给矿工的小费

1
2
3
4
5


// 现代以太坊 tx
{
 maxFeePerGas: ..., // 用户愿意付的最高总 fee
 maxPriorityFeePerGas: ... // 给矿工的小费
}

好处：费用更可预测、ETH 经济学进入通缩。

EIP-1283 / 2200 / 2929：Gas 调整

历史上多次调整 SSTORE / SLOAD 的 Gas 成本，主要影响合约 gas 估算与底层操作成本。经典副作用是 EIP-2929（Berlin，2021-04）抬高 SLOAD/CALL 成本后，依赖固定 2300 gas 的 transfer / send 在接收方为合约时不再可靠——这是真实改变了应用层的可用性，并不只是"算 gas 时数字变了"。

EIP-3074 / EIP-7702：让 EOA 也能"批量执行"

让 EOA 也能像智能账户一样"批量执行"。EIP-3074（AUTH / AUTHCALL）方向几次评审后被放弃，由更轻量的 EIP-7702 取代——后者已随 Pectra 升级（2025-05）上线主网。EIP-7702 让 EOA 在一笔交易内"临时"挂上一段合约代码，从而原子地批量调用、付费代付（gas sponsor）、与 ERC-4337 形成互补。

EIP-4844：Proto-Danksharding（2024 年上线）

引入 blob transaction——L2 发数据成本大降。

L2（Optimism、Arbitrum、zkSync 等）用 blob 替代 calldata 提交批数据——Gas 成本降到原来 10%。

七、账户抽象

ERC-4337：账户抽象

智能合约账户标准——不需要修改 Layer1 协议。

让用户的"账户"是一个智能合约——可以：

多签（不只是私钥控制）
社交恢复（朋友帮你恢复账户）
付 Gas 不需要 ETH（用 USDC 付 Gas）
批量交易

ERC-4337 的核心是 EntryPoint 合约 + UserOperation 数据结构 + Bundler 角色。

这是 Web3 走向主流的关键基础设施之一——降低普通用户的使用门槛。

八、合约升级与可拥有

EIP-1967：标准 Proxy Storage Slots

标准化 Proxy 合约的存储槽位置，避免槽位冲突。

1
2


implementation: keccak256("eip1967.proxy.implementation") - 1
admin: keccak256("eip1967.proxy.admin") - 1

OpenZeppelin Upgrades 用的就是这个。

EIP-1822：UUPS 代理

把"升级逻辑"放进 implementation 合约——proxy 更精简、Gas 更省。

OpenZeppelin 现在推荐 UUPS 而不是 Transparent Proxy。

EIP-2535：Diamond 标准

一个 proxy + 多个 facet——绕开合约 24KB 字节码上限。

适合超大型协议（Aavegotchi 是典型案例）。

九、其他常用提案

ERC-2470：Singleton Factory

部署在所有链上的"单例工厂"——通过 CREATE2 让你的合约在所有链上有相同地址。

ERC-3156：Flash Loan 标准

闪电贷标准。Aave、dYdX、Maker 都实现。

1

function flashLoan(IERC3156FlashBorrower receiver, address token, uint256 amount, bytes data) external returns (bool);

EIP-1167：Minimal Proxy（克隆合约）

用 EVM bytecode 技巧把 proxy 合约压缩到 ~60 字节——部署成本极低。

适合"工厂部署大量同类合约"场景（如 Uniswap pair、Compound cToken）。

EIP-3675：The Merge

2022 年的合并——POW 转 POS。

不影响应用层 API，但让以太坊能耗降低 99%。

EIP-4626（再提一下）

代币化 vault 标准——已经成事实标准。

EIP-3855：PUSH0 操作码

添加 PUSH0 操作码（替代 PUSH1 0）——Solidity 0.8.20+ 利用，编译产物更小。

十、根据用途的速查

做代币

同质化 → ERC-20 + EIP-2612（permit）
NFT → ERC-721 + EIP-2981（版税）
游戏 / 多种 → ERC-1155

做 DeFi

借贷 / Vault → ERC-4626
闪电贷 → ERC-3156
自动批准 → EIP-2612

做 NFT 市场

标准支持 → ERC-721 + ERC-1155 + ERC-2981
接口检测 → ERC-165

做钱包

签名 → EIP-712（必须）
智能合约签名 → EIP-1271
账户抽象 → ERC-4337

做 L2 / Rollup

数据可用性 → EIP-4844 (blobs)
跨链一致地址 → ERC-2470

做可升级合约

标准槽位 → EIP-1967
UUPS 代理 → EIP-1822
大合约模块化 → EIP-2535

十一、追踪新提案

主要资源：

EIP 主仓库：github.com/ethereum/EIPs
EIP 状态：每个提案有 Draft / Review / Last Call / Final / Withdrawn 状态
Magicians 论坛：ethereum-magicians.org
All Core Devs 会议纪要：核心开发者的双周会议

新提案出来时关注 status 是否 Final——只有 Final 才算"标准"。Draft / Review 阶段的提案随时可能改。

小结

把全文压一句：

ERC / EIP 不是"考点"——是 Web3 协议设计的实战手册。掌握核心标准让你能站在巨人的肩膀上做事，而不是重新发明轮子。

工程纪律：

代币必看 ERC-20/721/1155
签名必看 EIP-712 / EIP-2612
可升级必看 EIP-1967
追新关注 ERC-4337 / EIP-4844
不要造已有标准的轮子——用 OpenZeppelin

收藏本文作为速查——下次遇到陌生编号时不用再 Google 半天。

不可变的合约如何「升级」？聊聊 Solidity 合约升级模式

Mon, 02 Sep 2024 20:00:00 +0800

一个让所有以太坊新手都困惑的悖论

智能合约最被反复强调的特性，是 不可变（immutable）——代码部署上链之后，一行都不能改。

但你只要在生产里跑过几个月就会发现一个现实：

代码会有 bug
业务会有新需求
协议会被攻击，要打补丁

这两件事看起来根本是矛盾的——承诺不可变，又必须能改。

整个"合约升级"这个话题，本质上就是在回答：怎么在不破坏不可变承诺的前提下，让合约的行为可以演进？

下面我们从最朴素的方案开始，一路讲到现在主流的代理模式、UUPS、Beacon、Diamond，把这些方案的来龙去脉、踩坑点和适用边界一次性讲清楚。

一、最朴素的方案：合约迁移（Contract Migration）

最直观的思路：既然合约不能改，那就部署一份新的。

流程大致是：

部署 TokenV2
写一个迁移脚本，把 TokenV1 上每个用户的余额读出来，写进 TokenV2
通知所有依赖方（前端、其他合约、CEX、用户）：地址换了，请用新的

这条路在小协议里偶尔还会用到，但作为通用方案，它的痛点很硬：

地址变了——所有依赖你的合约和应用都要改地址。DeFi 里这意味着流动性池要重建、用户授权要重做，几乎等于一次"硬分叉"。
状态迁移成本高——用户多的时候，光迁移就要几十万美元 Gas，且过程中可能有人在动账。
信任成本极高——用户怎么相信新合约里的余额没被篡改？

所以业界很快意识到：迁移不是"升级"，是"换房"。真正的升级，应该让地址不变、状态延续，只换"大脑"。

二、核心技巧：`delegatecall` 与代理模式

要做到"地址不变换大脑"，离不开 EVM 提供的一个特殊指令——delegatecall。

一句话理解 `delegatecall`

普通调用 call：用别人的代码、操作别人的存储。 delegatecall：用别人的代码、操作自己的存储。

也就是说，合约 A 通过 delegatecall 调合约 B 的某个函数时，执行的是 B 的字节码，但 msg.sender、msg.value、所有存储读写都发生在 A 上。

这就给了我们一个大胆的想法——

让一个只负责存数据的合约（Proxy），通过 delegatecall 把所有调用都转发给另一个只负责跑逻辑的合约（Logic）。

升级时只需要把 Proxy 指向的 Logic 地址换掉，Proxy 的地址和存储完全不变。

关系图

flowchart LR
 User([用户 / DApp])
 Proxy["Proxy 合约
(地址不变 + 存储)"]
 LogicV1["Logic V1
(纯代码)"]
 LogicV2["Logic V2
(升级后)"]

 User -- 调用 --> Proxy
 Proxy -- delegatecall --> LogicV1
 Proxy -. 升级后改指向 .-> LogicV2

一个最小可运行的代理

 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
26


contract MinimalProxy {
 address public implementation; // 当前指向的逻辑合约
 address public admin;

 constructor(address _impl) {
 implementation = _impl;
 admin = msg.sender;
 }

 function upgrade(address _newImpl) external {
 require(msg.sender == admin, "not admin");
 implementation = _newImpl;
 }

 fallback() external payable {
 address impl = implementation;
 assembly {
 calldatacopy(0, 0, calldatasize())
 let result := delegatecall(gas(), impl, 0, calldatasize(), 0, 0)
 returndatacopy(0, 0, returndatasize())
 switch result
 case 0 { revert(0, returndatasize()) }
 default { return(0, returndatasize()) }
 }
 }
}

fallback 把任何调用都 delegatecall 到 implementation。换 implementation 就等于升级。

看起来挺优雅，但魔鬼藏在细节里——存储布局。

三、升级最大的坑：存储布局冲突

delegatecall 操作的是 Proxy 的存储，但用的是 Logic 的代码。这就要求两件事：

Logic 合约里读写哪个存储槽，必须和 Proxy 里实际的存储槽对得上
升级前后两版 Logic 之间，存储槽不能错位

举个例子。假设 Logic V1 是这样：

1
2
3
4


contract LogicV1 {
 address public owner; // slot 0
 uint256 public totalSupply; // slot 1
}

某天我们想升级，写了个看起来合情合理的 V2：

1
2
3
4
5


contract LogicV2 {
 uint256 public totalSupply; // slot 0 ← 和 V1 的 owner 撞了！
 address public owner; // slot 1
 uint256 public newField; // slot 2
}

升级完，原来 owner 的位置被当成了 totalSupply，瞬间把一个地址解读成天文数字的代币总量——协议直接报废。

三条铁律

不能删除已有变量
不能调整变量顺序
不能改变量类型（包括 uint256 ↔ int256、定长数组长度等）

新版本想加字段？只能在末尾追加。

Storage Gap 习惯（OpenZeppelin 4.x 时代的做法）

时效性更新：本节描述的 __gap 模式是 OpenZeppelin 4.x 的标准做法。OpenZeppelin 5.0（2023-10）起的 contracts-upgradeable 包已经改用 ERC-7201 命名空间存储（Namespaced Storage Layout）——每个合约的 storage 字段被收进一个独立 struct，slot 从 keccak256(namespace) - 1 派生，升级加字段不再受顺序约束，也不再需要预留 __gap。新项目应该直接用 ERC-7201；老项目从 __gap 模式迁移到 ERC-7201 时要小心 storage layout 兼容。下面这段 __gap 写法仍然适用于 4.x 的基类继承场景（与 4.x 升级链路向后兼容）。

为了给未来"末尾追加"留余地，可继承的基类里通常会预留一段空槽：

1
2
3
4
5
6
7


contract MyUpgradeable {
 address public owner;
 uint256 public totalSupply;
 // ... 业务字段

 uint256[50] private __gap; // 给未来升级留 50 个槽
}

这是 OpenZeppelin 4.x 的标准做法。一旦未来要在基类加字段，就从 __gap 里"借"——既不破坏子类的存储布局，又不需要 fork 一份父类。

ERC-7201 的等价写法长这样（5.0+）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


contract MyUpgradeable {
 /// @custom:storage-location erc7201:myproject.storage.MyUpgradeable
 struct MyStorage {
 address owner;
 uint256 totalSupply;
 // ... 业务字段
 }

 // keccak256(abi.encode(uint256(keccak256("myproject.storage.MyUpgradeable")) - 1)) & ~bytes32(uint256(0xff))
 bytes32 private constant STORAGE_SLOT =
 0x...;

 function _s() private pure returns (MyStorage storage s) {
 bytes32 slot = STORAGE_SLOT;
 assembly { s.slot := slot }
 }
}

每个合约把自己的 storage 锁进独立命名空间——升级时加字段、调顺序、改基类继承都不会再撞槽。这是 5.x 在升级模型上最关键的一步。

升级前一定要做 storage layout 校验

存储布局错位的检查靠人肉是不现实的——升级链路必须有自动化校验把这个关。具体工具按你用的栈选：

Hardhat 栈：OpenZeppelin Upgrades Plugin（@openzeppelin/hardhat-upgrades）——升级前自动比对两版合约的存储布局，不兼容直接报错挡住。
Foundry 栈：openzeppelin-foundry-upgrades，或者直接 forge inspect <Contract> storageLayout 把新旧两版的 storage layout 输出成 JSON，在 CI 里做 diff。
更通用：Slither 的 slither-check-upgradeability 也能做静态布局比对。

形式不重要——一定要有一道自动检查。生产合约靠肉眼 review storage layout 早晚出事。

四、三种主流代理标准

代理模式发展到今天，演化出了三种主流形态。

1. Transparent Proxy（透明代理）

OpenZeppelin 早期推荐。它的核心问题是解决一个微妙的冲突——

如果 Proxy 自己有个函数叫 upgrade()，Logic 里也有个函数叫 upgrade()，用户调进来时到底是哪个执行？

Transparent Proxy 的解法是按调用者区分：

管理员调用 → 永远走 Proxy 自己的管理函数
普通用户调用 → 永远走 delegatecall 到 Logic

flowchart LR
 Admin([管理员]) -->|管理调用| ProxyAdmin["Proxy
(管理逻辑)"]
 User([普通用户]) -->|业务调用| ProxyDelegate["Proxy
(delegatecall)"]
 ProxyDelegate --> Logic["Logic 合约"]

简单可靠，但代价是 Proxy 里要存管理员判断逻辑，每次调用都多一次条件判断和 SLOAD，Gas 偏贵。

2. UUPS（ERC-1822，OZ 现在的默认推荐）

UUPS 的核心反转是——把升级逻辑搬进 Logic 合约。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


contract LogicUUPS {
 address public owner;

 function upgradeTo(address newImpl) external {
 require(msg.sender == owner, "not owner");
 // 通过 delegatecall 改的是 Proxy 自己的 implementation 槽
 assembly { sstore(_IMPL_SLOT, newImpl) }
 }
 // ... 其他业务函数
}

这样一来：

Proxy 极度精简，只有一个 fallback，Gas 最省
升级权限由 Logic 控制——这意味着 如果你升级到一个忘了写 upgradeTo 的新 Logic，合约就永远没法再升级了（一种"自爆开关"）

OpenZeppelin 现在更推荐 UUPS，但前提是开发者必须严格遵守"新版本永远要继承 UUPSUpgradeable“的规范，否则可能误锁死。

3. Beacon Proxy（信标代理）

前两种都是"一个 Proxy 对应一个 Logic”。如果你有 几百上千个同种合约（比如 Uniswap V3 工厂创建的众多池子），每次升级要逐一调用，成本难以承受。

Beacon Proxy 抽象出一个信标合约：

flowchart LR
 Beacon["Beacon
(只存当前 Logic 地址)"]
 Logic["Logic 合约"]

 P1["Pool Proxy 1"] -.读地址.-> Beacon
 P2["Pool Proxy 2"] -.读地址.-> Beacon
 P3["Pool Proxy ..."] -.读地址.-> Beacon

 P1 -.delegatecall.-> Logic
 P2 -.delegatecall.-> Logic
 P3 -.delegatecall.-> Logic

 Beacon -. 指向 .-> Logic

所有 Proxy 都从 Beacon 读"当前 Logic 地址"。升级时只改 Beacon 一处，所有 Proxy 同时生效。代价是每次调用多一次跨合约读地址的 Gas。

方案	Gas 开销	升级权限位置	适用场景
Transparent Proxy	较高	Proxy	单实例、追求稳定保守
UUPS	最低	Logic	单实例、追求性能（OZ 默认推荐）
Beacon Proxy	中等	Beacon	多实例、需要批量同步升级

五、更激进的方案：Diamond（EIP-2535）

EVM 对单个合约的字节码大小有 24KB 的硬上限（EIP-170）。当协议复杂到一个 Logic 合约塞不下时，前面那些"单 Logic"的代理模式就不够用了。

Diamond 模式的思路是——一个 Proxy（Diamond），多个 Logic（Facet），按函数选择器路由。

flowchart TB
 User([用户调用])
 Diamond["Diamond Proxy
(查路由表 + delegatecall)"]
 F1["Facet A
转账逻辑"]
 F2["Facet B
治理逻辑"]
 F3["Facet C
奖励逻辑"]
 F4["Facet ...
(可动态增删)"]

 User --> Diamond
 Diamond -- delegatecall --> F1
 Diamond -- delegatecall --> F2
 Diamond -- delegatecall --> F3
 Diamond -- delegatecall --> F4

每个 Facet 只实现一部分函数，Diamond 内部维护一张 selector → facet address 的路由表，调用进来时查表然后 delegatecall。升级时可以按 facet 增、删、换，粒度比单 Logic 细得多。

代价是复杂度陡升——存储布局要按"Diamond Storage"的命名空间约定写、调试链路更长、对应工具链不如 OZ 主流模式成熟。不是协议规模真的超过单合约能力，不要轻易上 Diamond（Aavegotchi 是公认上得最成功的案例之一）。

六、不能忽略的工程细节

1. 没有 constructor，只有 initializer

constructor 在合约部署时执行，只对 Logic 自己的存储生效，不会写到 Proxy 的存储。所以可升级合约的初始化必须放在一个普通函数里，靠只能调用一次的修饰符保护：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


contract MyLogic {
 bool private initialized;
 address public owner;

 function initialize(address _owner) external {
 require(!initialized, "already initialized");
 initialized = true;
 owner = _owner;
 }
}

OpenZeppelin 提供了 Initializable 基类，标准做法是用 initializer 修饰符。

2. 部署后立刻调用 initializer

如果部署完 Logic 不立刻初始化，任何人都可以抢先调一次 initialize 把自己设成 owner。这种漏洞历史上发生过多次。脚本部署 Proxy 时要用 atomicallyDeployAndInitialize 之类的封装，把"部署 + 初始化"放进同一个交易。

3. 升级权限 = 协议生死开关

控制 upgrade 的私钥，等于握有协议的全部资金权。任何成熟协议都会用：

多签：避免单点泄密
Timelock：提案到生效之间留出延迟（通常 24~72 小时），让用户有撤资时间
DAO 治理投票：进一步去中心化，把升级决策交给代币持有者

如果你看到一个号称"去中心化"的协议，升级权在一把单签钥匙上——它在技术上和中心化产品没有任何区别。

七、可升级的代价：安全与去中心化的张力

可升级合约的存在，本身就违反了"不可变"的初心。

管理员可以悄悄换掉 Logic，把所有用户的资金转走——这是真实发生过的攻击。
审计的难度被放大：用户审计了今天的代码，明天升级后等于审了个寂寞。
形式化验证、不可变指标都失效：协议的安全保证从"代码"层退化为"运营方信誉 + 治理流程"层。

所以业界有一种相反的声音：真正成熟的协议应当逐步放弃可升级性。Uniswap V2/V3 的核心合约就是不可升级的——它的迭代靠"部署新协议、用户自愿迁移"完成，代价高，但换来了最强的信任。

作为协议设计者，你需要问自己：

“这个合约的升级权，是不是协议安全的天花板？”

如果答案是"是"，那就要尽一切努力收紧它——多签、Timelock、治理、最终弃管。

作为协议用户，你也要学会问：

“这个合约能升级吗？升级权在谁手里？有 Timelock 吗？”

回答不出来的协议，本质上就是一个许可型应用，无论它前端多花哨。

小结

把这一整圈讲下来，回到最初那个悖论——

智能合约的不可变是承诺，但现实的演进是必需。升级模式就是在两者之间做工程妥协的产物。

四种主流方案的本质：

合约迁移：放弃地址不变，老老实实换房
Transparent Proxy / UUPS：地址不变，靠 delegatecall 把存储和代码解耦
Beacon Proxy：多个 Proxy 共享一个 Logic 指针，批量升级
Diamond：突破合约大小上限，按 facet 灵活增删

而无论用哪种方案，真正的难点从来不是合约怎么写，而是升级权怎么管。技术层面可升级是简单的，治理层面让用户敢用一个可升级的合约，才是更难、也更重要的命题。

一句话收尾：

可升级是工程能力，不可升级是产品承诺，怎么在两者之间找平衡，是每一个协议设计者要回答的问题。

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

以太坊 on 牛哥聊技术

常见 EVM 提案速查：ERC 与 EIP 的核心标准

写在前面

一、ERC vs EIP

二、代币标准

ERC-20：可替代代币

ERC-721：非同质化代币（NFT）

ERC-1155：多代币标准

ERC-777：增强版 ERC-20（争议）

ERC-4626：代币化金库（Tokenized Vault）

三、接口与发现

ERC-165：标准接口检测

ERC-1820：通用注册表

四、签名标准

EIP-712：结构化数据签名

EIP-2612：Permit（无 Gas approve）

EIP-1271：合约签名验证

五、版税与市场

EIP-2981：NFT 版税标准

六、Gas 与费用

EIP-1559：基础费 + 优先费

EIP-1283 / 2200 / 2929：Gas 调整

EIP-3074 / EIP-7702：让 EOA 也能"批量执行"

EIP-4844：Proto-Danksharding（2024 年上线）

七、账户抽象

ERC-4337：账户抽象

八、合约升级与可拥有

EIP-1967：标准 Proxy Storage Slots

EIP-1822：UUPS 代理

EIP-2535：Diamond 标准

九、其他常用提案

ERC-2470：Singleton Factory

ERC-3156：Flash Loan 标准

EIP-1167：Minimal Proxy（克隆合约）

EIP-3675：The Merge

EIP-4626（再提一下）

EIP-3855：PUSH0 操作码

十、根据用途的速查

做代币

做 DeFi

做 NFT 市场

做钱包

做 L2 / Rollup

做可升级合约

十一、追踪新提案

小结

不可变的合约如何「升级」？聊聊 Solidity 合约升级模式

一个让所有以太坊新手都困惑的悖论

一、最朴素的方案：合约迁移（Contract Migration）

二、核心技巧：delegatecall 与代理模式

一句话理解 delegatecall

关系图

一个最小可运行的代理

三、升级最大的坑：存储布局冲突

三条铁律

Storage Gap 习惯（OpenZeppelin 4.x 时代的做法）

升级前一定要做 storage layout 校验

四、三种主流代理标准

1. Transparent Proxy（透明代理）

2. UUPS（ERC-1822，OZ 现在的默认推荐）

3. Beacon Proxy（信标代理）

五、更激进的方案：Diamond（EIP-2535）

六、不能忽略的工程细节

1. 没有 constructor，只有 initializer

2. 部署后立刻调用 initializer

3. 升级权限 = 协议生死开关

七、可升级的代价：安全与去中心化的张力

小结

NFT 标准选型与场景实践

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

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

数据结构

典型操作

ERC-721 的特性

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

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

痛点 2：合约碎片化

痛点 3：不能批量

ERC-1155 的解法

数据结构

二、核心技巧：`delegatecall` 与代理模式

一句话理解 `delegatecall`

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