智能合约 on 牛哥聊技术

Compound 协议解析：DeFi 借贷的奠基者

Tue, 28 Oct 2025 16:00:00 +0800

写在前面

DeFi 圈子里有几个绕不过去的奠基者协议：

MakerDAO：把法币概念引入链上（DAI 稳定币）
Uniswap：把 AMM（自动做市商）做到极致
Compound：把链上借贷做成可组合金融基础设施

Compound 由 Robert Leshner 和 Geoffrey Hayes 在 2018 年推出。它创造了几个让整个 DeFi 沿用至今的范式：

cToken 模型：把"存入资产"变成可流通的代币
算法利率：根据资金池利用率自动调整借贷利率
流动性挖矿（COMP 代币）：开启 DeFi 真正的"治理代币热"
预言机喂价：所有借贷依赖外部价格

如果你想理解 Aave、Venus、JustLend 等借贷协议——先吃透 Compound。本文讲清楚它的核心机制和工程价值。

一、Compound 在做什么

简单说——Compound 是一个去中心化的"借贷池"。任何人可以：

存入资产（USDC、ETH、DAI 等支持的资产）→ 赚利息
抵押资产借出（用你的存款做抵押借出别的资产）

flowchart LR
 Lender[出借人] -->|存入 USDC| Pool[(资金池)]
 Borrower[借款人] -->|抵押 ETH| Pool
 Pool -->|借出 USDC| Borrower
 Pool -->|利息| Lender

没有撮合——所有用户对的是"池子"，不是另一个用户。

二、cToken：存款的代币化

存进 Compound 的 USDC 不是普通存款——你换回了 cUSDC：

1

存入 100 USDC → 收到约 5000 cUSDC（按当前 exchange rate ≈ 1 USDC : 50 cUSDC）

cUSDC 是一种 ERC-20 代币：

数量代表你对池子的份额
池子产生利息时，cToken 总数不变，但 exchange rate 持续上涨——也就是 1 cUSDC 能兑换的 USDC 越来越多
取回时把 cUSDC 烧掉换回 USDC（按当前 exchange rate）

flowchart LR
 User -->|deposit 100 USDC| Compound
 Compound -->|mint ~5000 cUSDC| User
 Note1[初期 exchange rate ≈ 0.02 USDC/cUSDC]
 Note2[一年后 exchange rate ≈ 0.0213 USDC/cUSDC
同样 5000 cUSDC 现在能换回 ~106 USDC]

也就是说，同样数量的 cUSDC 能换回的 USDC 持续增加——这就是利息累积的体现。

cToken 的革命性：它是可组合的金融乐高——你可以把 cUSDC：

存进 Yearn 等收益聚合器
在 DEX 上交易
作为其他 DeFi 协议的抵押品

不像传统银行存款只是个数字——cToken 是真实的可流通资产。

三、算法利率模型

利率不是固定的——根据资金池的"利用率"动态调整：

1

利用率 U = 借出量 / 总存款

利率公式（简化）：

1
2


borrowRate = baseRate + U × multiplier // 利用率低时
borrowRate = baseRate + U × multiplier + (U - kink) × jumpMultiplier // U 超过 kink 后陡升

直觉：

池子很多人借 → 借款利率上升 → 抑制借款 / 鼓励存款 → 平衡池子
池子没什么借款 → 利率低 → 减少存款利息 / 鼓励借款 → 平衡池子

flowchart LR
 LowU[利用率低] --> LowRate[低利率] --> AttractBorrow[吸引借款]
 HighU[利用率高] --> HighRate[高利率] --> AttractDeposit[吸引存款]

Compound 的"利率曲线" 让市场自动平衡——不需要中心化机构定价。

四、抵押与清算

借款必须超额抵押——比如借 70 USDC 要抵押价值 100 ETH。

Collateral Factor

每种资产有一个 Collateral Factor（抵押因子）——比如 ETH 是 75%、稳定币 90%。

你抵押 1000 USD 的 ETH（CF=75%）→ 最多能借 750 USD 等值的资产

健康因子

1

Health Factor = (抵押品价值 × CF) / 借款价值

HF > 1：安全
HF < 1：可被清算

清算机制

如果 ETH 价格暴跌让 HF 跌破 1——任何人都可以触发清算：

