私有區塊鏈需要共識協議嗎？
我的理解是，在私有區塊鏈中，參與節點驗證並同意該塊是有效的，然後才將其添加到區塊鏈中。在這種情況下，是否需要共識協議（如 RAFT、PAXOS 等）？我在這裡錯過了什麼嗎？
TL;DR是的，在分佈式系統中總是需要共識協議，在這些系統中，同一數據可能有多個寫入者。當多個參與者可能同時更新其本地狀態時，可能會導致兩個不一致的版本無法合併為全域一致的狀態。
在區塊鏈的上下文中，發佈區塊類似於讀取和寫入餘額，我們希望強制執行每個賬戶的約束
balance >= 0以防止雙重支出。
想像一下，在區塊 4 的賬本狀態下，我有 10 個硬幣。然後在 A 分行，我給 Alice 發了 8 個幣，但在 BI 分行給了 Bob 8 個幣。如果我們試圖將這兩個更新調和為一個狀態，那麼要麼我的餘額為 -6 個硬幣，違反了
balance >= 0約束，要麼必須非法創建硬幣。共識算法旨在確保每個節點具有與其他節點一致的有效狀態。正如CAP 定理所解釋的，在網路分區期間，共識算法必須使服務不可用（只讀）或允許兩個分區可能變得不一致。這意味著在設計或選擇共識算法時，必須在數據的一致性（例如防止雙花）或可用性（例如進行交易）之間做出決定。
Nakamoto 共識優先考慮可用性，以便在網路分區期間它將繼續處理事務，並且在網路分區之後，全域狀態將最終保持一致。它量化了每個狀態的總工作量證明，以決定哪個狀態是正確的狀態。如果我們的節點之前只觀察了分支 A，但隨後收到了來自分支 B 的塊，它將計算在每個狀態下完成的工作量，以決定接受哪個分支。這意味著在網路分區期間，狀態仍然可以更新，但代價是它變得不一致。解決網路分區後，通過恢復一些更新並應用導致具有更多工作證明的狀態的更新來解決不一致的狀態。
其他共識協議（例如 Tendermint 中使用的權益證明變體）將優先考慮一致性，這意味著在網路分區期間嘗試更新狀態可能會失敗，從而導致服務不可用。為確保狀態更新（即創建區塊）的一致性，控制至少 2/3 權益的節點必須在超時期限內同意提議的區塊。如果太少的股份同意提議的更新，它將失敗並恢復，並且將開始新的提議。這在某種程度上類似於2 階段送出，但不同之處在於它可以容忍控制高達 1/3 權益的節點的故障。
即使在所有機器都正常執行的可信環境中，由於網路延遲也可能出現不一致的狀態，因為非同步消息傳遞與短暫的網路分區相當。在我們需要維護更複雜的約束（例如確保一致的智能合約執行）的情況下，保持狀態一致變得更加困難
其他非區塊鏈私有分佈式系統，必須在一致性和可用性之間做出相同的權衡，Google 的 BigTable維護可用性並將更新復製到其他節點，使其最終在整個數據中心保持一致，以便在 BigTable 集群內進行協調，它依賴於故障名為Chubby的容差鎖分佈式服務，在領導選舉期間使用 paxos。但是，似乎由於 Google 私有 WAN 的可靠性（>99.9995% 可用性）和非常準確的計時，他們還建構了Spanner，其時間戳的準確性允許對更新進行排序（如果順序不確定，則延遲更新），以便應用程序的數據視圖與應用程序的約束和其他不變數一致。
我強調 CAP 定理來解釋中本聰共識如何始終可用，但受最終一致性的影響，可能允許51% 攻擊。其他共識協議可以提供最終確定，但可能並不總是可以將它們開放給系統停止 DDoS 攻擊。在私有系統的背景下，對硬體的控制意味著分佈式系統幾乎可以始終可用並免受 DoS 攻擊，這導致像Google這樣的公司更喜歡提供一致性。
是的，需要共識，對於共識 RAFT，PAXOS 用於一般節點故障。如果他們是惡意節點，可以使用拜占庭容錯。但在私有區塊鏈的情況下不使用 POW，因為參與使用者是已知的。