区块链硬核入门教程（中篇）：生态全景与技术栈深度对比

上篇拆掉了底层黑盒，本篇进入"选哪条链、用什么技术、怎么避坑"的实战层。目标：读完后你能在技术评审会上有理有据地讨论"为什么选 EVM 而不是 Move"、"Optimistic Rollup 和 ZK Rollup 该怎么选"。

比特币深度：UTXO、脚本与闪电网络
以太坊深度：EVM、Solidity 与 Gas 经济学
主流公链横向对比：Solana / Avalanche / Cosmos / Polkadot / Aptos / Sui
Layer2 扩容之战：Rollup、状态通道与数据可用性
跨链技术：桥、IBC 与跨链安全
智能合约安全：攻击模式与防御手册
DeFi 全景：从 AMM 到衍生品
NFT、链上身份与社会图谱
DAO 治理：链上组织的实验与困境
实战：部署并交互一个 ERC-20 合约

1. 比特币深度：UTXO、脚本与闪电网络

1.1 UTXO 模型 vs 账户模型

这是区块链最根本的设计分歧之一。

维度	UTXO（比特币）	账户模型（以太坊）
状态表示	未花费输出集合	账户余额 + nonce
并行性	天然支持（不同 UTXO 可并行处理）	难（同一账户 nonce 串行）
隐私性	较好（每次用新地址）	差（地址复用，余额公开）
智能合约	难（脚本非图灵完备）	易（图灵完备）
状态膨胀	较慢（UTXO 集相对稳定）	快（所有账户状态持久化）
用户理解	难（找零、输入输出）	易（像银行账户）

硬核洞察：UTXO 的并行性是比特币能在 10 分钟出块下仍保持稳定的原因之一——矿工可以并行验证交易输入。以太坊的账户模型虽然好理解，但同一账户的交易必须串行执行，这是 EVM 并行化的最大障碍。EIP-648（并行交易）和一些新链（如 Sui 的对象模型）正在尝试解决这个问题。

1.2 比特币脚本：被低估的表达能力

比特币脚本是基于栈的、非图灵完备的脚本语言。虽然简单，但能表达很多复杂条件：

P2PKH（最常见的支付给公钥哈希）：

锁定脚本：OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
解锁脚本：<signature> <publicKey>

P2SH（支付给脚本哈希，支持多签）：

锁定脚本：OP_HASH160 <scriptHash> OP_EQUAL
解锁脚本：<sig1> <sig2> <redeemScript>

其中 redeemScript 可以是任意脚本，比如 2-of-3 多签：

OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3 OP_CHECKMULTISIG

时间锁（HTLC 的基础）：

OP_IF
  <recipientPubKey> OP_CHECKSIG
OP_ELSE
  <timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP
  <refundPubKey> OP_CHECKSIG
OP_ENDIF

这个脚本实现了：要么接收方签名立即取走，要么超时后退款方取走。这就是 哈希时间锁合约（HTLC），闪电网络的基石。

Taproot 升级（2021）：引入了 Schnorr 签名和 MAST（默克尔化抽象语法树），把复杂合约的所有分支用默克尔树提交，执行时只暴露用到的分支。这意味着：
多签和单签在链上看起来一样（隐私提升）
复杂脚本只付用到分支的手续费（费用降低）
为 DLC（离散日志合约）、闪电网络通道等提供了更强的表达能力

1.3 闪电网络：链下支付的工程奇迹

闪电网络（Lightning Network）是比特币的 Layer2，实现了即时、低费、可扩展的支付。

核心原理：

双方在链上创建一个 多签地址，各自存入资金（开通通道）
通道内通过交换签名的"承诺交易"更新余额，不需要上链
任何一方都可以广播最新的承诺交易关闭通道（结算上链）
作弊（广播旧状态）会被对方惩罚（罚没全部资金）

HTLC 实现跨节点路由：

Alice → Bob → Charlie，Alice 要付 Charlie 1 BTC
1. Charlie 生成随机数 R，把 hash(R)=H 告诉 Alice
2. Alice 和 Bob 建立 HTLC：Bob 知道 R 就能拿 1.001 BTC，超时 Alice 退款
3. Bob 和 Charlie 建立 HTLC：Charlie 知道 R 就能拿 1 BTC，超时 Bob 退款
4. Charlie 用 R 从 Bob 处取钱，Bob 看到 R 后从 Alice 处取钱
5. 整个过程原子化，Bob 赚 0.001 BTC 路由费

闪电网络现状（2024）：

通道数：~80,000
网络容量：~5,000 BTC（约 3 亿美元）
单笔支付费用：通常 < 1 聪（0.00000001 BTC）
支付延迟：亚秒级

工程挑战：闪电网络的痛点是 通道管理——你需要和谁开通通道、容量分配、路由寻路、在线率要求。大型节点（如 LN Big）提供流动性服务，但也带来了一定的中心化趋势。

2. 以太坊深度：EVM、Solidity 与 Gas 经济学

2.1 EVM 架构：世界计算机的内核