清算者替借款人还一部分债（最多 50%）
清算者以折扣价拿走借款人的抵押品（折扣通常 5-8%）

flowchart LR
 BorrowerHF[借款人 HF=0.95] --> Anyone[任何人]
 Anyone -->|repay 50% debt| Pool
 Pool -->|reward 105% collateral| Anyone

清算者赚 5% 差价——这是激励清算者监控市场的机制。链上有专门的"清算机器人"24x7 盯着所有借款人的 HF。

五、COMP 治理代币与流动性挖矿

2020 年 6 月 Compound 上线了 COMP 代币——治理用：

总量 1000 万
每天向用户分发——根据"借入 + 存款总额"按比例
持有 COMP 可以参与协议治理（提案、投票）

这一改动点燃了整个 DeFi 行业的"流动性挖矿"狂潮：

用户存款不仅能赚利息，还能赚 COMP——COMP 价格高时，挖矿收益甚至超过本金利息。

短短几周——Compound 总锁仓量从几亿美元飙到几十亿。Aave、SushiSwap、Curve 等无数协议跟进发币——DeFi 进入"DeFi Summer"。

治理实践

COMP 持有者可以：

提议加新借贷市场
调整 Collateral Factor
调整利率曲线参数
升级合约

Compound 是真正实现了"协议自治"的样板——团队渐渐退出，决策由代币持有者做。

六、预言机：Compound 的命门

所有借贷决策都依赖资产价格——清算判断、抵押率计算都要价格输入。

Compound 早期使用 Open Price Feed——以 Coinbase Pro（后改名 Coinbase Exchange）作为主要签名报价方，配合 Uniswap V2 TWAP 做防御。设计预期是接入更多 reporter，但实际上 Coinbase 长期是唯一稳定上报的数据源。

但预言机被攻击的案例不少——经典案例是 2020 年 11 月 26 日 DAI 在 Coinbase Pro 价格异常飙升，导致 Compound 上约 8900 万美元的资产被异常清算。这是 DeFi 借贷协议永远的 risk——单源预言机一旦被推、被异常波动，整个清算系统就被绑架。

V3 之后 Compound 全面切到 Chainlink 等专业预言机——多源 + 时间加权 + 偏离阈值 多重保护，把这类风险显著降低。

七、cToken vs aToken vs dToken

不同借贷协议的"存款代币"模型有差异：

	Compound (cToken)	Aave V2 (aToken)	Aave V3 (aToken)
余额变化	数量不变，价格上涨	数量上涨，价格 = 1	数量上涨
用户体验	看着不增长（要折算）	看到余额秒级增长	同 V2
复合性	✓	✓	✓

aToken 用户体验上更好——钱包里看到余额持续增长，比 cToken 直观。Compound 后来推出的 V3 借鉴了 aToken 模型。

八、Compound V2 vs V3

Compound V2（2019）：当时被称为"DeFi 借贷的标准"。

Compound V3（2022）——重大改变：

每个市场只有一种借出资产（如 USDC 池只能借 USDC）——避免协议级流动性碎片化
抵押品和借出资产分离——你抵押 ETH 借 USDC，但 ETH 不会被借出去
简化治理——更专注、更易管理

V3 的设计哲学是 “做对一件事”——让借贷更安全、更可预测，但灵活性比 V2 低一些。

九、Compound 的影响和遗产

直接受影响的协议

Aave - 借贷模型几乎完全师承 Compound
Venus（BNB 链） - Compound V2 的 fork
JustLend（Tron） - Compound V2 的 fork
Benqi（Avalanche） - Compound V2 的 fork

Compound 的开源代码被复制粘贴到了几乎所有 EVM 链——是 DeFi 借贷的"参考实现"。

留下的范式

池化借贷（vs P2P 撮合）
算法利率
代币化存款（cToken）
链上清算激励
流动性挖矿 / 治理代币

这些都是 Compound 第一个推广——后续协议都在它的基础上演化。

十、Compound 的局限与反思

1. 高 Gas 费

每次存款 / 借款 / 清算都是链上交易——以太坊高峰期单次操作 $50+。这是为什么 Compound 在 L2 / 侧链才能让小用户负担得起。

2. 系统性风险

借贷协议的风险叠加：

预言机被攻击 → 清算异常
某个抵押品资产暴跌 → 大量清算 → 价格进一步下跌（连环反应）
智能合约 bug → 资金被盗

