---
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>

## 直接回答

共識機制是這樣一套協定：在訊息延遲、並行以及模型所涵蓋的故障存在時，使無故障副本對有序日誌或狀態形成彼此相容的決定。在區塊鏈中，完整機制可能包括提議者選擇、區塊和狀態轉換驗證、投票或證明、分叉選擇、提交或最終性、復原及成員規則。它不只是「多台電腦儲存同一個檔案」，也不等同於一個投票門檻、挖礦、質押或激勵計畫。

必須分別說明三項性質。`safety`（安全性）防止無故障參與者作出不相容決定；`liveness`（活性）表示在指定條件下，有效工作最終可以繼續推進；`validity`（有效性）限制可以決定什麼。協定可能在維持安全性的同時停止，也可能依據允許之後重組的假設繼續運作。「共識」一詞本身並未說明哪項保證在何時成立，或用戶端應信任什麼證據。

交易有效性與規範歷史選擇並不相同。完整節點會獨立拒絕違反目前規則的狀態轉換。如果兩筆各自有效的交易花費同一輸入，排序或分叉選擇將決定哪一筆可進入規範歷史；多數資源不能讓兩筆同時有效。同樣，對位元組達成一致也不能證明預言機事實、跨鏈橋聲明、應用程式計算或法律主張為真。

工作量證明和權益證明通常提供抗女巫攻擊、提議影響力或可追責的投票權重，但名稱本身並未定義完整共識協定。Bitcoin 把工作量證明與驗證、累計工作量鏈選擇結合；Ethereum 的 Gasper 結合權益加權證明、LMD-GHOST 分叉選擇與 Casper FFG 檢查點最終性；CometBFT 這類分輪 BFT 協定則使用不同的訊息、門檻、時間假設和最終性。它們的百分比不能互相替換。

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

## 分析方法

1. **明確決定及範圍。** 說明副本決定的是單一值、有序交易日誌、每個高度的區塊、檢查點還是應用程式狀態；確定鏈、網路、層、協定版本和可信起點。
2. **定義參與者與影響力。** 區分提議者、投票者、完整驗證節點、輕用戶端和觀察者。記錄身分如何加入與退出，影響力取決於算力、權益、等權成員還是其他權重，以及如何阻止廉價複製身分。
3. **拆分協定階段。** 記錄交易與狀態有效性、提議建構、傳播、投票或證明、分叉選擇、提交、最終性和復原。有效區塊可能在分叉選擇中落敗，規範鏈頭也未必已經最終確定。
4. **說明系統模型。** 定義驗證通道、同步或部分同步、延遲和逾時假設、崩潰與拜占庭故障、矛盾投票、遺漏、自適應腐化、金鑰洩露、網路分割，以及最大故障數量或權重 `f`。
5. **追蹤一次決定。** 從提議到決定追蹤訊息域、高度、輪次、父區塊、鎖、憑證和本機狀態。說明訊息遲到、提議者矛盾提議、輪次逾時或出現兩個有效分支時會發生什麼。
6. **分別驗證安全性與活性。** 使用準確的參與者集合和權重快照推導法定人數交集、鏈成長或其他證明條件；再測試是否仍有足夠的誠實連線與參與來推進，不能從安全門檻推斷活性。
7. **把證明映射到部署。** 檢查用戶端版本、參數變更、成員與權益集中度、金鑰託管、對等節點多樣性、建構者或排序器角色、檢查點、弱主觀性規則、重組處理及應用程式自身的確認政策。

FLP 並不是說已部署的共識不可實現。它說明，在完全非同步的訊息傳遞模型中，即使只有一個崩潰故障，確定性共識協定也存在某個允許的執行無法終止。實際協定透過加入同步或部分同步假設、隨機選擇、故障偵測器、經濟假設或較弱的終止承諾來取得有用保證。這些附加條件必須明確寫出，不能藏在協定標籤後面。

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

## 計算範例

### 1. 有效性不等於規範排序

未花費輸出 `U` 價值 1 BTC。交易 `T_B` 把它付給 Bob，交易 `T_C` 把同一輸出付給 Carol。相對於同一父狀態，兩筆交易都可能具有正確的簽章和格式，但有效歷史不能把 `U` 消耗兩次。

如果兩個競爭的有效區塊各自包含一筆交易，驗證會在本機保留兩個候選分支，而分叉選擇會選出規範分支。一旦 `T_B` 進入選定歷史，`T_C` 就與所得狀態衝突。共識選擇了順序；它沒有把錯誤簽章變成正確簽章，也沒有判斷哪位收款人在道德上有權得到付款。

### 2. 比較累計工作量，而非節點數量

假設兩個有效的 Bitcoin 式分支在同一任意工作量單位下分別具有累計工作量 `W_A=240` 和 `W_B=235`。驗證節點依據累計工作量規則選擇 A，即使它先從更多對等節點聽到 B。對等節點數量不是共識權重。

如果 B 隨後增加 10 個工作量單位而 A 沒有增加，兩者變成 `W_B=245` 對 `W_A=240`，節點驗證分支後可能重組至 B。這個簡化算術說明工作量證明確認為何是機率性的：替換更深歷史的成本逐漸提高，而不是到達固定區塊數後在邏輯上不可逆。

### 3. 加權 BFT 法定人數與活性停頓

