共識算法解決的是對某個提案(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

總結

以上是生活随笔為你收集整理的区块链基础知识系列 第二课 区块链共识算法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。