以太坊虚拟机（EVM）是一个 基于栈的、确定性的、图灵完备的 虚拟机。

核心数据结构：

栈（Stack）：最多 1024 层，每个元素 256 bit
内存（Memory）：字节数组，可扩展，按字（32 字节）计费
存储（Storage）：持久化的键值对（256 bit → 256 bit），最贵的资源
Calldata：交易输入数据，只读

操作码（Opcode）：约 140 个，分为算术、比较、位运算、密码学、栈操作、内存操作、存储操作、流程控制、系统调用等。

EVM 的设计哲学：
确定性：相同输入必产生相同输出，所有节点执行结果一致
可计量：每个操作码有 Gas 成本，防止无限循环
简单性：256 bit 字长，栈式架构，易于实现
安全性：沙盒执行，不能访问外部系统

2.2 Solidity 实战要点

Solidity 是 EVM 上最主流的语言。以下是实战中必须掌握的要点：

存储布局

solidity

contract StorageExample {
    uint256 public a;          // slot 0
    uint128 public b;          // slot 1（和 c 打包）
    uint128 public c;          // slot 1
    mapping(uint => uint) map; // slot 2（仅作占位，实际存储 keccak256(key, slot)）
    uint[] public arr;         // slot 3（长度存在 slot 3，元素在 keccak256(3)）

    // 映射的存储位置：keccak256(abi.encode(key, slot))
    // 动态数组元素位置：keccak256(slot) + index
}

Gas 优化关键：合理排列变量，让多个小变量打包进同一个 slot（256 bit），可以节省 SSTORE 费用。一个 SSTORE 写入新值需要 20,000 Gas，而打包后一次写入就能存两个变量。

函数调用与 delegatecall

solidity

// call：在目标合约的上下文中执行，修改目标合约的存储
target.call(abi.encodeWithSignature("foo()"));

// delegatecall：在当前合约的上下文中执行目标合约的代码，修改当前合约的存储
// 这是代理模式（Proxy Pattern）的基础
target.delegatecall(abi.encodeWithSignature("foo()"));

// staticcall：只读调用，不允许修改状态
target.staticcall(abi.encodeWithSignature("bar()"));

代理模式是合约可升级性的标准方案：

用户调用代理合约，代理通过 delegatecall 转发到逻辑合约
升级时只需把代理指向新的逻辑合约
存储在代理合约中，逻辑合约可以替换但数据保留

代理模式的坑：存储碰撞。如果代理合约和逻辑合约的存储布局不一致，delegatecall 会覆盖错误的存储槽。标准解决方案是 EIP-1967（代理存储槽固定在特定位置）和 透明代理 / UUPS 模式。

2.3 Gas 经济学深度解析

Gas 是 EVM 的计量单位，每笔交易消耗 Gas，手续费 = Gas 用量 × Gas 价格。

常见操作的 Gas 成本（EIP-2929 后）：

操作	Gas 成本	说明
ADD	3	算术运算
MUL	5	乘法
SHA3	30 + 6/字	哈希
MLOAD	4	读内存
MSTORE	5	写内存
SLOAD（冷访问）	2100	首次读存储
SLOAD（热访问）	100	已访问过的存储
SSTORE（设为 0）	2900 + 退款	删除存储，有 Gas 退款
SSTORE（修改已有值）	5000	修改非零值
SSTORE（从零设为非零）	20000	新增存储，最贵
CALL（冷地址）	2600	调用新地址
CREATE	32000	创建合约
交易基础费	21000	每笔交易固定

EIP-1559 后的 Gas 市场：

总手续费 = base_fee × gas_used + priority_fee × gas_used
         = (base_fee + priority_fee) × gas_used

base_fee：由算法根据上一区块填充率动态调整，会被销毁（通缩）
priority_fee（小费）：给验证者的奖励，用户可设置
max_fee：用户愿意支付的最高价 = base_fee + priority_fee 的上限

Gas 优化实战技巧：
用 immutable 和 constant 代替存储变量（编译时嵌入字节码，不占存储）
短字符串用 bytes32 而非 string（省 SSTORE）
批量操作代替循环中的单次 SSTORE
用 unchecked { } 跳过安全检查（Solidity 0.8+ 默认有溢出检查）
用事件（Event）代替存储（日志便宜，且前端可以监听）
映射比数组更省 Gas（不需要遍历）

3. 主流公链横向对比

3.1 对比总表

链	共识	VM	出块时间	TPS	特点	生态成熟度
Ethereum	PoS (Gasper)	EVM	12s	~15-20	生态最大、安全性最高、标准制定者	★★★★★
Bitcoin	PoW	Script	10min	~7	价值存储、最去中心化	★★★★★
Solana	PoH + PoS	SVM（类 EVM）	400ms	2000-6000	高性能、但稳定性有争议	★★★★
Avalanche	Snowman++	C-Chain(EVM)	2s	4500+	子网架构、最终性快	★★★★
Polygon	PoS + zkEVM	EVM	2s	1000+	以太坊扩容、企业合作多	★★★★
Cosmos	Tendermint	各链自定义	~6s	1000+	应用链、IBC 跨链	★★★
Polkadot	BABE + GRANDPA	Wasm	6s/12s	1000+	中继链+平行链、共享安全	★★★
Aptos	AptosBFT	Move VM	<1s	10000+	Move 语言、并行执行	★★
Sui	Narwhal+Bullshark	Move VM	<1s	10000+	对象模型、并行性极强	★★
TRON	DPoS	EVM	3s	2000	稳定币转账、波场生态	★★★★
Near	Nightshade	Wasm	1-2s	1000+	分片、账户模型友好	★★★