設驗證者總權重為 `100`，一個 CometBFT 式提交要求同一高度、同一輪次中對同一區塊獲得 `>2/3` 的預提交。整數權重 `67` 可以通過。任意兩個 67 權重法定人數至少相交 `34`，因為 67 + 67 - 100 = 34。如果拜占庭權重低於三分之一，交集中就包含誠實權重，而誠實方依協定不能為衝突提交簽章。

同一門檻也揭示活性邊界。如果 34 權重離線，只剩 `66`，即使線上驗證者全部誠實也無法形成提交。協定可以在停止時維持安全性；治理投票或營運者數量不能替代缺失的共識權重。

### 4. 分叉選擇與檢查點最終性不同

在簡化的 Ethereum Gasper 軌跡中，設檢查點為 `C_0`、`C_1` 及其直接子檢查點 `C_2`。代表活躍有效餘額 `67/100` 的投票可建立從 `C_0` 到 `C_1` 的超多數連結，使 `C_1` 合理化。之後從 `C_1` 到 `C_2` 的合格連結可依據相應 FFG 規則最終確定較早的檢查點。

在檢查點之間，LMD-GHOST 使用驗證者最新證明，從合理化檢查點的可行後代中選擇鏈頭；最終檢查點限制則過濾衝突分支。因此，鏈頭選擇、合理化和最終確定是相關但不同的狀態轉換；「67% 為這個區塊投票」不足以完整描述其中任何一個。

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

## 風險與審查失敗

### 模型與保證

- 只說「網路達成共識」，卻不定義決定、安全性、活性、有效性和終止條件。
- 把工作量證明、權益證明、挖礦、質押或一個投票百分比當作完整協定規格。
- 把 `51%`、`2/3` 或 `n=3f+1` 普遍套用於不同的故障、時間、權重和最終性模型。
- 混淆崩潰故障、拜占庭行為、金鑰竊取、通道故障、相關軟體故障與治理俘獲。
- 把 FLP 說成對實用共識的禁令，而不是關於確定性、完全非同步且保證終止的結果。
- 只數節點或驗證者金鑰，不測量獨立營運者、投票權重、用戶端、雲端和託管關係。
- 假設規範、safe、合理化、提交和最終確定是可以互換的狀態。
- 從副本一致推斷外部事實正確、排序公平、隱私、去中心化或資產價值。

### 協定與實作

- 接受未綁定鏈、協定版本、高度、輪次、父區塊、承載內容、傳送者和成員時期的區塊或投票。
- 讓不同實作對狀態轉換、序列化、簽章域、分叉選擇、平手規則或取整產生分歧。
- 驗證法定人數憑證時不重建其合格權重快照和重複簽署者處理。
- 跨分叉、網路、輪次、升級或驗證者集合變更重放投票、工作量或憑證。
- 在逾時、視圖切換或復原時錯誤更新鎖、合理化檢查點或最高憑證。
- 把本機觀察到的鏈頭或單一 RPC 提供者的標籤當作獨立的網路最終性證據。
- 只測試正常路徑，不測試延遲、分割、矛盾投票、無效提議、重組和復原。

### 部署與應用

- 把算力、權益、用戶端、中繼、建構者、排序器、雲端或簽章基礎設施集中在名義上分離的身分背後。
- 把逾時或出塊間隔設得短於實際傳播與驗證時間，損害活性或增加分叉。
- 在達到所需來源鏈和應用程式最終性前記入存款、鑄造跨鏈資產或執行不可逆操作。
- 假設罰沒、獎勵或代幣價格總能形成充足且可變現的安全預算。
- 使用社會復原或治理介入，卻不說明誰負責協調、用戶端安裝哪條鏈以及原有哪項保證已改變。

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

## 常見誤解

- **共識與驗證相同。** 驗證拒絕違反規則的資料；共識在多個可能各自局部有效的候選中選擇相容決定。
- **節點越多就一定越安全。** 影響力、獨立性、拓撲、軟體多樣性和故障模型比原始程序數量更重要。
- **51% 攻擊者可以偽造任何人的簽章。** 在特定協定下，多數資源可能實施審查或重組，但不會因此洩露私鑰或授權無效花費。
- **三分之二總是意味著最終性。** 具體不等式、訊息、輪次、權重快照、鎖規則和最終性條件均由協定決定。
- **快速出塊證明共識更強。** 較短間隔可能增加傳播競爭和資源壓力；必須結合安全性、活性及最終性假設評估延遲。

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

## 相關主題

- [拜占庭容錯](/zh-tw/crypto/byzantine-fault-tolerance/)
- [拜占庭將軍問題](/zh-tw/crypto/byzantine-generals-problem/)
- [最終性](/zh-tw/crypto/finality/)
- [分叉選擇規則](/zh-tw/crypto/fork-choice-rule/)
- [權益證明](/zh-tw/crypto/proof-of-stake/)

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

## 來源

- [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）
- [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）
- [Impossibility of Distributed Consensus with One Faulty Process](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf) - Journal of the ACM（存取日期：2026-08-19）
- [Consensus in the Presence of Partial Synchrony](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) - Journal of the ACM（存取日期：2026-08-19）
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT（存取日期：2026-08-19）
- [HotStuff: BFT Consensus in the Lens of Blockchain](https://arxiv.org/abs/1803.05069) - arXiv（存取日期：2026-08-19）

Source: https://wiki.fcontext.com/zh-tw/crypto/consensus-mechanism/index.mdx