﻿---
title: "硬分叉与软分叉：规则兼容性、激活与链分裂"
description: "硬分叉和软分叉描述新旧共识规则之间不同的兼容关系。分析时应分别核对有效区块集合、激活机制、节点执行、矿工或验证者行为、应用准备、重放风险以及由此产生的链分裂。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 硬分叉与软分叉：规则兼容性、激活与链分裂

> 仅供协议教育分析，不构成投资建议。拟议或已激活的分叉可能扰乱验证、充提币、托管、合约、价格、流动性、税务处理和运营安全，也不保证会产生第二种可持续资产。

<a id="answer"></a>

## 直接答案

硬分叉和软分叉根据升级与未升级节点如何判断区块，对共识规则变更进行分类。令 `V_old` 表示旧规则接受的区块集合，`V_new` 表示新规则接受的区块集合。软分叉收紧有效性，使 `V_new subset V_old`：每个按新规则有效的区块也按旧规则有效，但旧节点不会执行新增限制。硬分叉至少允许一种会被旧节点拒绝的新规则有效区块：`exists b: b in V_new and b not in V_old`。硬分叉的规则集合可能是扩张，也可能互不包含；“硬”并不只是指更大的区块或更激进的功能。

这种兼容性并不对称。软分叉成功时，未升级节点会接受升级后矿工或验证者产生的区块，因此可以留在同一条链上；但它也可能把升级节点拒绝的对象判断为有效，因而提供较弱的保证。硬分叉中，一旦升级后的区块生产者产生超出旧有效集合的区块，旧节点便无法跟随。如果具有经济影响力的参与者继续维护两套规则，就可能形成两个持久网络；如果一方没有实际支持，规则变更不一定产生两种长期资产。

这些标签描述的是规则，而不是治理正当性、安全性、经济支持或激活方式。一项提案在激活前就可被称为硬分叉，已激活的变更可能不造成持久分裂，而意外的实现不兼容也可能在没有治理投票的情况下分裂链。矿工或验证者信号可以协调准备程度，但无法让全节点接受其自身规则认定为无效的区块。

不要把共识分叉与采用同一规则的短暂分叉、链重组、软件代码仓库分支或应用升级混为一谈。运营上的关键问题是：每个节点、钱包、交易平台、托管人、预言机和合约究竟认可哪个网络、哪套规则、何种激活条件和哪段链历史。

<a id="mechanism"></a>

## 如何分析协议分叉

1. **锁定身份与范围。** 记录 `chain`、`network`、`client version`、激活提案、创世块或最终确定检查点、当前区块哈希及受影响层。同一名称用于测试网、主网、执行层、共识层或应用时，可能代表不同规则。
2. **比较共识有效性。** 列出所有变更的区块、交易、签名、状态转换、Gas、时间戳、最终性或分叉选择规则。分别按两个版本将代表性对象归类为 `valid`、`invalid` 或 `unknown`；不要只凭发布说明推断兼容性。
3. **证明集合关系。** 检验所有新规则有效对象是否仍按旧规则有效。若是，变更可能具有软分叉兼容关系；只要有一个新规则有效区块按旧规则无效，这些节点就需要硬分叉式过渡。同时也要测试哪些旧规则有效对象会被新规则判为无效。
4. **复现激活过程。** 从已部署规范和代码核对高度、纪元、中位时间、信号阈值、锁定延迟、总难度条件或治理触发器。发出信号、锁定、激活和执行是不同状态。
5. **梳理参与者行为。** 衡量已升级的区块生产权重，并识别每一方的全节点、中继、钱包、交易平台、托管人、桥、稳定币发行方、预言机和合约。算力或质押权重本身不能决定经济接受度。
6. **追踪分裂与交易处理。** 按两套规则追踪父哈希和有效性。检查确认政策、内存池分歧、重放保护、地址格式、链标识符、签名域、提现路径，以及交易能否在两个分支上执行。
7. **设置运营控制。** 在祖先关系不明确时暂停或延长结算；有计划地升级并备份；按分支核对余额与负债；离线测试签名和恢复；只有满足明确的链、节点、对手方和最终性标准后才恢复业务。

这种方法把经常被“分叉”一词混在一起的四件事分开：规则提案、激活条件、观察到的链分歧，以及此后一个或多个分支能否在经济上存续。任何一步都不会自动证明下一步必然发生。

<a id="example"></a>

## 计算示例

### 1. 有效集合兼容性

假设旧规则接受 `100` 种候选区块形式，新规则只接受其中 `80` 种。如果这 `80` 种完全位于旧集合内，变更就具有软分叉关系；其余 `20` 种旧规则有效形式会被升级节点拒绝。这些数字用于说明集合，不代表概率或投票阈值。

再假设新规则接受一种所有旧节点都会拒绝的区块形式。即使大多数其他区块按两套规则都有效，这一个反例也足以破坏向后接受关系，使过渡与硬分叉兼容性相符。网络是否真的长期分裂，则取决于该区块出现后区块生产者、用户和经济基础设施的选择。

### 2. BIP 34 的激活机制并非定义

`BIP 34` 要求币基交易写入区块高度，并采用滚动就绪机制。此前 1,000 个区块中有 `750 of 1,000` 个为版本 2 或更高时，节点开始拒绝无效的版本 2 区块；达到 `950 of 1,000` 后，节点拒绝版本 1 区块。该 BIP 记载区块 `227,835` 是最后一个版本 1 区块。

这些阈值用于协调部署，并不是变更属于软分叉的原因。其兼容性来自升级节点收紧接受范围，同时旧客户端仍能接受符合新规则的升级区块。之后的 `BIP 9` 又规定了彼此分离的部署状态与版本位，进一步说明规则关系和激活机制是两个问题。