3.2 Solana：高性能的代价

核心创新：PoH（历史证明）

在 PoS 之前加一层"时间戳"机制，用 SHA-256 链式哈希证明事件发生顺序
节点不需要等待其他节点确认时间，可以并行处理交易
配合 Gulf Stream（交易转发）和 Sealevel（并行执行），实现高 TPS

问题与争议：

停机事件：2021-2022 多次因交易洪泛导致全网停机（最长 20 小时）
硬件要求高：验证者需要 128GB RAM + 高端 NVMe，普通用户无法运行
中心化风险：RPC 节点高度集中，大部分用户通过第三方 RPC 交互
经济模型：通胀率较高，SOL 质押收益约 7%

适用场景：高频交易、NFT 铸造、GameFi、需要亚秒级确认的应用。不适合：对去中心化要求极高的价值存储。

3.3 Cosmos：应用链范式

核心理念：每条应用有自己的链，通过 IBC 跨链通信。

Tendermint Core：BFT 共识引擎，确定最终性，~6 秒出块
Cosmos SDK：模块化框架，用 Go 编写应用链
IBC（跨链通信协议）：标准化的跨链消息传递，支持代币转移、智能合约调用
CosmWasm：Cosmos 上的 Wasm 智能合约层

优势：

应用链可以自定义共识、参数、经济模型
不会和其他应用抢 Gas（没有"老鼠仓"问题）
IBC 已连接 100+ 条链，跨链生态成熟

劣势：

每条链需要自己的验证者集，安全性独立（小链安全低）
用户体验碎片化（需要切换链、管理多种代币）
跨链桥安全事件频发（2022 年 Cosmos 生态跨链桥被盗超 1 亿美元）

3.4 Aptos / Sui：Move 语言的双雄

两者都源自 Meta（Facebook）的 Diem 项目，都用 Move 语言，但设计哲学不同。

Move 语言的核心优势：

资源类型：代币是"资源"，不能被复制或隐式丢弃，从类型系统层面防止双花
模块系统：代码和数据分离，比 EVM 的代理模式更安全
形式化验证：内置 Move Prover，可以数学证明合约属性

Aptos：

账户模型（类似以太坊，但有更灵活的认证）
Block-STM 并行执行引擎
强调"可升级性"和企业采用

Sui：

对象模型：一切都是对象，每个对象有所有者和版本
交易只声明要读写的对象，不相关的对象可以完全并行
创始人团队来自 Meta 的 Novi 团队核心

判断：Move 语言在安全性上确实优于 Solidity，但生态差距巨大（EVM 有 10 年积累，Move 才 2 年）。短期内 EVM 仍是主流，Move 可能在特定领域（如 RWA、游戏资产）找到突破口。

4. Layer2 扩容之战

4.1 扩容的不可能三角

        去中心化
           /\
          /  \
         /    \
        /______\
    安全性      可扩展性

Layer1 扩容（增大区块、提高 TPS）必然牺牲去中心化（硬件要求提高）。Layer2 的思路是：把计算搬到链下，把数据和证明留在链上，在不牺牲 Layer1 安全性的前提下提升吞吐量。

4.2 Rollup 两大路线

Optimistic Rollup（乐观 Rollup）

原理：假设交易都是有效的，直接打包上链；任何人都可以在挑战期内（通常 7 天）提交欺诈证明（Fraud Proof），证明某笔交易无效。

代表：Arbitrum、Optimism、Base（Coinbase）

挑战期机制：

交易提交后，需要等 7 天挑战期才能最终确认
这期间如果有人发现错误，可以提交欺诈证明
挑战成功，错误交易被回滚，挑战者获得奖励，提交者被罚没

优缺点：

✅ EVM 兼容性好（Arbitrum 几乎完全兼容）
✅ 技术相对简单，先上线
❌ 提款慢（7 天挑战期，虽然有快速提款服务但需要第三方）
❌ 挑战期内存在理论上的安全风险

ZK Rollup（零知识 Rollup）

原理：每批交易生成一个 零知识证明（ZK Proof），证明这批交易的状态转换是正确的。链上只验证证明，不需要重新执行交易。

代表：zkSync Era、StarkNet、Polygon zkEVM、Scroll、Linea

优缺点：

✅ 数学保证安全性，不需要挑战期
✅ 提款快（几分钟到几小时）
✅ 隐私潜力（ZK 技术天然支持隐私）
❌ EVM 兼容性难（zkEVM 分不同兼容等级）
❌ 证明生成慢、计算成本高（需要专门的证明者硬件）
❌ 技术复杂度极高

