---
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.
# 分叉選擇規則：有效分支、權重與規範鏈頭
> 僅供協議研究與教育用途。節點的當前鏈頭取決於網路、規則版本、已驗證本地檢視、權重證據、檢查點與時間；它不會因此自動最終化，也未必適合不可逆的應用結算。
## 直接答案
分叉選擇規則是一套協議程式，它把節點對競爭區塊與共識訊息的已驗證本地檢視對映為當前規範鏈頭。輸出是暫時的，也與觀察者有關：兩個誠實節點可能因收到的有效區塊、投票或時序事件不同，短暫選擇不同鏈頭。在協議的網路假設下，當可接受檢視趨於一致時，規則也應趨於一致。
分叉選擇不會讓無效區塊變得有效。狀態轉換、授權、證明、祖先關係和資料可用性檢查先決定哪些候選可接受，然後才能比較權重。選出的鏈頭也不一定已經最終化。分叉選擇決定現在延伸哪條分支；最終性規則可用更強安全證據保護較老祖先。替換當前鏈頭可能是常規操作，而替換已最終化檢查點則會越過另一條協議邊界。
“最長鏈”不是通用公式。Bitcoin 選擇累計工作量最大的有效鏈：決定因素是累計預期工作量，而非原始高度。Ethereum 的 LMD-GHOST 從已合理化檢查點出發，篩選可行分支，再貪心地沿最新訊息投票餘額最大的子節點前進，並計入適用的提議者加權；每個驗證者只貢獻最新合格訊息。其他協議可能使用可用性證書、領導者鎖定、輪次或明確提交證書，而不是持續競爭最重分支。
結果取決於精確輸入：鏈與網路、分叉版本、可信錨點、當前時間或時隙、已知有效區塊、父連結、工作量或投票權重快照、最新訊息、雙簽證據、已合理化與已最終化檢查點、可用性狀態、提議者時序和確定性平局規則。區塊瀏覽器徽章或一個 RPC 結果只是某個節點輸出的觀察值，不是規則本身，也不是對輸入的獨立證明。
## 如何分析分叉選擇規則
1. **固定身份與版本。** 記錄鏈、網路、共識分叉、客戶端版本、創世或可信錨點、當前高度或時隙，以及該位置生效的確切規則。不要把主網邏輯套用到測試網、側鏈、彙總或未來提案。
2. **構建可接受區塊圖。** 驗證雜湊、父節點、共識證明、狀態轉換、執行載荷狀態和所需資料可用性。明確標記未知、樂觀、無效和已剪枝節點；權重不能挽救無效分支。
3. **重建祖先關係與約束。** 找出共同祖先，確認哪些候選繼承所需檢查點、鎖定或證書。區分原始觀測樹與規則實際考慮的篩選後樹。
4. **復現每項權重輸入。** 對 PoW，解碼目標並把逐塊證明累加為累計鏈工作量。對投票規則，驗證驗證者身份、活躍有效餘額或其他權重、訊息域、目標根、時隙或 epoch、最新訊息替換、雙籤處理與臨時加權。
5. **精確執行選擇與平局規則。** 在每個分支應用規定的遞迴或比較器，遵守協議取整和確定性排序。記錄等權時是否允許暫時本地偏好，而不是假裝平局已經達成最終共識。
6. **核對鏈頭變化。** 勝者變化時識別斷開和接入的區塊，回滾並重放狀態，核對收據、日誌和記憶體池，並由共同祖先計算重組深度。區分 head、safe、justified、committed 與 finalized 標籤。
7. **壓力測試並監控部署。** 測試延遲或扣留區塊、分割槽、過期投票、雙籤、平衡攻擊、提議者時序、客戶端分歧、弱檢查點與資料不可用。比較獨立節點，在不可逆下游動作前，對意外鏈頭分歧、深度重組或與最終狀態衝突報警。
在當前 Bitcoin Core 中，候選排序先比較 `nChainWork`；工作量相等時再按最早可啟用序列排序，並有內部後備平局規則。RPC 欄位 `blocks` 是累計工作量最大且完整驗證的鏈高度，`bestblockhash` 則標識其鏈頭。在 Ethereum 當前分叉選擇規範中，`get_head(store)` 從 `justified_checkpoint` 開始，遍歷篩選後的樹，在每一步選取使 `(get_weight(store, child), child.root)` 最大的子節點。這些實現細節只屬於特定協議與版本，不是共識的通用定義。
## 計算示例
### 1. Bitcoin 累計工作量切換
兩條有效分支共享祖先 `C`。當前鏈頭為 `chainwork(A)=240` 與 `chainwork(B)=235`，所以節點選擇 `A`，即使粗略高度顯示讓兩條分支看似相近。一個新有效區塊為 B 分支增加工作量 `10`：
`chainwork(B') = 235 + 10 = 245`
因為 `245 > 240`，B 成為最大工作量候選。節點斷開 A 在 `C` 之後的區塊，接入 B 至 `B'`，並核對交易。逐塊目標不同時，原始區塊數不夠；工作量相等只是暫時平局，不是最終性證明。
### 2. 貪心最重觀測子樹
使用以已合理化檢查點 `J` 為根的簡化 LMD-GHOST 樹。其子節點為 `A` 與 `B`。驗證者最新合格訊息給 A 的整個子樹權重 `61`，給 B 子樹 `39`，因此第一步選擇 `A`。A 的子節點 `A_1` 與 `A_2` 的子樹權重為 `34` 和 `27`；下一步選擇 `A_1`。
鏈頭是透過反覆選擇最重子節點得到的，不是計算分支長度，也不是選擇孤立直接投票最多的葉節點。生產規則還包含可行性篩選、餘額快照、雙籤處理、提議者時序與平局規則，這棵教學樹均予以省略。
### 3. 最新訊息替換
假設最新合格訊息最初給 A 分支權重 `55`，給 B 分支 `45`。一個權重 `20` 的驗證者後來傳送支援 B 後代的更新合格訊息。最新訊息記賬會從 A 移除其舊支援，再加到 B：
`A: 55 - 20 = 35; B: 45 + 20 = 65`
該權重只計算一次，不會同時留在兩條分支，所以選中路徑可能改變。這並不允許不一致投票：如果有效的 attester-slashing 證據識別出雙籤，當前 Ethereum store 會跟蹤該驗證者，並從常規 attestation 評分中排除其權重。
### 4. 檢查點篩選與提議者加權
假設節點觀察到與已最終化檢查點衝突的分支擁有原始最新訊息權重 `70`，而可行後代分支權重為 `30`。衝突分支在鏈頭選擇前便被排除；原始多數權重不能透過常規分叉選擇越過最終化檢查點約束。
再看當前時隙的兩個可行子節點，其 attestation 權重為 `35` 與 `50`。按所引 Ethereum 配置，及時提議者加權等於單個委員會權重的 `40%`，不是總權益的 40%。若委員會權重為 `100`，且加權適用於權重 35 的子節點，其比較分數成為 `35 + 40 = 75`，因此該步勝過 `50`。加權是臨時且分叉特定的；它既不是額外驗證者投票，也不是最終性。
## 風險與審查失誤
### 候選集合與證據
- 未驗證父節點、狀態轉換、證明、載荷狀態或所需資料，便比較分支權重。
- 把未知或樂觀執行、不可用資料或僅區塊頭檢視當成完整驗證狀態。
- 用區塊高度、時間戳、交易數、手續費或瀏覽器熱度替代規則指定權重。
- 累加顯示的難度，而不按正確目標復現逐塊證明與累計鏈工作量。
- 累計每個歷史投票，而不是按正確權重快照採用每個驗證者的最新合格訊息。
- 忽略訊息域、根、時隙、epoch、及時性、簽名、雙籤與罰沒證據。
- 比較協議檢查點、鎖定、證書或可用性篩選已判為不合格的原始分支。
- 把未來規範、其他網路引數或實現最佳化當成當前共識規則。
### 選擇與操作故障
- 把 Bitcoin 規則描述為原始“最長高度”，或把 Ethereum 規則說成簡單的三分之二鏈頭投票。
- 用全域性葉節點分數替代貪心子樹遞迴，或省略提議者加權、取整和根平局規則。
- 假定接收順序、時鐘或訊息檢視不同的節點必須立即報告同一鏈頭。
- 重組時未正確斷開並重放狀態、收據、日誌、索引與記憶體池條目。
- 讓客戶端實現在有效性、檢查點可行性、最新訊息、時序或平局規則上分歧。
- 漏掉平衡、扣留、雙籤、分割槽、日蝕、延遲投票和提議者重組條件。
- 把一個 RPC、瀏覽器、中繼、客戶端系列、雲或驗證者運營方當成獨立共識檢視。
### 最終性與應用錯配
- 沒有協議的獨立最終性證據，卻把選中鏈頭稱為已最終化、不可逆或安全。
- 沒有按價值制定策略，就基於瞬時鏈頭釋放存款、橋訊息或不可逆交易。
- 假定已最終化祖先保證每個更新鏈頭、載荷、預言機或應用結果的正確性與可用性。
- 對工作量、投票、檢查點和恢復模型不同的鏈使用固定確認數。
- 把緊急檢查點、弱主觀性錨點或社會恢復視為沒有信任邊界的常規分叉選擇輸入。
## 常見誤解
- **最長分支總會勝出。** 協議可能比較累計工作量、加權最新訊息、證書或其他分數；原始高度並非通用規則。
- **觀測到的最重分支自動有效。** 有效性和可用性會在權重選擇前篩選候選。
- **分叉選擇與最終性是同一條規則。** 分叉選擇決定當前延伸的鏈頭；最終性用額外安全條件保護祖先。
- **每個驗證者的投票會永遠留在總數中。** 在最新訊息規則中，更新合格訊息會替換該驗證者先前的分叉支援。
- **一個瀏覽器就能證明規範鏈。** 它只報告某套基礎設施的檢視；仍需獨立驗證與核對。
## 相關主題
- [鏈重組](/zh-tw/crypto/chain-reorg/)
- [共識機制](/zh-tw/crypto/consensus-mechanism/)
- [難度調整](/zh-tw/crypto/difficulty-adjustment/)
- [最終性](/zh-tw/crypto/finality/)
- [弱主觀性](/zh-tw/crypto/weak-subjectivity/)
## 資料來源
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST（訪問日期：2026-08-19）
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org（訪問日期：2026-08-19）
- [Bitcoin Core: validation.h](https://github.com/bitcoin/bitcoin/blob/master/src/validation.h) - Bitcoin Core（訪問日期：2026-08-19）
- [Bitcoin Core: blockstorage.cpp](https://github.com/bitcoin/bitcoin/blob/master/src/node/blockstorage.cpp) - Bitcoin Core（訪問日期：2026-08-19）
- [Bitcoin Core RPC: getblockchaininfo](https://developer.bitcoin.org/reference/rpc/getblockchaininfo.html) - Bitcoin Project（訪問日期：2026-08-19）
- [Ethereum Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org（訪問日期：2026-08-19）
- [Ethereum Consensus Specifications: Fork Choice](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/fork-choice.md) - Ethereum Foundation（訪問日期：2026-08-19）
- [CometBFT Byzantine Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT（訪問日期：2026-08-19）
Source: https://wiki.fcontext.com/zh-tw/crypto/fork-choice-rule/index.mdx