Compound 历史上有过几次小事故——DAI 利率公式 bug 短暂导致部分清算异常，但整体记录良好。

3. 治理参与度低

虽然有 COMP 投票——多数提案投票率不高。“代币持有者治理"在理论上美好，实践中常常是『大户投票决定一切』。

4. 复杂性对小用户不友好

抵押率、利率曲线、清算阈值——普通人很难弄懂。这是 DeFi 至今没能真正"出圈"的痛点之一。

十一、对开发者的启发

读 Compound 源码（github.com/compound-finance/compound-protocol）能学到很多：

CToken.sol：cToken 实现，学习"代币化金融头寸"的范式
Comptroller.sol：协议核心控制器，学习如何用单合约管理多市场
InterestRateModel.sol：利率模型——算法定价的实战案例
PriceOracleProxy.sol：预言机抽象层
Governance.sol：治理合约

这些不是"教学代码”——是真实管理着数十亿美元资金的代码，工程质量在 DeFi 中属于标杆水平。

小结

把 Compound 的价值压一句：

Compound 不只是一个借贷协议——它是 DeFi 的『结构性创新者』，定义了池化借贷、算法利率、流动性挖矿等几乎所有 DeFi 沿用至今的范式。

理解它的几个关键：

cToken = 代币化的存款 + 利息
算法利率根据利用率动态调整
清算激励让市场自动维持安全
COMP 让协议进入"代币治理"时代
V3 进一步简化和专注

如果你做 DeFi 借贷类项目——绝不要 fork Compound 就上线。要理解每一行代码、每一个参数的含义。Compound 的代码值得反复研读—— 是 DeFi 工程师值得花时间啃的源码之一。

OpenZeppelin Contracts 5.0 的关键变化

Thu, 07 Aug 2025 15:30:00 +0800

写在前面

OpenZeppelin Contracts 是 Solidity 生态最广泛使用的标准库——ERC-20、ERC-721、AccessControl、Proxy、Pausable…… 几乎每个生产级合约项目都依赖它。

2023 年 10 月发布的 5.0 是它自 4.0 之后最大的一次主版本升级——不只是 bug 修复，而是对 API、安全模型、模块组织的全面重塑。

本文讲清楚 5.0 的核心变化、升级要踩的坑、新特性的工程价值。

一、最大变化：Solidity 0.8.20+ 基线

OpenZeppelin 5.0 要求 Solidity ^0.8.20——意味着几个旧版本必须放弃：

pragma solidity ^0.8.0 不够了
升级编译器同时要校对每个 mixin/inherit

升 Solidity 版本通常是个连锁反应——所有依赖的第三方库也要兼容。

二、Ownable 必须传 `initialOwner`

最容易踩的小坑——Ownable 构造函数变了：

1
2
3
4
5
6
7
8
9


// 4.x
contract MyContract is Ownable {
 constructor() {} // 自动用 msg.sender 作为 owner
}

// 5.x
contract MyContract is Ownable {
 constructor(address initialOwner) Ownable(initialOwner) {} // 必须显式传
}

为什么改？——因为 msg.sender 在 deployer 用 factory 模式时往往不是真实的 owner。强制显式传 owner，**避免"工厂部署却把 owner 设成工厂"**这类隐蔽 bug。

升级时所有 Ownable 的子合约构造函数都要改。

三、AccessControl 的角色管理变了

`_grantRole` 移到 internal

1
2
3
4
5


// 4.x：_setupRole 用于初始化阶段
_setupRole(DEFAULT_ADMIN_ROLE, msg.sender);

// 5.x：_setupRole 删除，统一用 _grantRole
_grantRole(DEFAULT_ADMIN_ROLE, msg.sender);

_setupRole 这个"专门为初始化用"的函数被合并——减少 API 表面。

`hasRole` 行为不变，但 `getRoleMemberCount` / `getRoleMember` 移到了 `AccessControlEnumerable`

如果你需要枚举角色成员，必须显式继承 AccessControlEnumerable。

四、ERC20 的 `_beforeTokenTransfer` / `_afterTokenTransfer` 删除

4.x 钩子模型：

1
2
3
4


function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual override {
 // ...
 super._beforeTokenTransfer(from, to, amount);
}