4.3 zkEVM 兼容等级

等级	含义	代表	兼容性	证明开销
Level 1	EVM 等价（字节码完全兼容）	Scroll, Linea	极高	高
Level 2	EVM 等价（修改部分操作码）	Polygon zkEVM	高	中
Level 3	EVM 兼容（高级语言兼容，需重新编译）	zkSync Era	中	低
Level 4	自定义 VM（不兼容 EVM）	StarkNet (Cairo)	低	极低

实战选择建议：
需要完全兼容现有 Solidity 合约 → Arbitrum / Base（Optimistic）或 Scroll（ZK Level 1）
追求极致性能和新技术 → zkSync Era / StarkNet
做 DeFi 且需要快速提款 → ZK Rollup
做 NFT / GameFi，对提款速度不敏感 → Optimistic Rollup（生态更成熟）

4.4 其他扩容方案

方案	原理	代表	安全性
状态通道	双方链下交换签名，结算上链	闪电网络、Connext	高（双方即可）
侧链	独立链，通过桥连接	Polygon PoS、Skale	中（依赖自身共识）
Validium	计算链下，数据也链下	StarkEx、Immutable X	中低（数据可用性依赖第三方）
Plasma	子链，欺诈证明	已基本淘汰	低（数据可用性问题）

关键区别：数据可用性

Rollup：交易数据上链（Calldata），任何人都可以重建状态 → 继承 Layer1 安全
Validium：数据不上链，由数据可用性委员会（DAC）保管 → 委员会作恶可冻结资金

5. 跨链技术：桥、IBC 与跨链安全

5.1 跨链桥的类型

类型	原理	代表	安全模型
锁定+铸造	源链锁定资产，目标链铸造映射资产	WBTC、renBTC	依赖托管方/多签
销毁+铸造	源链销毁原生资产，目标链铸造	IBC 转账、Arbitrum 桥	依赖双方链共识
原子交换	HTLC 实现跨链原子交易	早期跨链方案	密码学保证，但体验差
流动性网络	各链有流动性池，用户在源链存入、目标链取出	Hop、Stargate、Across	依赖流动性提供者
消息传递	通用跨链消息，支持任意数据	LayerZero、Wormhole、CCIP	依赖预言机/中继网络

5.2 IBC：Cosmos 的跨链标准

IBC（Inter-Blockchain Communication）是 Cosmos 生态的跨链协议，已成为行业标准之一。

核心流程：

链 A 上的合约/模块发送 IBC 数据包
中继者（Relayer）监听并把数据包转发到链 B
链 B 验证数据包的 Merkle Proof（证明包确实在链 A 的状态中）
链 B 执行对应逻辑，生成确认（Ack）
中继者把确认传回链 A

优势：

信任最小化：不需要信任中继者，只需要信任对方链的共识
标准化：IBC 协议有明确的规范（ICS 标准）
通用性：不仅能转代币，还能传递任意消息

局限：

只支持 Tendermint 类共识（快速最终性）的链
与以太坊等 PoW/PoS 链连接需要特殊的"客户端"（如 07-tendermint、08-wasm）

5.3 跨链安全：最大的黑洞

跨链桥是区块链安全事故的重灾区。2021-2023 年，跨链桥被盗总额超过 25 亿美元。

著名事件：

Ronin Bridge（2022）：6.25 亿美元，攻击者攻破 5/9 验证者节点
Wormhole（2022）：3.2 亿美元，智能合约漏洞（未验证 guardian 签名）
Nomad（2022）：1.9 亿美元，合约初始化错误，任何人都能调用证明函数
BNB Chain Bridge（2022）：5.66 亿美元，IAVL 树漏洞，后被社区阻止部分损失

安全教训：

多签不是万能的——验证者节点可能被逐个攻破
智能合约审计不能省——Nomad 的漏洞在审计报告中被标记但未修复
去中心化的验证者集比固定多签更安全
跨链消息的验证逻辑是最容易出 bug 的地方

前沿方案：
共享安全：Cosmos 的 Interchain Security、Polkadot 的 Relay Chain，让小链共享大链的验证者
零知识跨链：用 ZK 证明跨链状态转换，不需要信任对方共识
Restaking（再质押）：EigenLayer 让以太坊验证者同时为跨链桥提供安全

6. 智能合约安全：攻击模式与防御手册

6.1 经典攻击模式

重入攻击（Reentrancy）

solidity

// 脆弱代码
function withdraw(uint amount) public {
    require(balances[msg.sender] >= amount);
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
    balances[msg.sender] -= amount;  // 状态更新在转账之后！
}

攻击流程：

攻击者合约存入 1 ETH
调用 withdraw(1 ETH)
合约转账 1 ETH 到攻击者合约，触发攻击者的 receive() 函数
receive() 中再次调用 withdraw(1 ETH)
因为 balances[msg.sender] 还没扣减，检查通过
重复直到合约余额被掏空

