PBFT——實用拜占庭容錯演算法
你一覺醒來，發現自己沒躺床上，而是站到皇帝身邊，變成貼身侍衛。皇帝合上奏摺，扭頭問你：甘肅有沒有旱災？
你剛來，不熟悉業務，但欺君是罪，只好抱著問題溜出門，幸虧遇到三位大臣圍在門口點煙，於是你湊前一步說：皇上讓我問問你們，甘肅有旱災？
兩個大臣連忙點頭，但另一個卻吐出兩個煙圈，笑而不語。
你的挑戰才剛剛開始——到底有沒有旱災？
按照PBFT共識演算法，你應該馬上挽起兩位點頭大臣的手臂，找皇上彙報：甘肅確有旱災一事。因為已達成2/3多數的共識，但且慢一步，先搞清楚一件事：
一、什麼是PBFT？
將軍喻指網路節點，解決拜占庭將軍問題就要祭出一個概念：拜占庭容錯。
網路節點總有錯誤，它們可能是叛徒（惡意節點），也可能是傻子（故障節點），各節點並不能確保收到的信息沒被做過手腳。「拜占庭容錯」指在分散式系統里容下這些「錯」的同時，又能達成正確的共識。
我們已經熟悉經典的拜占庭容錯解決方案：POW演算法——使用工作量證明找隨機數。
如果你讀過專欄第一季的文章，就能體驗到那場面的轟轟烈烈：腱鞘炎都快翻出來了，但隨機數還是很難找到。可一旦找到隨機數，硬邦邦的事實就戳在地上，誰都無法撼動。
很安全，但是沒效率。
PBFT只是嫌棄傳統方案不實用而已，所以增加一個假設，千萬別小看這個假設，它把原本鋪漫到天邊的工作量變成幾乎不需要工作量，這個假設就是：不良節點不超過節點總數的1/3。
最終，從效率角度望過去，拜占庭將軍問題的傳統解法POW在PBFT這種火箭推進器面前頓時灰頭土臉，像台燒劈柴的鍋爐。
那PBFT具體是如何運作的？
二、PBFT的運作過程
PBFT共識演算法的全過程分五步：第一步是「請求」，相當於客戶端發出讀寫需求，第五步是「答覆」，相當於系統給客戶端的最終答覆。
真正達成共識的是中間三步：
第二步：你問大臣（預準備）
第三步：大臣回答（準備）
第四步：官僚系統間再次確認（確認）
PBFT把你和所有大臣（全網節點）稱為「副本」，而你是最重要的副本，即「主節點」，負責從大臣們處搜集信息，統籌分發確認，最終牽頭答覆。
主節點向全網廣播，這個過程就是預準備。預準備的關鍵是分發，主節點為每個請求編上號，然後群發向所有副本。
圖1 PBFT演算法的前兩步：請求和預準備
預準備消息（圖1右側三個箭頭）含有請求的數字簽名（戳此複習），這使得其他副本很容易驗證真偽。
通過驗證後進入準備階段：此時，副本向全網廣播它自己的答覆。為防惡意攻擊，副本把預準備消息和準備消息都記在自己的小本子上。如果看預準備消息不順眼，就什麼都不做。
圖2PBFT演算法的前三步：請求、預準備和準備
準備階段最重要的事：確保所有正常節點達成一致。
但總有不一致的節點，比如那位只吐煙圈不吐字的大臣（副本3），PBFT將這種沒有響應的節點視作失效。處理失效節點是下一步「確認階段」要做的事。
進入確認階段，副本首先驗證消息的數字簽名，廣播確認後，主節點負責統計共識，說白了，你只做一件事：統計出達到系統節點總數2/3的共識，這個共識就是最終答覆。
你發現：兩票點贊，一票失效，於是主節點在圖3右側雙虛線處敲定共識：甘肅有旱災。
圖3 PBFT的完整過程
最後，進入答覆環節，主節點和其他正常副本一起答覆客戶端，整個過程都在全網監督下一氣呵成，「一氣呵成」的意思是一秒鐘完成。
但你可能會提個問題：如果主節點不按規矩辦事系統會怎麼辦？即，圖3左下角的「×」畫在主節點上，那系統又該如何應對？
我們稱這種情況為「主節點失效」，一旦遇到主節點失效時，系統的應對方案很簡單：變更視圖。
什麼是視圖？視圖即節點排位，變更視圖就是其他副本確認主節點出問題後，立即認副本1為主節點，原主節點到後面去排隊，變成副本3。
圖4 變更視圖示例
當主節點無法執行請求時，副本必須變更視圖，這樣才能保持系統活性，關於變更視圖條件有三點說明：
第一，至少確保2/3多數的正常節點在同一視圖中，換句話說，如果共識未超越2/3多數，主節點就跑去答覆客戶端，副本就會認定主節點失效。
第二，請求編號必須在系統規定的範圍內。還記得在預準備環節里，主節點要給請求分配編號才能廣播么？設計這一編號，本來是為便於相互確認，否則請求一多就會對不上賬，但這也給主節點擾亂系統的留下一個後門：故意分配超大編號，塞爆內存。
應對方案也很樸素，設一個編號上限就ok，這個上限稱為「水線」。一旦副本發現請求編號超出水線範圍，就會認定主節點失效。
第三，必須定義出超時的時長，不能讓副本無底線地等待；
為滿足這點要求，每當副本收到一個請求，就開始計時，直到副本做出最終答覆計時才停止。如果超過系統設定的響應時間，而沒有看到主節點答覆客戶端，副本就會認定主節點失效。
於是，系統始終能夠應對主節點失效：好好乾活你就是中心，一旦作假或怠工，找人換你只是下一秒的事，這就是PBFT演算法的核心邏輯。
作者把PBFT說成了花，那它有沒有軟肋呢？
你一定看出來了，如果湧進足夠多的不良節點（超過總節點的1/3），則網路勢必奔潰，因為根本假設已不成立，所以基於PBFT構建的網路不能像比特幣網路一樣完全開放。
於是，我們必須引入一個新概念：
三、許可鏈
指經許可才能接入的鏈。
小規模的許可鏈就像私家莊園，稱為私有鏈；較大規模的許可鏈就像經濟開發區內的企業集群，我們稱之為聯盟鏈。不管是私有鏈還是聯盟鏈，入網都必須經過有權人核准。
與許可鏈對應的概念就是公有鏈（公鏈），公有鏈的代表是比特幣，任何節點都能隨時出入、隨時讀取，賬本全公開，沒有私密性。
而許可鏈則在地上圍了一圈籬笆，你想進來嗎？先拿到批准再說，所以私密性好。
當然，和公有鏈相比，許可鏈的安全性就短了一截。比如就在4天前，基於PBFT開發的應用Ripple就被曝永久丟失32570個區塊，這意味著沒有人能夠審核Ripple的完整區塊鏈。
雖然當事方稱未對普通用戶造成影響，但和比特幣平穩運行9年多相比，安全性瞬間矮下一頭。甚至有人稱Ripple的PBFT共識機製為「沒有必要又毫無意義的煙霧鏡像」。
沒有錯，PBFT演算法並不是去中心化的共識，而是中心化的控制，這就是為什麼很多人並沒有把Ripple的代幣XRP劃為去中心化貨幣的原因。
但PBFT的效率終究秒殺POW，所以幾乎所有的大型金融項目都傾向使用PBFT構建聯盟鏈，那這麼做對我們有什麼好處呢？
舉個小例子：傳統跨境支付需要3-5天，而基於PBFT的Ripple搞定同樣的事只需3-5秒，同時費用下降50%以上。
你看，不管是去中心化還是中心化，足夠先進的科技，都和魔法無異。
結語
1779年，和珅上表乾隆，西征軍在甘肅遇澇，行軍延期。皇帝合上奏摺，心中蹊蹺不已，甘肅已報旱災多年，不僅減稅，而且開捐（賣官），所得全部賑濟災民。
1781年，甘肅布政司王亶望被處斬，陪他一起被誅的還有56名官員，乾隆親手終結清史上最轟動的欺上瞞下運動——甘肅冒賑案。
原來，鏈並不會因為私有而安全，如果缺乏足夠的信息迴路，PBFT演算法就會失效，古代官場就是一個例子。
雖然皇帝端坐權力系統中央，但他並不居於信息系統中心，皇帝只是一個與信息系統若即若離的客戶端，在本文的例子中，你才是信息系統的君王。
官僚體系本質上是權力系統，但它同時也是信息系統。皇帝要了解民情，得通過官僚，民情想上傳天聽，也得過官僚，而官僚內部的貪腐網路阻斷著上下政情。
而我們現代社會就不同，因為有更多的信息流，這讓信息系統從權力系統中獨立出來，最終使得傳統權貴的招數在現代社會根本玩不下去。
有人說根治腐敗得靠講道德，有人說嚴刑峻法更有效，還有人說只要貼上民主的膏藥就能藥到病除。但歷史證明，這些符合常人直覺的土辦法，都煉不出好鋼。
腐敗看起來是權力問題，但說到底是信息問題，只要我們鑿通更多的信息迴路，把更多事實擺在人們面前，把內部信息攤到陽光下一曬，自然能根治腐敗。
所以，想想這兩年清透很多的官場，難道是因為公務員們多上了兩節黨課、多抄了三遍黨章？還是因為全國人手一部智能手機？
一段視頻了斷一堆官員前途的故事，不應該被忘記。
本文從PBFT共識演算法分叉聊到治理腐敗，結論也就一句話，這句話同時也是區塊鏈的意義所在：
陽光是最好的殺毒劑。
回到我們專欄的主題，考慮到難度已經爬坡，為讓你的思路更柔順，正文沒有鋪設一個英文單詞。
如果你想深扒一層，請自行對照文末辭彙表，這可以讓你更潤滑地閱讀PBFT演算法發明者的說明書：
http://pmg.csail.mit.edu/papers/osdi99.pdf
如果你不習慣看原文，可參考趣鏈科技聯合創始人、浙大博士李啟磊的文章：
http://blog.liqilei.com/bai-zhan-ting-gong-shi-suan-fa-zhi-pbftjie-xi/
其中不僅有對預準備、準備和確認三步的技術描述，而且一些小概念的精緻說明，如消息日誌、穩定檢查點和水線。
辭彙表
實用拜占庭容錯演算法（PBFT）
Practical Byzantine Fault Tolerance
拜占庭容錯（BFT）
Byzantine Fault Tolerance
工作量證明（POW）
Proof Of Work
客戶端 client 文中的皇帝
副本 replica 系統中的記賬節點，文中的官僚系統
主節點 primary 文中的你
備份 backup 即除主節點外的其他節點，當主節點失效時按序備份
視圖 view 「你-大臣1-大臣2-大臣3」的順位架構就是一種視圖
變更視圖 change view 主節點失效時的系統策略
活性 liveness 主節點沒失效，就說明系統有活性
消息日誌 message log
水線 watermark
穩定檢查點 stable checkpoint
請求 request
預準備 pre-prepare
準備 prepare
確認 commit
答覆 reply
為便於你理解，和上篇講述DPOS的文章一樣，作者把共識確認條件從2/3+1多數簡化為2/3，因為當節點數足夠多時，2/3+1多數≈2/3多數。
另外，實際場景中不可能只有4個節點，更可能是40個、400個或者更多，你可以把本文的例子推廣到9個大臣，然後在A4紙上推演一遍五步過程和視圖變更。
因為這樣你就能輕而易舉地發現：正文變更視圖的案例好不嚴謹——4個副本一旦變更視圖，只剩2個正常副本，另外2個是失效節點：吐煙圈的大臣和你。所以，這局視圖根本玩不下去。
如果用9個節點推演就不存在這樣的問題，相信我，在A4紙上推演一遍，你一定能徹底理解PBFT。
祝你每周都有進步。
TAG:操作大腦 |