paxosraft區塊鏈

① 共識演算法4 (BFT)

拜占庭將軍問題（Byzantine Generals Problem），由Leslie Lamport、Robert Shostak和Marshall Pease，在其同名論文中提出（1982年）。拜占庭將軍問題現在主要指分布式對等網路節點間的通信容錯問題。在分布式網路中，不同的計節點通過交換信息達成共識。但有時候，系統中的成員節點可能出錯而發送錯誤的信息，用於傳遞信息的通訊網路也可能導致信息損壞，也可能存在惡意節點或被黑客攻破的節點故意發送錯誤的信息，從而導致系統無法達成共識或者達成錯誤的共識。（參考： BFT Wikipedia ）

拜占庭將軍問題提出後，有很多的演算法被提出用於解決這個問題。這類演算法統稱拜占庭容錯演算法（BFT: Byzantine Fault Tolerance）。BFT從上世紀80年代開始被研究，目前已經是一個被研究得比較透徹的理論，具體實現都已經有現成的演算法。

BFT演算法中最典型的是PBFT（Practical BFT）。PBFT是由Miguel Castro和Barbara Liskov於1999年提出。PBFT演算法解決了之前拜占庭容錯演算法效率不高的問題，將演算法復雜度由指數級降低到多項式級，使得拜占庭容錯演算法在實際系統應用中變得可行。PBFT在保證安全性和可用性的前提下，提供了 (n-1)/3 的容錯性。（細節請參考： PBFT ）

PBFT之後，很多進一步提升性能或魯棒性的BFT演算法先後被提出，例如Zyzzyva、ABsTRACTs、Aardvark、RBFT等等。近幾年，由於區塊鏈的熱度，無數針對區塊鏈應用場景優化過的BFT演算法也不斷涌現出來。雖然目前PBFT已經不能說是最好的，或最適合區塊鏈的BFT演算法。但是PBFT已經足夠好了，而且在實際應用中已經非常成熟。

在BFT共識機制中，網路中節點的數量和身份必須是提前確定好的。BFT共識機制無法做到PoW共識機制中實現的任何人都可以隨時加入挖礦。另外，BFT演算法無法應用到大量的節點，業內普遍認為100個節點是BFT演算法的上限。所以BFT演算法無法直接用於公有鏈，BFT演算法適合的場景是私有鏈和聯盟鏈。業內大名鼎鼎的聯盟鏈Hyperledger fabric v0.6採用的是PBFT，v1.0又推出PBFT的改進版本SBFT。這里再順便提一句，在可信環境下共識演算法一般使用傳統的分布式一致演算法PAXOS或者RAFT。

公有鏈使用BFT的一個例外是NEO，NEO使用了DBFT（delegated BFT）共識機制。DBFT共識機制下投票選出7個共識節點。這些代理節點是通過靜態選出的，並完全由項目方部署。這也是NEO被外界質疑過於中心化的原因。（參考： 早期公有鏈明星項目-NEO ）

BFT演算法和公有鏈合適的結合點在於基於BFT的PoS共識演算法（BFT based PoS）。基於BFT的PoS共識演算法要點有：一，網路節點通過鎖定虛擬資產申請成為區塊鏈系統的驗證者（或礦工）。系統驗證者的數量是動態變化的。二，系統從當前驗證者中隨機選擇一個人作為區塊提案人。三，系統驗證者對區塊提案進行投票表決，投票可能要進行多輪才能達成共識。每個人的投票比重與鎖定的虛擬資產成比例。

基於BFT的PoS的典型例子是tendermint（Cosmos採用了tendermint作為共識核心）。

② 昆明電腦培訓分享分布式與區塊鏈之間的關系分析

關於區塊鏈技術的探討我們在前幾期的文章中已經說過很多次了，而且也給大家介紹了使用哪些編程開發語言來實現對區塊鏈技術的具現化，今天我們就一起來了解一下，如何從分布式的角度來分析理解區塊鏈的構造。

區塊鏈是源於比特幣中的底層技術，用於實現一個無中心的點對點現金系統，因為沒有中心機構的參與，比特幣以區塊鏈的形式來組織交易數據，防止「雙花」，達成交易共識。

傳統意義上的數字資產，比如游戲幣，是以集中式的方式管理的，僅能在單個系統中流轉，由某個中心化機構負責協調，通常以資料庫的方式來存儲。宏觀上看，區塊鏈和資料庫一樣，都是用來保存數據，只是數據存取的形式有所不同。

區塊鏈本質上是一個異地多活的分布式資料庫。異地多活的提出，原本是為了在解決系統的容災問題，多年來也一直是分布式資料庫領域在探索的方向，但鮮有成效，因為異地多活需要解決數據沖突的問題，這個問題其實不好解決。然而誕生於比特幣的區塊鏈以一種全新的方式實現了全球大的異地多活資料庫，它完全開放，沒有邊界，支持上萬節點並可隨機的加入和退出。

在區塊鏈中數據沖突問題就更加突出了，區塊鏈里每個節點是完全對等的多活架構，上萬個節點要達成一致，數據以誰為准呢?比特幣採用的方式是POW，大家來算一個謎題，誰先算出來，就擁有記賬權，在這個周期，就以他所記的賬為准，下一個周期大家重新計算。爭奪記賬權的節點決定將哪些交易打包進區塊，並將區塊同步給其他節點，其他節點仍然需要基於本地數據對區塊中的交易做驗證，並不像資料庫的主從節點間那樣無條件接受，這就是區塊鏈里的共識演算法。POW雖然消耗大量算力，好處是在爭奪記賬權的過程中POW只要在自身節點中計算hash，不需要經過網路投票來選舉，網路通信的代價小，適合大規模節點之間共識。昆明電腦培訓http://www.kmbdqn.com/認為POW是目前公有鏈里完備簡單粗暴做法，經得起考驗，但問題是效率太低。

所以後面發展出了PoS、DPoS，誰擁有資產多，誰就擁有記賬權，或者大家投票，但這樣又引入了經濟學方面的問題，比如所謂的賄選的問題，這就不太好控制了。在傳統分布式資料庫里，不叫共識演算法，而叫一致性演算法，本質上也是一回事。但分布式資料庫里一般節點數都很少，而且網路是可信的，通常節點都是安全可靠的，我們基本上可以相信每一個節點，即使它出現故障，不給應答，但絕對不會給出假應答。所以在傳統公司分布式數據里，都用Raft或Paxos協議去做這種一致性演算法。

③ OceanBase的一致性協議為什麼選擇 paxos而不是raft

基於Raft的分布式一致性協議實現的局限及其對資料庫的風險普通伺服器具有良好的性價比，因此在互聯網等行業得到了廣泛的應用。但普通伺服器也不得不面對2%-4%的年故障率([1])，於是必須高可用的傳統資料庫只得很悲催地使用性價比低得可憐的高可靠伺服器。分布式一致性協議（distributed consensus protocol）是迄今為止最有效的解決伺服器不可靠問題的途徑，因為它使得一組伺服器形成一個相互協同的系統，從而當其中部分伺服器故障後，整個系統也能夠繼續工作。而Paxos協議([2])則幾乎成了分布式一致性協議的代名詞。然而，Paxos協議的難以理解的名聲似乎跟它本身一樣出名。為此，Stanford大學的博士生Diego Ongaro甚至把對Paxos協議的研究作為了博士課題。他在2014年秋天正式發表了博士論文：「CONSENSUS: BRIDGING THEORY AND PRACTICE」，在這篇博士論文中，他給出了分布式一致性協議的一個實現演算法，即Raft。由於這篇博士論文很長（257頁），可能是為了便於別人閱讀和理解，他在博士論文正式發表之前，即2014年初，把Raft相關的部分摘了出來，形成了一篇十多頁的文章：「In Search of an Understandable Consensus Algorithm」，即人們俗稱的Raft論文。Raft演算法給出了分布式一致性協議的一個比較簡單的實現，到目前為止並沒有人挑戰這個演算法的正確性。然而，OceanBase卻沒有採用Raft演算法，這並非是OceanBase團隊同學不懂Raft，而是Raft的一個根本性的局限對資料庫的事務有很大的風險。Raft有一個很強的假設是主（leader）和備（follower）都按順序投票，為了便於闡述，以資料庫事務為例：·主庫按事務順序發送事務日誌·備庫按事務順序持久化事務和應答主庫

④ raft演算法與paxos演算法相比有什麼優勢，使用場景有什麼差異

Paxos演算法解決的問題是一個分布式系統如何就某個值（決議）達成一致。一個典型的場景是，在一個分布式資料庫系統中，如果各節點的初始狀態一致，每個節點都執行相同的操作序列，那麼他們最後能得到一個一致的狀態。為保證每個節點執行相同的命令序列，需要在每一條指令上執行一個「一致性演算法」以保證每個節點看到的指令一致。一個通用的一致性演算法可以應用在許多場景中，是分布式計算中的重要問題。因此從20世紀80年代起對於一致性演算法的研究就沒有停止過。節點通信存在兩種模型：共享內存（Sharedmemory）和消息傳遞（Messagespassing）。Paxos演算法就是一種基於消息傳遞模型的一致性演算法。不僅只用在分布式系統，凡是多個過程需要達成某種一致性的都可以用到Paxos演算法。一致性方法可以通過共享內存（需要鎖）或者消息傳遞實現，Paxos演算法採用的是後者。下面是Paxos演算法適用的幾種情況：一台機器中多個進程/線程達成數據一致；分布式文件系統或者分布式資料庫中多客戶端並發讀寫數據；分布式存儲中多個副本響應讀寫請求的一致性。Lamport最初Paxos演算法的論文ThePart-TimeParliament在理解起來比較有挑戰性，個人認為部分原因是Lamport通過故事的方式來表述、解釋這個問題，所以在閱讀文章的時候讀者需要透過故事講的本身看到作者想說明什麼。比如文章中會有很多講到Paxos文明沒有被發現和考證的，這些映射到實際系統中往往是簡單、大家都心知肚明的基礎，但如果讀者苦於想知道這些內容是什麼時，就上當了。下面章節安排如下：第二節對應原文的1.1-2.1。第三節對應原文2.2-3.2。

⑤ 共識演算法系列之一：私鏈的raft演算法和聯盟鏈的 pbft 演算法

對數據順序達成一致共識是很多共識演算法要解決的本質問題
Fabic的pbft演算法實現
現階段的共識演算法主要可以分成三大類：公鏈，聯盟鏈和私鏈
私鏈，所有節點可信
聯盟鏈，存在對等的不信任節點
私鏈：私鏈的共識演算法即區塊鏈這個概念還沒普及時的傳統分布式系統里的共識演算法，比如 zookeeper 的 zab 協議，就是類 paxos 演算法的一種。私鏈的適用環境一般是不考慮集群中存在作惡節點，只考慮因為系統或者網路原因導致的故障節點。

聯盟鏈：聯盟鏈中，經典的代表項目是 Hyperledger 組織下的 Fabric 項目， Fabric0.6 版本使用的就是 pbft 演算法。聯盟鏈的適用環境除了需要考慮集群中存在故障節點，還需要考慮集群中存在作惡節點。對於聯盟鏈，每個新加入的節點都是需要驗證和審核的。

公鏈：公鏈不僅需要考慮網路中存在故障節點，還需要考慮作惡節點，這一點和聯盟鏈是類似的。和聯盟鏈最大的區別就是，公鏈中的節點可以很自由的加入或者退出，不需要嚴格的驗證和審核。

在公有鏈中用的最多的是pow演算法和pos演算法，這些演算法都是參與者的利益直接相關，通過利益來制約節點誠實的工作，解決分布式系統中的拜占庭問題。拜占庭容錯演算法是一種狀態機副本復制演算法，通過節點間的多輪消息傳遞，網路內的所有誠實節點就可以達成一致的共識。

使用拜占庭容錯演算法不需要發行加密貨幣，但是只能用於私有鏈或者聯盟鏈，需要對節點的加入進行許可權控制；不能用於公有鏈，因為公有鏈中所有節點都可以隨意加入退出，無法抵擋女巫攻擊（sybil attack）

raft 演算法包含三種角色，分別是：跟隨者（ follower ），候選人（candidate ）和領導者（ leader ）。集群中的一個節點在某一時刻只能是這三種狀態的其中一種，這三種角色是可以隨著時間和條件的變化而互相轉換的。

raft 演算法主要有兩個過程：一個過程是領導者選舉，另一個過程是日誌復制，其中日誌復制過程會分記錄日誌和提交數據兩個階段。raft 演算法支持最大的容錯故障節點是（N-1）/2，其中 N 為 集群中總的節點數量。

國外有一個動畫介紹raft演算法介紹的很透徹，鏈接地址為： http://thesecretlivesofdata.com/raft/ 。這個動畫主要包含三部分內容，第一部分介紹簡單版的領導者選舉和日誌復制的過程，第二部分內容介紹詳細版的領導者選舉和日誌復制的過程，第三部分內容介紹的是如果遇到網路分區（腦裂），raft 演算法是如何恢復網路一致的。

pbft 演算法的提出主要是為了解決拜占庭將軍問題
要讓這個問題有解，有一個 十分重要的前提 ，那就是 信道必須是可靠的 。如果信道不能保證可靠，那麼拜占庭問題無解。關於信道可靠問題，會引出兩軍問題。兩軍問題的結論是，在一個不可靠的通信鏈路上試圖通過通信以達成一致是基本不可能或者十分困難的。
拜占庭將軍問題最早是由 Leslie Lamport 與另外兩人在 1982 年發表的論文《The Byzantine Generals Problem 》提出的， 他證明了在將軍總數大於 3f ，背叛者為f 或者更少時，忠誠的將軍可以達成命令上的一致，即 3f+1<=n 。演算法復雜度為 o（n^(f+1)) 。而 Miguel Castro (卡斯特羅)和 Barbara Liskov （利斯科夫）在1999年發表的論文《 Practical Byzantine Fault Tolerance 》中首次提出 pbft 演算法，該演算法容錯數量也滿足 3f+1<=n ，演算法復雜度為 o（n^2）。

首先我們先來思考一個問題，為什麼 pbft 演算法的最大容錯節點數量是（n-1）/3，而 raft 演算法的最大容錯節點數量是（n-1）/2 ？

對於raft演算法，raft演算法的的容錯只支持容錯故障節點，不支持容錯作惡節點。什麼是故障節點呢？就是節點因為系統繁忙、宕機或者網路問題等其它異常情況導致的無響應，出現這種情況的節點就是故障節點。那什麼是作惡節點呢？作惡節點除了可以故意對集群的其它節點的請求無響應之外，還可以故意發送錯誤的數據，或者給不同的其它節點發送不同的數據，使整個集群的節點最終無法達成共識，這種節點就是作惡節點。

raft 演算法只支持容錯故障節點，假設集群總節點數為n，故障節點為 f ，根據小數服從多數的原則，集群里正常節點只需要比 f 個節點再多一個節點，即 f+1 個節點，正確節點的數量就會比故障節點數量多，那麼集群就能達成共識。因此 raft 演算法支持的最大容錯節點數量是（n-1）/2。

對於 pbft 演算法，因為 pbft 演算法的除了需要支持容錯故障節點之外，還需要支持容錯作惡節點。假設集群節點數為 N，有問題的節點為 f。有問題的節點中，可以既是故障節點，也可以是作惡節點，或者只是故障節點或者只是作惡節點。那麼會產生以下兩種極端情況：

第一種情況，f 個有問題節點既是故障節點，又是作惡節點，那麼根據小數服從多數的原則，集群里正常節點只需要比f個節點再多一個節點，即 f+1 個節點，確節點的數量就會比故障節點數量多，那麼集群就能達成共識。也就是說這種情況支持的最大容錯節點數量是 （n-1）/2。
第二種情況，故障節點和作惡節點都是不同的節點。那麼就會有 f 個問題節點和 f 個故障節點，當發現節點是問題節點後，會被集群排除在外，剩下 f 個故障節點，那麼根據小數服從多數的原則，集群里正常節點只需要比f個節點再多一個節點，即 f+1 個節點，確節點的數量就會比故障節點數量多，那麼集群就能達成共識。所以，所有類型的節點數量加起來就是 f+1 個正確節點，f個故障節點和f個問題節點，即 3f+1=n。
結合上述兩種情況，因此 pbft 演算法支持的最大容錯節點數量是（n-1）/3

pbft 演算法的基本流程主要有以下四步：

客戶端發送請求給主節點
主節點廣播請求給其它節點，節點執行 pbft 演算法的三階段共識流程。
節點處理完三階段流程後，返回消息給客戶端。
客戶端收到來自 f+1 個節點的相同消息後，代表共識已經正確完成。
為什麼收到 f+1 個節點的相同消息後就代表共識已經正確完成？從上一小節的推導里可知，無論是最好的情況還是最壞的情況，如果客戶端收到 f+1 個節點的相同消息，那麼就代表有足夠多的正確節點已全部達成共識並處理完畢了。

3.演算法核心三階段流程
演算法的核心三個階段分別是 pre-prepare 階段（預准備階段），prepare 階段（准備階段）， commit 階段（提交階段）

流程的對比上，對於 leader 選舉這塊， raft 演算法本質是誰快誰當選，而 pbft 演算法是按編號依次輪流做主節點。對於共識過程和重選 leader 機制這塊，為了更形象的描述這兩個演算法，接下來會把 raft 和 pbft 的共識過程比喻成一個團隊是如何執行命令的過程，從這個角度去理解 raft 演算法和 pbft 的區別。

一個團隊一定會有一個老大和普通成員。對於 raft 演算法，共識過程就是：只要老大還沒掛，老大說什麼，我們（團隊普通成員）就做什麼，堅決執行。那什麼時候重新老大呢？只有當老大掛了才重選老大，不然生是老大的人，死是老大的鬼。

對於 pbft 演算法，共識過程就是：老大向我發送命令時，當我認為老大的命令是有問題時，我會拒絕執行。就算我認為老大的命令是對的，我還會問下團隊的其它成員老大的命令是否是對的，只有大多數人 （2f+1） 都認為老大的命令是對的時候，我才會去執行命令。那什麼時候重選老大呢？老大掛了當然要重選，如果大多數人都認為老大不稱職或者有問題時，我們也會重新選擇老大。
四、結語
raft 演算法和 pbft 演算法是私鏈和聯盟鏈中經典的共識演算法，本文主要介紹了 raft 和 pbft 演算法的流程和區別。 raft 和 pbft 演算法有兩點根本區別：

raft 演算法從節點不會拒絕主節點的請求，而 pbft 演算法從節點在某些情況下會拒絕主節點的請求 ;
raft 演算法只能容錯故障節點，並且最大容錯節點數為 （n-1）/2 ，而 pbft 演算法能容錯故障節點和作惡節點，最大容錯節點數為 （n-1）/3 。

pbft演算法是通過投票來達成共識，可以很好的解決包括分叉等問題的同時提升效率。但僅僅比較適合於聯盟鏈私有鏈，因為兩兩節點之間通信量是O(n^2)（通過優化可以減少通信量），一般來說不能應用於超過100個節點。
pbft有解的前提是 信道必須是可靠的 ，存在的問題是 可擴展性（scalability）差

部分來自： https://blog.csdn.net/kojhliang/article/details/80270223
區塊鏈在設計上就是為了BFT

⑥ raft演算法與paxos演算法相比有什麼優勢，使用場景有什麼差異

，主存儲器仍採用磁芯。軟體方面出現了分時操作系統以及結構化、規模化程序設計方法。特點是速度更快（一般為每秒數百萬次至數千萬次），而且可靠性有了顯著提高，價格進一步下降，產品走向了通用化、系列化和標准化等。應用領域開始進入文字處理和圖形圖像處理領域。

第4代：大規模集成電路機（1970年至今）

硬體方面，邏輯元件採用大規模和超大規模集成電路（LSI和VLSI）。軟體方面出現了數據

⑦ 為什麼去中心化了還能升級

什麼是「去中心化」？

「去中心化」翻譯自英語單詞Decentralization，是由前綴de-、詞干central、後綴-ization組成。其中，詞干central意為「中心」，後綴-ization意為「……化」，而前綴de-則有離開、除去、取消、相反等含義。因此，將其翻譯為去中心化是非常准確的。

那麼，去中心化具體而言是什麼含義呢？

以太坊創始人Vitalik Buterin於2017年2月發表的《The meaning of decentralization》一文中，詳細闡述了去中心化的含義。他認為應該從三個角度來區分計算機軟體的中心化和去中心化：架構、治理和邏輯。