5.x 简化为单个 _update 钩子：

1
2
3
4


function _update(address from, address to, uint256 value) internal virtual override {
 super._update(from, to, value);
 // 在这里加自定义逻辑
}

为什么改——钩子分前后两个增加了心智负担和 Gas 开销，单个 _update 函数已经覆盖所有需求。

升级时所有自定义 ERC20 / ERC721 都要把 hook 重写。

五、SafeERC20 的简化

1
2
3
4
5
6
7


// 4.x
SafeERC20.safeTransfer(token, to, amount);
SafeERC20.safeApprove(token, spender, amount); // ⚠️ 已弃用

// 5.x
token.safeTransfer(to, amount); // 用 using for
token.forceApprove(spender, amount); // 替代 safeApprove

safeApprove 因为重入 + 兼容性问题被废除——forceApprove 通过先 approve(0) 再 approve(amount) 解决。

六、Proxy / Upgradeability 的整理

升级合约用 ERC-1967 原生槽

5.x 完全用 EIP-1967 标准槽（不再有自定义实现）——所有可升级合约都用同一套 storage slot。

`Initializable` 的 `_disableInitializers`

1
2
3


constructor() {
 _disableInitializers(); // 防止 implementation 合约被攻击者初始化
}

这是必须做的——否则 implementation 合约本身可能被外部直接 init（Parity Wallet 2017 年就因为这个被 self-destruct，14 万 ETH 永久冻结）。5.x 的 Initializable 加了更严格的检查。

七、新增模块

Multicall

1
2
3
4
5
6
7


contract MyContract is Multicall { ... }

// 一笔交易里调多个本合约函数
multicall([
 abi.encodeCall(MyContract.func1, (...)),
 abi.encodeCall(MyContract.func2, (...))
]);

节省 Gas、保证原子性——很多 DeFi 协议自己实现 Multicall，5.x 提供了官方版本。

Nonces

1
2
3
4


contract MyContract is Nonces { ... }

// 防 replay 的 nonce 管理标准化
uint256 nonce = _useNonce(user);

ERC-2612 permit、EIP-712 签名场景的标配。

ERC4337（账户抽象）

5.x 提供基础组件，让你能更容易地实现 ERC-4337 智能账户。

ERC2771 Forwarder

支持 meta-transaction（用户不付 Gas，relayer 代发）。

ERC-7201 命名空间存储（Namespaced Storage）

contracts-upgradeable 包里全面改用 ERC-7201 命名空间存储布局，取代原来的 __gap 模式：

1
2
3
4
5


// 5.x 风格
/// @custom:storage-location erc7201:openzeppelin.storage.MyContract
struct MyContractStorage {
 uint256 value;
}

每个合约的 storage 字段被收进一个独立 struct，slot 由 keccak256(namespace) - 1 派生——升级加字段不再受顺序约束，老项目从 __gap 模式迁移过来要小心 storage layout 兼容。这是 5.x 在升级合约存储模型上最大的改动。

八、删除的东西

1. 一些低使用率的工具

MerkleProof 内部实现优化，但 API 兼容；Address.isContract 删除（用 code.length > 0 替代）。

2. `Counters` 库

1
2
3
4
5
6
7
8


// 4.x
using Counters for Counters.Counter;
Counters.Counter private _id;
_id.increment();

// 5.x
uint256 private _id;
_id++;

随着 Solidity 0.8+ 内置溢出检查，Counters 已经没意义——直接用 uint256 + ++。

3. `Address.functionDelegateCall`

整体 Address 库被简化——某些 helper 函数移除或重命名。

九、Governor 的全面重构

DAO 治理的 Governor 模块——4.x 的复杂度被 5.x 大幅简化：

1
2
3
4
5
6
7
8
9


// 5.x
contract MyGovernor is
 Governor,
 GovernorSettings,
 GovernorCountingSimple,
 GovernorVotes,
 GovernorVotesQuorumFraction,
 GovernorTimelockControl
{ ... }

mixin 数量更精简、API 更一致——做 DAO 的项目必看。

十、安全增强

1. 更严格的 reentrancy 检查

