1 背景
當前大家對fabric的共識算法的觀點，普遍都認為是kafka，而kafka是主從模式，所以不能防止作惡。針對這個觀點，詳細解析fabric的共識模式。
2 fabric共識
fabric共識模式采用的 Endorse+Kafka+Commit 的模式，這里我們簡稱EKC共識。此共識包含以下幾個步驟：
請求背書：
客戶端用自己的私鑰對交易進行簽名后，按照指定格式將交易和簽名信息進行打包，然后將打包后的數據發給背書節點請求背書。驗證背書：
背書節點收到背書請求后，驗證交易的簽名是否正確并調用智能合約驗證交易內容是否合法。驗證通過的話，背書節點用自己的私鑰對背書結果進行簽名并按照指定格式打包，然后將打包后的數據發給客戶端。提交交易：
客戶端收到背書結果后，驗證背書結果的簽名是否正確。驗證通過后，對交易請求和背書結果簽名并打包。然后，把打包后的數據發送給orderer節點提交交易。排序廣播：
orderer節點收到交易后，驗證數據的客戶端簽名[bJ1] 是否正確。驗證通過后，將交易發給kafka集群對應的topic。由于orderer中的對于每個通道都在kafka上監聽對應的消息，因此，kafka將消息存放到對應topic上之后，會將消息廣播給通道上的所有orderer。因為各個orderer的消息都是由kafka按照相同順序發送的，因此，這個過程也實現了消息的排序。打包出塊：
orderer節點接收到從kafka推送的消息（kafka節點見同步消息不需要驗證），當滿足出塊策略[bJ2] ：緩存交易個數達到區塊最大交易數或者時間達到出快時間，則將交易進行打包、對數據簽名，然后出塊，并將區塊分發給peer節點。驗證記賬：
peer節點接收到區塊后，驗證交易是否有效即驗證區塊的交易是否滿足背書策略以及區塊中交易的讀寫集版本是否正確[bJ3] 。驗證通過的話，執行此交易的內容更改狀態數據庫。驗證失敗的話，對此條交易不做任何處理。當區塊中的交易全部處理完成后，將區塊記錄在本地數據庫。
3 交互流程圖
4 數據流程圖
