區塊鏈基礎知識系列 第二課 區塊鏈共識演算法

共識演算法解決的是對某個提案(proposal)大家達成一致意見的過程。 PBFT (拜占庭容錯)演算法 -Fabric 0.6採用

五個階段：request，預準備（pre-prepare）、準備（prepare）、和確認（commit），reply

步驟：

    1.從全網節點選舉出一個主節點（Leader），新區塊由主節點負責產生
    2.Pre-Prepare：每個節點把用戶端發來的交易向全網廣播，主節點0將從網路收集到需放在新區塊內的多個交易排序後存入列表，並將該列表向全網廣播，擴散至123
    3.Prepare：每個節點接收到交易列表後，根據排序類比執行這些交易。所有交易執行完後，基於交易結果計算新區塊的雜湊摘要，並向全網廣播，1->023，2->013，3因為宕機無法廣播
    4.Commit：如果一個節點收到的2f（f為可容忍的拜占庭節點數）個其它節點發來的摘要都和自己相等，就向全網廣播一條commit訊息
    5.Reply：如果一個節點收到2f+1條commit訊息，即可提交新區塊及其交易到本地的區塊鏈和狀態資料庫。

拜占庭容錯能夠容納將近1/3的錯誤節點誤差，IBM建立的Hyperledger 0.6版本就是使用了該演算法作為共識演算法（1.0版本已棄用，使用kafka）。

Fabric1.0採用共識演算法為Solo、Kafka

1.Solo Orderer: The solo orderer is intended to be an extremely easy to deploy, non-production orderer. It consists of a single process which serves all clients, so no `consensus' is required as there is a single central authority. There is correspondingly no high availability or scalability. This makes solo ideal for development and testing, but not deployment. The Solo orderer depends on a backing orderer ledge

order-solo模式作為單節點通訊模式，所有從peer收到的訊息都在本節點進行排序與產生資料區塊，詳細流程見下圖：（用於開發模式下）

order-solo過程分析：Peer（用戶端）通過GRPC發起通訊，與Orderer串連成功之後，便可以向Orderer發送訊息。Orderer通過Recv介面接收Peer發送過來的訊息，Orderer將接收到的訊息產生資料區塊，並將資料區塊存入ledger，peer通過deliver介面從orderer中的ledger擷取資料區塊。

2.Kafka Orderer : The Kafka orderer leverages the Kafka pubsub system to perform the ordering, but wraps this in the familiar ab.proto definition so that the peer orderer client code does not to be written specifically for Kafka. In real world deployments, it would be expected that the Kafka proto service would bound locally in process, as Kafka has its own robust wire protocol. However, for testing or novel deployment scenarios, the Kafka orderer may be deployed as a network service. Kafka is anticipated to be the preferred choice production deployments which demand high throughput and high availability but do not require byzantine fault tolerance. The Kafka orderer does not utilize a backing orderer ledger because this is handled by the Kafka brokers.

Orderer-Kafka分析 （用於正式環境下） BroadCast ：Broadcast主要接收Peer的資料並在Orderer裡面產生一系列資料區塊，主要流程見下圖： Broadcast過程分析：Peer（用戶端）通過GRPC發起通訊，與Orderer串連成功之後，便可以向Orderer發送訊息。Orderer通過Recv介面接收Peer發送過來的訊息，並將訊息推送到Kafka。同時與Kafka相串連的Orderer通過Consumer執行個體消費Kafka上的訊息，將消費的訊息進行同一排序（Order），排序完成後，當達到產生資料區塊（Block）的條件（條件有兩個1：下一資料區塊定時器到期，定時器通過向Orderer向Kafka發送定時器訊息，再通過Kafka消費來達到定時效果。2：每消費一條真實資料，就觸發判斷是否達到產生一個新的資料區塊條件，該條件由當前待產生資料區塊的資料總的大小以及記錄數決定），並建立新的資料區塊（CreateNextBlock），建立成功則將資料區塊寫入ledger（WriteBlock）Deliver過程分析：

Peer通過GRPC與orderer建立通訊，串連成功以後，通過deliver介面發起擷取資料請求。Orderer通過recv介面接收到資料擷取請求，分析請求參數（SeekInfo_Start:1、SeekPosition_Oldest：從第一條資料區塊開始擷取。2、SeekPosition_Newest：從最新一個資料區塊開始擷取 3、SeekPosition_Specified：從指定資料區塊數擷取）。Orderer從ledger中擷取資料區塊迭代器入口，迴圈迭代器擷取所有的資料區塊，每擷取一個資料區塊同時就擷取到的資料區塊返回給peer，知道所有資料區塊擷取完，最後向peer返回擷取成功狀態。

參考內容：https://zhuanlan.zhihu.com/p/25358777