### 3. 隔离见证的软分叉设计

`BIP 141` 引入 `witness` 数据，并通过币基交易把其树承诺纳入既有区块承诺结构。该设计使旧节点无需理解或验证新的见证规则，也能接受符合规则的区块；升级节点则会执行这些规则。

这是向后接受，并非验证能力相同。对于受新规则约束的输出，旧节点看到的限制可能少于升级节点，因此依赖新安全属性的用户需要使用升级后的验证。“旧软件仍能运行”并不是完整的风险分析。

### 4. 以太坊 DAO Fork

EIP-779 记录 DAO Fork 在主网区块 `1,920,000` 激活。它描述了一次非常规状态变更：将指定账户列表 `L` 中的余额转入 `WithdrawDAO` 合约，而 EVM 操作码、交易格式和区块结构保持不变。

执行该状态转换的节点与拒绝执行的节点会计算出不同的边界后状态。这个案例说明，硬分叉不一定扩大区块或增加操作码：一次性的状态转换规则也会产生不兼容，而双方持续支持各自历史时，两个独立网络可以继续存在。

<a id="risks"></a>

## 风险与审查错误

### 分类与规范错误

- 把每次短暂的竞争链头都称为硬分叉，尽管所有节点采用相同规则，普通分叉选择即可解决。
- 未检验真实的有效区块集合，就把所有规则放宽定义为硬分叉、所有规则收紧定义为软分叉。
- 把向后接受等同于完整的向后安全；旧节点并不执行新的软分叉限制。
- 根据品牌名、路线图、发布说明或代码仓库分支推断共识行为，而不核对已部署代码和链参数。
- 混用主网、测试网、执行层、共识层、桥、Rollup 和应用层升级。
- 认为提案、客户端发布、信号阈值、锁定和激活是同一事件。
- 把矿工或验证者信号当作用户、交易平台、托管人或全节点具有约束力的投票。

### 分裂与交易风险

- 认为激活必然造成分裂，或分裂必然产生两种有流动性且可持续的资产。
- 分支可在同一高度包含不同区块时只看高度；还应验证哈希与祖先关系。
- 在未检查重放保护、链标识符、签名域和分支专用交易构造的情况下于分裂期间转账。
- 在一个分支确认入金，却在另一个分支结算负债或提现。
- 依赖单一浏览器、RPC 端点或托管标签，而这些服务商可能遵循不同规则或落后于过渡进度。
- 忽略重组、最终性停滞、对等节点分区、少数算力、验证者双签或数据不可用状况。
- 假设代币代码、合约地址、稳定币余额、预言机价格或桥接凭证在两个分支上得到相同发行方支持。

### 治理与运营风险

- 把协议兼容性描述为变更合法、去中心化、安全或获得经济支持的证明。
- 在没有可复现二进制文件、备份、回滚边界、数据库迁移测试和独立哈希核对时升级生产节点。
- 在引入新状态数据、钱包格式或罚没条件后，假设降级始终安全。
- 使用未经验证的软件移动私钥或“领取分叉币”，从而暴露秘密或造成签名重放。
- 未检查成熟期、锁定、合约状态和托管政策，就把快照余额视为可以立即支配。
- 在明确分支所有权、控制权、流动性和当地规则前作出税务、会计或估值结论。

<a id="misconceptions"></a>

## 常见误区

- **硬分叉一定会创造一种新币。** 持久的第二种资产需要持续区块生产、用户、基础设施和市场；许多升级最终只保留一段被接受的历史。
- **旧节点仍可运行，所以软分叉没有风险。** 旧节点可以跟随链，但不会执行新增规则，验证保证可能更弱。
- **多数算力或质押权重可以自行改变任何规则。** 全节点会拒绝不符合自身规则的区块；生产权重只在它们接受的区块之间发挥作用。
- **硬分叉表示有争议，软分叉表示一致同意。** 这些术语分类的是兼容性，而不是社会共识、治理质量或争议程度。
- **浏览器显示的每次分叉都是协议升级。** 使用相同规则的竞争区块和链重组可以在没有任何共识规则变更时发生。

<a id="related"></a>

## 相关主题

- [共识机制](/zh-cn/crypto/consensus-mechanism/)
- [全节点](/zh-cn/crypto/full-node/)
- [分叉选择规则](/zh-cn/crypto/fork-choice-rule/)
- [链重组](/zh-cn/crypto/chain-reorg/)
- [比特币](/zh-cn/crypto/bitcoin/)

<a id="sources"></a>

## 资料来源

- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST（访问日期：2026-08-19）
- [Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Project（访问日期：2026-08-19）
- [BIP 34: Block v2, Height in Coinbase](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki) - Bitcoin BIPs（访问日期：2026-08-19）
- [BIP 66: Strict DER signatures](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki) - Bitcoin BIPs（访问日期：2026-08-19）
- [BIP 9: Version bits with timeout and delay](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) - Bitcoin BIPs（访问日期：2026-08-19）
- [BIP 141: Segregated Witness (Consensus layer)](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) - Bitcoin BIPs（访问日期：2026-08-19）
- [BIP 50: March 2013 Chain Fork Post-Mortem](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki) - Bitcoin BIPs（访问日期：2026-08-19）
- [EIP-779: Hardfork Meta: DAO Fork](https://eips.ethereum.org/EIPS/eip-779) - Ethereum Improvement Proposals（访问日期：2026-08-19）

Source: https://wiki.fcontext.com/zh-cn/crypto/hard-fork-soft-fork/index.mdx