防御：

检查-生效-交互（Checks-Effects-Interactions）模式：先更新状态，再转账
用 ReentrancyGuard（OpenZeppelin）加锁
用 transfer() 代替 call()（但 2300 Gas 限制在 EIP-1884 后可能不够用）

整数溢出/下溢

Solidity 0.8 之前，uint256 溢出会回绕（2^256-1 + 1 = 0）。

solidity

// Solidity 0.7 及以下的脆弱代码
function transfer(address to, uint256 amount) public {
    require(balances[msg.sender] - amount >= 0);  // 永远为真！
    balances[msg.sender] -= amount;
    balances[to] += amount;
}

防御：

Solidity 0.8+ 默认有溢出检查（会 revert）
低版本用 SafeMath 库
性能敏感场景用 unchecked { } 但必须确保不会溢出

访问控制漏洞

solidity

// 脆弱代码：任何人都能调用初始化函数
function initialize(address _owner) public {
    owner = _owner;
}

防御：

初始化函数加 initializer 修饰符（OpenZeppelin Initializable）
关键函数加 onlyOwner 或角色控制（AccessControl）
代理合约的实现合约要在构造时就初始化（防止被他人抢先初始化）

闪电贷攻击（Flash Loan Attack）

闪电贷允许在同一笔交易中借入并归还资金（不需要抵押），攻击者利用这一点在一笔交易内操纵价格。

典型流程：

从 Aave 闪电贷借入大量 USDC
用 USDC 在 Uniswap 池子中大量买入 Token X，推高价格
在另一个协议（用 Uniswap 价格作为预言机）中用高估的 Token X 作为抵押借出更多资产
卖出 Token X，归还闪电贷，获利

防御：

不要用单一 DEX 的现货价格作为预言机，用 Chainlink 等去中心化预言机
加入时间加权平均价格（TWAP）
设置价格变动上限

6.2 安全工具链

工具	用途	类型
Slither	静态分析，检测常见漏洞	开源（Trail of Bits）
Mythril	符号执行，检测漏洞	开源（ConsenSys）
Echidna	模糊测试（Fuzzing）	开源（Trail of Bits）
Foundry	测试框架，内置 fuzz	开源
OpenZeppelin Defender	合约监控、自动化响应	商业
Tenderly	模拟、调试、监控	商业
Forta	链上威胁检测网络	去中心化

6.3 安全检查清单（部署前必过）

[ ] 用 Slither / Mythril 扫描，无高危漏洞
[ ] 单元测试覆盖率 > 90%
[ ] 模糊测试覆盖核心函数
[ ] 第三方专业审计（至少一家知名审计公司）
[ ] 公开审计报告，修复所有高危/中危问题
[ ] 部署后设置监控告警（Forta / Defender）
[ ] 准备应急响应计划（暂停合约、升级路径）
[ ] 考虑 Bug Bounty（Immunefi 等平台）

实战经验：审计不是万能的。2023 年被黑的项目中，超过 60% 经过了审计。审计只能发现"已知的未知"，不能发现"未知的未知"。最好的安全是 简单的代码 + 严格的测试 + 持续的监控。

7. DeFi 全景：从 AMM 到衍生品

7.1 DeFi 协议地图

DeFi 生态
├── 资产层
│   ├── 稳定币（USDC, USDT, DAI, FRAX）
│   ├── 流动性质押代币（stETH, rETH, cbETH）
│   └── 收益凭证（LP Token, aToken, cToken）
├── 交易层
│   ├── DEX / AMM（Uniswap, Curve, Balancer）
│   ├── 聚合器（1inch, Matcha, CoW Swap）
│   └── 订单簿 DEX（dYdX, 0x Protocol）
├── 借贷层
│   ├── 超额抵押借贷（Aave, Compound, MakerDAO）
│   ├── 无抵押借贷（TrueFi, Goldfinch）
│   └── 闪电贷（Aave, dYdX）
├── 衍生品层
│   ├── 永续合约（dYdX, GMX, Perpetual Protocol）
│   ├── 期权（Dopex, Lyra, Hegic）
│   └── 利率衍生品（Pendle, Notional）
├── 收益层
│   ├── 收益聚合器（Yearn, Beefy, Convex）
│   ├── 流动性挖矿（Sushi, Curve Gauge）
│   └── 再质押（EigenLayer）
└── 基础设施
    ├── 预言机（Chainlink, Pyth, RedStone）
    ├── 跨链桥（Stargate, Across, CCIP）
    └── 账户抽象（Safe, Argent, Biconomy）

7.2 AMM 数学：恒定乘积做市商

Uniswap 的核心公式：x × y = k

x：池中 Token A 的数量
y：池中 Token B 的数量
k：常数（交易前后不变，扣除手续费后略增）

交易定价：

用户用 Δx 个 Token A 换 Token B
新的 x' = x + Δx
新的 y' = k / x'
获得的 Token B = y - y' = y - k/(x+Δx)

滑点：交易越大，价格偏离越远。滑点 = (执行价 - 市场价) / 市场价。

