區塊鍊技術的核心是在沒有中心控制的情況下,在互相沒有信任基礎的個體之間就交易的合法性等達成共識的共識機制
提起共識那麼非常有名的拜占庭将軍問題使我們應該首先應該了解
1.拜占庭将軍問題
本文不講故事,請移步http://baijiahao.baidu.com/s?id=1591728006111720793&wfr=spider&for=pc
我們在這裡讨論拜占庭的2種情況
1.1.非拜占庭故障:
因為當機、網絡擁塞等原因産生故障的程序。 特點，僅停止服務，不主動作惡。例： Quorum,Paxos,Raft系統。
1.2.拜占庭故障:
程序被攻擊者完全控制，可以進行任意行為。特點：程序的行為是不可預測的，常見有：停機、發送任意消息、篡改轉發
的消息、合謀等。例： PBFT系統。
1.3.說明:
拜占庭故障是最嚴重缺陷或故障。可能的原因例如遭黑客入侵、管理者背叛等等。
2.共識機制
2.1.poW:
poW(工作量證明),也就像比特币的挖礦機制,礦工通過把網絡尚未記錄的現有交易打包到一個區塊,然後不斷周遊嘗試來尋找一個随機數,使得新區塊加上随機數的哈希值滿足一定的難度條件,例如前面10位為0.找到滿足條件的随機數,就相當于确定了區塊鍊最新的一個區塊,也就相當于獲得了區塊鍊的本輪記賬權.礦工把滿足挖礦難度條件的區塊在網絡中廣播出去,全網的其他節點在驗證該區塊滿足挖礦的難度條件,同時區塊裡的交易資料符合協定規範後,将各自把該區塊連接配接到自己版本的區塊鍊上,進而在全網形成對目前網絡狀态的共識
優點:完全去中心化,節點自由進出,避免了建立和維護中心化信用機構的成本.隻要網絡破壞者的算力不超過網絡總算力的50%,網絡的交易狀态就能達成一緻.
缺點:資源浪費,挖礦激勵造成礦池算力的高度集中,背離了中心化的特征.更大的問題poW機制的共識達成時間較長,最多每秒7筆,不适合做商業應用.
2.2.poS:
poS權益證明,要求節點提供擁有一定數量的代币證明來擷取競争區塊鍊記賬權的一種分布式共識機制.如果單純依靠代币餘額來決定記賬者必然使得富有者勝出,導緻記賬權的中心化,降低共識的公平性,是以不同的PoS機制在權益證明的基礎上,采用不同的方式來增加記賬權的随機性來避免中心化.例如點點币(peerCoin)PoS機制中,擁有最長鍊齡的比特币獲得記賬權的機率就很大.NXT和Blockcoin則采用一個共識來預測下一個記賬節點.擁有多的代币被選為記賬節點的機率就很大.未來以太坊也會從目前的poW機制轉換的poS機制,從目前看到的資料來看,以太坊的poS機制将采用節點下賭注來賭下一個區塊,賭中者有額外的以太币獎勵,賭不中者會被扣以太币的方式來達成下一個區塊共識
優點:在一定程度上縮短了達成共識的時間,降低了poW機制的資源浪費
缺點:破壞者對網絡的攻擊成本很低,網絡安全性有待驗證.另外擁有代币數量大的節點獲得記賬權的機率會更大,會使得網絡共識受少數富裕賬戶支配,進而失去公正性
2.3.DPoS
DPoS(股份授權證明)機制,類似于董事會投票.比特股(bitshares)采用的PoS機制是持股者投票選出一定數量的見證人,每個見證人按序有兩秒鐘的權限時間生成區塊,若見證人在給定的時間片不能生成區塊,區塊生成權限交給下一個時間片對應的見證人.持股人可以随時通過投票更換這些見證人.DPoS的這種設計使得區塊的生成更為快速,也更加節能.
優點:大幅縮小參與驗證和記賬節點的數量,可以達到秒級的共識驗證.
缺點:選舉固定數量的見證人作為記賬候選人有可能不适合于完全去中心化的場景.另外在網絡節點很少的場景,選舉的見證人的代表性也不強.
2.4.分布式一緻性算法
分布式一緻性算法是基于傳統的分布式一緻性技術.其中有分為解決拜占庭将軍問題的拜占庭容錯算法,如PBFT.另外解決非拜占庭問題的分布式一緻性算法(Paxos.Raft).該類算法目前是聯盟鍊和私有鍊場景中常用的共識機制
優點:實作秒級的共識機制,保證一緻性.适合多方參與的多中心商業模式.
缺點:去中心化程度不如公有鍊上的共識機制
2.4.1拜占庭容錯系統
這裡讨論2種情況
拜占庭問題:節點中有可能出現被入侵後叛變的風險,亂發消息.
PBFT協定:
PBFT是一類狀态機拜占庭系統。
每個獨立程序共同維護一個狀态，執行用戶端發出的操作.
所有節點采取的行動一緻，操作後達成的狀态也是一緻的。（順序一緻性）
為了友善讨論，假設client也是“好的”
這是一個簡單的PBFT通信協定模型其中C為用戶端,0-3代表服務節點,0為主節點,3為故障節點.
1)用戶端發送請求,激活主節點的服務操作.
2)當主節點接受請求後,啟動三階段的協定以向各從節點廣播請求.
2.1:序号配置設定階段,主節點給請求指派一個序号n,廣播序号配置設定消息和用戶端的請求m,并将構造的pre-prepare消息給各從節點
2.2:互動階段,從節點接收pre-prepare消息,向其他服務節點廣播prepare消息.
2.3:序号确認階段,各個節點對視圖内的請求和次序進行驗證後,廣播commit消息,執行收到的用戶端的請求并給用戶端響應
3)用戶端等待來自不同節點的響應,若有m+1個相同,則該響應即為運算的結果
PBFT應用場景很多如:IBM主導的超級賬本種,PBFT是一個可選的共識機制
以上就是解決所有拜占庭問題的共識機制
非拜占庭問題:節點中基本安全可靠,隻是處理一般的當機故障.
RAFT協定
zookeeper也使用類似協定
看動畫了解協定
http://thesecretlivesofdata.com/raft/
總結: