題目與使用情境
普通複製狀態機通常假設節點會當機、丟包或重啟，但不會主動偽造不同內容。現在控制面管理憑證、權限和路由，一台被入侵的節點可能對不同節點傳送不一致日誌，甚至偽造身分。候選人需要從威脅模型出發，說明 Raft、認證和拜占庭容錯分別解決什麼問題。
面試官考察什麼
- 是否能區分崩潰故障、網路分區、惡意節點和身分金鑰洩露。
- 是否理解 Raft 的安全前提、法定人數交集和拜占庭協議的額外通訊與節點成本。
- 能否把簽章、成員資格、稽核、金鑰輪換和恢復流程納入系統邊界。
- 是否會避免把「加密」或「多數票」直接當成拜占庭安全證明。
作答前的釐清問題
先確認攻擊者能控制多少節點、能否偽造身分、節點之間是否有可信金鑰，以及系統更重視一致性還是可用性。再確認控制面是否管理高價值狀態、是否允許人工審批、成員變更頻率和跨區域網路延遲。若節點都在同一受控機房且金鑰由硬體保護，普通崩潰容錯可能已經足夠；若存在供應鏈或營運商不受信任，結論會不同。
30 秒回答框架
我會先寫出故障模型和要保護的不變量。Raft 假設非惡意故障，適合受控叢集中的崩潰容錯；認證只證明訊息來自某個金鑰，不能保證持鑰節點誠實。若攻擊者能讓少量節點傳送矛盾值，就需要能在該故障上限內保持安全的拜占庭協議，通常意味著更多副本、簽章或認證廣播、逾時和稽核成本。若風險可由隔離、金鑰保護和人工審批降低，我會保留 Raft 並明確剩餘風險。
分步驟深入解答
- 寫清故障模型。 將節點分成崩潰、遺漏、網路分區和主動惡意四類，並註明是否可能串謀、偽造身分、延遲訊息或修改磁碟。沒有模型就無法比較協議。
- 定義安全不變量。 例如任何誠實副本不會提交兩個衝突配置、撤銷操作不能被回滾、金鑰發佈必須可追溯。可用性、最終性和恢復時間分別設定目標。
- 檢查普通共識前提。 Raft 透過領導者、日誌匹配和多數派提交抵抗崩潰故障；它不阻止一個持有合法身分的惡意節點向不同對等方傳送不同內容。TLS 能保護傳輸，不會修復惡意端點。
- 評估拜占庭協議成本。 在經典未認證口信模型中，容忍 f 個拜占庭節點需要更高的副本規模；帶認證的協議、門檻簽章和可信硬體可以改變工程取捨，但不能跳過故障上限和成員資格假設。
- 設計邊界控制。 即使採用拜占庭協議，也要限制誰能加入、輪換和撤銷金鑰，隔離控制面與資料面，記錄證據並準備安全恢復。協議只能約束參與者，不能阻止管理員直接改資料庫。
- 做威脅驅動的驗證。 注入分叉訊息、偽造簽章、重放舊配置、延遲法定人數回應和節點恢復，檢查安全不變量、稽核證據和恢復路徑。用故障演練證明選擇的協議滿足實際上限。
高品質示範回答
我不會因為「跨區域」就直接選擇拜占庭容錯。先確認攻擊者模型：如果節點只會當機或網路異常，Raft 的領導者、日誌匹配和多數派提交足夠；如果持有合法金鑰的節點能對不同副本傳送矛盾配置，認證傳輸和多數票都不能證明它誠實。
對於高價值控制面，我會定義 f、節點加入規則、不可衝突提交和撤銷不可回滾等不變量，再選擇能在該 f 下保持安全的認證拜占庭協議。副本數量、簽章驗證、延遲和金鑰維運成本必須和風險比較。若隔離、硬體金鑰、雙人審批和唯讀恢復已把惡意節點風險降到可接受範圍，可以繼續使用 Raft，並記錄它不覆蓋的威脅。依據包括 Lamport 的拜占庭將軍問題、Raft 論文和其形式化規格說明。
常見錯誤
- 把網路分區或當機直接稱為拜占庭故障，沒有說明節點是否會主動說謊。
- 認為 TLS、數位簽章或多數票單獨就能阻止惡意合法節點。
- 只報一個副本數量，忽略認證模型、串謀上限、成員資格和金鑰保護。
- 只討論協議訊息，不考慮管理員、資料庫、備份和恢復路徑的旁路修改。
- 用「更安全」取代明確不變量、攻擊演練和可接受風險門檻。
追問及應對
三節點叢集能容忍一個拜占庭節點嗎？
不能脫離協議和認證模型給出肯定答案。經典未認證口信模型有更高的副本下限；認證協議、可信硬體和部分同步假設會改變條件。回答應先聲明模型，再說明 f、法定人數和安全證明。
為什麼多數票不能自動解決惡意節點？
惡意節點可以向不同觀察者投遞不同值，甚至偽造多個邏輯角色。只有在訊息認證、視圖變更、證據傳播和法定人數交集都滿足協議假設時，多數才有意義。
什麼時候應堅持使用 Raft？
當節點和金鑰處於受控邊界、主要故障是崩潰或網路異常、業務能接受人工恢復時，Raft 更簡單且可驗證。應補上成員審批、金鑰輪換、稽核和故障演練，並明確惡意節點不在其保證範圍內。