无常损失（Impermanent Loss）：当你向 AMM 提供流动性时，如果代币价格相对变化，你的资产价值会低于"单纯持有"的价值。

无常损失 = 2 × sqrt(price_ratio) / (1 + price_ratio) - 1

price_ratio = 1（价格不变）→ 损失 0%
price_ratio = 2（涨/跌 2 倍）→ 损失 5.7%
price_ratio = 4（涨/跌 4 倍）→ 损失 25%
price_ratio = 10 → 损失 42.5%

关键认知：无常损失不是"永久损失"——如果价格回到原点，损失消失。但如果你在价格偏离时撤出流动性，就变成了实际损失。交易手续费可以抵消无常损失，所以 APY 高的池子通常风险也大。

7.3 借贷协议：Aave 的机制

核心流程：

存款者存入资产，获得 aToken（生息凭证，数量随利息增长）
借款者抵押资产，按 LTV（贷款价值比）借入其他资产
如果抵押品价值下降到清算线，任何人可以清算（拍卖抵押品）并获得清算奖励

关键参数：

LTV（Loan-to-Value）：最高可借比例，如 75%
清算阈值：低于此比例可被清算，如 80%
清算奖励：清算者获得的折扣，如 5-10%
利率模型：根据利用率动态调整（利用率高→利率高→吸引存款/抑制借款）

DeFi 安全事件规律：
经济攻击 > 代码漏洞（很多攻击利用的是协议设计的经济激励缺陷）
预言机操纵是重灾区（用单一 AMM 价格作为预言机）
治理攻击（持有足够治理代币提案恶意参数）
跨链桥漏洞（见第 5 节）

8. NFT、链上身份与社会图谱

8.1 NFT 标准演进

标准	名称	特点	代表
ERC-721	非同质化代币	每个 Token 唯一，基础标准	BAYC, CryptoPunks
ERC-1155	多代币标准	同一合约可同时有 FT 和 NFT，批量转账省 Gas	OpenSea, GameFi
ERC-4907	租赁 NFT	增加"使用者"角色，支持租赁	游戏、元宇宙
ERC-6551	代币绑定账户	NFT 本身就是一个智能合约钱包，可以持有资产	未来方向
Metaplex	Solana NFT 标准	Solana 生态的 NFT 标准	Solana NFT

8.2 链上身份（DID）

ENS（以太坊名称服务）：把 0x1234...abcd 映射为 alice.eth，同时可以存储头像、Twitter、邮箱等元数据。

SBT（灵魂绑定代币，EIP-5114）：不可转让的 NFT，代表个人的凭证（学历、证书、贡献记录）。

** Lens Protocol**：去中心化社交图谱，用户的关注关系、帖子、收藏都是链上 NFT，可以跨应用迁移。

趋势判断：NFT 的投机泡沫已破，但技术本身在向"实用化"演进——票务、会员、游戏资产、身份凭证、RWA 代币化。下一波 NFT 的增长不会来自 JPEG 图片，而是来自"链上凭证"和"真实世界资产"。

9. DAO 治理：链上组织的实验与困境

9.1 DAO 的类型

类型	治理对象	代表
协议 DAO	管理 DeFi 协议参数	Uniswap DAO, Aave DAO, MakerDAO
投资 DAO	集体投资	MetaCartel, The LAO
社交 DAO	社区/内容	Friends with Benefits, Bankless DAO
收藏 DAO	集体收藏 NFT	PleasrDAO, ConstitutionDAO
服务 DAO	提供服务（开发、设计）	RaidGuild, DeepWork

9.2 治理机制

代币投票（1 token = 1 vote）：最简单，但容易被巨鲸控制。

委托投票（Delegation）：代币持有者可以把投票权委托给他人。Compound 首创，已成为行业标准。

二次方投票（Quadratic Voting）：投票成本 = 票数²，让小额持有者的影响力相对更大。Gitcoin Grants 使用。

多签治理：关键操作需要 N-of-M 多签确认。适合早期项目，但去中心化程度低。

9.3 DAO 的现实困境

投票率低：大多数 DAO 的治理投票参与率 < 10%
巨鲸控制：前 10 大地址通常持有 50%+ 投票权
选民冷漠：普通持有者没有动力研究复杂提案
治理攻击：借入大量治理代币，通过恶意提案后归还（闪电贷治理攻击）
法律模糊：DAO 的法律地位不明确，责任归属困难

前沿探索：
可委托的治理：Optimism 的 Citizen House / Token House 两院制
基于声誉的投票：不是按代币量，而是按贡献/参与度
乐观治理：提案默认通过，有异议才需要投票
AI 辅助治理：AI 代理帮助分析提案、模拟影响

10. 实战：部署并交互一个 ERC-20 合约

10.1 环境准备

bash

# 安装 Foundry（最快的 Solidity 开发框架）
curl -L https://foundry.paradigm.xyz | bash
foundryup

# 初始化项目
forge init my-token
cd my-token