5.0 的 ReentrancyGuard 仍是普通 storage 实现（5.0 发布时 EIP-1153 transient storage 还未上链；EIP-1153 随 Cancun 升级在 2024-03 才上线主网）。5.1（2024-10）之后新增了独立的 ReentrancyGuardTransient 合约——基于 EIP-1153 transient storage，gas 显著降低（普通版热槽约 5000 gas，transient 版约 200 gas）。

1
2
3
4
5


// 5.0+：普通版
import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";

// 5.1+：transient 版（更省 gas，但需 EVM 支持 EIP-1153）
import "@openzeppelin/contracts/utils/ReentrancyGuardTransient.sol";

2. Permit 标准化

ERC-2612 (permit) 在 5.x 默认开启更严格的签名校验。

3. 改进的 ECDSA 验证

签名相关的工具类（ECDSA、SignatureChecker）的 API 更清晰，避免 recover 返回 0 地址不被察觉的隐患。

十一、升级实战 Checklist

老项目升 5.x 的清单：

Solidity 升到 0.8.20+
Ownable 子合约改构造函数
_setupRole → _grantRole
_beforeTokenTransfer / _afterTokenTransfer → _update
safeApprove → forceApprove
删除 Counters，用 uint256 +1
删除 Address.isContract，用 addr.code.length > 0
可升级合约的 implementation 加 _disableInitializers()
Governor 子合约重写
完整跑 audits / tests

工具：

1
2


# 用 OpenZeppelin 的 upgrade tool
npx @openzeppelin/upgrades migrate

未必能自动改全——手工 review 仍然必须。

十二、新项目的最佳实践

如果你是从 0 起步——直接用 5.x。几条建议：

1. 用 ERC-1967 标准的可升级合约

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


import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";

contract MyContract is Initializable, OwnableUpgradeable {
 /// @custom:oz-upgrades-unsafe-allow constructor
 constructor() {
 _disableInitializers(); // ⚠️ 必加：防止 implementation 合约被外部 init
 }

 function initialize(address initialOwner) public initializer {
 __Ownable_init(initialOwner);
 }
}

2. 永远 `_disableInitializers()`

3. 用 `using SafeERC20 for IERC20`

1
2


using SafeERC20 for IERC20;
token.safeTransfer(to, amount);

4. ReentrancyGuard 默认启用

任何接收/转账函数加 nonReentrant——5.1+ 优先用 ReentrancyGuardTransient（transient storage 版，每次开销约 200 gas），5.0 用普通版（gas 量级与 4.x 同）。

5. 关注 EIP-712 签名

权限调用 / 用户授权 / meta-tx——签名相关都用 OpenZeppelin 的 EIP-712 实现，别自己造。

十三、为什么这次升级值得

OpenZeppelin 4.x 系列已经是事实标准——5.x 升级带来的不是惊艳新功能，而是『更精简、更安全、更现代』。

具体收益：

代码量减少：单个 _update 替代两个 hook
更小 Gas：transient storage、内置优化
避免历史坑：forceApprove、_disableInitializers
DAO 治理更易用
新场景支持：ERC-4337、Multicall

小结

把全文压一句：

OpenZeppelin 5.0 不是『可选的小升级』——它是 Solidity 0.8.20+ 时代的事实标准，新项目应该直接采用，老项目应该规划迁移。

工程要点：

Ownable 构造函数必传 owner
ERC20 hook 改为 _update
safeApprove 用 forceApprove
Counters 删除，直接 uint256
可升级合约必加 _disableInitializers
永远去 OpenZeppelin GitHub 看 release notes

智能合约的"代码即资金"特性意味着——用过期的库 = 用过期的安全保护。OpenZeppelin 5.x 是当下应该用的版本。

不可变的合约如何「升级」？聊聊 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 生态还在演进，理解这些标准的边界比追新更重要——搞清"业务场景该用哪个”，远比"哪个最先进"实用。

智能合约的四种调用方式：Call / CallCode / DelegateCall / StaticCall

Thu, 17 Mar 2022 16:00:00 +0800

一段看似平平无奇的代码，行为完全不同

四个看起来很像的调用：

1
2
3
4


target.call(data); // call
target.callcode(data); // callcode（已弃用）
target.delegatecall(data); // delegatecall
target.staticcall(data); // staticcall

它们都是"调另一个合约"——但存储上下文、msg.sender、能否改状态完全不同。用错任何一个轻则无效，重则被攻击者利用整个协议归零。