架構中心化是指系統能容忍多少節點的崩潰而可以繼續運行；治理中心化是指需要多少的個人和組織能最終控制這個系統；邏輯中心化是指系統呈現的介面和數據是否像是一個單一的整體。

區塊鏈是全網統一的賬本，因此從邏輯上看是中心化的，這一點無可置疑。從架構上看，區塊鏈是基於對等網路的，因此是架構去中心化的。從治理上看，區塊鏈通過共識演算法使得少數人很難控制整個系統，因此是治理去中心化的。架構和治理上的去中心化為區塊鏈帶來三個好處：容錯性、抗攻擊力和防合謀。

區塊鏈與傳統分布式系統的5點區別

作為一種全新種類的分布式系統，區塊鏈往往被錯誤地當作是一個分布式的資料庫或日誌系統，實際上區塊鏈與傳統的分布式系統之間有著本質的區別——去中心化。現在我們來審視一下區塊鏈與傳統分布式系統的主要區別：

（1）一致性演算法：區塊鏈需要解決的是拜占庭將軍問題，即網路中存在一個或多個欺詐節點，可能會故意違反協議或傳輸錯誤的數據，因此區塊鏈往往採用拜占庭容錯的一致性演算法（通常稱為共識演算法），如BFT、PoW、PoS等；而傳統分布式系統只需考慮節點失效和通訊錯誤的情況，往往採用paxos、raft之類的一致性演算法，這類演算法不能對抗欺詐節點。

（2）中央控制方：在區塊鏈網路中是不存在中央控制方的，沒有一個節點可以控制或協調賬本數據的生成，各節點通過共識演算法進行協調，生成一致的賬本。而傳統發布式系統則往往是由一個機構進行控制，統一調度各節點參與運算。

（3）規則制定：區塊鏈的規則就是共識協議，又稱共識機制，共識演算法是其中的一部分。共識機制一般是由一個人或一個團隊設計制定，並開發出相應的程序，提供給社區使用。這一點似乎與傳統的分布式系統一樣，但區塊鏈的共識機制的改變、升級是需要社區對此有一致的共識，如果不能達成共識，則任何人都可以實施硬分叉，另建一個社區、一條鏈。這就是共識機制的去中心化過程。

⑧ 常見的共識演算法介紹

在非同步系統中，需要主機之間進行狀態復制，以保證每個主機達成一致的狀態共識。而在非同步系統中，主機之間可能出現故障，因此需要在默認不可靠的非同步網路中定義容錯協議，以確保各個主機達到安全可靠的狀態共識。

共識演算法其實就是一組規則，設置一組條件，篩選出具有代表性的節點。在區塊鏈系統中，存在很多這樣的篩選方案，如在公有鏈中的POW、Pos、DPOS等，而在不需要貨幣體系的許可鏈或私有鏈中，絕對信任的節點、高效的需求是公有鏈共識演算法不能提供的，對於這樣的區塊鏈，傳統的一致性共識演算法成為首選，如PBFT、PAXOS、RAFT等。

目錄

一、BFT（拜占庭容錯技術）

二、PBFT（實用拜占庭容錯演算法）

三、PAXOS

四、Raft

五、POW（工作量證明）

六、POS（權益證明）

七、DPOS（委任權益證明）

八、Ripple

拜占庭弄錯技術是一類分布式計算領域的容錯技術。拜占庭假設是由於硬體錯誤、網路擁塞或中斷以及遭到惡意攻擊的原因，計算機和網路出現不可預測的行為。拜占庭容錯用來處理這種異常行為，並滿足所要解決問題的規范。

拜占庭容錯系統是一個擁有n台節點的系統，整個系統對於每一個請求，滿足以下條件：

1）所有非拜占庭節點使用相同的輸入信息，產生同樣的結果；

2）如果輸入的信息正確，那麼所有非拜占庭節點必須接收這個信息，並計算相應的結果。

拜占庭系統普遍採用的假設條件包括：

1）拜占庭節點的行為可以是任意的，拜占庭節點之間可以共謀；

2）節點之間的錯誤是不相關的；

3）節點之間通過非同步網路連接，網路中的消息可能丟失、亂序並延時到達，但大部分協議假設消息在有限的時間里能傳達到目的地；

4）伺服器之間傳遞的信息，第三方可以嗅探到，但是不能篡改、偽造信息的內容和驗證信息的完整性。

拜占庭容錯由於其理論上的可行性而缺乏實用性，另外還需要額外的時鍾同步機制支持，演算法的復雜度也是隨節點的增加而指數級增加。

實用拜占庭容錯降低了拜占庭協議的運行復雜度，從指數級別降低到多項式級別。

PBFT是一種狀態機副本復制演算法，即服務作為狀態機進行建模，狀態機在分布式系統的不同節點進行副本復制。PBFT要求共同維護一個狀態。需要運行三類基本協議，包括一致性協議、檢查點協議和視圖更換協議。

一致性協議。一致性協議至少包含若干個階段：請求（request）、序號分配（pre-prepare）和響應（reply），可能包含相互交互（prepare），序號確認（commit）等階段。

PBFT通信模式中，每個客戶端的請求需要經過5個階段。由於客戶端不能從伺服器端獲得任何伺服器運行狀態的信息，PBFT中主節點是否發生錯誤只能由伺服器監測。如果伺服器在一段時間內都不能完成客戶端的請求，則會觸發視圖更換協議。

整個協議的基本過程如下：

1）客戶端發送請求，激活主節點的服務操作。

2）當主節點接收請求後，啟動三階段的協議以向各從節點廣播請求。

［2.1］序號分配階段，主節點給請求賦值一個序列號n，廣播序號分配消息和客戶端的請求消息m，並將構造PRE-PREPARE消息給各從節點；

［2.2］交互階段，從節點接收PRE-PREPARE消息，向其他服務節點廣播PREPARE消息；

［2.3］序號確認階段，各節點對視圖內的請求和次序進行驗證後，廣播COMMIT消息，執行收到的客戶端的請求並給客戶端以響應。

3）客戶端等待來自不同節點的響應，若有m+1個響應相同，則該響應即為運算的結果。

PBFT一般適合有對強一致性有要求的私有鏈和聯盟鏈，例如，在IBM主導的區塊鏈超級賬本項目中，PBFT是一個可選的共識協議。在Hyperledger的Fabric項目中，共識模塊被設計成可插拔的模塊，支持像PBFT、Raft等共識演算法。

在有些分布式場景下，其假設條件不需要考慮拜占庭故障，而只是處理一般的死機故障。在這種情況下，採用Paxos等協議會更加高效。。PAXOS是一種基於消息傳遞且具有高度容錯特性的一致性演算法。

PAXOS中有三類角色Proposer、Acceptor及Learner，主要交互過程在Proposer和Acceptor之間。演算法流程分為兩個階段：

phase 1

a) proposer向網路內超過半數的acceptor發送prepare消息

b) acceptor正常情況下回復promise消息

phase 2

a) 在有足夠多acceptor回復promise消息時，proposer發送accept消息

b) 正常情況下acceptor回復accepted消息

流程圖如圖所示：

PAXOS協議用於微信PaxosStore中，每分鍾調用Paxos協議過程數十億次量級。

Paxos是Lamport設計的保持分布式系統一致性的協議。但由於Paxos非常復雜，比較難以理解，因此後來出現了各種不同的實現和變種。Raft是由Stanford提出的一種更易理解的一致性演算法，意在取代目前廣為使用的Paxos演算法。

Raft最初是一個用於管理復制日誌的共識演算法，它是在非拜占庭故障下達成共識的強一致協議。Raft實現共識過程如下：首先選舉一個leader，leader從客戶端接收記賬請求、完成記賬操作、生成區塊，並復制到其他記賬節點。leader有完全的管理記賬權利，例如，leader能夠決定是否接受新的交易記錄項而無需考慮其他的記賬節點，leader可能失效或與其他節點失去聯系，這時，重新選出新的leader。

在Raft中，每個節點會處於以下三種狀態中的一種：

（1）follower：所有結點都以follower的狀態開始。如果沒收到leader消息則會變成candidate狀態；

（2）candidate：會向其他結點「拉選票」，如果得到大部分的票則成為leader。這個過程就叫做Leader選舉(Leader Election)；

（3）leader：所有對系統的修改都會先經過leader。每個修改都會寫一條日誌(log entry)。leader收到修改請求後的過程如下：此過程叫做日誌復制（Log Replication）

1）復制日誌到所有follower結點

2）大部分結點響應時才提交日誌

3）通知所有follower結點日誌已提交

4）所有follower也提交日誌

5）現在整個系統處於一致的狀態

Raft階段主要分為兩個，首先是leader選舉過程，然後在選舉出來的leader基礎上進行正常操作，比如日誌復制、記賬等。

（1）leader選舉

當follower在選舉時間內未收到leader的消息，則轉換為candidate狀態。在Raft系統中：

1）任何一個伺服器都可以成為候選者candidate，只要它向其他伺服器follower發出選舉自己的請求。

2）如果其他伺服器同意了，發出OK。如果在這個過程中，有一個follower宕機，沒有收到請求選舉的要求，此時候選者可以自己選自己，只要達到N/2+1的大多數票，候選人還是可以成為leader的。

3）這樣這個候選者就成為了leader領導人，它可以向選民也就是follower發出指令，比如進行記賬。

4）以後通過心跳消息進行記賬的通知。

5）一旦這個leader崩潰了，那麼follower中有一個成為候選者，並發出邀票選舉。

6）follower同意後，其成為leader，繼續承擔記賬等指導工作。

（2）日誌復制

記賬步驟如下所示：

1）假設leader已經選出，這時客戶端發出增加一個日誌的要求；

2）leader要求follower遵從他的指令，將這個新的日誌內容追加到各自日誌中；

3）大多數follower伺服器將交易記錄寫入賬本後，確認追加成功，發出確認成功信息；

4）在下一個心跳消息中，leader會通知所有follower更新確認的項目。

對於每個新的交易記錄，重復上述過程。

在這一過程中，若發生網路通信故障，使得leader不能訪問大多數follower了，那麼leader只能正常更新它能訪問的那些follower伺服器。而大多數的伺服器follower因為沒有了leader，他們將重新選舉一個候選者作為leader，然後這個leader作為代表與外界打交道，如果外界要求其添加新的交易記錄，這個新的leader就按上述步驟通知大多數follower。當網路通信恢復，原先的leader就變成follower，在失聯階段，這個老leader的任何更新都不能算確認，必須全部回滾，接收新的leader的新的更新。

在去中心賬本系統中，每個加入這個系統的節點都要保存一份完整的賬本，但每個節點卻不能同時記賬，因為節點處於不同的環境，接收不同的信息，如果同時記賬，必然導致賬本的不一致。因此通過同時來決定那個節點擁有記賬權。

在比特幣系統中，大約每10分鍾進行一輪算力競賽，競賽的勝利者，就獲得一次記賬的權力，並向其他節點同步新增賬本信息。

PoW系統的主要特徵是計算的不對稱性。工作端要做一定難度的工作才能得出一個結果，而驗證方卻很容易通過結果來檢查工作端是不是做了相應的工作。該工作量的要求是，在某個字元串後面連接一個稱為nonce的整數值串，對連接後的字元串進行SHA256哈希運算，如果得到的哈希結果（以十六進制的形式表示）是以若干個0開頭的，則驗證通過。

比特幣網路中任何一個節點，如果想生成一個新的區塊並寫入區塊鏈，必須解出比特幣網路出的PoW問題。關鍵的3個要素是 工作量證明函數、區塊及難度值 。工作量證明函數是這道題的計算方法，區塊決定了這道題的輸入數據，難度值決定了這道題所需要的計算量。

（1）工作量證明函數就是<u style="box-sizing: border-box;"> SHA256 </u>

比特幣的區塊由區塊頭及該區塊所包含的交易列表組成。擁有80位元組固定長度的區塊頭，就是用於比特幣工作量證明的輸入字元串。

（2）難度的調整是在每個完整節點中獨立自動發生的。每2016個區塊，所有節點都會按統一的公式自動調整難度。如果區塊產生的速率比10分鍾快則增加難度，比10分鍾慢則降低難度。

公式可以總結為：新難度值=舊難度值×（過去2016個區塊花費時長/20160分鍾）

工作量證明需要有一個目標值。比特幣工作量證明的目標值（Target）的計算公式：目標值=最大目標值/難度值

其中最大目標值為一個恆定值：

目標值的大小與難度值成反比。比特幣工作量證明的達成就是礦工計算出來的 區塊哈希值必須小於目標值 。

（3）PoW能否解決拜占庭將軍問題

比特幣的PoW共識演算法是一種概率性的拜占庭協議（Probabilistic BA）

當不誠實的算力小於網路總算力的50%時，同時挖礦難度比較高（在大約10分鍾出一個區塊情況下）比特幣網路達到一致性的概念會隨確認區塊的數目增多而呈指數型增加。但當不誠實算力具一定規模，甚至不用接近50%的時候，比特幣的共識演算法並不能保證正確性，也就是，不能保證大多數的區塊由誠實節點來提供。

比特幣的共識演算法不適合於私有鏈和聯盟鏈。其原因首先是它是一個最終一致性共識演算法，不是一個強一致性共識演算法。第二個原因是其共識效率低。

擴展知識： 一致性

嚴格一致性，是在系統不發生任何故障，而且所有節點之間的通信無需任何時間這種理想的條件下，才能達到。這個時候整個系統就等價於一台機器了。在現實中，是不可能達到的。

強一致性，當分布式系統中更新操作完成之後，任何多個進程或線程，訪問系統都會獲得最新的值。

弱一致性，是指系統並不保證後續進程或線程的訪問都會返回最新的更新的值。系統在數據成功寫入之後，不承諾立即可以讀到最新寫入的值，也不會具體承諾多久讀到。但是會盡可能保證在某個時間級別（秒級）之後。可以讓數據達到一致性狀態。

最終一致性是弱一致性的特定形式。系統保證在沒有後續更新的前提下，系統最終返回上一次更新操作的值。也就是說，如果經過一段時間後要求能訪問到更新後的數據，則是最終一致性。

在股權證明PoS模式下，有一個名詞叫幣齡，每個幣每天產生1幣齡，比如你持有100個幣，總共持有了30天，那麼，此時你的幣齡就為3000，這個時候，如果你發現了一個PoS區塊，你的幣齡就會被清空為0。你每被清空365幣齡，你將會從區塊中獲得0.05個幣的利息(假定利息可理解為年利率5%)，那麼在這個案例中，利息 = 3000 * 5% / 365 = 0.41個幣，這下就很有意思了，持幣有利息。

點點幣（Peercoin）是首先採用權益證明的貨幣。，點點幣的權益證明機制結合了隨機化與幣齡的概念，未使用至少30天的幣可以參與競爭下一區塊，越久和越大的幣集有更大的可能去簽名下一區塊。一旦幣的權益被用於簽名一個區塊，則幣齡將清為零，這樣必須等待至少30日才能簽署另一區塊。

PoS機制雖然考慮到了PoW的不足，但依據權益結余來選擇，會導致首富賬戶的權力更大，有可能支配記賬權。股份授權證明機制（Delegated Proof of Stake，DPoS）的出現正是基於解決PoW機制和PoS機制的這類不足。

比特股（Bitshare）是一類採用DPoS機制的密碼貨幣。它的原理是，讓每一個持有比特股的人進行投票，由此產生101位代表 , 我們可以將其理解為101個超級節點或者礦池，而這101個超級節點彼此的權利是完全相等的。如果代表不能履行他們的職責（當輪到他們時，沒能生成區塊），他們會被除名，網路會選出新的超級節點來取代他們。

比特股引入了見證人這個概念，見證人可以生成區塊，每一個持有比特股的人都可以投票選舉見證人。得到總同意票數中的前N個（N通常定義為101）候選者可以當選為見證人，當選見證人的個數（N）需滿足：至少一半的參與投票者相信N已經充分地去中心化。

見證人的候選名單每個維護周期（1天）更新一次。見證人然後隨機排列，每個見證人按序有2秒的許可權時間生成區塊，若見證人在給定的時間片不能生成區塊，區塊生成許可權交給下一個時間片對應的見證人。

比特股還設計了另外一類競選，代表競選。選出的代表擁有提出改變網路參數的特權，包括交易費用、區塊大小、見證人費用和區塊區間。若大多數代表同意所提出的改變，持股人有兩周的審查期，這期間可以罷免代表並廢止所提出的改變。這一設計確保代表技術上沒有直接修改參數的權利以及所有的網路參數的改變最終需得到持股人的同意。

Ripple（瑞波）是一種基於互聯網的開源支付協議，在Ripple的網路中，交易由客戶端（應用）發起，經過追蹤節點（tracking node）或驗證節點（validating node）把交易廣播到整個網路中。

追蹤節點的主要功能是分發交易信息以及響應客戶端的賬本請求。驗證節點除包含追蹤節點的所有功能外，還能夠通過共識協議，在賬本中增加新的賬本實例數據。

Ripple的共識達成發生在驗證節點之間，每個驗證節點都預先配置了一份可信任節點名單，稱為UNL（Unique Node List）。在名單上的節點可對交易達成進行投票。每隔幾秒，Ripple網路將進行如下共識過程：

1）每個驗證節點會不斷收到從網路發送過來的交易，通過與本地賬本數據驗證後，不合法的交易直接丟棄，合法的交易將匯總成交易候選集（candidate set）。交易候選集裡面還包括之前共識過程無法確認而遺留下來的交易。

2）每個驗證節點把自己的交易候選集作為提案發送給其他驗證節點。

3）驗證節點在收到其他節點發來的提案後，如果不是來自UNL上的節點，則忽略該提案；如果是來自UNL上的節點，就會對比提案中的交易和本地的交易候選集，如果有相同的交易，該交易就獲得一票。在一定時間內，當交易獲得超過50%的票數時，則該交易進入下一輪。沒有超過50%的交易，將留待下一次共識過程去確認。

4）驗證節點把超過50%票數的交易作為提案發給其他節點，同時提高所需票數的閾值到60%，重復步驟3）、步驟4），直到閾值達到80%。

5）驗證節點把經過80%UNL節點確認的交易正式寫入本地的賬本數據中，稱為最後關閉賬本（Last Closed Ledger），即賬本最後（最新）的狀態。

在Ripple的共識演算法中，參與投票節點的身份是事先知道的。該共識演算法只適合於許可權鏈（Permissioned chain）的場景。Ripple共識演算法的拜占庭容錯（BFT）能力為（n-1）/5，即可以容忍整個網路中20%的節點出現拜占庭錯誤而不影響正確的共識。

在區塊鏈網路中，由於應用場景的不同，所設計的目標各異，不同的區塊鏈系統採用了不同的共識演算法。一般來說，在私有鏈和聯盟鏈情況下，對一致性、正確性有很強的要求。一般來說要採用強一致性的共識演算法。而在公有鏈情況下，對一致性和正確性通常沒法做到百分之百，通常採用最終一致性（Eventual Consistency）的共識演算法。

共識演算法的選擇與應用場景高度相關，可信環境使用paxos 或者raft，帶許可的聯盟可使用pbft ，非許可鏈可以是pow，pos，ripple共識等，根據對手方信任度分級，自由選擇共識機制。

⑨ 共識演算法：Raft

上篇講到了「拜占庭將軍問題」：多個拜占庭將軍要如何在可能有叛徒、信使可能被策反或者暗殺的情況下達成是否要進攻的一致性決定？還不了解的先看看上一篇 《拜占庭將軍問題》 。這篇主要是介紹簡化版拜占庭將軍問題的解決方案：Raft 共識演算法。

所以將拜占庭將軍問題根據常見的工作上的問題進行簡化： 假設將軍中沒有叛軍，信使的信息可靠但有可能被暗殺的情況下，將軍們如何達成一致性決定？

對於這個簡化後的問題，有許多解決方案，第一個被證明的共識演算法是 Paxos，由拜占庭將軍問題的作者 Leslie Lamport 在1990年提出，最初以論文難懂而出名，後來這哥們在2001重新發了一篇簡單版的論文 Paxos Made Simple ，然而還是挺難懂的。

因為 Paxos 難懂，難實現，所以斯坦福大學的教授在2014年發表了新的分布式協議 Raft。與 Paxos 相比，Raft 有著基本相同運行效率，但是更容易理解，也更容易被用在系統開發上。

