学习视频来源:https://www.bilibili.com/video/BV1Vt411X7JF/?p=10
本博客除了包含自己的在学习过程中记录的笔记外，还包含少部分自己扩展的内容，如有错误，敬请指正。
文章目录
- [1 分叉原理](#1 分叉原理)
-
- [1.1 概念](#1.1 概念)
- [1.2 硬分叉 vs 软分叉](#1.2 硬分叉 vs 软分叉)
- [2 比特币中的分叉案例](#2 比特币中的分叉案例)
-
- [2.1 硬分叉示例 --- 区块大小限制](#2.1 硬分叉示例 — 区块大小限制)
- [2.2 软分叉示例 --- P2SH (Pay-to-Script-Hash)](#2.2 软分叉示例 — P2SH (Pay-to-Script-Hash))
- [3 以太坊的分叉案例](#3 以太坊的分叉案例)
-
- [3.1 The DAO 事件](#3.1 The DAO 事件)
- [3.2 防止跨链交易重放攻击](#3.2 防止跨链交易重放攻击)
- [4 分叉提案](#4 分叉提案)
-
- [4.1 Coinbase 字段扩展------软分叉（只是提案，尚未激活！）](#4.1 Coinbase 字段扩展——软分叉（只是提案，尚未激活！）)
- [5 总结](#5 总结)
1 分叉原理
1.1 概念
当区块链网络中的协议规则发生分歧时，会导致链分裂成两条或更多独立的链，这种情况称为 分叉（Fork） 。
根据协议修改的内容是否向后兼容，分叉可分为 硬分叉（Hard Fork） 和 软分叉（Soft Fork）。
1.2 硬分叉 vs 软分叉
- 硬分叉：向后不兼容。旧节点无法验证新规则下产生的区块，若不升级，将继续在旧链上运行，可能导致永久性链分裂。
- 软分叉：向后兼容。旧节点仍能验证新区块（尽管可能无法理解其中的新规则），只要多数算力支持新规则，根据最长区块原则，网络最终会收敛到单一链上。
2 比特币中的分叉案例
2.1 硬分叉示例 --- 区块大小限制
假设比特币区块大小限制从 1 MB 增加到 4 MB， 大多数节点更新了软件版本，认可最大 4 MB 的区块，少数未更新的节点仍只认可1 MB 的区块。
- 新节点挖出的<= 4 MB 区块，旧节点不认可，收到>1M的区块，直接拒绝，还是只在旧链上延申；
- 旧节点挖出的 <=1 MB 区块，新节点认可，加入区块链，形成了短暂的分叉，但新节点算力数量多，算力强，挖的快，根据最长区块原则，最终也会认可新链；
这样就分裂为两条独立的链，形成永久性硬分叉。
举例
- 区块高度 N：所有节点共识一致（比如 1MB）
- 新节点挖出区块 A（2MB），广播
- 旧节点收到 A → 检查大小 → >1MB → 无效 → 丢弃
- 旧节点继续在 N 上挖 → 产出 B（0.8MB），广播
- 新节点收到 B → 检查：≤4MB → PoW 有效 → 接受 B 为有效区块
- 但注意：B 的父区块是 N，不是 A
- 所以新节点看到两条链：
链1: N → A（2MB）
链2: N → B（0.8MB）
如果新节点随后在 A 后挖出 A2，那么链1 变成 N→A→A2，根据最长区块原则，新节点就会放弃链2（N→B），即使 B 本身是有效的。
注意：
- 新节点可以接受 B（因为 B ≤4MB），但它不会把 B 接在 A 后面，因为 B 的父哈希是 N，不是 A。
- 区块并非越大越好。过大的区块会显著增加 P2P 网络的带宽和存储负担。
2.2 软分叉示例 --- P2SH (Pay-to-Script-Hash)
P2SH 是一种通过脚本哈希实现复杂支付逻辑（如多重签名）的技术，在早期比特币版本中并不存在，后来通过软分叉方式引入：
- 旧节点仅验证交易的基本结构（如输入/输出格式），不解析脚本内容，因此仍会接受包含 P2SH 输出的新区块；旧节点只验证哈希是否匹配，不执行脚本。虽然这时候输出中的哈希已经不是P2PKH中的接收方公钥哈希，而是赎回脚本哈希。但哈希函数使用的都是HASH160 函数，两者的哈希值，对节点来说格式是一样的，符合格式要求。
- 新节点完整理解并执行 P2SH 验证。（两阶段：哈希匹配 + 脚本执行）
- 只要网络中超过半数的算力运行支持 P2SH 的新版本，旧链将因"非最长有效链"而被自然淘汰；
- 因此，不会产生永久性分叉，系统最终保持统一。
3 以太坊的分叉案例
3.1 The DAO 事件
2016 年，基于以太坊构建的去中心化自治组织 The DAO 遭遇智能合约漏洞攻击，导致约 360 万 ETH（当时价值超 5000 万美元）被黑客盗取。
面对危机，以太坊社区就是否干预链上状态展开激烈争论：
- 一方坚持"代码即法律"，反对任何回滚；
- 另一方主张保护用户资产，推动协议级修复。
最终，社区通过多数共识实施了一次硬分叉 ，在区块高度 #1,920,000 处将资金状态回滚至攻击前，并允许投资者取回资金。
这一决策直接导致原链继续运行，形成 以太坊经典（Ethereum Classic, ETC） ，而新链则成为今天的主流 以太坊（Ethereum, ETH）。
3.2 防止跨链交易重放攻击
分叉初期，ETH 与 ETC 使用完全相同的地址格式、签名算法和交易结构，导致严重的跨链交易重放攻击 风险：
用户在一条链上发起的交易，可被复制并在另一条链上重复执行，造成意外资产损失。
为解决此问题，以太坊通过 EIP-155 提案引入了 chainId（链标识符）机制：
- 在交易签名过程中，将
chainId作为哈希计算的一部分； - 不同链使用不同的
chainId（如 ETH = 1，ETC = 61）； - 这使得一笔在 ETH 上签名的交易，在 ETC 网络上验证时会因
chainId不匹配而失败； - 从而确保交易仅在其目标链上有效，彻底防止跨链重放。
如今，chainId 已成为所有 EVM 兼容链的标准配置，是多链生态安全运行的基础。
4 分叉提案
4.1 Coinbase 字段扩展------软分叉（只是提案，尚未激活！）
在比特币中，每个区块的首笔交易称为 Coinbase 交易 ，由矿工创建，用于领取区块奖励。
目前，由于nonce大小不够用，只有4个字节，就算枚举完大概率还是找不到符合target的哈希。所以将Coinbase 交易的前 8 个字节常被用作 extra nonce，以增加挖矿随机性空间（可达 2 96 2^{96} 296 种组合）。
有人提出进一步扩展其用途：将 UTXO（未花费交易输出）集合的默克尔根哈希值写入 Coinbase 字段 。
这样做的意义在于：
- 全节点可将 UTXO 集构建成默克尔树；
- 轻节点可通过默克尔证明，验证某个账户余额是否真实存在（当前比特币无法直接证明余额）；
- 该根哈希最终会影响区块头的 Merkle Root，从而锚定到区块链中。
由于旧节点仅检查 Coinbase 交易的格式合法性（而非内容语义），它们仍会接受包含 UTXO 根的新区块。
因此，这一变更属于软分叉：新节点可执行新规则，旧节点仍兼容，无需强制全网升级。
5 总结
- 硬分叉 ： 旧节点接受不了新规则，将新节点挖出的区块试为无效。 要求所有节点都必须升级，否则将导致永久性链分裂（如 ETH / ETC、BTC / BCH）。
- 软分叉 ：旧节点以仍能接受新规则，将新节点挖出的区块视为有效。只需多数算力支持即可成功部署，旧节点仍能验证新区块，系统可能会产生临时性分叉，但不会产生永久分叉（如 P2SH）。
- 在实施任何类型的分叉前，必须充分评估其对现有用户、矿工、开发者及整个生态的影响，确保平稳过渡与社区共识。