本文把这四种调用的差异系统讲清楚，并配代码例子说明各自用法和风险。

一、四者本质对比

EVM 中合约调用的"上下文"由三个核心要素组成：

代码（Code）：要执行哪段字节码？
存储（Storage）：读写哪个合约的存储？
msg.sender / msg.value：调用者身份是谁？

四种调用对这三个要素的处理：

	执行的代码	操作的存储	msg.sender	msg.value	能否改状态
`call`	target	target	caller	可传值	✓
`callcode`	target	caller	caller	可传值	✓
`delegatecall`	target	caller	原发起者	原 value	✓
`staticcall`	target	target	caller	不可传值	✗ 只读

callcode 已经被官方标记为 deprecated（功能被 delegatecall 替代），实战中几乎不用。重点是 call / delegatecall / staticcall 三种。

二、call：最朴素的"远程调用"

1
2
3
4
5
6
7
8


contract Caller {
 function callTarget(address target) external payable {
 (bool ok, bytes memory data) = target.call{value: msg.value}(
 abi.encodeWithSignature("doSomething(uint256)", 100)
 );
 require(ok, "call failed");
 }
}

call 的语义是——让对方合约执行对方的代码、操作对方的存储。

执行 target 的代码
改 target 的存储
在 target 看来，msg.sender = Caller 这个调用方
可以转账（{value: x}）

这就是一次"标准的合约间调用"。

典型场景

转账给一个普通地址：recipient.call{value: amount}("")
调用未知接口：当目标合约接口不固定时（如 ERC-721 的 onERC721Received 钩子），用 call

注意点

call 失败不会自动 revert ——返回 bool ok，要自己 require
重入风险：call 触发外部代码执行，可能再调回来——经典 The DAO 漏洞就是这个

三、delegatecall：用别人的代码、操作自己的存储

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


contract Proxy {
 address public implementation;

 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()) }
 }
 }
}

delegatecall 的语义是——借用对方的字节码逻辑，但操作的是自己的存储和上下文。

执行 target 的代码
改 caller 的存储（不是 target 的！）
msg.sender 是原始调用者（不是 caller）
msg.value 也是原始的

典型场景：代理升级模式

可升级合约（OpenZeppelin Proxy / UUPS）的根基就是 delegatecall：

flowchart LR
 User --> Proxy
 Proxy -- delegatecall --> Logic
 Proxy -.存储在.-> Storage

Proxy 把所有调用 delegatecall 给 Logic 合约——Logic 操作的存储是 Proxy 的，所以升级 Logic 不影响数据。

致命陷阱：存储槽冲突

delegatecall 操作 caller 的存储，但用的是 target 的存储槽布局——两边布局必须严格对齐。

1
2
3
4
5
6
7
8
9


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

contract LogicV2 {
 uint256 public counter; // slot 0 ← 和 V1 的 owner 撞了
 address public owner; // slot 1
}

升级到 V2 后，原来 owner 槽存的地址被当作 counter 解读——协议直接报废。

致命陷阱二：误用 delegatecall 给陌生地址

1
2
3


function execute(address target, bytes calldata data) external onlyOwner {
 target.delegatecall(data); // ❌ 极度危险
}

如果攻击者诱导 owner 调用此函数指向恶意 target，target 的代码可以任意改 caller 的存储——包括把 owner 改成攻击者地址。

历史上的 Parity Wallet 漏洞、Audius 攻击等，都是 delegatecall 滥用导致的灾难。

delegatecall 必须只指向你自己控制的、白名单内的合约。

四、staticcall：只读调用

1
2
3
4
5
6
7


function readSomething(address target) external view returns (uint256) {
 (bool ok, bytes memory data) = target.staticcall(
 abi.encodeWithSignature("getValue()")
 );
 require(ok, "staticcall failed");
 return abi.decode(data, (uint256));
}

staticcall 是 EIP-214 引入——和 call 几乎一样，但强制只读：

执行 target 的代码
改 target 的存储——不行，只读
不能转账
target 内部任何 SSTORE / LOG / CREATE 都会让调用 revert

典型场景

view / pure 函数的调用——Solidity 编译器会自动用 staticcall
集成第三方合约的查询：你想查别人合约状态但不信任它会改你状态——staticcall 强制只读

1
2
3
4