# 安装 OpenZeppelin 合约库
forge install OpenZeppelin/openzeppelin-contracts

10.2 编写合约

solidity

// src/MyToken.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract MyToken is ERC20, ERC20Burnable, Ownable {
    uint256 public constant MAX_SUPPLY = 100_000_000 * 10**18; // 1 亿枚

    constructor(address initialOwner)
        ERC20("My Hardcore Token", "MHT")
        Ownable(initialOwner)
    {
        // 初始铸造 1000 万枚给部署者
        _mint(msg.sender, 10_000_000 * 10**18);
    }

    // 只有 owner 可以铸造
    function mint(address to, uint256 amount) public onlyOwner {
        require(totalSupply() + amount <= MAX_SUPPLY, "Exceeds max supply");
        _mint(to, amount);
    }

    // 批量转账（省 Gas）
    function batchTransfer(address[] calldata recipients, uint256[] calldata amounts)
        external
        returns (bool)
    {
        require(recipients.length == amounts.length, "Length mismatch");
        for (uint256 i = 0; i < recipients.length; i++) {
            _transfer(msg.sender, recipients[i], amounts[i]);
        }
        return true;
    }
}

10.3 编写测试

solidity

// test/MyToken.t.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Test.sol";
import "../src/MyToken.sol";

contract MyTokenTest is Test {
    MyToken public token;
    address public owner = address(0x1234);
    address public user1 = address(0x5678);
    address public user2 = address(0x9abc);

    function setUp() public {
        vm.prank(owner);
        token = new MyToken(owner);
    }

    function test_InitialSupply() public {
        assertEq(token.totalSupply(), 10_000_000 * 10**18);
        assertEq(token.balanceOf(owner), 10_000_000 * 10**18);
    }

    function test_Mint() public {
        vm.prank(owner);
        token.mint(user1, 1000 * 10**18);
        assertEq(token.balanceOf(user1), 1000 * 10**18);
        assertEq(token.totalSupply(), 10_001_000 * 10**18);
    }

    function test_MintNotOwner() public {
        vm.prank(user1);
        vm.expectRevert();
        token.mint(user1, 1000 * 10**18);
    }

    function test_MaxSupply() public {
        vm.prank(owner);
        vm.expectRevert("Exceeds max supply");
        token.mint(owner, 100_000_000 * 10**18); // 超过上限
    }

    function test_BatchTransfer() public {
        address[] memory recipients = new address[](2);
        recipients[0] = user1;
        recipients[1] = user2;

        uint256[] memory amounts = new uint256[](2);
        amounts[0] = 100 * 10**18;
        amounts[1] = 200 * 10**18;

        vm.prank(owner);
        token.batchTransfer(recipients, amounts);

        assertEq(token.balanceOf(user1), 100 * 10**18);
        assertEq(token.balanceOf(user2), 200 * 10**18);
    }

    // 模糊测试：随机金额转账
    function testFuzz_Transfer(uint256 amount) public {
        amount = bound(amount, 1, 10_000_000 * 10**18);

        vm.prank(owner);
        token.transfer(user1, amount);

        assertEq(token.balanceOf(user1), amount);
        assertEq(token.balanceOf(owner), 10_000_000 * 10**18 - amount);
    }
}

10.4 运行测试与部署

bash

# 运行测试
forge test -vvv

# 编译
forge build

# 部署到 Sepolia 测试网
forge create src/MyToken.sol:MyToken \
  --rpc-url $SEPOLIA_RPC_URL \
  --private-key $PRIVATE_KEY \
  --constructor-args $OWNER_ADDRESS

# 验证合约（在 Etherscan 上可查看源码）
forge verify-contract \
  --chain sepolia \
  --compiler-version v0.8.20 \
  <CONTRACT_ADDRESS> \
  src/MyToken.sol:MyToken

10.5 用脚本交互

solidity

// script/Interact.s.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Script.sol";
import "../src/MyToken.sol";

contract Interact is Script {
    function run() external {
        uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY");
        address tokenAddress = vm.envAddress("TOKEN_ADDRESS");
        address recipient = vm.envAddress("RECIPIENT");

        vm.startBroadcast(deployerPrivateKey);

        MyToken token = MyToken(tokenAddress);
        token.transfer(recipient, 100 * 10**18);

        vm.stopBroadcast();
    }
}

bash

# 执行脚本
forge script script/Interact.s.sol:Interact \
  --rpc-url $SEPOLIA_RPC_URL \
  --broadcast

下一步学习路径：
给合约加投票/治理功能（ERC-20Votes）
部署到 Layer2（Arbitrum / Base），对比 Gas 费
写一个前端用 ethers.js / viem 交互
用 Slither 扫描安全漏洞
提交到 Immunefi 设 Bug Bounty

中篇小结

本篇覆盖了区块链生态的全貌：从比特币的 UTXO 和闪电网络，到以太坊的 EVM 和 Gas 经济学；从主流公链横向对比，到 Layer2 扩容和跨链技术；从智能合约安全攻防，到 DeFi/NFT/DAO 的应用生态。最后用 Foundry 完整演示了 ERC-20 合约的开发、测试、部署流程。

