--- 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. # 硬分叉與軟分叉：規則相容性、啟用與鏈分裂 > 僅供協議教育分析，不構成投資建議。擬議或已啟用的分叉可能擾亂驗證、存提款、託管、合約、價格、流動性、稅務處理和營運安全，也不保證會產生第二種可持續資產。 ## 直接答案 硬分叉和軟分叉根據升級與未升級節點如何判斷區塊，對共識規則變更進行分類。令 `V_old` 表示舊規則接受的區塊集合，`V_new` 表示新規則接受的區塊集合。軟分叉收緊有效性，使 `V_new subset V_old`：每個按新規則有效的區塊也按舊規則有效，但舊節點不會執行新增限制。硬分叉至少允許一種會被舊節點拒絕的新規則有效區塊：`exists b: b in V_new and b not in V_old`。硬分叉的規則集合可能是擴張，也可能互不包含；「硬」並不只是指更大的區塊或更激進的功能。 這種相容性並不對稱。軟分叉成功時，未升級節點會接受升級後礦工或驗證者產生的區塊，因此可以留在同一條鏈上；但它也可能把升級節點拒絕的物件判斷為有效，因而提供較弱的保證。硬分叉中，一旦升級後的區塊生產者產生超出舊有效集合的區塊，舊節點便無法跟隨。如果具有經濟影響力的參與者繼續維護兩套規則，就可能形成兩個持久網路；如果一方沒有實際支持，規則變更不一定產生兩種長期資產。 這些標籤描述的是規則，而不是治理正當性、安全性、經濟支持或啟用方式。一項提案在啟用前就可被稱為硬分叉，已啟用的變更可能不造成持久分裂，而意外的實作不相容也可能在沒有治理投票的情況下分裂鏈。礦工或驗證者訊號可以協調準備程度，但無法讓全節點接受其自身規則認定為無效的區塊。 不要把共識分叉與採用同一規則的短暫分叉、鏈重組、軟體程式碼儲存庫分支或應用程式升級混為一談。營運上的關鍵問題是：每個節點、錢包、交易平台、託管人、預言機和合約究竟認可哪個網路、哪套規則、何種啟用條件和哪段鏈歷史。 ## 如何分析協議分叉 1. **鎖定身分與範圍。** 記錄 `chain`、`network`、`client version`、啟用提案、創世區塊或最終確定檢查點、目前區塊雜湊及受影響層。同一名稱用於測試網、主網、執行層、共識層或應用程式時，可能代表不同規則。 2. **比較共識有效性。** 列出所有變更的區塊、交易、簽章、狀態轉換、Gas、時間戳、最終性或分叉選擇規則。分別按兩個版本將代表性物件歸類為 `valid`、`invalid` 或 `unknown`；不要只憑版本說明推斷相容性。 3. **證明集合關係。** 檢驗所有新規則有效物件是否仍按舊規則有效。若是，變更可能具有軟分叉相容關係；只要有一個新規則有效區塊按舊規則無效，這些節點就需要硬分叉式過渡。同時也要測試哪些舊規則有效物件會被新規則判為無效。 4. **重現啟用過程。** 從已部署規範和程式碼核對高度、時期、中位時間、訊號門檻、鎖定延遲、總難度條件或治理觸發器。發出訊號、鎖定、啟用和執行是不同狀態。 5. **梳理參與者行為。** 衡量已升級的區塊生產權重，並識別每一方的全節點、中繼、錢包、交易平台、託管人、跨鏈橋、穩定幣發行方、預言機和合約。算力或質押權重本身不能決定經濟接受度。 6. **追蹤分裂與交易處理。** 按兩套規則追蹤父雜湊和有效性。檢查確認政策、記憶體池分歧、重放保護、位址格式、鏈識別碼、簽章域、提款路徑，以及交易能否在兩個分支上執行。 7. **設定營運控制。** 在祖先關係不明確時暫停或延長結算；有計畫地升級並備份；按分支核對餘額與負債；離線測試簽署和復原；只有滿足明確的鏈、節點、交易對手和最終性標準後才恢復業務。 這種方法把經常被「分叉」一詞混在一起的四件事分開：規則提案、啟用條件、觀察到的鏈分歧，以及此後一個或多個分支能否在經濟上存續。任何一步都不會自動證明下一步必然發生。 ## 計算範例 ### 1. 有效集合相容性 假設舊規則接受 `100` 種候選區塊形式，新規則只接受其中 `80` 種。如果這 `80` 種完全位於舊集合內，變更就具有軟分叉關係；其餘 `20` 種舊規則有效形式會被升級節點拒絕。這些數字用於說明集合，不代表機率或投票門檻。 再假設新規則接受一種所有舊節點都會拒絕的區塊形式。即使大多數其他區塊按兩套規則都有效，這一個反例也足以破壞向後接受關係，使過渡與硬分叉相容性相符。網路是否真的長期分裂，則取決於該區塊出現後區塊生產者、使用者和經濟基礎設施的選擇。 ### 2. BIP 34 的啟用機制並非定義 `BIP 34` 要求 Coinbase 交易寫入區塊高度，並採用滾動就緒機制。此前 1,000 個區塊中有 `750 of 1,000` 個為版本 2 或更高時，節點開始拒絕無效的版本 2 區塊；達到 `950 of 1,000` 後，節點拒絕版本 1 區塊。該 BIP 記載區塊 `227,835` 是最後一個版本 1 區塊。 這些門檻用於協調部署，並不是變更屬於軟分叉的原因。其相容性來自升級節點收緊接受範圍，同時舊客戶端仍能接受符合新規則的升級區塊。之後的 `BIP 9` 又規定了彼此分離的部署狀態與版本位元，進一步說明規則關係和啟用機制是兩個問題。 ### 3. 隔離見證的軟分叉設計 `BIP 141` 引入 `witness` 資料，並透過 Coinbase 交易把其樹狀承諾納入既有區塊承諾結構。該設計使舊節點無需理解或驗證新的見證規則，也能接受符合規則的區塊；升級節點則會執行這些規則。 這是向後接受，並非驗證能力相同。對於受新規則約束的輸出，舊節點看到的限制可能少於升級節點，因此依賴新安全屬性的使用者需要使用升級後的驗證。「舊軟體仍能執行」並不是完整的風險分析。 ### 4. 以太坊 DAO Fork EIP-779 記錄 DAO Fork 在主網區塊 `1,920,000` 啟用。它描述了一次非常規狀態變更：將指定帳戶列表 `L` 中的餘額轉入 `WithdrawDAO` 合約，而 EVM 操作碼、交易格式和區塊結構保持不變。 執行該狀態轉換的節點與拒絕執行的節點會計算出不同的邊界後狀態。這個案例說明，硬分叉不一定擴大區塊或增加操作碼：一次性的狀態轉換規則也會產生不相容，而雙方持續支持各自歷史時，兩個獨立網路可以繼續存在。 ## 風險與審查錯誤 ### 分類與規範錯誤 - 把每次短暫的競爭鏈頭都稱為硬分叉，儘管所有節點採用相同規則，一般分叉選擇即可解決。 - 未檢驗真實的有效區塊集合，就把所有規則放寬定義為硬分叉、所有規則收緊定義為軟分叉。 - 把向後接受等同於完整的向後安全；舊節點並不執行新的軟分叉限制。 - 根據品牌名稱、路線圖、版本說明或程式碼儲存庫分支推斷共識行為，而不核對已部署程式碼和鏈參數。 - 混用主網、測試網、執行層、共識層、跨鏈橋、Rollup 和應用層升級。 - 認為提案、客戶端發布、訊號門檻、鎖定和啟用是同一事件。 - 把礦工或驗證者訊號當作使用者、交易平台、託管人或全節點具有約束力的投票。 ### 分裂與交易風險 - 認為啟用必然造成分裂，或分裂必然產生兩種有流動性且可持續的資產。 - 分支可在同一高度包含不同區塊時只看高度；還應驗證雜湊與祖先關係。 - 在未檢查重放保護、鏈識別碼、簽章域和分支專用交易建構的情況下於分裂期間轉帳。 - 在一個分支確認入金，卻在另一個分支結算負債或提款。 - 依賴單一瀏覽器、RPC 端點或託管標籤，而這些服務商可能遵循不同規則或落後於過渡進度。 - 忽略重組、最終性停滯、對等節點分區、少數算力、驗證者雙簽或資料不可用狀況。 - 假設代幣代碼、合約位址、穩定幣餘額、預言機價格或橋接憑證在兩個分支上得到相同發行方支持。 ### 治理與營運風險 - 把協議相容性描述為變更合法、去中心化、安全或獲得經濟支持的證明。 - 在沒有可重現二進位檔、備份、回復邊界、資料庫遷移測試和獨立雜湊核對時升級正式環境節點。 - 在引入新狀態資料、錢包格式或罰沒條件後，假設降級始終安全。 - 使用未經驗證的軟體移動私鑰或「領取分叉幣」，從而暴露祕密或造成簽章重放。 - 未檢查成熟期、鎖定、合約狀態和託管政策，就把快照餘額視為可以立即支配。 - 在明確分支所有權、控制權、流動性和當地規則前作出稅務、會計或估值結論。 ## 常見誤解 - **硬分叉一定會創造一種新幣。** 持久的第二種資產需要持續區塊生產、使用者、基礎設施和市場；許多升級最終只保留一段被接受的歷史。 - **舊節點仍可執行，所以軟分叉沒有風險。** 舊節點可以跟隨鏈，但不會執行新增規則，驗證保證可能較弱。 - **多數算力或質押權重可以自行改變任何規則。** 全節點會拒絕不符合自身規則的區塊；生產權重只在它們接受的區塊之間發揮作用。 - **硬分叉表示有爭議，軟分叉表示一致同意。** 這些術語分類的是相容性，而不是社會共識、治理品質或爭議程度。 - **瀏覽器顯示的每次分叉都是協議升級。** 使用相同規則的競爭區塊和鏈重組可以在沒有任何共識規則變更時發生。 ## 相關主題 - [共識機制](/zh-tw/crypto/consensus-mechanism/) - [全節點](/zh-tw/crypto/full-node/) - [分叉選擇規則](/zh-tw/crypto/fork-choice-rule/) - [鏈重組](/zh-tw/crypto/chain-reorg/) - [比特幣](/zh-tw/crypto/bitcoin/) ## 資料來源 - [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-tw/crypto/hard-fork-soft-fork/index.mdx