我們還是用拜占庭將軍的例子來幫助理解 Raft。

Raft 的解決方案大概可以理解成 先在所有將軍中選出一個大將軍，所有的決定由大將軍來做。 選舉環節 ：比如說現在一共有3個將軍 A, B, C，每個將軍都有一個 隨機時間 的倒計時器，倒計時一結束，這個將軍就會把自己當成大將軍候選人，然後派信使去問其他幾個將軍，能不能選我為總將軍？假設現在將軍A倒計時結束了，他派信使傳遞選舉投票的信息給將軍B和C，如果將軍B和C還沒把自己當成候選人（倒計時還沒有結束），並且沒有把選舉票投給其他，他們把票投給將軍A，信使在回到將軍A時，將軍A知道自己收到了足夠的票數，成為了大將軍。在這之後，是否要進攻就由大將軍決定，然後派信使去通知另外兩個將軍，如果在一段時間後還沒有收到回復（可能信使被暗殺），那就再重派一個信使，直到收到回復。

故事先講到這里，希望不做技術方面的朋友可以大概能理解 Raft 的原理，下面從比較技術的角度講講 Raft 的原理。

從拜占庭將軍的故事映射到分布式系統上，每個將軍相當於一個分布式網路節點，每個節點有 三種狀態：Follower，Candidate，Leader ，狀態之間是互相轉換的，可以參考下圖，具體的後面說。

每個節點上都有一個倒計時器 (Election Timeout)，時間隨機在 150ms 到 300ms 之間。有幾種情況會重設 Timeout：

在 Raft 運行過程中，最主要進行兩個活動：

假設現在有如圖5個節點，5個節點一開始的狀態都是 Follower。

在一個節點倒計時結束 (Timeout) 後，這個節點的狀態變成 Candidate 開始選舉，它給其他幾個節點發送選舉請求 (RequestVote)

其他四個節點都返回成功，這個節點的狀態由 Candidate 變成了 Leader，並在每個一小段時間後，就給所有的 Follower 發送一個 Heartbeat 以保持所有節點的狀態，Follower 收到 Leader 的 Heartbeat 後重設 Timeout。

這是最簡單的選主情況， 只要有超過一半的節點投支持票了，Candidate 才會被選舉為 Leader ，5個節點的情況下，3個節點 (包括 Candidate 本身) 投了支持就行。

一開始已經有一個 Leader，所有節點正常運行。

Leader 出故障掛掉了，其他四個 Follower 將進行重新選主。

4個節點的選主過程和5個節點的類似，在選出一個新的 Leader 後，原來的 Leader 恢復了又重新加入了，這個時候怎麼處理？在 Raft 里，第幾輪選舉是有記錄的，重新加入的 Leader 是第一輪選舉 (Term 1) 選出來的，而現在的 Leader 則是 Term 2，所有原來的 Leader 會自覺降級為 Follower

假設一開始有4個節點，都還是 Follower。

有兩個 Follower 同時 Timeout，都變成了 Candidate 開始選舉，分別給一個 Follower 發送了投票請求。

兩個 Follower 分別返回了ok，這時兩個 Candidate 都只有2票，要3票才能被選成 Leader。

兩個 Candidate 會分別給另外一個還沒有給自己投票的 Follower 發送投票請求。

但是因為 Follower 在這一輪選舉中，都已經投完票了，所以都拒絕了他們的請求。所以在 Term 2 沒有 Leader 被選出來。

這時，兩個節點的狀態是 Candidate，兩個是 Follower，但是他們的倒計時器仍然在運行，最先 Timeout 的那個節點會進行發起新一輪 Term 3 的投票。

兩個 Follower 在 Term 3 還沒投過票，所以返回 OK，這時 Candidate 一共有三票，被選為了 Leader。

如果 Leader Heartbeat 的時間晚於另外一個 Candidate timeout 的時間，另外一個 Candidate 仍然會發送選舉請求。

兩個 Follower 已經投完票了，拒絕了這個 Candidate 的投票請求。

Leader 進行 Heartbeat， Candidate 收到後狀態自動轉為 Follower，完成選主。

以上是 Raft 最重要活動之一選主的介紹，以及在不同情況下如何進行選主。

Raft 在實際應用場景中的一致性更多的是體現在不同節點之間的數據一致性，客戶端發送請求到任何一個節點都能收到一致的返回，當一個節點出故障後，其他節點仍然能以已有的數據正常進行。在選主之後的復制日誌就是為了達到這個目的。

一開始，Leader 和 兩個 Follower 都沒有任何數據。

客戶端發送請求給 Leader，儲存數據 「sally」，Leader 先將數據寫在本地日誌，這時候數據還是 Uncommitted (還沒最終確認，紅色表示)

Leader 給兩個 Follower 發送 AppendEntries 請求，數據在 Follower 上沒有沖突，則將數據暫時寫在本地日誌，Follower 的數據也還是 Uncommitted。

Follower 將數據寫到本地後，返回 OK。Leader 收到後成功返回， 只要收到的成功的返回數量超過半數 (包含Leader) ，Leader 將數據 「sally」 的狀態改成 Committed。( 這個時候 Leader 就可以返回給客戶端了)

Leader 再次給 Follower 發送 AppendEntries 請求，收到請求後，Follower 將本地日誌里 Uncommitted 數據改成 Committed。這樣就完成了一整個復制日誌的過程，三個節點的數據是一致的，

在 Network Partition 的情況下，部分節點之間沒辦法互相通信，Raft 也能保證在這種情況下數據的一致性。

一開始有 5 個節點處於同一網路狀態下。

Network Partition 將節點分成兩邊，一邊有兩個節點，一邊三個節點。

兩個節點這邊已經有 Leader 了，來自客戶端的數據 「bob」 通過 Leader 同步到 Follower。

因為只有兩個節點，少於3個節點，所以 「bob」 的狀態仍是 Uncommitted。所以在這里， 伺服器會返回錯誤給客戶端

另外一個 Partition 有三個節點，進行重新選主。客戶端數據 「tom」 發到新的 Leader，通過和上節網路狀態下相似的過程，同步到另外兩個 Follower。

因為這個 Partition 有3個節點，超過半數，所以數據 「tom」 都 Commit 了。

網路狀態恢復，5個節點再次處於同一個網路狀態下。但是這里出現了數據沖突 「bob" 和 「tom"

三個節點的 Leader 廣播 AppendEntries

兩個節點 Partition 的 Leader 自動降級為 Follower，因為這個 Partition 的數據 「bob」 沒有 Commit，返回給客戶端的是錯誤，客戶端知道請求沒有成功，所以 Follower 在收到 AppendEntries 請求時，可以把 「bob「 刪除，然後同步 」tom」，通過這么一個過程，就完成了在 Network Partition 情況下的復制日誌，保證了數據的一致性。

Raft 是能夠實現分布式系統強一致性的演算法，每個系統節點有三種狀態 Follower，Candidate，Leader。實現 Raft 演算法兩個最重要的事是：選主和復制日誌