下篇预告：我们将进入最前沿的领域——零知识证明、账户抽象、MEV、模块化区块链、RWA、区块链工程实践（节点运维、索引器、监控）、监管合规，以及职业路径与学习资源。

上篇回顾：密码学、共识、数据结构、P2P 网络、钱包、交易生命周期、Python 实现最小区块链。

区块链硬核入门教程（中篇）：生态全景与技术栈深度对比 ​

目录 ​

1. 比特币深度：UTXO、脚本与闪电网络 ​

1.1 UTXO 模型 vs 账户模型 ​

1.2 比特币脚本：被低估的表达能力 ​

1.3 闪电网络：链下支付的工程奇迹 ​

2. 以太坊深度：EVM、Solidity 与 Gas 经济学 ​

2.1 EVM 架构：世界计算机的内核 ​

2.2 Solidity 实战要点 ​

存储布局 ​

函数调用与 delegatecall ​

2.3 Gas 经济学深度解析 ​

3. 主流公链横向对比 ​

3.1 对比总表 ​

3.2 Solana：高性能的代价 ​

3.3 Cosmos：应用链范式 ​

3.4 Aptos / Sui：Move 语言的双雄 ​

4. Layer2 扩容之战 ​

4.1 扩容的不可能三角 ​

4.2 Rollup 两大路线 ​

Optimistic Rollup（乐观 Rollup） ​

ZK Rollup（零知识 Rollup） ​

4.3 zkEVM 兼容等级 ​

4.4 其他扩容方案 ​

5. 跨链技术：桥、IBC 与跨链安全 ​

5.1 跨链桥的类型 ​

5.2 IBC：Cosmos 的跨链标准 ​

5.3 跨链安全：最大的黑洞 ​

6. 智能合约安全：攻击模式与防御手册 ​

6.1 经典攻击模式 ​

重入攻击（Reentrancy） ​

整数溢出/下溢 ​

访问控制漏洞 ​

闪电贷攻击（Flash Loan Attack） ​

6.2 安全工具链 ​

6.3 安全检查清单（部署前必过） ​

7. DeFi 全景：从 AMM 到衍生品 ​

7.1 DeFi 协议地图 ​

7.2 AMM 数学：恒定乘积做市商 ​

7.3 借贷协议：Aave 的机制 ​

8. NFT、链上身份与社会图谱 ​

8.1 NFT 标准演进 ​

8.2 链上身份（DID） ​

9. DAO 治理：链上组织的实验与困境 ​

9.1 DAO 的类型 ​

9.2 治理机制 ​

9.3 DAO 的现实困境 ​

10. 实战：部署并交互一个 ERC-20 合约 ​

10.1 环境准备 ​

10.2 编写合约 ​

10.3 编写测试 ​

10.4 运行测试与部署 ​

10.5 用脚本交互 ​

中篇小结 ​

区块链硬核入门教程（中篇）：生态全景与技术栈深度对比

目录

1. 比特币深度：UTXO、脚本与闪电网络

1.1 UTXO 模型 vs 账户模型

1.2 比特币脚本：被低估的表达能力

1.3 闪电网络：链下支付的工程奇迹

2. 以太坊深度：EVM、Solidity 与 Gas 经济学

2.1 EVM 架构：世界计算机的内核

2.2 Solidity 实战要点

存储布局

函数调用与 delegatecall

2.3 Gas 经济学深度解析

3. 主流公链横向对比

3.1 对比总表

3.2 Solana：高性能的代价

3.3 Cosmos：应用链范式

3.4 Aptos / Sui：Move 语言的双雄

4. Layer2 扩容之战

4.1 扩容的不可能三角

4.2 Rollup 两大路线

Optimistic Rollup（乐观 Rollup）

ZK Rollup（零知识 Rollup）

4.3 zkEVM 兼容等级

4.4 其他扩容方案

5. 跨链技术：桥、IBC 与跨链安全

5.1 跨链桥的类型

5.2 IBC：Cosmos 的跨链标准

5.3 跨链安全：最大的黑洞

6. 智能合约安全：攻击模式与防御手册

6.1 经典攻击模式

重入攻击（Reentrancy）

整数溢出/下溢

访问控制漏洞

闪电贷攻击（Flash Loan Attack）

6.2 安全工具链

6.3 安全检查清单（部署前必过）

7. DeFi 全景：从 AMM 到衍生品

7.1 DeFi 协议地图

7.2 AMM 数学：恒定乘积做市商

7.3 借贷协议：Aave 的机制

8. NFT、链上身份与社会图谱

8.1 NFT 标准演进

8.2 链上身份（DID）

9. DAO 治理：链上组织的实验与困境

9.1 DAO 的类型

9.2 治理机制

9.3 DAO 的现实困境

10. 实战：部署并交互一个 ERC-20 合约

10.1 环境准备

10.2 编写合约

10.3 编写测试

10.4 运行测试与部署

10.5 用脚本交互

中篇小结