function getPriceFromOracle(IOracle oracle) external view returns (uint256) {
 // 编译器自动选 staticcall
 return oracle.price();
}

为什么重要

没有 staticcall 之前，要"安全地查询别人的合约"非常麻烦——对方合约可能在 view 函数里偷偷改状态（虽然不该）。staticcall 从 EVM 层面强制只读——这是一个安全保障。

五、callcode：已弃用

1

target.callcode(data); // 已 deprecated

callcode 是 delegatecall 的早期版本，唯一区别是 msg.sender 不会保留为原始调用者——这通常是个 bug 而不是 feature。所以 Solidity 0.5.0 之后 callcode 被禁用，全部用 delegatecall。

新代码里永远不要写 callcode。

六、四种调用的"决策树"

flowchart TD
 Start([要调用另一个合约?])
 Start --> S{需要写状态?}
 S -->|不需要，只查询| Static[staticcall]
 S -->|需要写| Self{改的是自己的存储 or 对方的?}
 Self -->|对方的存储 - 远程调用| Call[call]
 Self -->|自己的存储 - 借代码| Trust{对方合约 100% 可信?}
 Trust -->|是| Delegate[delegatecall]
 Trust -->|否| Avoid[别 delegatecall！]

七、Solidity 高级语法的隐式调用

直接写函数调用时，Solidity 会根据函数修饰符自动选择：

1
2
3


ITarget(addr).viewFn(); // staticcall
ITarget(addr).pureFn(); // staticcall
ITarget(addr).normalFn(); // call

view / pure → staticcall
普通函数 → call
delegatecall 永远要显式写——没有"自动 delegatecall"

这是合理的——delegatecall 太危险，必须开发者明确知道自己在做什么。

八、几个工程实践

1. call 一律检查返回值

1
2


(bool ok, ) = target.call(data);
require(ok, "call failed");

不检查就忽略错误，等于"我以为调用成功了，其实没有"——脏数据由此而生。

2. 转账永远用 call 不要用 transfer

老代码：

1

recipient.transfer(amount); // ❌ 现代不推荐

transfer 一直限制 2300 gas（这点从 Solidity 引入 transfer 时就如此）。真正让它频繁出问题的是 EIP-2929（Berlin 升级，2021-04）——抬高了 SLOAD/CALL 等状态访问的 gas 成本，接收方 fallback 里很多原本能跑过的操作再也挤不进 2300 gas，导致 OOG。现代写法：

1
2


(bool ok, ) = recipient.call{value: amount}("");
require(ok, "transfer failed");

3. delegatecall 配 onlyOwner / 白名单

1
2
3
4
5
6
7


mapping(address => bool) public trustedTargets;

function delegateAction(address target, bytes calldata data) external onlyOwner {
 require(trustedTargets[target], "not trusted");
 (bool ok, ) = target.delegatecall(data);
 require(ok);
}

永远不要让外部参数决定 delegatecall 的目标。

4. staticcall 保证只读

集成新协议时——只查询、不修改：

1

ISomeProtocol(addr).getInfo(); // 用 view 接口，编译器自动 staticcall

如果对方接口没声明 view 但你确定它只读——可以手动 staticcall：

1

(bool ok, bytes memory data) = addr.staticcall(abi.encodeWithSignature("getInfo()"));

如果对方实际改了状态，staticcall 会让交易失败——EVM 层面拦截，比靠开发者自觉安全。

5. 用 OpenZeppelin Address 库

1
2
3
4
5


using Address for address;

target.functionCall(data); // 安全的 call + revert
target.functionStaticCall(data); // 安全的 staticcall
target.functionDelegateCall(data); // 安全的 delegatecall（要白名单）

OZ 的封装多了 require、revert reason 解析等——比裸 call 安全得多。

九、几个真实案例

案例 1：Parity Wallet 的 14 万 ETH（2017）

Parity 的多签钱包用 delegatecall 委托给一个共享 Library。攻击者发现可以直接调用 Library 的 init 函数把自己设成 owner——再调用 kill 函数，整个 Library 自毁，所有依赖它的钱包永久无法转账。

教训：delegatecall 目标合约的所有 public/external 函数都要审慎设计——public 入口被外部直接调用 + delegatecall 同时滥用，就是这种灾难。

案例 2：Audius 治理攻击（2022）