參考鏈接：
Raft 官網： https://raft.github.io/

Raft 原理動畫 (推薦看看)： http://thesecretlivesofdata.com/raft/

（本來不想一個個圖片粘，但是在國內時候訪問不了這個鏈接，乾脆就復述了一遍整個過程。）

⑩ 區塊鏈的核心技術是什麼

簡單來說，區塊鏈是一個提供了拜占庭容錯、並保證了最終一致性的分布式資料庫；從數據結構上看，它是基於時間序列的鏈式數據塊結構；從節點拓撲上看，它所有的節點互為冗餘備份；從操作上看，它提供了基於密碼學的公私鑰管理體系來管理賬戶。
或許以上概念過於抽象，我來舉個例子，你就好理解了。
你可以想像有 100 台計算機分布在世界各地，這 100 台機器之間的網路是廣域網，並且，這 100 台機器的擁有者互相不信任。
那麼，我們採用什麼樣的演算法（共識機制）才能夠為它提供一個可信任的環境，並且使得：
節點之間的數據交換過程不可篡改，並且已生成的歷史記錄不可被篡改；
每個節點的數據會同步到最新數據，並且會驗證最新數據的有效性；
基於少數服從多數的原則，整體節點維護的數據可以客觀反映交換歷史。
區塊鏈就是為了解決上述問題而產生的技術方案。
二、區塊鏈的核心技術組成
無論是公鏈還是聯盟鏈，至少需要四個模塊組成：P2P 網路協議、分布式一致性演算法（共識機制）、加密簽名演算法、賬戶與存儲模型。
1、P2P 網路協議
P2P 網路協議是所有區塊鏈的最底層模塊，負責交易數據的網路傳輸和廣播、節點發現和維護。
通常我們所用的都是比特幣 P2P 網路協議模塊，它遵循一定的交互原則。比如：初次連接到其他節點會被要求按照握手協議來確認狀態，在握手之後開始請求 Peer 節點的地址數據以及區塊數據。
這套 P2P 交互協議也具有自己的指令集合，指令體現在在消息頭（Message Header) 的 命令（command）域中，這些命令為上層提供了節點發現、節點獲取、區塊頭獲取、區塊獲取等功能，這些功能都是非常底層、非常基礎的功能。如果你想要深入了解，可以參考比特幣開發者指南中的 Peer Discovery 的章節。
2、分布式一致性演算法
在經典分布式計算領域，我們有 Raft 和 Paxos 演算法家族代表的非拜占庭容錯演算法，以及具有拜占庭容錯特性的 PBFT 共識演算法。
如果從技術演化的角度來看，我們可以得出一個圖，其中，區塊鏈技術把原來的分布式演算法進行了經濟學上的拓展。
在圖中我們可以看到，計算機應用在最開始多為單點應用，高可用方便採用的是冷災備，後來發展到異地多活，這些異地多活可能採用的是負載均衡和路由技術，隨著分布式系統技術的發展，我們過渡到了 Paxos 和 Raft 為主的分布式系統。
而在區塊鏈領域，多採用 PoW 工作量證明演算法、PoS 權益證明演算法，以及 DPoS 代理權益證明演算法，以上三種是業界主流的共識演算法，這些演算法與經典分布式一致性演算法不同的是，它們融入了經濟學博弈的概念，下面我分別簡單介紹這三種共識演算法。
PoW： 通常是指在給定的約束下，求解一個特定難度的數學問題，誰解的速度快，誰就能獲得記賬權（出塊）權利。這個求解過程往往會轉換成計算問題，所以在比拼速度的情況下，也就變成了誰的計算方法更優，以及誰的設備性能更好。
PoS： 這是一種股權證明機制，它的基本概念是你產生區塊的難度應該與你在網路里所佔的股權（所有權佔比）成比例，它實現的核心思路是：使用你所鎖定代幣的幣齡（CoinAge）以及一個小的工作量證明，去計算一個目標值，當滿足目標值時，你將可能獲取記賬權。
DPoS： 簡單來理解就是將 PoS 共識演算法中的記賬者轉換為指定節點數組成的小圈子，而不是所有人都可以參與記賬。這個圈子可能是 21 個節點，也有可能是 101 個節點，這一點取決於設計，只有這個圈子中的節點才能獲得記賬權。這將會極大地提高系統的吞吐量，因為更少的節點也就意味著網路和節點的可控。
3、加密簽名演算法
在區塊鏈領域，應用得最多的是哈希演算法。哈希演算法具有抗碰撞性、原像不可逆、難題友好性等特徵。
其中，難題友好性正是眾多 PoW 幣種賴以存在的基礎，在比特幣中，SHA256 演算法被用作工作量證明的計算方法，也就是我們所說的挖礦演算法。
而在萊特幣身上，我們也會看到 Scrypt 演算法，該演算法與 SHA256 不同的是，需要大內存支持。而在其他一些幣種身上，我們也能看到基於 SHA3 演算法的挖礦演算法。以太坊使用了 Dagger-Hashimoto 演算法的改良版本，並命名為 Ethash，這是一個 IO 難解性的演算法。
當然，除了挖礦演算法，我們還會使用到 RIPEMD160 演算法，主要用於生成地址，眾多的比特幣衍生代碼中，絕大部分都採用了比特幣的地址設計。
除了地址，我們還會使用到最核心的，也是區塊鏈 Token 系統的基石：公私鑰密碼演算法。
在比特幣大類的代碼中，基本上使用的都是 ECDSA。ECDSA 是 ECC 與 DSA 的結合，整個簽名過程與 DSA 類似，所不一樣的是簽名中採取的演算法為 ECC（橢圓曲線函數）。
從技術上看，我們先從生成私鑰開始，其次從私鑰生成公鑰，最後從公鑰生成地址，以上每一步都是不可逆過程，也就是說無法從地址推導出公鑰，從公鑰推導到私鑰。
4、賬戶與交易模型
從一開始的定義我們知道，僅從技術角度可以認為區塊鏈是一種分布式資料庫，那麼，多數區塊鏈到底使用了什麼類型的資料庫呢？
我在設計元界區塊鏈時，參考了多種資料庫，有 NoSQL 的 BerkelyDB、LevelDB，也有一些幣種採用基於 SQL 的 SQLite。這些作為底層的存儲設施，多以輕量級嵌入式資料庫為主，由於並不涉及區塊鏈的賬本特性，這些存儲技術與其他場合下的使用並沒有什麼不同。
區塊鏈的賬本特性，通常分為 UTXO 結構以及基於 Accout-Balance 結構的賬本結構，我們也稱為賬本模型。UTXO 是「unspent transaction input/output」的縮寫，翻譯過來就是指「未花費的交易輸入輸出」。
這個區塊鏈中 Token 轉移的一種記賬模式，每次轉移均以輸入輸出的形式出現；而在 Balance 結構中，是沒有這個模式的。