本文參考BOS白皮書https://boscore.gitbook.io/docs/essentials/bos-resources/bos-whitepapers

一 基礎概念

（1）Byzantine Fault Tolerance

Byzantine Fault Tolerance（拜占庭容錯）來自與拜占庭將軍問題。該問題可以表述為幾位將軍從多地共同攻城，已知只有同時全體決定進攻或不進攻才能保證勝利或不損傷，問題在於如何在有叛徒存在的情況下達成一致。

拜占庭容錯系統就是用來解決拜占庭將軍問題帶來的去中心化一致性風險的手段。即在個別分散式節點出現惡意行為的情況下，拜占庭容錯系統依然可以正確完成一致性確認。

現有主流底鏈框架中使用BFT共識機制的包括：

• Fabric：PBFT(Practical Byzantine Fault Tolerance)
• EOS：PBFT(pipelined Byzantine Fault Tolerance)
• BCOS：BFT（batch Byzantine Fault Tolerance）

（2）LIB

LIB：last Irreversible Block，最後一個不能修改的區塊將被標註為LIB。

If a block is deemed irreversible, it means that you can trust with 100% confidence that that transaction is final, fully confirmed, and immutable. If the block number of a block is lower than the Last Irreversible Block, that means it is considered final. Commonly abbreviated as LIB.

二共識演演算法

（1）EOSIO

EOSIO使用一種P(pipelines)BFT演演算法。每一個塊，需要經歷Propose、Pre-commit、Commit、Finalise階段，該交易不可修改的時間大約是3分鐘（理論上的最小值是325個塊時間，也就是大約162.5秒）。

但是流水線式的驗證過程存在效率低的問題。每一個塊產生後會廣播給其他所有驗證節點進行驗證，但是每個收到確認資訊的節點只能輪流表達自己的意見（即塊確認）。最後，經過一輪迴圈後才可以確認一個塊。

（2）BOS

BOS網路使用P（Practical）BFT機制來代替P（Pipelined）BFT，在這樣的機制下每一個BP可以立即確認塊。

程式碼層次對EOS的修改：

1. 保留了原共識中迴圈出塊的機制，同步時鐘、出塊順序的強限制依然保留。
2. 刪除了確認環節的部分邏輯以避免和新共識機制在邊緣情況下有衝突。
3. 保留P2P網路的通訊機制，確保通訊成本可接受
4. 用批共識代替了單塊機制，通過一次性廣播多個塊，接近實時BFT效果，降低網路負載。

BOS中PBFT的過程可以表述為：

1. Pre-prepare
   當產生一個區塊之後，廣播到其他出塊節點的過程。
2. Prepare
   當一個出塊節點接收到驗證請求並驗證成功後，將接收到的資訊廣播到整個網路。
3. Commit
   當出塊節點接收到足夠多的對於某條請求的確認，將該請求傳送到全網路
4. Commit-local
   當出塊節點收到針對某塊的足夠多的Commit資訊，會完成塊驗證過程，即該塊
5. View：當出塊節點改變的時候，所有未經許可的資訊全部被丟棄，並重新嘗試共識程式，直到達成節點共識。
6. Checkpoint：檢查塊高度的一致性，用來提供安全證明。當足夠多的出塊節點具有相同的塊高度時，該檢查點被認為是可靠的。檢查點的生成分為兩大類：一類是固定塊的生成，另一類是需要提供特殊安全證明的特殊點。

效果：
通過對EOS主網路觀測，全域性節點之間的網路延時大部分處於1秒以內。根絕BOS現有共識機制推算，區塊一致性過程預計可以3秒內完成，即3秒內實現區塊鏈的不可更改。

混淆點

（1）pipeline vs batch

該說法是用來區分塊同步的方法。在流水線（pipeline）形式的塊同步中，出塊節點每次只進行一個塊的驗證申請。在批次處理（batch）形式中，出塊節點每次都會發出多個塊的驗證申請。

（2）DPOS BFT vs PBFT

EOS的發展傳承了BM大佬在之前商業嘗試中的思路，最初仍採用DPOS來實現。DPOS的核心思想在於不需要浪費算力資源爭奪記賬權，而是選擇依據EOS持有人的投票選出21人擔任記賬角色。投票中擁有更多EOS的人會有更多的投票權和影響力。

但是DPOS沒有考慮網路延遲的因素，比如輪流出塊的節點如果分別在不同的國家，網路延遲會過多地影響同步時間。於是BM大佬設計了最新的機制為BFT-BPOS。

最新機制對DPOS主要有三點改進：

1. 在BFT-DPOS中，引入了拜占庭容錯機制，即只需要保證作惡節點不超過1/3即可。這樣的機制下，只要有2/3的節點可以認可該區塊就能保證全網的一致性；
2. 按照地理位置指定BP節點出塊順序：中國->日本->美國->加拿大等，保證按照地理位置依次交接出塊角色；
3. 出塊節點可以0.5秒產生一個區塊，但是為了增加效率的同時考慮時延影響，每個出塊節點會連續產生6個區塊。區塊產生與驗證也是同步進行的，在進行出塊的同時，也會進行其他塊的驗證與廣播。

BOSCore側鏈嘗試了另外一種思路來實現速度的提升，
即基於P（practical）BFT機制的批次處理方式來改進原有的EOS程式碼。

PBFT（Practical Byzantine Fault Tolerance），即實用拜占庭容錯演演算法，由Miguel Castro和Barbara Liskov在1999年發表的論文《Practical Byzantine Fault Tolerance and Proactive Recovery》中提出。PBFT演演算法可以工作在非同步環境中，並且通過優化解決了原始拜占庭容錯演演算法效率不高的問題，將演演算法複雜度由指數級降低到多項式級，使得拜占庭容錯演演算法在實際系統應用中變得可行，目前已得到廣泛應用。PBFT演演算法可以在失效節點不超過總數1/3的情況下同時保證Safety和Liveness。

通過可批次處理的BFT演演算法（即Batch Byzantine Fault Tolerance），目前BOSCore已實現秒級塊確認及不可修改。

（3）EOS 的LIB時間到底是多少？

這裡參考：https://blog.csdn.net/zhuxiangzhidi/article/details/82927020

對於EOS最新的BFT-DPOS共識機制，每一個出塊節點有6秒的出塊時間，每個塊用時0.5秒，所以每次一個出塊節點連續產生12個區塊。關於設計的原因，可以參考BM的說法：

6 seconds was chosen based upon the 「maximum downtime」 if a producer goes off line. This matches Steem & BitShares where a single missed block creates 6 seconds without any confirmation.

通過BM與V神的討論，DPOS的節點確認被定義為兩輪。
所以總確認時間為：
T = 2*(2/3) *21 *12 = 336塊時間，而理論上的最小塊時間也需要325，所需的最少時間也大概是162.5秒（接近3分鐘）。