區塊鏈拜占庭將軍問題詳解
『壹』 區塊鏈 --- 共識演算法
PoW演算法是一種防止分布式服務資源被濫用、拒絕服務攻擊的機制。它要求節點進行適量消耗時間和資源的復雜運算，並且其運算結果能被其他節點快速驗算，以耗用時間、能源做擔保，以確保服務與資源被真正的需求所使用。
PoW演算法中最基本的技術原理是使用哈希演算法。假設求哈希值Hash(r)，若原始數據為r（raw），則運算結果為R（Result）。
R = Hash(r)
哈希函數Hash()的特性是，對於任意輸入值r，得出結果R，並且無法從R反推回r。當輸入的原始數據r變動1比特時，其結果R值完全改變。在比特幣的PoW演算法中，引入演算法難度d和隨機值n，得到以下公式：
Rd = Hash(r+n)
該公式要求在填入隨機值n的情況下，計算結果Rd的前d位元組必須為0。由於哈希函數結果的未知性，每個礦工都要做大量運算之後，才能得出正確結果，而算出結果廣播給全網之後，其他節點只需要進行一次哈希運算即可校驗。PoW演算法就是採用這種方式讓計算消耗資源，而校驗僅需一次。
PoS演算法要求節點驗證者必須質押一定的資金才有挖礦打包資格，並且區域鏈系統在選定打包節點時使用隨機的方式，當節點質押的資金越多時，其被選定打包區塊的概率越大。
POS模式下，每個幣每天產生1幣齡，比如你持有100個幣，總共持有了30天，那麼，此時你的幣齡就為3000。這個時候，如果你驗證了一個POS區塊，你的幣齡就會被清空為0，同時從區塊中獲得相對應的數字貨幣利息。
節點通過PoS演算法出塊的過程如下：普通的節點要成為出塊節點，首先要進行資產的質押，當輪到自己出塊時，打包區塊，然後向全網廣播，其他驗證節點將會校驗區塊的合法性。
DPoS演算法和PoS演算法相似，也採用股份和權益質押。
但不同的是，DPoS演算法採用委託質押的方式，類似於用全民選舉代表的方式選出N個超級節點記賬出塊。
選民把自己的選票投給某個節點，如果某個節點當選記賬節點，那麼該記賬節點往往在獲取出塊獎勵後，可以採用任意方式來回報自己的選民。
這N個記賬節點將輪流出塊，並且節點之間相互監督，如果其作惡，那麼會被扣除質押金。
通過信任少量的誠信節點，可以去除區塊簽名過程中不必要的步驟，提高了交易的速度。
拜占庭問題：
拜占庭是古代東羅馬帝國的首都，為了防禦在每塊封地都駐扎一支由單個將軍帶領的軍隊，將軍之間只能靠信差傳遞消息。在戰爭時，所有將軍必須達成共識，決定是否共同開戰。
但是，在軍隊內可能有叛徒，這些人將影響將軍們達成共識。拜占庭將軍問題是指在已知有將軍是叛徒的情況下，剩餘的將軍如何達成一致決策的問題。
BFT：
BFT即拜占庭容錯，拜占庭容錯技術是一類分布式計算領域的容錯技術。拜占庭假設是對現實世界的模型化，由於硬體錯誤、網路擁塞或中斷以及遭到惡意攻擊等原因，計算機和網路可能出現不可預料的行為。拜占庭容錯技術被設計用來處理這些異常行為，並滿足所要解決的問題的規范要求。
拜占庭容錯系統 ：
發生故障的節點被稱為 拜占庭節點 ，而正常的節點即為 非拜占庭節點 。
假設分布式系統擁有n台節點，並假設整個系統拜占庭節點不超過m台（n ≥ 3m + 1），拜占庭容錯系統需要滿足如下兩個條件：
另外，拜占庭容錯系統需要達成如下兩個指標：
PBFT即實用拜占庭容錯演算法，解決了原始拜占庭容錯演算法效率不高的問題，演算法的時間復雜度是O(n^2)，使得在實際系統應用中可以解決拜占庭容錯問題
PBFT是一種狀態機副本復制演算法，所有的副本在一個視圖（view）輪換的過程中操作，主節點通過視圖編號以及節點數集合來確定，即：主節點 p = v mod |R|。v：視圖編號，|R|節點個數，p：主節點編號。
PBFT演算法的共識過程如下：客戶端（Client）發起消息請求（request），並廣播轉發至每一個副本節點（Replica），由其中一個主節點（Leader）發起提案消息pre-prepare，並廣播。其他節點獲取原始消息，在校驗完成後發送prepare消息。每個節點收到2f+1個prepare消息，即認為已經准備完畢，並發送commit消息。當節點收到2f+1個commit消息，客戶端收到f+1個相同的reply消息時，說明客戶端發起的請求已經達成全網共識。
具體流程如下 ：
客戶端c向主節點p發送<REQUEST, o, t, c>請求。o: 請求的具體操作，t: 請求時客戶端追加的時間戳，c：客戶端標識。REQUEST: 包含消息內容m，以及消息摘要d(m)。客戶端對請求進行簽名。
主節點收到客戶端的請求，需要進行以下交驗：
a. 客戶端請求消息簽名是否正確。
非法請求丟棄。正確請求，分配一個編號n，編號n主要用於對客戶端的請求進行排序。然後廣播一條<<PRE-PREPARE, v, n, d>, m>消息給其他副本節點。v：視圖編號，d客戶端消息摘要，m消息內容。<PRE-PREPARE, v, n, d>進行主節點簽名。n是要在某一個范圍區間內的[h, H]，具體原因參見 垃圾回收 章節。
副本節點i收到主節點的PRE-PREPARE消息，需要進行以下交驗：
a. 主節點PRE-PREPARE消息簽名是否正確。
b. 當前副本節點是否已經收到了一條在同一v下並且編號也是n，但是簽名不同的PRE-PREPARE信息。
c. d與m的摘要是否一致。
d. n是否在區間[h, H]內。
非法請求丟棄。正確請求，副本節點i向其他節點包括主節點發送一條<PREPARE, v, n, d, i>消息, v, n, d, m與上述PRE-PREPARE消息內容相同，i是當前副本節點編號。<PREPARE, v, n, d, i>進行副本節點i的簽名。記錄PRE-PREPARE和PREPARE消息到log中，用於View Change過程中恢復未完成的請求操作。
主節點和副本節點收到PREPARE消息，需要進行以下交驗：
a. 副本節點PREPARE消息簽名是否正確。
b. 當前副本節點是否已經收到了同一視圖v下的n。
c. n是否在區間[h, H]內。
d. d是否和當前已收到PRE-PPREPARE中的d相同
非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的PREPARE消息，則向其他節點包括主節點發送一條<COMMIT, v, n, d, i>消息，v, n, d, i與上述PREPARE消息內容相同。<COMMIT, v, n, d, i>進行副本節點i的簽名。記錄COMMIT消息到日誌中，用於View Change過程中恢復未完成的請求操作。記錄其他副本節點發送的PREPARE消息到log中。
主節點和副本節點收到COMMIT消息，需要進行以下交驗：
a. 副本節點COMMIT消息簽名是否正確。
b. 當前副本節點是否已經收到了同一視圖v下的n。
c. d與m的摘要是否一致。
d. n是否在區間[h, H]內。
非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的COMMIT消息，說明當前網路中的大部分節點已經達成共識，運行客戶端的請求操作o，並返回<REPLY, v, t, c, i, r>給客戶端，r：是請求操作結果，客戶端如果收到f+1個相同的REPLY消息，說明客戶端發起的請求已經達成全網共識，否則客戶端需要判斷是否重新發送請求給主節點。記錄其他副本節點發送的COMMIT消息到log中。
如果主節點作惡，它可能會給不同的請求編上相同的序號，或者不去分配序號，或者讓相鄰的序號不連續。備份節點應當有職責來主動檢查這些序號的合法性。
如果主節點掉線或者作惡不廣播客戶端的請求，客戶端設置超時機制，超時的話，向所有副本節點廣播請求消息。副本節點檢測出主節點作惡或者下線，發起View Change協議。
View Change協議 ：
副本節點向其他節點廣播<VIEW-CHANGE, v+1, n, C , P , i>消息。n是最新的stable checkpoint的編號， C 是 2f+1驗證過的CheckPoint消息集合， P 是當前副本節點未完成的請求的PRE-PREPARE和PREPARE消息集合。
當主節點p = v + 1 mod |R|收到 2f 個有效的VIEW-CHANGE消息後，向其他節點廣播<NEW-VIEW, v+1, V , O >消息。 V 是有效的VIEW-CHANGE消息集合。 O 是主節點重新發起的未經完成的PRE-PREPARE消息集合。PRE-PREPARE消息集合的選取規則：
副本節點收到主節點的NEW-VIEW消息，驗證有效性，有效的話，進入v+1狀態，並且開始 O 中的PRE-PREPARE消息處理流程。
在上述演算法流程中，為了確保在View Change的過程中，能夠恢復先前的請求，每一個副本節點都記錄一些消息到本地的log中，當執行請求後副本節點需要把之前該請求的記錄消息清除掉。
最簡單的做法是在Reply消息後，再執行一次當前狀態的共識同步，這樣做的成本比較高，因此可以在執行完多條請求K（例如：100條）後執行一次狀態同步。這個狀態同步消息就是CheckPoint消息。
副本節點i發送<CheckPoint, n, d, i>給其他節點，n是當前節點所保留的最後一個視圖請求編號，d是對當前狀態的一個摘要，該CheckPoint消息記錄到log中。如果副本節點i收到了2f+1個驗證過的CheckPoint消息，則清除先前日誌中的消息，並以n作為當前一個stable checkpoint。
這是理想情況，實際上當副本節點i向其他節點發出CheckPoint消息後，其他節點還沒有完成K條請求，所以不會立即對i的請求作出響應，它還會按照自己的節奏，向前行進，但此時發出的CheckPoint並未形成stable。
為了防止i的處理請求過快，設置一個上文提到的 高低水位區間[h, H] 來解決這個問題。低水位h等於上一個stable checkpoint的編號，高水位H = h + L，其中L是我們指定的數值，等於checkpoint周期處理請求數K的整數倍，可以設置為L = 2K。當副本節點i處理請求超過高水位H時，此時就會停止腳步，等待stable checkpoint發生變化，再繼續前進。
在區塊鏈場景中，一般適合於對強一致性有要求的私有鏈和聯盟鏈場景。例如，在IBM主導的區塊鏈超級賬本項目中，PBFT是一個可選的共識協議。在Hyperledger的Fabric項目中，共識模塊被設計成可插拔的模塊，支持像PBFT、Raft等共識演算法。
Raft基於領導者驅動的共識模型，其中將選舉一位傑出的領導者(Leader)，而該Leader將完全負責管理集群，Leader負責管理Raft集群的所有節點之間的復制日誌。
下圖中，將在啟動過程中選擇集群的Leader（S1），並為來自客戶端的所有命令/請求提供服務。 Raft集群中的所有節點都維護一個分布式日誌（復制日誌）以存儲和提交由客戶端發出的命令（日誌條目）。 Leader接受來自客戶端的日誌條目，並在Raft集群中的所有關注者（S2，S3，S4，S5）之間復制它們。
在Raft集群中，需要滿足最少數量的節點才能提供預期的級別共識保證， 這也稱為法定人數。 在Raft集群中執行操作所需的最少投票數為 (N / 2 +1) ，其中N是組中成員總數，即 投票至少超過一半 ，這也就是為什麼集群節點通常為奇數的原因。 因此，在上面的示例中，我們至少需要3個節點才能具有共識保證。
如果法定仲裁節點由於任何原因不可用，也就是投票沒有超過半數，則此次協商沒有達成一致，並且無法提交新日誌。
數據存儲：Tidb/TiKV
日誌：阿里巴巴的 DLedger
服務發現：Consul& etcd
集群調度：HashiCorp Nomad
只能容納故障節點(CFT)，不容納作惡節點
順序投票，只能串列apply，因此高並發場景下性能差
Raft通過解決圍繞Leader選舉的三個主要子問題，管理分布式日誌和演算法的安全性功能來解決分布式共識問題。
當我們啟動一個新的Raft集群或某個領導者不可用時，將通過集群中所有成員節點之間協商來選舉一個新的領導者。 因此，在給定的實例中，Raft集群的節點可以處於以下任何狀態: 追隨者(Follower)，候選人(Candidate)或領導者(Leader)。
系統剛開始啟動的時候，所有節點都是follower，在一段時間內如果它們沒有收到Leader的心跳信號，follower就會轉化為Candidate；
如果某個Candidate節點收到大多數節點的票，則這個Candidate就可以轉化為Leader，其餘的Candidate節點都會回到Follower狀態；
一旦一個Leader發現系統中存在一個Leader節點比自己擁有更高的任期(Term)，它就會轉換為Follower。
Raft使用基於心跳的RPC機制來檢測何時開始新的選舉。 在正常期間， Leader 會定期向所有可用的 Follower 發送心跳消息（實際中可能把日誌和心跳一起發過去）。 因此，其他節點以 Follower 狀態啟動，只要它從當前 Leader 那裡收到周期性的心跳，就一直保持在 Follower 狀態。
當 Follower 達到其超時時間時，它將通過以下方式啟動選舉程序：
根據 Candidate 從集群中其他節點收到的響應，可以得出選舉的三個結果。
共識演算法的實現一般是基於復制狀態機（Replicated state machines），何為 復制狀態機 ：
簡單來說： 相同的初識狀態 + 相同的輸入 = 相同的結束狀態 。不同節點要以相同且確定性的函數來處理輸入，而不要引入一下不確定的值，比如本地時間等。使用replicated log是一個很不錯的注意，log具有持久化、保序的特點，是大多數分布式系統的基石。
有了Leader之後，客戶端所有並發的請求可以在Leader這邊形成一個有序的日誌（狀態）序列，以此來表示這些請求的先後處理順序。Leader然後將自己的日誌序列發送Follower，保持整個系統的全局一致性。注意並不是強一致性，而是 最終一致性 。
日誌由有序編號（log index）的日誌條目組成。每個日誌條目包含它被創建時的任期號（term），和日誌中包含的數據組成，日誌包含的數據可以為任何類型，從簡單類型到區塊鏈的區塊。每個日誌條目可以用[ term, index, data]序列對表示，其中term表示任期， index表示索引號，data表示日誌數據。
Leader 嘗試在集群中的大多數節點上執行復制命令。 如果復製成功，則將命令提交給集群，並將響應發送回客戶端。類似兩階段提交(2PC)，不過與2PC的區別在於，leader只需要超過一半節點同意（處於工作狀態）即可。
leader 、 follower 都可能crash，那麼 follower 維護的日誌與 leader 相比可能出現以下情況
當出現了leader與follower不一致的情況，leader強制follower復制自己的log， Leader會從後往前試 ，每次AppendEntries失敗後嘗試前一個日誌條目（遞減nextIndex值）， 直到成功找到每個Follower的日誌一致位置點（基於上述的兩條保證），然後向後逐條覆蓋Followers在該位置之後的條目 。所以丟失的或者多出來的條目可能會持續多個任期。
要求候選人的日誌至少與其他節點一樣最新。如果不是，則跟隨者節點將不投票給候選者。
意味著每個提交的條目都必須存在於這些伺服器中的至少一個中。如果候選人的日誌至少與該多數日誌中的其他日誌一樣最新，則它將保存所有已提交的條目，避免了日誌回滾事件的發生。
即任一任期內最多一個leader被選出。這一點非常重要，在一個復制集中任何時刻只能有一個leader。系統中同時有多餘一個leader，被稱之為腦裂（brain split），這是非常嚴重的問題，會導致數據的覆蓋丟失。在raft中，兩點保證了這個屬性：
因此， 某一任期內一定只有一個leader 。
當集群中節點的狀態發生變化（集群配置發生變化）時，系統容易受到系統故障。 因此，為防止這種情況，Raft使用了一種稱為兩階段的方法來更改集群成員身份。 因此，在這種方法中，集群在實現新的成員身份配置之前首先更改為中間狀態（稱為聯合共識）。 聯合共識使系統即使在配置之間進行轉換時也可用於響應客戶端請求，它的主要目的是提升分布式系統的可用性。
『貳』 區塊鏈的技術原理是什麼
區塊鏈技術涉及的關鍵點包括：去中心化（冊蘆陪Decentralized）、去信任（Trustless）、集體維護（Collectivelymaintain）、可靠資料庫（ReliableDatabase）、時間戳（Timestamp）、非對稱加密（AsymmetricCryptography）等。
區塊鏈技術重新定義了網路中信用的生成方式：在系統中，參與者無需了解其他人的背景資料，也不需要藉助第三方機構的擔保或保證，區塊鏈技術保障了系統對價值轉移的活動進行記錄、傳輸、存儲，其最後的結果一定是可信的。
(2)區塊鏈拜占庭將軍問題詳解擴展閱讀
區塊鏈技術原理的來源可歸納為一個數學問題：拜占庭將軍問題。拜占庭將軍問題延伸到互聯網生活中來，其內涵可概括為：在互聯網大背景下，當需要與不熟悉的對手方進行價值交換活動時，人們如何才能防止不會被其中的惡意破壞者欺騙、迷惑從而做出錯誤的決策。
進一步將拜占庭將軍問題延伸到技術領域中來，其內涵可概括為：在缺少可信任州蠢的中央節點和可信任的通道的情況嘩此下，分布在網路中的各個節點應如何達成共識。區塊鏈技術解決了聞名已久的拜占庭將軍問題——它提供了一種無需信任單個節點、還能創建共識網路的方法。
『叄』 三. 區塊鏈系統的核心之一-分布式共識機制
拜占庭將軍問題（Byzantine Generals Problem），是由萊斯利·蘭波特在其同名論文中提出的分布式對等網路通信容錯問題。
在分布式計算中，不同的計算機通過通訊交換信息達成共識而按照同一套協作策略行動。但有時候，系統中的成員計算機可能出錯而發送錯誤的信息，用於傳遞信息的通訊網路也可能導致信息損壞，使得網路中不同的成員關於全體協作的策略得出不同結論，從而破壞系統一致性。這個難題被稱為「拜占庭容錯」，或者「兩軍問題」。
拜占庭假設是對現實世界的模型化。拜占庭將軍問題被認為是容錯性問題中最難的問題類型之一。拜占庭容錯協議要求能夠解決由於硬體錯誤、網路擁塞或斷開以及遭到惡意攻擊，其他計算機和網路可能出現不可預料的行為而帶來的各種問題。並且拜占庭容錯協議還要滿足所要解決的問題要求的規范。
在拜占庭時代有一個牆高壁厚的城邦——拜占庭，高牆之內存放在世人無法想像多的財富。拜占庭被其他10個城邦所環繞，這10個城邦也很富饒，但和拜占庭相比就有天壤之別了。
拜占庭的十個鄰居都覬覦它的財富，並希望侵略並佔領它。但是，拜占庭的防禦非常強大，任何單個城邦的入侵行動都會失敗，而入侵者的軍隊也會被殲滅，使得該城邦自身遭到其他互相覬覦對方的九個城邦的入侵和劫掠。
拜占庭的防禦很強，十個城邦中要有一半以上同時進攻才能攻破它。也就是說，如果有六個或者以上的相鄰城邦一起進攻，他們就會成功並獲得拜占庭的財富。然而，如果其中有一個或者更多城邦背叛了其他城邦，答應一起入侵但在其他城邦進攻的時候又不幹了，也就導致只有五支或者更少的城邦的軍隊在同時進攻，那麼所有的進攻城邦的軍隊都會被殲滅，並隨後被其他的（包括背叛他們的那（幾）個）城邦所入侵和劫掠。
這是一個由許多不互相信任的城邦構成的一個網路。城邦們必須一起努力以完成共同的使命。而且，各個城邦之間通訊和協調的唯一途徑是通過信使騎馬在城邦之間傳遞信息。城邦的決策者們無法聚集在一個地方開個會（所有的城邦的決策者都不互相信任自己的安全會在自己的城堡或者軍隊范圍之外能夠得到保障）。
城邦的決策者可以在任意時間以任意頻率派出任意數量的信使到任意的對方。每條信息都包含如下的內容：「我城邦將在某一天的某個時間發動進攻，你城邦願意加入嗎？」。如果收信城邦同意了，該城邦就會在原信上附上一份簽名了的或蓋了圖章的（以就是驗證了的）回應然送回發信城邦。然後，再把新合並了的信息的拷貝一一發送給其他八個城邦，要求他們也如此這樣做。最後的目標是，通過在原始信息鏈上蓋上他們所有十個城邦的決策者的圖章，讓他們在時間上達成共識。最後的結果是，會有一個蓋有十個同意同一時間發動進攻的圖章信息包，和一些被拋棄了的包含部分但不是全部圖章的信息包。
在這個過程中首先出現了第一個問題，就是如果每個城邦向其他九個城邦派出一名信使，那麼就是十個城邦每個派出了九名信使，也就是在任何一個時間又總計90次的傳輸，並且每個城市分別收到九個信息，可能每一封都寫著不同的進攻時間。
在這個過程中還有第二個問題，就是部分城邦會答應超過一個的攻擊時間，故意背叛進攻發起人，所以他們將重新廣播超過一條（甚至許許多多條）的信息包，由此產生許多甚至無數的足以淹沒一切的雜音。
有了以上兩個問題，整個網路系統可能迅速變質，並演變成不可信的信息和攻擊時間相互矛盾的糾結體。
拜占庭假設是對現實網路世界的一種模型化。在現實網路世界中由於硬體錯誤、網路擁塞或斷開以及遭到惡意攻擊，網路可能出現許許多多不可預料的行為。拜占庭容錯協議必須處理這些失效，並且還要使這些協議滿足所要解決的問題所要求的規范。
對於拜占庭將軍問題中本聰的區塊鏈給出了比較圓滿的解決方案。也就是比較圓滿的解決了上述的兩個問題。
拜占庭將軍問題的第一個問題從本質上來講就是時間和空間的障礙導致信息的不準確和不及時。
區塊鏈對於第一個問題的解決方案是利用分布式存儲技術和比特流技術（BT技術，一種新型的點對點傳輸技術，具有節點同時作為客戶端和伺服器端和沒有中心伺服器等特點），將整個網路系統內的所有交易信息匯總為一個統一的，分布式存儲的，近乎實時同步更新的電子總賬。統一的分布式共同賬本就解決了空間障礙問題；而近乎同步進行的，實時的，持續的對所有賬本備份的更新、對賬則解決了時間障礙問題。
這個過程較具體一點的描述大概是將區塊鏈系統內所有的交易活動的記錄數據統一於一種標准化的總帳上；區塊鏈系統的每一個節點都會保存一份總帳的備份；所有總帳的備份都是在實時的，持續的更新、對賬、以及同步著。區塊鏈系統的每一個節點能在這本總帳里記上添加記錄；每一筆新添加的記錄都會實時的廣播到區塊鏈系統內；所以在每一個節點上的每一份總帳的備份都是幾乎同時更新的，並且所有的總帳的備份保持著同步。
拜占庭將軍問題的第二個問題從本質上來講就是關於信息過量問題和信息干擾問題。信息過量和信息干擾問題導致決策延遲，甚至決策系統崩潰而無法決策。
區塊鏈對於第二個問題的解決方案是區塊鏈系統的任何一個節點在發送每一筆新添加的記錄時需要附帶一條額外的信息。對區塊鏈系統的任何一個節點來說這條額外的信息的獲得都是有成本的，並且只能有一個節點可以獲得。這樣就解決了區塊鏈系統的任何一個節點新添加額外信息時的信息多且亂而無法達成一致的問題。在這里，區塊鏈系統的任何一個節點獲得那條附帶的額外的信息的過程就是著名的工作量證明機制。
共識機制主要解決區塊鏈系統的數據如何記錄和如何保存的問題。工作量證明機制就是要求區塊鏈系統的節點通過做一定難度的工作得出一個結果的過程。
區塊鏈系統中某節點生成了一筆新的交易記錄，並且該節點將這筆新的交易記錄向全網廣播。全網各個節點收到這個交易記錄並與其他所有準備打包進區塊的交易記錄共同組成交易記錄列表。在列表內先對所有交易進行兩兩的哈希計算；再對以獲得的哈希值進行哈希計算獲得Merkle樹和Merkle樹的根值；把Merkle樹的根值及其他相關欄位組裝成區塊頭。
各個節點將區塊頭的80位元組數據加上一個不停的變更的區塊頭隨機數一起進行不停的哈希運算（實際上這是一個雙重哈希運算）；不停的將哈希運算結果值與當前網路的目標值做對比，直到哈希運算結果值小於目標值，就獲得了符合要求的哈希值，工作量證明也就完成了。
分布式的區塊鏈系統是一個動態變化的系統（硬體的運算速度的增長，節點參與網路的程度的變化）。系統的不斷變化必然帶來系統的算力的不斷變化。而算力的變化又會導致通過消耗算力（工作）來獲得符合要求的哈希值的速度的不同。最終的結果會是區塊鏈的增長速度會有巨大的不同。這是一個很大的問題。為了解決這個問題，區塊鏈系統自動根據算力的變化對工作難度進行調整。也就是採用移動平均目標的方法來確定，難度控制為每小時生成區塊的速度為某一個預定的平均數。
在區塊鏈系統中一個符合要求的哈希值是由N個前導零構成，零的個數取決於網路的難度值。為了使區塊的形成時間控制在大約十分鍾左右，區塊鏈系統採用了固定工作難度的難度演算法。難度值每2016個區塊調整一次零的個數。
新的難度值是根據前2015個區塊（理論上應該是2016個區塊，由於當初程序編寫時的失誤造成了用2015而不是2016）的出塊時間來計算。
難度 = 目標值 * 前2015個區塊生成所用的時間 / 1209600 （兩周的秒鍾數）
這樣通過規定的演算法，區塊鏈系統就保證所有節點計算出的難度值都一致，區塊的形成時間大約一致在十分鍾左右。
（1）結果不可控制。其依賴機器進行哈希函數的運算來獲得結果；計算結果是一個隨機數；沒有人能直接控制計算的結果。
（2）計算具有對稱性。就是結果的獲得和結果的驗收需要的工作量是不同的。計算出結果所需要的工作量遠遠大於驗收結果所需要的工作量。
（3）計算的難度自動控制。為了使區塊的形成時間控制在大約十分鍾左右，區塊鏈系統自動控制了每一個符合要求的哈希獲得為大約在十分鍾左右。
第一，方法簡單易行。
第二，系統達成共識容易，節點間不需要太多的信息交換。
第三，系統比較牢固可靠，任何破壞系統的企圖都需要投入大到得不償失的成本。
第一，消耗大量的算力，也就是浪費能源和其他資源。
第二，區塊的確認時間比較長，並且難以縮短。
第三，新創立的區塊鏈非常容易受到算力攻擊。
第四，容易產生區塊鏈分叉，穩定的區塊鏈需要多個確認，並且這種狀況可能不斷持續下去。
第五，算力的逐漸集中導致與去中心化的系統設計基礎的沖突日益明顯。
權益證明機制是一種工作量證明機制的替代方法，試圖解決工作量計算浪費的問題.目前其成功的應用是點點幣區塊鏈系統。
權益證明不要求區塊鏈系統的節點完成一定數量的計算工作，而是要求區塊鏈系統的節點對某些數量的錢展示所有權。
權益證明機制首先應用於點點幣區塊鏈系統中。
點點幣區塊鏈系統的區塊生成時，節點需要構造一個「錢幣權益」交易，即把自己的一些錢幣和預先設定的獎勵發給自己。進行哈希計算時，哈希值的計算只同交易輸入、一些附加的固定數據以及當前時間（是一個表示自1970年1月1日距離當前時刻的秒數的正數）有關。然後，根據類似工作量證明的要求來檢查這個哈希值是否正確。
點點幣區塊鏈系統的權益證明機制除了設定了哈希計算難度與交易輸入的「幣齡」成反比外，其與工作量證明機制非常類似。其中，幣齡的定義為交易輸入大小和它存在時間的乘積。權益證明機制中哈希值只和時間和固定的數據有關，因而沒有辦法通過多完成工作來快速獲取它。
每個點點幣區塊鏈系統的交易的輸出都有一定的幾率來產生有效的正比於幣齡和交易貨幣數量的工作。
第一，縮短了共識達成的時間。
第二，不再需要大量消耗能源。
第一，還是需要哈希計算。
第二，所有的確認都只是一個概率上的表達，而不是一個確定性的事情，有可能受到其他攻擊影響。
授權股份證明機制類似於權益證明機制，是比特股BitShares採用的區塊鏈公識演算法。授權股份證明機制是民主選舉和輪流執政相結合方式來確定區塊的產生。
授權股份證明機制是先由節點選舉若干代理人，由代理人驗證和記賬。其他方面和權益證明機制相似。
每個節點按其持股比例擁有相應的影響力，51%節點投票的結果將是不可逆且有約束力的。為達到及時而高效的方法達到51%批準的目標。每個節點可以將其投票權授予一名節點。獲票數最多的前100位節點按既定時間表輪流產生區塊。每名節點分配到一個時間段來生產區塊。
所有的節點將收到等同於一個平均水平的區塊所含交易費的10%作為報酬。
第一，大幅縮小參與驗證和記賬節點的數量，
第二，可以快速實現共識驗證。
主要缺點就是仍然無法擺脫對代幣的依賴。
在分布式計算上，不同的計算機透過訊息交換，嘗試達成共識；但有時候，系統上協調計算或成員計算機可能因系統錯誤並交換錯的訊息，導致影響最終的系統一致性。
拜占庭將軍問題就根據錯誤計算機的數量，尋找可能的解決辦法，這無法找到一個絕對的答案，但只可以用來驗證一個機制的有效程度。
而拜占庭問題的可能解決方法為：
在 N ≥ 3F + 1 的情況下一致性是可能解決。其中，N為計算機總數，F為有問題計算機總數。信息在計算機間互相交換後，各計算機列出所有得到的信息，以大多數的結果作為解決辦法。
第一，系統運轉可以擺脫對代幣的依賴，共識各節點由業務的參與方或者監管方組成，安全性與穩定性由業務相關方保證。
第二，共識的時延大約在2到5秒鍾。
第三，共識效率高，可滿足高頻交易量的需求。
第一，當有1/3或以上記賬人停止工作後，系統將無法提供服務；
第二，當有1/3或以上記賬人聯合作惡，可能系統會出現會留下密碼學證據的分叉。
小蟻改良了實用拜占庭容錯機制。該機制是由權益來選出記賬人，然後記賬人之間通過拜占庭容錯演算法來達成共識。
此演算法在PBFT基礎上進行了以下改進：
第一，將C/S架構的請求響應模式，改進為適合P2P網路的對等節點模式；
第二，將靜態的共識參與節點改進為可動態進入、退出的動態共識參與節點；
第三，為共識參與節點的產生設計了一套基於持有權益比例的投票機制，通過投票決定共識參與節點（記賬節點）；
第四，在區塊鏈中引入數字證書，解決了投票中對記賬節點真實身份的認證問題。
第一，專業化的記賬人；
第二，可以容忍任何類型的錯誤；
第三，記賬由多人協同完成，每一個區塊都有最終性，不會分產生區塊鏈分叉；
第四，演算法的可靠性有嚴格的數學證明來保證；
第一，當有1/3或以上記賬人停止工作後，區塊鏈系統將無法提供服務；
第二，當有1/3或以上記賬人聯合作惡，且其它所有的記賬人被恰好分割為兩個網路孤島時，惡意記賬人可以使區塊鏈系統出現分叉，但是會留下密碼學證據；
瑞波共識機制是全體節點選取出特殊節點組成特殊節點列表，由特殊節點列表內的節點達成共識。
初始特殊節點列表就像一個俱樂部，要接納一個新成員，必須由51%的該俱樂部會員投票通過。共識遵循這核心成員的51%權力，外部人員則沒有影響力。波共識機制將股東們與其投票權隔開，並因此比其他系統更中心化。
瑞波共識機制參與共識形成的只有特殊節點，大大的減少了共識形成的時間。在實踐中，瑞波區塊鏈系統達成共識需要3-6秒鍾，遠遠快於比特幣區塊鏈系統的10分鍾。同時瑞波區塊鏈系統對並發交易的處理達到每秒數萬筆，而比特幣區塊鏈系統只有每秒7筆。
瑞波共識機制處理節點意見分歧的方式也是不同的。瑞波的信任節點對於新區塊的創造進行協商的時間是區塊鏈更新前。先協商，達成共識後再對區塊鏈進行更新。
由於瑞波共識機制的共識是由特殊節點達成的，普通節點並不需要維護一個完整的歷史賬本。各個節點可以根據自己的業務需要選擇同步同步完整的歷史賬本或者任意最近幾步的賬本。這也意味著對存儲空間和網路流量需求的減少。
瑞波共識機製取消了挖坑的發行貨幣機制，採用了原生貨幣（1000億枚）的方式發幣，從而大量的避免了挖礦的天量能耗。
『肆』 區塊鏈技術的六大核心演算法
區塊鏈技術的六大核心演算法
區塊鏈核心演算法一：拜占庭協定
拜占庭的故事大概是這么說的：拜占庭帝國擁有巨大的財富，周圍10個鄰邦垂誕已久，但拜占庭高牆聳立，固若金湯，沒有一個單獨的鄰邦能夠成功入侵。任何單個鄰邦入侵的都會失敗，同時也有可能自身被其他9個鄰邦入侵。拜占庭帝國防禦能力如此之強，至少要有十個鄰邦中的一半以上同時進攻，才有可能攻破。然而，如果其中的一個或者幾個鄰邦本身答應好一起進攻，但實際過程出現背叛，那麼入侵者可能都會被殲滅。於是每一方都小心行事，不敢輕易相信鄰國。這就是拜占庭將軍問題。
在這個分布式網路里：每個將軍都有一份實時與其他將軍同步的消息賬本。賬本里有每個將軍的簽名都是可以驗證身份的。如果有哪些消息不一致，可以知道消息不一致的是哪些將軍。盡管有消息不一致的，只要超過半數同意進攻，少數服從多數，共識達成。
由此，在一個分布式的系統中，盡管有壞人，壞人可以做任意事情(不受protocol限制)，比如不響應、發送錯誤信息、對不同節點發送不同決定、不同錯誤節點聯合起來干壞事等等。但是，只要大多數人是好人，就完全有可能去中心化地實現共識
區塊鏈核心演算法二：非對稱加密技術
在上述拜占庭協定中，如果10個將軍中的幾個同時發起消息，勢必會造成系統的混亂，造成各說各的攻擊時間方案，行動難以一致。誰都可以發起進攻的信息，但由誰來發出呢?其實這只要加入一個成本就可以了，即：一段時間內只有一個節點可以傳播信息。當某個節點發出統一進攻的消息後，各個節點收到發起者的消息必須簽名蓋章，確認各自的身份。
在如今看來，非對稱加密技術完全可以解決這個簽名問題。非對稱加密演算法的加密和解密使用不同的兩個密鑰.這兩個密鑰就是我們經常聽到的」公鑰」和」私鑰」。公鑰和私鑰一般成對出現, 如果消息使用公鑰加密,那麼需要該公鑰對應的私鑰才能解密; 同樣，如果消息使用私鑰加密,那麼需要該私鑰對應的公鑰才能解密。
區塊鏈核心演算法三：容錯問題
我們假設在此網路中，消息可能會丟失、損壞、延遲、重復發送，並且接受的順序與發送的順序不一致。此外，節點的行為可以是任意的：可以隨時加入、退出網路，可以丟棄消息、偽造消息、停止工作等，還可能發生各種人為或非人為的故障。我們的演算法對由共識節點組成的共識系統，提供的容錯能力，這種容錯能力同時包含安全性和可用性，並適用於任何網路環境。
區塊鏈核心演算法四：Paxos 演算法(一致性演算法)
Paxos演算法解決的問題是一個分布式系統如何就某個值(決議)達成一致。一個典型的場景是，在一個分布式資料庫系統中，如果各節點的初始狀態一致，每個節點都執行相同的操作序列，那麼他們最後能得到一個一致的狀態。為保證每個節點執行相同的命令序列，需要在每一條指令上執行一個「一致性演算法」以保證每個節點看到的指令一致。一個通用的一致性演算法可以應用在許多場景中，是分布式計算中的重要問題。節點通信存在兩種模型：共享內存和消息傳遞。Paxos演算法就是一種基於消息傳遞模型的一致性演算法。
區塊鏈核心演算法五：共識機制
區塊鏈共識演算法主要是工作量證明和權益證明。拿比特幣來說，其實從技術角度來看可以把PoW看做重復使用的Hashcash，生成工作量證明在概率上來說是一個隨機的過程。開采新的機密貨幣，生成區塊時，必須得到所有參與者的同意，那礦工必須得到區塊中所有數據的PoW工作證明。與此同時礦工還要時時觀察調整這項工作的難度，因為對網路要求是平均每10分鍾生成一個區塊。
區塊鏈核心演算法六：分布式存儲
分布式存儲是一種數據存儲技術，通過網路使用每台機器上的磁碟空間，並將這些分散的存儲資源構成一個虛擬的存儲設備，數據分散的存儲在網路中的各個角落。所以，分布式存儲技術並不是每台電腦都存放完整的數據，而是把數據切割後存放在不同的電腦里。就像存放100個雞蛋，不是放在同一個籃子里，而是分開放在不同的地方，加起來的總和是100個。
『伍』 拜占庭容錯和PBFT共識演算法
實用的拜占庭容錯演算法
BFT 是區塊鏈共識演算法中，需要解決的一個核心問題。比特幣的POW，eos的dpos，以及共識演算法pos，這些公鏈演算法，解決的是共識節點眾多情況下的bft問題。
拜占庭將軍問題。也稱為拜占庭容錯。
用來描述分布式系統一致性問題。
背景如下：
拜占庭帝國想要進攻一個強大的敵人，為此派出了10支軍隊去包圍這個敵人。這個敵人雖不比拜占庭帝國，但也足以抵禦5支常規拜占庭軍隊的同時襲擊。這10支軍隊在分開的包圍狀態下同時攻擊。他們任一支軍隊單獨進攻都毫無勝算，除非有至少6支軍隊（一半以上）同時襲擊才能攻下敵國。他們分散在敵國的四周，依靠通信兵騎馬相互通信來協商進攻意向及進攻時間。困擾這些將軍的問題是，他們不確定他們中是否有叛徒，叛徒可能擅自變更進攻意向或者進攻時間。在這種狀態下，拜占庭將軍們才能保證有多於6支軍隊在同一時間一起發起進攻，從而贏取戰斗？
單從上面的說明可能無法理解這個問題的復雜性，我們來簡單分析一下：
先看在沒有叛徒情況下，假如一個將軍A提一個進攻提議（如：明日下午1點進攻，你願意加入嗎？）由通信兵通信分別告訴其他的將軍，如果幸運中的幸運，他收到了其他6位將軍以上的同意，發起進攻。如果不幸，其他的將軍也在此時發出不同的進攻提議（如：明日下午2點、3點進攻，你願意加入嗎？），由於時間上的差異，不同的將軍收到（並認可）的進攻提議可能是不一樣的，這是可能出現A提議有3個支持者，B提議有4個支持者，C提議有2個支持者等等。
再加一點復雜性，在有叛徒情況下，一個叛徒會向不同的將軍發出不同的進攻提議（通知A明日下午1點進攻， 通知B明日下午2點進攻等等），一個叛徒也會可能同意多個進攻提議（即同意下午1點進攻又同意下午2點進攻）。
叛徒發送前後不一致的進攻提議，被稱為「拜占庭錯誤」，而能夠處理拜占庭錯誤的這種容錯性稱為「Byzantine fault tolerance」，簡稱為BFT。
使用密碼學演算法保證節點之間的消息傳送是不可篡改的， 通過下面的演算法我們可以保證A將軍收到B將軍發來的消息確實是B將軍本人的真實請求 。
我們採用的是哈希函數（散列演算法）SHA256 -- 從數據（byte）值中創建獨一無二的hash值，並壓縮成摘要，將數據格式固定下來。通過這個摘要與個人私鑰生成Digital Signature 和個人公鑰Public-key certificate，接收方驗證簽名和摘要，如果是通過驗證，即證明摘要內容沒有經過篡改。
pbft容忍無效或者惡意節點數量 e 。為了保證整個系統可以正常運作，需要有2f+1個正常節點，系統的總結點數為 ：3f+1。即pbft演算法容忍小於1/3的惡意或者無效節點。 原因見節點作惡的極端情況
pbft是一種狀態機副本復制演算法，所有副本在一個view輪換過程中操作，哪些是主節點（進攻的提議者的大將軍們，輪流當）通過view中其他節點（其他將軍）賦予的編號和節點數集合來確定，即：主節點p=v mod |R| 。 v：view編號，|R|節點個數，p：主節點編號。 關於狀態機復制演算法、view change的意義（主要是防止主節點作惡），主節點詳見論文。
基於拜占庭將軍問題，PBFT演算法一致性的確保主要分為這三個階段：預准備（pre-prepare）、准備(prepare)和確認(commit)。流程如下圖所示：
[圖片上傳失敗...(image-e3329d-1562488133052)]
首先解釋一下上面各個符號表達的意思：
下面結合上圖，詳細說一下PBFT的步驟：
根據上述流程，在 N ≥ 3F + 1 的情況下一致性是可能解決， N為總計算機數，F為有問題的計算機總數 。
下面所有的校驗流程略去對消息內容、簽名和身份的驗證，即已經保證了節點之間消息傳播是不可篡改的
上述演算法中，比較重要的一個點是view change，為了能恢復之前的請求，每一個副本節點收到消息之後或者發送消息的時候都會記錄消息到本地的log記錄中。當執行請求後，副本節點需要把之前該請求的記錄消息清除掉。最簡單的做法是在reply消息後，在執行一次當前狀態的共識同步，但是為了節省資源，一般在多條請求K後執行一次狀態同步。這個狀態同步就是checkpoint消息。
為了節省內存，系統需要一種將日誌中的 無異議消息記錄 刪除的機制。為了保證系統的安全性，副本節點在刪除自己的消息日誌前，需要確保至少 f+1 個正常副本節點執行了消息對應的請求，並且可以在視圖變更時向其他副本節點證明。另外，如果一些副本節點錯過部分消息，但是這些消息已經被所有正常副本節點刪除了，這就需要通過 傳輸部分或者全部服務狀態實現該副本節點的同步 。因此，副本節點同樣需要證明狀態的正確性。
在每一個操作執行後都生成這樣的證明是非常消耗資源的。因此，證明過程只有在請求序號可以被某個常數（比如100）整除的時候才會周期性地進行。我們將這些請求執行後得到的狀態稱作 檢查點（checkpoint） ，並且將具有證明的檢查點稱作 穩定檢查點（stable checkpoint） 。
上述情況是理想情況，實際上當副本節點i向其他節點發出checkpoint消息之後，其他節點還沒有完成K條請求的相互共識，所以不會立即對i的請求作出響應。其他節點會按照自己的處理步驟和順序，向前行進和共識。但是此時i發出的checkpoint沒有形成stable，為了防止i太快，超過自己太多，於是被便會設置一個高水位H=h+L，其中L就是我們指定允許的高度差，等於checkpoint周期處理數K的整數倍，可以設置為L=2K。當副本節點i處理請求超過高水位H時，副本節點即使接受到請求也會視為非法請求。等待stable checkpoint發生變化，再繼續向前推進處理。
如果主節點作惡，它可能會給不同的請求編上相同的序號，或者不去分配序號，或者讓相鄰請求的序號不連續。備份節點（備份主節點）應當有職責來主動檢查這些序號的合法性。如果主節點掉線或者作惡不廣播客戶端的請求，客戶端設置超時機制，超時的話，向所有副本節點廣播請求消息。副本節點檢測出主節點或者下線，發起view change流程。
我們在上面講到，當網路中有F台有問題的計算機時，至少需要3F+1台計算機才能保證一致性問題的解決，我們在這里討論一下原因。
我們可以考慮：由於有F個節點為故障或被攻擊的節點，故我們只能從N-F個節點中進行判斷。但是由於非同步傳輸，故當收到N-F個消息後，並不能確定後面是否有新的消息。（有可能是目前收到的N-F個節點的消息中存在被攻擊的節點發來的消息，而好的節點的消息由於非同步傳輸還沒有被收到。）
我們考慮最壞的情況，即剩下F個都是好的節點，收到的中有F個被攻擊的節點，故我們需要使得收到的中好節點的數量 (N-F)-F 大於被攻擊節點的數量 F ，於是有 N-2F>F ，即 N>3F ，所以N的最小整數為 N=3F+1 。
pbft是需要參與認證的節點進行的。所以一個完整的共識演算法包括DPOS+PBFT。其速度是可以達到1500tps左右的。
參考文獻：
https://mathpretty.com/9602.html
https://blog.csdn.net/jfkidear/article/details/81275974
Practical Byzantine Fault Tolerance
Miguel Castro and Barbara Liskov Laboratory for Computer Science, Massachusetts Institute of Technology, 545 Technology Square, Cambridge, MA 02139 castro,liskov @lcs .mit.e
https://www.jianshu.com/p/fb5edf031afd 部分論文翻譯
『陸』 《幣圈筆記》第377期：拜占庭問題
19年06月06日，祝六六大順。
我們以前常看到以太坊拜占庭分叉，這個拜占庭又是什麼意思呢？
拜占庭位於如今的土耳其的伊斯坦布爾，是東羅馬帝國的首都。
由於當時拜占庭羅馬帝國國土遼闊，為了達到防禦目的，每個軍隊都離得很遠，將軍與將軍之間只能靠信差傳消息。在戰爭期間，拜占庭軍隊內所有將軍必須達成一致共識，全體都決定認同有贏的機會才能去攻打敵人的陣營。
但是，在軍隊內有可能存有叛徒和敵軍的間諜，他們可能影響將軍們的決定、甚至某個將軍自己就是叛徒。那麼，在已知有成員謀反的情況下，其餘忠誠的將軍如何在不受叛徒的影響下達成一致的協議，拜占庭問題就此形成。
對區塊鏈有認識的讀者們可以看出來，拜占庭將軍問題其實是一個協議問題：由於叛徒可以任意行動以達到以下目標：欺騙某些將軍採取進攻行動；促成一個不是所有將軍都同意的決定；或迷惑某些將軍，使他們無法做出決定。如果叛徒達到了這些目的之一，則任何攻擊行動的結果都是註定要失敗的。
所謂拜占庭失效指一方向另一方發送消息，另一方沒有收到，或者收到了錯誤的信息的情形。
這些錯誤被統稱為「崩潰失效」和「發送與遺漏式失效」。當拜占庭失效發生時，系統可能會做出任何不可預料的反應！
以太坊以前那個拜占庭硬分叉，為什麼叫拜占庭？筆者認為該階段旨在用技術演算法解決歷史上的難題，以便區塊鏈網路在受到干擾的情況下依然能夠達成共識。人家說藝術來源於生活，那麼這一靈感來源於真實歷史事件，讀史使人明智。
『柒』 區塊鏈技術開發到底是什麼原理
狹義來講，區塊鏈是一種按照時間順序將數據區塊以順序相連的方式組合成的一種鏈式數據結構， 並以密碼學方式保證的不可篡改和不可偽造的分布式賬本。
廣義來講，區塊鏈技術是利用塊鏈式數據結構來驗證與存儲數據、利用分布式節點共識演算法來生成和更新數據、利用密碼學的方式保證數據傳輸和訪問的安全、利用由自動化腳本代碼組成的智能合約來編程和操作數據的一種全新的分布式基礎架構與計算方式。
工作原理
區塊鏈系統由數據層、網路層、共識層、激勵層、合約層和應用層組成。 其中，數據層封裝了底層數據區塊以及相關的數據加密和時間戳等基礎數據和基本演算法;網路層則包括分布式組網機制、數據傳播機制和數據驗證機制等;共識層主要封裝網路節點的各類共識演算法;激勵層將經濟因素集成到區塊鏈技術體系中來，主要包括經濟激勵的發行機制和分配機制等;合約層主要封裝各類腳本、演算法和智能合約，是區塊鏈可編程特性的基礎;應用層則封裝了區塊鏈的各種應用場景和案例。該模型中，基於時間戳的鏈式區塊結構、分布式節點的共識機制、基於共識算力的經濟激勵和靈活可編程的智能合約是區塊鏈技術最具代表性的創新點。
『捌』 如何理解拜占庭將軍問題
拜占庭將軍問題（以下簡稱「共識問題」）的正式表述是：如何在一個不基於信任的分布式網路中就信息達成共識？這個表述聽起來有些晦澀，但其本質並不復雜，下面的例子與共識問題雖然並不完全一致，但卻有助於我們的理解[9]。 想像一下在遙遠的拜占庭時代，有一個富饒的城邦，金銀珠寶綾羅綢緞應有盡有，它的領主哆啦A夢獨享著這一切奢華與榮耀。而在城邦的外圍，四位拜占庭將軍大雄、胖虎、小夫和靜香都覬覦著哆啦A夢的財富，於是他們決定聯手攻佔哆啦A夢的城邦。根據雙方的實力對比，必須有超過半數的將軍同時發起進攻方能克敵制勝，因此獲勝條件就是四人中至少三個人可以就進攻時間達成一致。那麼四位將軍的勝算有多少呢？ 這個問題的答案就要取決於四個人的合作方式了，如果是集中式系統，有一個盟主，比如胖虎（相當於中央伺服器），那麼他們的勝利是毫無懸念的，因為就進攻時間達成一致非常簡單，只要胖虎召集大雄、小夫和靜香開個會討論一下就可以了，即使大家意見有分歧胖虎也可以在最後予以定奪。下面讓我們回到拜占庭將軍問題的假設里，在不基於信任的分布式網路中，四位將軍的勝算又如何呢？ ? 首先由於四位將軍之間缺乏信任，因此聚到小黑屋裡開個密謀會的可能性被排除了（一旦在小黑屋裡被胖虎綁架了怎麼辦？）；其次由於沒有盟主，四個人的意見都會被同等的看重。在這種情況下，四位將軍只能通過信使在各自營地之間傳遞消息，來商定進攻時間了。比如大雄覺得早上6點是發動進攻的好時機，他就會派信使將自己的意見告訴胖虎、小夫和靜香，與此同時，胖虎可能認為晚上9點發動突襲更好，小夫更喜歡下午3點出擊，而靜香希望是上午10點，他們三人也會在同一時間派出自己的信使。這樣一來，在第一輪通信結束後，四位將軍每個人都有了四個可供選擇的進攻時間，他們各自要在下一輪通信中把自己選定的時間告知另外三人。由於四個人的決策都是獨立做出的，因此最終的選擇結果就有256種可能，而只有當三人以上都恰好選擇了同一時間的時候，共識才被達成，而這樣的結果才64種，也就是說達成共識的概率僅為1/4。這還只是四位將軍的情況，如果將軍的人數是10人，100人，1000人呢？我們稍加計算就可以發現隨著人數的增加，達成共識的希望會變得越來越渺茫。 把上面例子中的將軍換成計算機網路中的節點，把信使換成節點之間的通信，把進攻時間換成需要達成共識的信息，你就可以理解共識問題所描述的困境了。達成共識的能力對於一個支付系統來說重要性不言而喻，如果你給家裡匯了一筆錢買車，第二天去銀行核實的時候櫃台告訴你「關於你匯了多少錢的問題，我們的系統里有三個版本的記錄」，這樣的銀行你顯然是不敢把錢存進去的。在比特幣出現之前共識問題是很難被完美解決的，要保證達成共識就需要採用集中式系統（除非節點滿足特定條件），要想去中心化共識就無法保證。那麼區塊鏈技術又是如何解決這一難題的呢？
『玖』 拜占庭將軍很忙—《區塊鏈思維》第21塊
無論在鏈圈，還是在幣圈混，經常聽到一個名詞「拜占庭將軍問題」。
到底拜占庭是啥，拜占庭將軍怎麼啦，到處都被提及，這位將軍好忙啊！
先說拜占庭這個地方。很久很久以前的歐洲，建立在比中世紀還古老的時期，歷史上就是東羅馬帝國，跨越了千年的歷史期盼。
扯遠了，回到正題，什麼是拜占庭將軍問題。
拜占庭這個地方異常堅固，同時被十個獨立鄰邦環伺，分別有一位將軍，單獨攻城必敗，只有一半以上的將軍同時攻打才能破城。
十位將軍為了協調一致，在那個古老的時代，累死傳令兵，要麼飛鴿傳書（那時的歐洲比中國落後，好像沒有這個高速通信手段）。十位將軍相互通信一次就需要90次傳信，每位將軍都有各自的攻城計劃，要想達成統一就需要往復傳遞不知道多少次。
我們可以假設一個場景，一個桌子上坐著十位將軍，每個人各自說著自己的想法，同時聽其他九位的說法，但是信息的傳遞不是實時的，有快有慢，有早有晚。想明白了嗎？也就是說，這十位將軍如果想達成一致，理論上有可能，實際上他們的有生之年都實現不了，難怪拜占庭帝國經歷了千年也沒有被這十位將軍攻破。
中本聰這個神人，利用互聯網信息傳遞的及時性特點，引入時間戳可以明確知道「誰先說、誰後說」的特性，創造性地加入挖礦機制（就是用計算機算隨機數滿足一定難度才算成功）比拼各位將軍的智商來決定誰做本次進攻的統帥，使用非對稱加密保證信息傳輸的安全性等等手段融合到比特幣中，用實例說明自己破解了這個歷史難題「拜占庭將軍問題」。從而向世人證明解決60億人口的互信問題是有去中心化解決方案地。
幣圈和鏈圈的朋友很焦慮的另一個關鍵問題就是：這個圈子概念太TM多。除了這個「拜占庭將軍問題」，還有一個「拜占庭容錯」，這是什麼鬼？這兩個是一樣的嗎？這兩個是故意有一個被寫錯了嗎？還是說我的智商稅沒交夠？其實，你都說對了。
「拜占庭將軍問題」假設所有十個將軍都是好的，都想攻破拜占庭，只是達成共識很難，比特幣提供了好人達成共識的方案。
「拜占庭容錯」是說十個將軍可以很好地達成共識。但是，如果其中出了壞人，怎麼解決？
如果十個將軍中出現了壞人（叫叛徒也行），進攻計劃是否會永遠無法達成共識呢？
「拜占庭容錯」告訴大家，是可以達成地，並且，還能找出這些「叛徒」是誰。只是，10個將軍中叛徒的數量不能超過3個，超出了就無法「容錯」，也找不出這些叛徒是誰。對應的公式就是：3n+1。其中3n+1是將軍總數（區塊鏈的賬本/礦機總數），n是能夠「容錯」的「叛徒」（惡意記錯賬）總數。
對於十個將軍來說，最多容忍三個叛徒，多了就徹底沒戲啦。為了比特幣的容錯能力越來越強，就需要更多的節點，這樣才能容忍並找出更多的叛徒。懂了吧。
小結一下：拜占庭將軍問題是假設都是好人前提下如何達成共識，拜占庭容錯就是全網最多能夠容忍多少叛徒並且能找出他們。
請交智商稅到如下地址：
國稅BTC到Kcash：
地稅ETH及各種原生Token到 Imtoken：
不交稅的，祝你做「韭菜」一切順利 :D
『拾』 拜占庭問題
拜占庭帝國即中世紀的土耳其，擁有巨大的財富，周圍10個鄰邦垂誕已久，但拜占庭高牆聳立，固若金湯，沒有一個單獨的鄰邦能夠成功入侵。任何單個鄰邦入侵的都會失敗，同時也有可能自身被其他9個鄰邦入侵。拜占庭帝國防禦能力如此之強，至少要有十個鄰邦中的一半以上同時進攻，才有可能攻破。
然而，如果其中的一個或者幾個鄰邦本身答應好一起進攻，但實際過程出現背叛，那麼入侵者可能都會被殲滅。
於是每一方都小心行事，不敢輕易相信鄰國。這就是拜占庭將軍問題。
在拜占庭問題中，最重要的point就是： 所有將軍如何達成一致攻打拜占庭的共識 ，這當中，可能出現的情況舉例如下：
用一個模型解釋一下：
假設只有3個人，A、B、C，三人中如果其中一個是叛徒。當A發出進攻命令時，B如果是叛徒，他可能告訴C，他收到的是「撤退」的命令。這時C收到一個「進攻」，一個「撤退「，於是C被信息迷惑，而無所適從。
如果A是叛徒。他告訴B「進攻」，告訴C「撤退」。當C告訴B，他收到「撤退」命令時，B由於收到了司令「進攻」的命令，而無法與C保持一致。
正由於上述原因，在只有三個角色的系統中，只要有一個是叛徒，即叛徒數等於1/3，拜占庭問題便不可解。
可以看得出， 只要叛徒的數量大於或等於1/3，拜占庭問題不可解
從技術上理解， 拜占庭將軍問題是分布式系統容錯性問題 。加密貨幣建立在P2P網路之上，是典型的分布式系統，類比一下， 將軍就是P2P網路中的節點，信使就是節點之間的通信，進攻還是撤退的決定就是需要達成的共識 。 如果某台獨立的節點計算機拓機、掉線或攻擊網路搞破壞，整個系統就要停止運行，那這樣的系統將非常脆弱，所以容許部分節點出錯或搞破壞而不影響整個系統運行是必要的 ， 這就需要演算法理論上的支撐，保證分布式系統在一定量的錯誤節點存在的情況下，仍然保持一致性和可用性 。
而且，拜占庭將軍與兩軍問題不同，前者假定信差沒有問題，只是將軍出現了叛變等問題；後者研究信差的通信問題。
終極解決方案到了——
如果 10個將軍中的幾個同時發起消息，勢必會造成系統的混亂，造成各說各的攻擊時間方案，行動難以一致 。
誰都可以發起進攻的信息，但由誰來發出呢？中本聰巧妙地在個系統加入了 發送信息的成本 ，即：
它加入的 成本就是」工作量「 —— 節點必須完成一個計算工作才能向各城邦傳播消息 ，當然，誰第一個完成工作，誰才能傳播消息。（這也是 工作量證明機制的意義：以檢驗結果的方式證明你過去所做過了多少工作 ）
這種加密技術——非對稱加密，完全可以解決古代難以解決的簽名問題：
中本聰在設計比特幣時，它採用了一種工作量證明機制叫哈希現金，在一個交易塊這要找到一個隨機數，計算機只能用窮舉法來找到這個隨機數，可以說，能不能找到全靠運氣，所以對於各個節點來說，這個世界上，只有隨機才是真正的公平，實現隨機的最好辦法是使用數學，所有的將軍在尋找共識的過程，藉助了大家都認可的數學邏輯。
當然了， 憑什麼要義務進行計算工作，那麼肯定要有一個激勵機制 ：比特幣的獎勵機制是每打包一個塊，目前是獎勵25個比特幣，而拜占庭將軍問題的獎勵機制可以是瓜分拜占庭獲得的利益。
在這個分布式網路里：
每個將軍都有一份實時與其他將軍同步的消息賬本 。
賬本里有每個將軍的簽名都是可以驗證身份的。 如果有哪些消息不一致，可以知道消息不一致的是哪些將軍 。
盡管有消息不一致的，只要超過半數同意進攻，少數服從多數，共識達成（只要大多數是好人，那麼就可以實現共識）。
區塊鏈上的共識機制主要解決 由誰來構造區塊 ，以及 如何維護區塊鏈統一 的問題。
拜占庭容錯問題需要解決的也同樣是 誰來發起信息 ，如何 實現信息的統一同步 的問題。
註：區塊鏈學習新人，若有不正確的地方，望指出