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

## 直接答案

拜占庭將軍問題追問：只能透過訊息通訊的無故障參與者，如何在部分參與者可任意行動、甚至向不同接收者傳送矛盾說法時作出一致決定。軍事故事是分散式系統「互動一致性」的類比，不是歷史事件，也不是某一種區塊鏈共識演算法。

在「司令—副官」表述中，`IC1` 要求所有忠誠副官執行同一命令，`IC2` 要求司令忠誠時，每名忠誠副官執行司令的命令。只達成一致還不夠：永遠選擇撤退的規則雖能一致，卻會違背忠誠司令發出的有效進攻命令。

在論文的「口頭訊息」模型中，若叛徒最多為 `m`，僅當 `n>3m` 時問題才可解；參與者數量為整數時等價於 `n>=3m+1`。此模型假定忠誠者發出的訊息能被正確送達、接收者知道傳送者是誰，且能發現預期訊息缺失。「口頭」表示未經驗證的內容可被偽造成其他參與者的轉述，並不等於信使可永遠消失且無人察覺。

論文的「簽署訊息」模型加入不可偽造、任何人可驗證的簽章，因而改變容錯結論。它不會使簽署內容變真，不會保證送達、解決完全非同步終止、保護被盜金鑰，或證明現代協定安全。拜占庭將軍問題、兩軍問題或協調攻擊問題、FLP、BFT 協定、工作量證明和權益證明彼此相關，卻是不同模型或架構。

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

## 分析方法

1. **定義一致任務。** 說明參與者、輸入、輸出，以及精確的一致性、有效性和終止屬性。對司令模型，應明確寫出 `IC1` 與 `IC2`，而不是只說「達成共識」。
2. **定義身分與通道。** 說明點對點訊息是否經過驗證、可靠送達、有序、防重放且可歸責；訊息缺失能否發現；廣播是基本原語還是靠逐一傳送實作。
3. **定義時序。** 區分延遲有上界的同步、未知穩定時間後的部分同步與完全非同步。不能替一個模型加入消失的信使，卻沿用為另一模型證明的定理。
4. **定義故障預算。** 記錄參與者總數 `n`、拜占庭參與者上限 `m`、腐化是靜態或自適應，以及故障是否包含遺漏、矛盾訊息、串謀、金鑰竊取或通道故障。
5. **遞迴追蹤資訊。** 對每名忠誠參與者列出直接說法和轉述說法，包括傳送者路徑、缺失訊息預設值與確定性平手規則；比較兩名忠誠者從本地視圖可區分哪些執行。
6. **同時核對定理與演算法。** 把下界與充分性對應到精確的口頭或簽署模型、連通性和故障預算。一個門檻不等式既不是實作，也不是證明。
7. **映射到實際部署。** 核驗部署協定的 `OM(m)`、`SM(m)` 或其他機制，以及訊息網域、輪次、鎖定、憑證、成員變更、逾時、客戶端行為、最終性規則與應用確認政策。

關鍵證明技術是不可區分性。忠誠參與者只能看到自己的本地訊息；若兩次執行在它看來完全相同，卻因有效性要求不同決定，任何確定性規則都無法始終正確選擇。協定藉由增加足夠多的獨立參與者、驗證證據、時序假設、隨機性或其他結構，使必要的執行變得可區分，或改變所承諾的保證。

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

## 計算範例

### 1. 三名口頭訊息將軍為何不能容忍一名叛徒

設 `n=3`、`m=1`。必要條件 `n>3m` 變為 `3>3`，不成立。假設司令 A 告訴副官 B `ATTACK`，卻告訴副官 C `RETREAT`。B 無法判斷是 A 作為叛徒傳送矛盾命令，還是 C 作為叛徒謊報 A 的說法；C 面臨對稱的不確定性。

任何能在相應「忠誠 A」執行中保留忠誠司令命令的確定性選擇，都可能迫使 B 和 C 在「叛徒 A」執行中作出不同決定。轉送訊息不會創造第四個獨立來源，因此無法同時保證 `IC1` 與 `IC2`。

### 2. 四名口頭訊息將軍與一名叛徒

在 `OM(1)` 中，`n=4`、`m=1`。司令向三名副官傳送命令；每名副官把收到的值轉送給另外兩名；每名忠誠副官採用同一個多數規則與預設值。若司令忠誠並傳送 `v`，忠誠副官看到的值可為 `v`、`v` 和叛徒可能傳送的 `x`，所以選擇 `v`。

若司令是唯一叛徒，三名副官全都忠誠，並如實轉送各自收到的內容。因此三者重建出同一組「司令向各副官傳送的說法」，並採用相同確定性規則。他們未必找回司令的「真實意圖」，但能滿足一致性。

### 3. 口頭訊息的一般下界

