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

# 拜占庭容錯：安全性、活性與法定人數

> 僅供協定分析教育參考。BFT 標籤或法定人數門檻本身無法證明安全性、活性、正確執行、去中心化、最終性或資產安全。

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

## 直接答案

拜占庭容錯（BFT）是某個明確分散式協定在明確故障模型與網路模型下的屬性：即使部分參與者當機、扣留訊息、對不同對象傳送矛盾訊息，或以其他方式任意作惡，協定仍滿足其聲明的保證。BFT 不是單一演算法，也不表示每次網路分割期間所有服務都保持可用。

必須區分各種保證。`safety`（安全性）表示誠實參與者不會決定互相衝突的值；`liveness`（活性）表示合格輸入最終能促成決定；`validity`（有效性）限制可以決定哪些值。通訊或誠實投票權不足時，協定可以停止以保全安全性。共識正確也不等於應用程式碼、交易有效性規則、跨鏈橋、金鑰或治理正確。

對一類常見、具身分驗證且部分同步的 BFT 協定，`n=3f+1` 個副本最多容忍 `f` 個拜占庭副本，提交憑證使用 `q=2f+1` 票。熟悉的「故障少於三分之一」與「法定人數超過三分之二」來自此模型。同步協定、隨機化非同步協定、崩潰容錯協定、工作量證明鏈及其他 BFT 架構可能採用不同假設與門檻。

在按質押加權的系統中，門檻指協定定義的投票權，不一定是驗證者數量、地址數量、人數或獨立營運方數量。套用比例前，必須說明確切協定版本、權重快照、決定類型、網路假設、法定人數比較符（`>` 或 `>=`）與故障行為。

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

## 運作方式

1. **定義決定對象。** 確認節點是在排序交易、提交區塊、最終確定檢查點、選舉領導者、接受狀態轉換或選擇分叉。這些不是可互換的決定。
2. **說明系統與對手模型。** 記錄成員資格、身分驗證、權限變更、投票權重、自適應腐化、金鑰洩漏、矛盾投票、崩潰故障、訊息遺失、審查、阻斷服務，以及故障是否可能相關。
3. **說明網路模型。** 區分同步、部分同步與非同步。對部分同步模型，要指出哪些保證只在未知的全域穩定時間之後成立，以及逾時如何調整。
4. **推導法定人數規則。** 使用協定的精確門檻、鎖定與投票規則。在經典 `n=3f+1` 情境中，兩個 `2f+1` 法定人數至少有 `f+1` 個副本重疊；拜占庭副本最多為 `f` 時，交集必含誠實副本。
5. **追蹤每個階段與憑證。** 核驗提議、投票、鎖定、視圖或輪次變更、提交、分叉選擇與復原規則。只有節點驗證高度、輪次、值、父級、網域、成員時期及前序憑證時，簽署的超級多數才有意義。
6. **分開驗證安全性與活性。** 先證明在所有相關時刻排除了哪些衝突決定，再測試協定的通訊與誠實參與假設恢復後是否重新推進。逾時是排程工具，不能證明沉默節點有惡意。
7. **核驗實作與營運。** 按照證明模型檢查客戶端多樣性、金鑰保管、簽章器容錯移轉、防重放、狀態同步、證據處理、成員變更、監控、應用確認政策及事故復原。

FLP 結果指出：在完全非同步模型中，只要可能有一個程序崩潰，確定性共識協定就不能保證終止。它沒有說安全性不可能，也沒有說分散式共識永遠無法運作。部分同步、隨機化、故障偵測器、經濟假設或較弱保證，分別藉由改變特定不可能性條件來取得進展。

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

## 計算範例

### 1. 四個等權副本

設 `n=4`、`f=1`、`q=3`。任意兩個三票集合至少重疊 `3+3-4=2` 個副本。拜占庭副本最多一個，因此交集中至少有一個誠實副本。如果協定要求誠實節點不能在相關高度與輪次歷史中為衝突值投票，就不可能同時形成兩份衝突的提交憑證。

若兩個副本離線，只剩 `2` 票，無法形成 `q=3` 憑證。這是活性故障，不會自動成為安全性故障：安全設計的協定會等待，而不是在本地降低門檻。

### 2. 七個等權副本

設 `n=7`、`f=2`、`q=5`。兩個法定人數至少重疊 `5+5-7=3=f+1` 個副本。由於拜占庭副本最多 `2` 個，交集必含誠實副本。兩個拜占庭副本無法單獨形成五票憑證，但三個離線或扣票的副本會使可用票數只剩 `4`，足以阻止推進。

門檻算術是必要條件，卻不是充分條件。若誠實實作接受錯誤高度的投票、重複使用成員集合、違反鎖定規則，或透過已洩漏金鑰簽署，證明假設就與部署系統不再相符。

### 3. 加權投票權

假設驗證者權重為 `40`、`30`、`20`、`10`，合計 `100`；憑證要求嚴格超過 `2/3`，在此實作為至少 `67`。`40+30=70` 的聯盟可以形成憑證；`30+20+10=60` 不行，儘管它包含四名驗證者中的三名。若權重為 `40` 的驗證者離線，只剩 `60`，最終性便會停頓。

任意兩個至少為 `67` 權重的集合，至少重疊 `67+67-100=34`。所以出現衝突憑證表示至少 `34` 權重同時參與兩組投票，或某項其他協定假設失效。這說明在部分協定中，只略高於三分之一的矛盾投票就可能破壞安全；「攻擊必須有三分之二」不是普遍最低門檻。