Audius 协议合约存在 storage collision + initialize 未保护双重 bug——存储槽布局错位让攻击者可以重新调用 initialize 把自己设为治理 guardian，然后通过提交并自我通过的恶意治理提案转走社区池里约 1860 万 AUDIO（约 600 万美元）。

教训：proxy 模式下，所有可升级合约的 initialize 必须加 initializer 修饰符防止重复调用，并且基类与子类的 storage 布局必须严格对齐——这两个 bug 任何一个不出，攻击都成立不了。

案例 3：The DAO（2016）

经典重入——call 触发的外部调用导致重新进入合约，余额还没扣就被反复提款。

教训：调用外部前先改自己的状态（Checks-Effects-Interactions 模式）。

十、调试工具

Foundry trace：forge test -vvvv 能看到每一层 call/delegatecall/staticcall 的细节
Tenderly：可视化交易调用链路
Etherscan trace：交易详情里的"Internal Txns"标签

调试 delegatecall 出现"为什么状态没变 / 变错"的问题——第一步永远是看清楚到底是 call 还是 delegatecall，存储槽对齐没。

小结

把全文压一句：

call 是远程调用、delegatecall 是借代码、staticcall 是强制只读、callcode 是历史。四者用错就是漏洞。

工程上几条铁律：

call 一定要 require(ok)
delegatecall 只指向自己控制的、白名单内的合约
delegatecall 升级要严格保持存储布局
查询用 staticcall 比信任 view 更安全
永远不要 callcode
转账用 call{value:...} 不用 transfer

把这四种调用的语义吃透——你看 OpenZeppelin / Aave / Uniswap 的代码就能瞬间看懂"为什么这里要这么写"。

智能合约 on 牛哥聊技术

Compound 协议解析：DeFi 借贷的奠基者

写在前面

一、Compound 在做什么

二、cToken：存款的代币化

三、算法利率模型

四、抵押与清算

Collateral Factor

健康因子

清算机制

五、COMP 治理代币与流动性挖矿

治理实践

六、预言机：Compound 的命门

七、cToken vs aToken vs dToken

八、Compound V2 vs V3

九、Compound 的影响和遗产

直接受影响的协议

留下的范式

十、Compound 的局限与反思

1. 高 Gas 费

2. 系统性风险

3. 治理参与度低

4. 复杂性对小用户不友好

十一、对开发者的启发

小结

OpenZeppelin Contracts 5.0 的关键变化

写在前面

一、最大变化：Solidity 0.8.20+ 基线

二、Ownable 必须传 initialOwner

三、AccessControl 的角色管理变了

_grantRole 移到 internal

hasRole 行为不变，但 getRoleMemberCount / getRoleMember 移到了 AccessControlEnumerable

四、ERC20 的 _beforeTokenTransfer / _afterTokenTransfer 删除

五、SafeERC20 的简化

六、Proxy / Upgradeability 的整理

升级合约用 ERC-1967 原生槽

Initializable 的 _disableInitializers

七、新增模块

Multicall

Nonces

ERC4337（账户抽象）

ERC2771 Forwarder

ERC-7201 命名空间存储（Namespaced Storage）

八、删除的东西

1. 一些低使用率的工具

2. Counters 库

3. Address.functionDelegateCall

九、Governor 的全面重构

十、安全增强

1. 更严格的 reentrancy 检查

2. Permit 标准化

3. 改进的 ECDSA 验证

十一、升级实战 Checklist

十二、新项目的最佳实践

1. 用 ERC-1967 标准的可升级合约

2. 永远 _disableInitializers()

3. 用 using SafeERC20 for IERC20

4. ReentrancyGuard 默认启用

5. 关注 EIP-712 签名

十三、为什么这次升级值得

小结

不可变的合约如何「升级」？聊聊 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

二、Ownable 必须传 `initialOwner`

`_grantRole` 移到 internal

`hasRole` 行为不变，但 `getRoleMemberCount` / `getRoleMember` 移到了 `AccessControlEnumerable`

四、ERC20 的 `_beforeTokenTransfer` / `_afterTokenTransfer` 删除

`Initializable` 的 `_disableInitializers`

2. `Counters` 库

3. `Address.functionDelegateCall`

2. 永远 `_disableInitializers()`

3. 用 `using SafeERC20 for IERC20`

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

一句话理解 `delegatecall`

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