當 `n=7`、`m=2` 時，`7>6` 成立，所以參與者數量符合前提；在其他假設也成立時，遞迴口頭訊息架構最多容忍兩名叛徒。對 `n=6`，`6>6` 不成立。對 `n=10`、`m=3`，`10>9` 成立。通過不等式只是必要條件，仍須正確實作輪次、轉送、多數、預設值和通道。

### 4. 簽章改變了什麼

在三名將軍的 `SM(1)` 範例中，叛徒司令為傳給 B 的 `ATTACK` 和傳給 C 的 `RETREAT` 分別簽署。忠誠副官轉送兩份簽署命令，所以雙方都得到同一集合 `{ATTACK, RETREAT}`，並採用同一個規定預設值，例如 `RETREAT`。司令傳送矛盾命令的行為可以歸責。

在此模型下，簽章防止忠誠參與者的命令被偽造或無痕修改。它不會揭示叛徒兩份命令中的哪一份代表「真實意圖」，不會保證及時送達，也不能阻止控制合法私鑰的攻擊者同時簽署兩份內容。

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

## 風險與審查失誤

### 問題與模型

- 只複述寓言，不給出精確的一致性、有效性和終止條件。
- 把拜占庭將軍問題當作歷史圍城、單一演算法或區塊鏈的同義詞。
- 與兩軍問題混淆；後者關注不可靠通道上的共同知識。
- 加入無法發現的永久訊息遺失，卻引用口頭訊息假設排除此情形的定理。
- 把 `n>3m` 套到所有驗證、非同步、加權、無許可或按資源競爭的協定。
- 把崩潰、遺漏、矛盾訊息、任意計算、通道故障與金鑰洩漏視為同一故障。
- 假設參與者數量等於獨立實體、質押、算力或委員會權重。
- 在有效性條件中遺漏忠誠司令與叛徒司令的差別。

### 演算法與實作

- 只看最終多數，不遞迴追蹤傳送者路徑及每名忠誠參與者的本地視圖。
- 各實作採用不同的缺失訊息預設值、平手規則、成員快照或訊息順序。
- 接受未綁定協定、鏈、任務、高度、輪次、值、傳送者與成員時期的訊息。
- 跨執行、輪次、分叉、網路或成員變更重放、拼接訊息。
- 假設簽章能證明真實、新鮮、授權語境、送達、可用或金鑰被誠實保管。
- 引用 `OM(m)` 或 `SM(m)`，卻未實作所需輪次、轉送、驗證與連通性。
- 只測試一種叛徒位置，不測試司令、副官、串謀、遺漏和矛盾訊息情形。

### 部署與解釋

- 宣稱某共識協定「解決了拜占庭問題」，卻不說明精確的安全、活性與網路假設。
- 把對位元組達成一致當作應用執行或鏈外事實正確的證明。
- 忽略共同客戶端、營運方、雲端服務、金鑰系統或治理造成的相關故障。
- 在達到所需最終性條件前記入入金、鑄造跨鏈資產或結算不可逆操作。
- 從容錯標籤推斷去中心化、資產安全、法律事實或代幣價值。

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

## 常見誤區

- **這個問題就是 51% 攻擊。** 它研究明確一致模型下的任意與矛盾行為；資源多數攻擊屬於特定協定。
- **多數總能解決問題。** 在經典口頭訊息模型中，容忍 `m` 名叛徒要求參與者總數超過其三倍，不只是誠實者比叛徒多一名。
- **數位簽章證明訊息是真的。** 簽章可驗證金鑰並保護完整性；惡意或已洩漏的金鑰仍能簽署虛假、矛盾內容。
- **原始口頭訊息結果已涵蓋不可靠送達。** 該結果包含明確的送達、傳送者身分和可發現遺漏假設；其他時序與通道模型需要其他結論。
- **達成一致表示系統獲知現實真相。** 除非另有驗證規則，忠誠節點也可能對無效應用輸出或錯誤外部資料達成一致。

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

## 相關主題

- [拜占庭容錯](/zh-tw/crypto/byzantine-fault-tolerance/)
- [共識機制](/zh-tw/crypto/consensus-mechanism/)
- [最終性](/zh-tw/crypto/finality/)

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

## 資料來源

- [The Byzantine Generals Problem](https://lamport.azurewebsites.net/pubs/byz.pdf) - ACM Transactions on Programming Languages and Systems（存取日期：2026-08-19）
- [Reaching Agreement in the Presence of Faults](https://lamport.azurewebsites.net/pubs/reaching.pdf) - Journal of the ACM（存取日期：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）
- [Practical Byzantine Fault Tolerance](https://pmg.csail.mit.edu/papers/osdi99.pdf) - USENIX OSDI（存取日期：2026-08-19）
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT（存取日期：2026-08-19）
- [HotStuff: BFT Consensus with Linearity and Responsiveness](https://arxiv.org/abs/1803.05069) - arXiv（存取日期：2026-08-19）
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST（存取日期：2026-08-19）

Source: https://wiki.fcontext.com/zh-tw/crypto/byzantine-generals-problem/index.mdx