### 4. 部分同步與逾時

假設四個副本依序採用 `1 s`、`2 s`、`4 s`、`8 s` 的輪次逾時。在未知穩定時間之前，訊息可能每次都遲於目前逾時抵達，輪次因而不斷變更而不作決定。網路穩定後，若延遲低於 `3 s`，則 `4 s` 或更後面的輪次可以讓誠實提議者和法定人數有足夠時間交換訊息並推進，但仍須符合協定的其他假設。

這些數字只說明最終推進，並非通用逾時公式。計時器過短會導致無謂的視圖變更，過長則會拉長復原延遲。安全性不能依賴在穩定前猜中正確的延遲上限。

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

## 風險與審查失誤

### 模型與證明

- 只說「BFT」，卻不說明協定、版本、決定對象、故障模型、網路模型、成員規則和門檻。
- 把 `n=3f+1` 或三分之一比例套到所有分散式帳本，包括證明採用不同假設的協定。
- 把安全性、活性、有效性、可用性、一致性、最終性、分叉選擇與交易正確性當作同義詞。
- 宣稱 FLP 證明共識不可能，卻省略確定性、完全非同步及保證終止這些條件。
- 協定按質押、委託權重、委員會、時期或其他資源計票時，仍按節點或地址數計數。
- 含糊取整「三分之二」，或忽略實作採用 `>`、`>=`、整數權重還是某個分母快照。
- 只檢查法定人數大小，不檢查交集、鎖定、憑證、視圖變更、重新配置與狀態轉移。
- 未經證明就假設模型涵蓋自適應腐化、金鑰竊取、相關故障、阻斷服務或長程歷史。

### 實作與營運

- 接受未綁定鏈、網域、高度、輪次、值、父級、成員時期及訊息類型的簽章。
- 跨輪次、高度、分叉、網路、升級或驗證者集合變更重放舊投票或憑證。
- 允許雙簽、鎖定回退、不安全的簽章器容錯移轉，或兩個活動副本共用一個驗證者身分。
- 把逾時到期當作惡意證明，並僅憑本地時鐘作出影響安全性的決定。
- 忽略共同客戶端、雲端服務、地區、網路、硬體、金鑰管理或營運方造成的相關故障。
- 誤以為罰沒能阻止故障、恢復活性、撤銷已最終執行的應用操作，或賠償所有受影響使用者。
- 只測試正常運作，不測試分割、訊息延遲與重排、矛盾投票、提議者故障、重啟和成員變更。

### 應用與治理

- 未進行確定性執行與狀態轉換驗證，就把共識提交值當成有效應用狀態。
- 在達到應用所需的準確最終性條件前記入入金、鑄造跨鏈資產或結算交易。
- 假設金鑰洩漏、軟體故障或治理介入後的社會不可逆性與協定最終性完全相同。
- 因區塊仍為其他使用者最終確定，就忽略審查和交易納入延遲。
- 從 BFT 標籤或宣傳的驗證者數量推斷去中心化、資產安全、代幣價值或法律可執行性。

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

## 常見誤區

- **BFT 表示網路永不停機。** 許多 BFT 協定在故障過多或網路分割時會主動犧牲活性以保全安全性。
- **誠實參與者超過 51% 總是足夠。** 門檻取決於協定；經典部分同步 BFT 通常需要相關投票權超過三分之二才能推進。
- **攻擊者總要有三分之二才能破壞安全。** 三分之二可以獨自形成憑證，但在常見法定人數設計中，兩份衝突的超級多數憑證可能只暴露略高於三分之一的矛盾投票。
- **增加驗證者地址必然提高容錯。** 共同所有權、委託權重、客戶端、基礎設施、金鑰及故障域決定獨立容錯能力。
- **罰沒就是 BFT 證明。** 罰沒是部分 PoS 系統的經濟應對；安全性來自協定規則與假設，懲罰也不能撤銷外部後果。

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

## 相關主題

- [拜占庭將軍問題](/zh-tw/crypto/byzantine-generals-problem/)
- [共識機制](/zh-tw/crypto/consensus-mechanism/)
- [最終性](/zh-tw/crypto/finality/)
- [權益證明](/zh-tw/crypto/proof-of-stake/)
- [驗證者](/zh-tw/crypto/validator/)

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

## 資料來源

- [The Byzantine Generals Problem](https://lamport.azurewebsites.net/pubs/byz.pdf) - ACM Transactions on Programming Languages and Systems（存取日期：2026-08-18）
- [Impossibility of Distributed Consensus with One Faulty Process](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf) - Journal of the ACM（存取日期：2026-08-18）
- [Consensus in the Presence of Partial Synchrony](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) - Journal of the ACM（存取日期：2026-08-18）
- [Practical Byzantine Fault Tolerance](https://pmg.csail.mit.edu/papers/osdi99.pdf) - USENIX OSDI（存取日期：2026-08-18）
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT（存取日期：2026-08-18）
- [HotStuff: BFT Consensus with Linearity and Responsiveness](https://arxiv.org/abs/1803.05069) - arXiv（存取日期：2026-08-18）
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org（存取日期：2026-08-18）
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST（存取日期：2026-08-18）

Source: https://wiki.fcontext.com/zh-tw/crypto/byzantine-fault-tolerance/index.mdx