1，摘要

本文盡可能列出所有主要的共識算法，評估各自的優(yōu)劣之處。共識算法是區(qū)塊鏈的核心技術(shù)，本文會跟隨作者的理解，持續(xù)更新。如果讀者發(fā)現(xiàn)有所遺漏，或是存在錯誤，希望能通過評論指出。
2，區(qū)塊鏈共識算法
2.1 工作量證明（PoW，Proof of Work）

優(yōu)點： 自2009年以來得到了廣泛測試，目前依然得到廣泛的使用。
不足：速度慢。耗能巨大，對環(huán)境不好。易受“規(guī)模經(jīng)濟(jì)”（economies of scale）的影響。
使用者： Bitcoin、Ethereum、LiteCoin、Dogecoin等。
類型：有競爭共識(Competive consensus）。
解釋：PoW是是首個共識算法。它是由中本聰在他的論文中提出的，用于建立分布式無信任共識并識別“雙重支付”（double spend）問題。PoW并非一個新理念，但是中本聰將Pow與加密簽名、Merkle鏈和P2P網(wǎng)絡(luò)等已有理念結(jié)合，形成一種可用的分布式共識系統(tǒng)。加密貨幣是這樣系統(tǒng)的首個基礎(chǔ)和應(yīng)用，因而獨具創(chuàng)新性。
在PoW的工作方式中，區(qū)塊鏈參與者（稱為“礦工”）要在區(qū)塊鏈中添加一塊交易，必須解決某種“復(fù)雜但是無用”的計算問題。
只要由礦工提交的工作有超過一半是值得信任的，那么Bitcoin就是安全的。
從某種角度來看，PoW有點像買彩票，只是概率高一點而已。
技術(shù)原理：
工作量證明最核心的技術(shù)原理是散列函數(shù)（哈希）。在比特幣中，PoW工作其實就是如何去計算一個區(qū)塊的目標(biāo)哈希值問題，讓用戶進(jìn)行大量的窮舉運算，同時得出這個哈希值還必須滿足一些必要條件，這個條件在區(qū)塊鏈中其實就是一個難度系數(shù)值，通過計算出的哈希值是否符合前面N位全是0，最終達(dá)成工作量證明。
舉個例子：
比如現(xiàn)在給出一個固定的字符串“Hello, blockchain”，現(xiàn)在要求計算的難題是將這個字符串與一個隨機數(shù)（Nonce）拼接起來，并通過SHA256哈希計算一個固定256位長度的哈希值，如果計算結(jié)果得到的前5位全是0，即認(rèn)為滿足計算條件，同時得到的隨機數(shù)（Nonce）值證明為達(dá)成工作量證明的有效隨機數(shù)。
2.2 權(quán)益證明（PoS，Proof of Stake）

優(yōu)點：節(jié)能、攻擊者代價更大、不易受“規(guī)模經(jīng)濟(jì)”的影響。
不足：“無利害關(guān)系“（Nothing at stake）”攻擊問題。
使用者：Ethereum（即將推出）、Peercoin、Nxt。
類型：有競爭共識。
解釋：
類似于財產(chǎn)儲存在銀行，這種模式會根據(jù)你持有數(shù)字貨幣的量和時間，分配給你相應(yīng)的利息。
簡單來說，就是一個根據(jù)你持有貨幣的量和時間，給你發(fā)利息的一個制度，在股權(quán)證明POS模式下，有一個名詞叫幣齡，每個幣每天產(chǎn)生1幣齡，比如你持有100個幣，總共持有了30天，那么，此時你的幣齡就為3000，這個時候，如果你發(fā)現(xiàn)了一個POS區(qū)塊，你的幣齡就會被清空為0。你每被清空365幣齡，你將會從區(qū)塊中獲得0.05個幣的利息(假定利息可理解為年利率5%)，那么在這個案例中，利息 = 3000 * 5% / 365 = 0.41個幣，這下就很有意思了，持幣有利息。以太坊就是采用POS共識算法。
從某種角度來看，PoS有點像銀行存款，你持有的時間越長，本金越大，你得到的利息會越多。
技術(shù)原理：
每個曠工都有出塊(即挖礦)的權(quán)力，只要出塊成功，就有系統(tǒng)給出的獎勵，這里不需要通過復(fù)雜的計算來挖礦，問題只在于誰來出塊，股權(quán)越大，出塊的概率就越大，反之，則相反。POS有很多變種，股權(quán)可以是持有幣的數(shù)量，或者支付的數(shù)量等等。

go的demo代碼實現(xiàn):

package mainimport ("time""strconv""crypto/sha256""math/rand""fmt""encoding/hex" )//實現(xiàn)pos挖礦的原理type Block struct {Index intData string //PreHash stringHash stringTimestamp string//記錄挖礦節(jié)點Validator *Node}func genesisBlock() Block {var genesBlock = Block{0, "Genesis block","","",time.Now().String(),&Node{0, 0, "dd"}}genesBlock.Hash = hex.EncodeToString(BlockHash(&genesBlock))return genesBlock }func BlockHash(block *Block) []byte {record := strconv.Itoa(block.Index) + block.Data + block.PreHash + block.Timestamp + block.Validator.Addressh := sha256.New()h.Write([]byte(record))hashed := h.Sum(nil)return hashed }//創(chuàng)建全節(jié)點類型 type Node struct {Tokens int //持幣數(shù)量Days int //持幣時間Address string //地址 }//創(chuàng)建5個節(jié)點 //算法的實現(xiàn)要滿足 持幣越多的節(jié)點越容易出塊 var nodes = make([]Node, 5) //存放節(jié)點的地址 var addr = make([]*Node, 15)func InitNodes() {nodes[0] = Node{1, 1, "0x12341"}nodes[1] = Node{2, 1, "0x12342"}nodes[2] = Node{3, 1, "0x12343"}nodes[3] = Node{4, 1, "0x12344"}nodes[4] = Node{5, 1, "0x12345"}cnt :=0for i:=0;i<5;i++ {for j:=0;j<nodes[i].Tokens * nodes[i].Days;j++{addr[cnt] = &nodes[i]cnt++}}}//采用Pos共識算法進(jìn)行挖礦 func CreateNewBlock(lastBlock *Block, data string) Block{var newBlock BlocknewBlock.Index = lastBlock.Index + 1newBlock.Timestamp = time.Now().String()newBlock.PreHash = lastBlock.HashnewBlock.Data = data//通過pos計算由那個村民挖礦//設(shè)置隨機種子rand.Seed(time.Now().Unix())//[0,15)產(chǎn)生0-15的隨機值var rd =rand.Intn(15)//選出挖礦的曠工node := addr[rd]//設(shè)置當(dāng)前區(qū)塊挖礦地址為曠工newBlock.Validator = node//簡單模擬 挖礦所得獎勵node.Tokens += 1newBlock.Hash = hex.EncodeToString(BlockHash(&newBlock))return newBlock }func main() {InitNodes()//創(chuàng)建創(chuàng)世區(qū)塊var genesisBlock = genesisBlock()//創(chuàng)建新區(qū)快var newBlock = CreateNewBlock(&genesisBlock, "new block")//打印新區(qū)快信息fmt.Println(newBlock)fmt.Println(newBlock.Validator.Address)fmt.Println(newBlock.Validator.Tokens)}

輸出結(jié)果： {1 new block
72e8838ad3bb761c7d3ba42c4e6bad86409dd3f4ce958c890409c4b9ddf44171
e4f9575cfb14ee146810862c9e5cc78ebff185f5888f428dbb945bd9060b31f7
2018-06-29 19:29:04.827332898 +0800 CST m=+0.000837770 0xc42007e0a0}
0x12341

2.3 委任權(quán)益證明（DPOS，Delegated Proof-of-Stake）

優(yōu)點：
節(jié)能、快速、高流量博客網(wǎng)站Steemit就使用了它。EOS 的塊時間是 0.5 秒。
不足：
略為中心化、擁有高權(quán)益的參與者可投票使自己成為一名驗證者。這是近期已在 EOS 中出現(xiàn)的問題。
采用者：BitShares、Steemit、EOS、Lisk、Ark。
類型：協(xié)同型共識
解釋：在 DPoS 系統(tǒng)中，權(quán)益持有者可以選舉領(lǐng)導(dǎo)者（或稱為見證人，Witness）。經(jīng)權(quán)益持有者授權(quán)，這些領(lǐng)導(dǎo)者可進(jìn)行投票。該機制使得 DPoS 要快于正常的 PoS。
例如，EOS 中選舉出 21 位見證人，并且有一堆節(jié)點（潛在的見證人）作為候選者。一旦見證人節(jié)點死亡或是做出了惡意行為，新節(jié)點就會立刻替代見證人節(jié)點。見證人會因為生成區(qū)塊而獲得一筆支付費用。該費用是由權(quán)益持有者設(shè)立的 。
通常，所有節(jié)點采用輪詢方式，一次生成一個區(qū)塊。該機制防止一個節(jié)點發(fā)布連續(xù)的塊，進(jìn)而執(zhí)行“雙重支付”攻擊。如果一個見證人在分配給他的時間槽中未生成區(qū)塊，那么該時間槽就被跳過，并由下一位見證人生成下一個區(qū)塊。如果見證人持續(xù)丟失他的區(qū)塊，或是發(fā)布了錯誤的交易，那么權(quán)益持有者將投票決定其退出，用更好的見證人替換他。
在 DPoS 中，礦工可以合作生成塊，而不是像在 PoW 和 PoS 中那樣競爭生成。通過區(qū)塊生成的部分中心化，DPoS 的運行可以比其它共識算法呈數(shù)量級快。
從某種角度來看，DPOS有點像是議會制度或人民代表大會制度。如果代表不能履行他們的職責(zé)（當(dāng)輪到他們時，沒能生成區(qū)塊），他們會被除名，網(wǎng)絡(luò)會選出新的超級節(jié)點來取代他們。EOS就是采用DPOS共識算法。
技術(shù)原理：
假設(shè)n為21，競選的節(jié)點有幾百個，持幣人對這些節(jié)點進(jìn)行投票，選出票數(shù)最多的21位，由這21位輪流來出塊。
GO DEMO簡單實現(xiàn)：

package mainimport ("fmt""math/rand""time""strconv""crypto/sha256""encoding/hex" )type Block struct {Index intTimestamp stringPrehash stringHash stringData []bytedelegate *Node// 代理 區(qū)塊由哪個節(jié)點挖出 }func GenesisBlock() Block {gene := Block{0, time.Now().String(),"", "", []byte("genesis block"), nil}gene.Hash = string(blockHash(gene))var delegate *Node = new(Node)delegate.Name = "Genis Block"delegate.Votes = 0;gene.delegate = delegatereturn gene }func blockHash(block Block) []byte {record := strconv.Itoa(block.Index) + block.Timestamp + block.Prehash + hex.EncodeToString(block.Data)h := sha256.New()h.Write([]byte(record))hashed := h.Sum(nil)return hashed }//節(jié)點類型 type Node struct {Name string //節(jié)點名稱Votes int // 被選舉的票數(shù) }func (node *Node)GenerateNewBlock(lastBlock Block, data []byte) Block {var newBlock = Block{lastBlock.Index+1, time.Now().String(), lastBlock.Hash, "", data, nil}newBlock.Hash = hex.EncodeToString(blockHash(newBlock))newBlock.delegate = nodereturn newBlock}//創(chuàng)建節(jié)點 var NodeArr = make([]Node,10) func CreateNode() {for i := 0; i < 10; i++ {name := fmt.Sprintf("NODE %d num", i+1)NodeArr[i] = Node{name, 0}}}//簡單模擬投票 func Vote() {for i := 0; i < 10; i++ {rand.Seed(time.Now().UnixNano())vote := rand.Intn(10) + 1NodeArr[i].Votes = vote} }//選出票數(shù)最多的前3位 func SortNodes() []Node {n:= NodeArrfor i := 0; i<len(n) ;i++ {for j := 0; j < len(n)-1 ;j++ {if n[j].Votes < n[j+1].Votes {n[j],n[j+1] = n[j+1],n[j]}}}return n[:3] }func main() {CreateNode()fmt.Println(NodeArr)Vote()nodes := SortNodes()fmt.Println(nodes)//創(chuàng)建創(chuàng)世區(qū)塊gene := GenesisBlock()lastBlock := genefor i:= 0; i< len(nodes) ;i++ {//打印新區(qū)塊信息// var node *Nodenode := lastBlock.delegatefmt.Println("區(qū)塊號:",lastBlock.Index,"節(jié)點名稱:",node.Name,"節(jié)點投票數(shù):",node.Votes)lastBlock = nodes[i].GenerateNewBlock(lastBlock,[]byte(fmt.Sprintf("new block %d",i)))}}

輸出結(jié)果： [{NODE 1 num 0} {NODE 2 num 0} {NODE 3 num 0} {NODE 4 num 0}
{NODE 5 num 0} {NODE 6 num 0} {NODE 7 num 0} {NODE 8 num 0} {NODE 9
num 0} {NODE 10 num 0}] [{NODE 1 num 3} {NODE 2 num 3} {NODE 3 num 3}]
區(qū)塊號: 0 節(jié)點名稱: Genis Block 節(jié)點投票數(shù): 0 區(qū)塊號: 1 節(jié)點名稱: NODE 1 num 節(jié)點投票數(shù): 3
區(qū)塊號: 2 節(jié)點名稱: NODE 2 num 節(jié)點投票數(shù): 3

2.4 拜占庭容錯（PBFT，Practical Byzantine Fault Tolerance）

優(yōu)點：高速、可擴(kuò)展。
不足：通常用于私有網(wǎng)絡(luò)和許可網(wǎng)絡(luò)。
采用者：Hyperledger Fabric、Stellar、Ripple、Dispatch
解釋：拜占庭將軍問題是分布式計算中的一個經(jīng)典問題。問題描述為，幾位拜占庭將軍分別率領(lǐng)部隊合力包圍了一座城市。他們必須一致決定是否發(fā)起攻城。如果一些將軍在沒有其他將軍參與的情況下決定發(fā)起攻城，那么他們的行動將以失敗告終。將軍們之間相互隔著一定的距離，必須依靠信息傳遞進(jìn)行交流。 一些加密貨幣協(xié)議在達(dá)成共識時使用了特定版本的 BFT，每種版本都具有各自的優(yōu)缺點：
[1] 實用拜占庭容錯（PBFT，Practical Byzantine Fault Tolerance）：首個提出的該問題解決方案稱為“實用拜占庭容錯”（PBFT），當(dāng)前已被 Hyperledger Fabric 采用。PBFT 使用了較少（少于 20 個，之后會稍有增加）的預(yù)選定將軍數(shù)，因此運行非常高效。它的優(yōu)點是高交易通量和吞吐量，但是不足之處在于是中心化的，并用于許可網(wǎng)絡(luò)。

從某種角度來看，PBFT有點像《天黑請閉眼殺人游戲》的玩法。

[2] 聯(lián)邦拜占庭協(xié)議（FBA，Federated Byzantine Agreement）：另一類拜占庭將軍問題的解決方案是 FBA，已被 Stellar 和 Ripple 等代幣使用。FBA 的通用理念是每個拜占庭將軍負(fù)責(zé)自身的鏈、消息一旦到來，通過排序建立事實。在 Ripple 中，將軍（驗證者）是 Ripple 基金會預(yù)先選定的。在 Stellar 中，任何人都可以成為驗證者，需要用戶選擇去相信哪個驗證者。
由于 FBA 可提供令人難以置信的吞吐量、低交易開銷和網(wǎng)絡(luò)擴(kuò)展性，我相信 FBA 類公式算法是目前提出的最好的分布式共識發(fā)現(xiàn)算法。
技術(shù)原理：
PBFT基于拜占庭將軍問題，一致性的確保主要分為這三個階段：預(yù)準(zhǔn)備（pre-prepare）、準(zhǔn)備(prepare)和確認(rèn)(commit)。流程如下圖所示：

其中C為發(fā)送請求端，0123為服務(wù)端，3為宕機的服務(wù)端，具體步驟如下：

1.Request：請求端C發(fā)送請求到任意一節(jié)點，這里是0
2.Pre-Prepare：服務(wù)端0收到C的請求后進(jìn)行廣播，擴(kuò)散至123
3.Prepare：123,收到后記錄并再次廣播，1->023，2->013，3因為宕機無法廣播
4.Commit：0123節(jié)點在Prepare階段，若收到超過一定數(shù)量的相同請求，則進(jìn)入Commit階段，廣播Commit請求；
5.Reply：0123節(jié)點在Commit階段，若收到超過一定數(shù)量的相同請求，則對C進(jìn)行反饋；

更多原理細(xì)節(jié)可參考《第13課 共識層PBFT共識算法》
)

GO demo代碼樣例：

package mainimport ("os""fmt""net/http""io" )//聲明節(jié)點信息,代表各個小國家 type nodeInfo struct {//標(biāo)示id string//準(zhǔn)備訪問的方法path string//服務(wù)器做出的相應(yīng)writer http.ResponseWriter}//存放四個國家的地址 var nodeTable = make(map[string]string)//拜占庭在Fabric中的使用 func main() {//獲取執(zhí)行的參數(shù)userId :=os.Args[1]//獲取執(zhí)行的第一個參數(shù)fmt.Println(userId)//./main Apple//創(chuàng)建四個國家的地址nodeTable = map[string]string {"Apple":"localhost:1111","MS":"localhost:1112","Google":"localhost:1113","IBM":"localhost:1114",}node:=nodeInfo{userId,nodeTable[userId],nil}fmt.Println(node)//http協(xié)議的回調(diào)函數(shù)//http://localhost:1111/req?warTime=8888http.HandleFunc("/req",node.request)http.HandleFunc("/prePrepare",node.prePrepare)http.HandleFunc("/prepare",node.prepare)http.HandleFunc("/commit",node.commit)//啟動服務(wù)器if err:=http.ListenAndServe(node.path,nil);err!=nil {fmt.Print(err)}}//此函數(shù)是http訪問時候req命令的請求回調(diào)函數(shù) func (node *nodeInfo)request(writer http.ResponseWriter,request *http.Request){//設(shè)置允許解析參數(shù)request.ParseForm()//如果有參數(shù)值，則繼續(xù)處理if (len(request.Form["warTime"])>0){node.writer = writer//激活主節(jié)點后，廣播給其他節(jié)點,通過Ａpple向其他節(jié)點做廣播node.broadcast(request.Form["warTime"][0],"/prePrepare")}}//由主節(jié)點向其他節(jié)點做廣播 func (node *nodeInfo)broadcast(msg string ,path string ){//遍歷所有的國家for nodeId,url:=range nodeTable {if nodeId == node.id {continue}//調(diào)用Get請求//http.Get("http://localhost:1112/prePrepare?warTime=8888&nodeId=Apple")http.Get("http://"+url+path+"?warTime="+msg+"&nodeId="+node.id)}}func (node *nodeInfo)prePrepare(writer http.ResponseWriter,request *http.Request) {request.ParseForm()//fmt.Println("hello world")//在做分發(fā)if(len(request.Form["warTime"])>0){//分發(fā)給其他三個人node.broadcast(request.Form["warTime"][0],"/prepare")}}func (node *nodeInfo)prepare(writer http.ResponseWriter,request *http.Request){request.ParseForm()//調(diào)用驗證if len(request.Form["warTime"])>0{fmt.Println(request.Form["warTime"][0])}if len(request.Form["nodeId"])>0 {fmt.Println(request.Form["nodeId"][0])}node.authentication(request) }var authenticationsuccess = true var authenticationMap = make(map[string]string) //獲得除了本節(jié)點外的其他節(jié)點數(shù)據(jù) func (node *nodeInfo)authentication(request *http.Request) {//接收參數(shù)request.ParseForm()if authenticationsuccess!=false {if len(request.Form["nodeId"])>0 {authenticationMap[request.Form["nodeId"][0]]="ok"}}if len(authenticationMap)>len(nodeTable)/3 {//則拜占庭原理實現(xiàn),通過commit反饋給瀏覽器node.broadcast(request.Form["warTime"][0],"/commit")} }func (node *nodeInfo)commit(writer http.ResponseWriter,request *http.Request){//給瀏覽器反饋相應(yīng)io.WriteString(node.writer,"ok")}

如何運行：開啟4個終端，eg：

./pbft Apple ./pbft IBM ./pbft MS ./pbft Google

然后在瀏覽器輸入：http://localhost:1112/req?warTime=1234 輸出結(jié)果：

okokok

2.5 分布式一致性協(xié)議- RAFT算法

優(yōu)點：
模型比Paxos更簡單，但提供了同等的安全性。有多種語言的實現(xiàn)可用。
不足：通常用于私有網(wǎng)絡(luò)和許可網(wǎng)絡(luò)。
采用者：IPFS Private Cluster、Quorum。
解釋：
將拜占庭將軍問題根據(jù)常見的工作上的問題進(jìn)行簡化：假設(shè)將軍中沒有叛軍，信使的信息可靠但有可能被暗殺的情況下，將軍們?nèi)绾芜_(dá)成一致性決定？
對于這個簡化后的問題，有許多解決方案，第一個被證明的共識算法是 Paxos，由拜占庭將軍問題的作者 Leslie Lamport 在1990年提出，但其論文難懂而出名，所以斯坦福大學(xué)的教授在2014年發(fā)表了新的分布式協(xié)議 Raft。與 Paxos 相比，Raft 有著基本相同運行效率，但是更容易理解，也更容易被用在系統(tǒng)開發(fā)上。
我們還是用拜占庭將軍的例子來幫助理解 Raft。

假設(shè)將軍中沒有叛軍，信使的信息可靠但有可能被暗殺的情況下，將軍們?nèi)绾芜_(dá)成一致性決定？

Raft 的解決方案大概可以理解成 先在所有將軍中選出一個大將軍，所有的決定由大將軍來做。選舉環(huán)節(jié)：比如說現(xiàn)在一共有3個將軍 A, B, C，每個將軍都有一個隨機時間的倒計時器，倒計時一結(jié)束，這個將軍就會把自己當(dāng)成大將軍候選人，然后派信使去問其他幾個將軍，能不能選我為總將軍？假設(shè)現(xiàn)在將軍A倒計時結(jié)束了，他派信使傳遞選舉投票的信息給將軍B和C，如果將軍B和C還沒把自己當(dāng)成候選人（倒計時還沒有結(jié)束），并且沒有把選舉票投給其他，他們把票投給將軍A，信使在回到將軍A時，將軍A知道自己收到了足夠的票數(shù)，成為了大將軍。在這之后，是否要進(jìn)攻就由大將軍決定，然后派信使去通知另外兩個將軍，如果在一段時間后還沒有收到回復(fù)（可能信使被暗殺），那就再重派一個信使，直到收到回復(fù)。
技術(shù)原理：
Raft要求系統(tǒng)在任意時刻最多只有一個Leader，正常工作期間只有Leader和Followers。Raft算法將時間分為一個個的任期（term），每一個term的開始都是Leader選舉。在成功選舉Leader之后，Leader會在整個term內(nèi)管理整個集群。如果Leader選舉失敗，該term就會因為沒有Leader而結(jié)束。

（1）Raft 節(jié)點狀態(tài)
從拜占庭將軍的故事映射到分布式系統(tǒng)上，每個將軍相當(dāng)于一個分布式網(wǎng)絡(luò)節(jié)點，每個節(jié)點有三種狀態(tài)：Follower，Candidate，Leader，狀態(tài)之間是互相轉(zhuǎn)換的，可以參考下圖：

每個節(jié)點上都有一個倒計時器 (Election Timeout)，時間隨機在 150ms 到 300ms 之間。有幾種情況會重設(shè) Timeout：
（1）收到選舉的請求
（2）收到 Leader 的 Heartbeat (后面會講到)
在 Raft 運行過程中，最主要進(jìn)行兩個活動：
（1）選主 Leader Election
（2）復(fù)制日志 Log Replication

技術(shù)原理
（1）選主 Leader Election
1）正常情況下選主
假設(shè)現(xiàn)在有如圖5個節(jié)點，5個節(jié)點一開始的狀態(tài)都是 Follower。

在一個節(jié)點倒計時結(jié)束 (Timeout) 后，這個節(jié)點的狀態(tài)變成 Candidate 開始選舉，它給其他幾個節(jié)點發(fā)送選舉請求 (RequestVote)

其他四個節(jié)點都返回成功，這個節(jié)點的狀態(tài)由 Candidate 變成了 Leader，并在每個一小段時間后，就給所有的 Follower 發(fā)送一個 Heartbeat 以保持所有節(jié)點的狀態(tài)，Follower 收到 Leader 的 Heartbeat 后重設(shè) Timeout。

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

（2） 2.2 Leader 出故障情況下的選主

一開始已經(jīng)有一個 Leader，所有節(jié)點正常運行。

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

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

（3）2.3 多個 Candidate 情況下的選主

假設(shè)一開始有4個節(jié)點，都還是 Follower。

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

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

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

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

這時，兩個節(jié)點的狀態(tài)是 Candidate，兩個是 Follower，但是他們的倒計時器仍然在運行，最先 Timeout 的那個節(jié)點會進(jìn)行發(fā)起新一輪 Term 3 的投票。

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

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

兩個 Follower 已經(jīng)投完票了，拒絕了這個 Candidate 的投票請求。

Leader 進(jìn)行 Heartbeat， Candidate 收到后狀態(tài)自動轉(zhuǎn)為 Follower，完成選主。

實現(xiàn)代碼參考： https://github.com/goraft/raft 或者
https://github.com/happyer/distributed-computing/tree/master/src/raft

2.6 有向無環(huán)圖（DAG，Directed Acyclic Graphs）

優(yōu)點：
由于 DAG 的非線性結(jié)構(gòu)，它是高度可擴(kuò)展的、快速、節(jié)能、立即實現(xiàn)終結(jié)性（Finality）。
不足：只能通過使用 Oracle 實現(xiàn)智能合約。
采用者：Iota、HashGraph、Byteball、RaiBlocks/Nano。
解釋：DAG 是一種更通用形式的區(qū)塊鏈。由于其獨特結(jié)構(gòu)，DAG 內(nèi)在支持高可擴(kuò)展性，因此也得到了廣泛的使用。

從根本上說，任何區(qū)塊鏈系統(tǒng)都具有線性結(jié)構(gòu)，因為區(qū)塊是依次添加到鏈中的。這使得相比于并行向鏈中添加區(qū)塊，線性區(qū)塊鏈在本質(zhì)上是非常緩慢的。但是對于 DAG 而言，每個區(qū)塊和交易只需數(shù)個前期區(qū)塊得到確認(rèn)，就可以并行地添加到區(qū)塊和交易中。這意味著，DAG 在本質(zhì)上是高可擴(kuò)展的。

DAG 存在多種變體，取決于：
· 如何選取前期區(qū)塊驗證的算法，也稱為“Tip 選擇算法”。
· 交易完成的順序。
· 如何抵達(dá)完成狀態(tài)。

下面列出一些廣為使用的 DAG 項目。

1 Tangle（IOTA）
image

解釋：Tangle是一種 DAG 共識算法，由 IOTA 使用。為了發(fā)送一個 IOTA 交易，用戶需要驗證接收到的前兩個交易。在更多交易添加到 Tangle 的情況下，這種二對一、前瞻性支付的共識可加強交易的有效性。由于共識是由交易確定的，因此理論上，如果有人可以生成三分之一的交易，那么他就可以說服網(wǎng)絡(luò)中的其余部分，使得他的無效交易變成有效的。一旦交易量足夠大，使得個人難以創(chuàng)建三分之一交易量，這時 IOTA 就會在一個稱為“協(xié)調(diào)器（The Coordinator）”的中心節(jié)點上對網(wǎng)絡(luò)中的所有交易做“復(fù)核”（double-checking）。按 ITOA 的說法，協(xié)調(diào)員的工作類似于輔助輪。一旦 Tangle 達(dá)到一定的規(guī)模，協(xié)調(diào)員就會被從中移除。

2 Hashgraph
解釋：Hashgraph 是由 Leemon Baird 開發(fā)的一種 Gossip 協(xié)議共識。節(jié)點隨機與其它節(jié)點共享自身已知的交易，最終所有交易都被以 Gossip 協(xié)議傳播到（Gossip around）到所有節(jié)點。Hashgraph 對于私有網(wǎng)絡(luò)是一個很好的選擇。但我們并不會看到它實現(xiàn)在以太坊這樣的公共網(wǎng)絡(luò)中，或是不通過 Gossip 協(xié)議隨機傳播交易。

3 Holochain
解釋：Holochain 十分類似于 HashGraph，但不同于 Hashgraph。它提供了一種可用于構(gòu)建去中心化應(yīng)用的數(shù)據(jù)結(jié)構(gòu)。用戶可以具有自己的鏈，并向其中添加包括金融交易在內(nèi)的數(shù)據(jù)。鏈可以采用復(fù)雜的方式合并、拆分和交互。數(shù)據(jù)以去中心化的方式存儲（類似于 Bittorrent）。數(shù)據(jù)具有一個哈希值，即一個對應(yīng)于數(shù)據(jù)的數(shù)學(xué)指紋。如果有人意圖篡改數(shù)據(jù)，那么我們就會注意到在數(shù)據(jù)和哈希值之間存在不匹配，這樣就可拒絕數(shù)據(jù)為無效的。數(shù)字簽名保證了數(shù)據(jù)的作者身份。Holochain 可看成是“Bittorrent+git+ 數(shù)字簽名”。

4 Block-Nano

解釋：Nano（以前稱為 Raiblocks）是以纏繞在區(qū)塊鏈上的方式運行，這種方式被稱為“塊狀格子”（Block-lattice）。在 Block-lattice 結(jié)構(gòu)中，每個用戶（地址）都有自己的鏈，只有用戶本身可寫，每個用戶都擁有所有鏈的副本。

每個交易都可分解為發(fā)送者鏈上的發(fā)送區(qū)塊，以及接收者鏈上的接收區(qū)塊。Block-lattice 看上似乎太簡單，以至于無法工作，但它已經(jīng)在實際運行了。Block-lattice 的獨特結(jié)構(gòu)的確無法抵制一些獨特的攻擊向量，例如 Penny-spend 攻擊。在這種攻擊中，攻擊者通過向大量空錢包發(fā)送數(shù)額可忽略不計的金錢，導(dǎo)致必須要追蹤的鏈數(shù)量急劇膨脹。

5 SPECTRE

解釋：SPECTRE，即“序列化 PoW 事件并通過遞歸選舉確認(rèn)交易”（Serialization of Proof-of-work Events， Confirming Transactions via Recursive Elections），是提議的一種 Bitcoin 擴(kuò)展解決方案。它利用 PoW 和 DAG 的組合實現(xiàn)可擴(kuò)展的共識。在 SPECTER 中，一個挖掘的區(qū)塊指向多個父節(jié)點，而不僅僅是單個節(jié)點，這使得網(wǎng)絡(luò)每秒可以處理多個區(qū)塊。而挖掘指向某些父區(qū)塊的區(qū)塊，這將支持區(qū)塊的有效性。與 PoW 的“最長鏈勝出”的原則相比，SPECTER 使用的原則可描述為“擁有最多子節(jié)點的區(qū)塊勝出”。SPECTRE 尚未得到實際運行測試，因此可能會存在一些新的攻擊向量。但我認(rèn)為，SPECTRE 很有可能成為一種修正 Bitcoin 問題的潛在好做法。

6 ByteBall

解釋：ByteBall 使用 DAG 建立交易間的偏序關(guān)系，此外還在 DAG 中添加了“主鏈”（MC，Main Chain）。

圖 DAG 中加粗顯示的“主鏈”

MC 允許在交易間定義全序關(guān)系，即更早加入（直接或間接）MC 的交易，必定更早出現(xiàn)在全序中。如果存在“雙重支付”問題，那么將視較早出現(xiàn)在全序中的交易版本為有效的，而其它所有的交易均被視為是無效的。

根據(jù)交易在圖中的位置，MC 可得到確定性的定義。相關(guān)詳細(xì)信息，請參閱白皮書。作為一般性規(guī)則，MC 傾向于采納由一些總所周知用戶所給出的交易，這樣的用戶被稱為“證人”（Witnesses）。證人列表是由用戶自己定義的，因為列表中包括了用戶發(fā)布的每個交易。然后，MC 沿著 DAG 內(nèi)路徑推進(jìn)。推進(jìn)原則包括：

· MC 上相鄰交易的證人列表要么完全相同，要么只存在一個突變。

· 與其它鏈相比，MC 中為經(jīng)過最多數(shù)量的由見證人認(rèn)證的交易。

ByteBall 也是首個在系統(tǒng)中包含 Oracle 的平臺。Oracle 是在 DAG 中添加智能合約功能所必需的。
2.7 容量證明（PoC，Proof of Capacity）

優(yōu)點：
它類似于 PoW，只是使用空間替代了計算。因此更加環(huán)境友好。

可用于惡意軟件檢測。通過確定處理器的 L1 緩存是否為空（例如，具有足夠空間在沒有緩存未命中的情況下計算 PoSpace 過程），或是包含一個拒絕被逐出（evicted）的例程。

可用于反垃圾郵件措施，以及防范拒絕服務(wù)（DoS）攻擊。

不足：激勵機制可能存在問題。

使用者： Butcoin、Chia、SpaceMint。

類型：協(xié)同型共識。

解釋：PoSpace，也稱為 PoC，通過分配一定數(shù)量的內(nèi)存或磁盤空間用于解決服務(wù)提供者所提供挑戰(zhàn)的方式，顯示了某個人對某個服務(wù)（例如發(fā)送郵件）具有合法的興趣。該理念是由 Dziembowski 等在 2015 年形式化定義的。雖然 Ateniese 等人的論文名稱也是“Proof-of-space”，但它事實上一種采用 MHF（Memory Hard Function，一種計算代價取決內(nèi)存的哈希算法）的 PoW 協(xié)議。

PoSpace 非常類似于 PoW，只是使用存儲替代了 Pow 中的計算。PoSpace 與 MHF 和可回收性證明（PoR，Proof of Retrievability）有關(guān)，但也在很大程度上存在著差異。

PoSpace 是由證明者 （Prover） 發(fā)送給驗證者 （Verifier） 的一小塊數(shù)據(jù)，該數(shù)據(jù)確認(rèn)了證明者已經(jīng)保留了一定量的空間。出于實用性上的考慮，驗證過程需要盡量高效，即消耗盡可能少的空間和時間。出于公平性上的考慮，如果驗證者沒有保留所聲明數(shù)量的空間，那么它應(yīng)該難以通過驗證。PoSpace 的一種實現(xiàn)方式是通過使用一個難以實現(xiàn) Pebbling 的圖。驗證者請求證明者構(gòu)建對一個“非 Pebbling 圖”標(biāo)記。證明者提交標(biāo)記，進(jìn)而驗證者請求證明者在提交中開放多個隨機位置。

由于存儲的通用本質(zhì)，以及存儲所需的更低耗能，PoSpace 被認(rèn)為是一種更公平、更綠色的替換方法。
2.8 延遲工作量證明（dPoW，Delayed Proof-of-Work）、

優(yōu)點：
節(jié)能、安全性增加、可以通過非直接提供 Bitcoin（或是其它任何安全鏈），添加價值到其它區(qū)塊鏈，無需付出 Bitcoin（或是其它任何安全鏈）交易的代價。
不足：
只有使用 PoW 或 PoS 的區(qū)塊鏈，才能采用這種共識算法。
在“公證員激活”（Notaries AcTIve）模式下，必須校準(zhǔn)不同節(jié)點（公證員或正常節(jié)點）的哈希率，否則哈希率間的差異會爆炸（下文將給出詳細(xì)解釋）。
采用者：Komodo
類型：協(xié)同型共識（CollaboraTIve consensus）
解釋：dPoW 是一種混合共識方法，允許一個區(qū)塊鏈利用第二個區(qū)塊鏈的哈希算力（Hashing Power）所提供的安全。該機制是通過一組公證員節(jié)點（Notary Node）實現(xiàn)的。公證員節(jié)點實現(xiàn)將第一個區(qū)塊鏈的數(shù)據(jù)添加到第二個區(qū)塊鏈中。進(jìn)而，第二個區(qū)塊鏈請求在兩個區(qū)塊鏈間達(dá)成妥協(xié)，弱化第一個區(qū)塊鏈的安全。Komodo是首個使用該共識方法的區(qū)塊鏈，它就是附加于 Bitcoin 區(qū)塊鏈之上的。

使用 dPoW 的區(qū)塊鏈也可以使用 PoW 或 PoS 共識方法工作，并可以附加在任何采用 PoW 的區(qū)塊鏈上。但對于由 dPoW 提供安全的區(qū)塊鏈，當(dāng)前 Bitcoin 給出了最高安全層級的哈希率。下圖展示了主區(qū)塊鏈的單個記錄以及其所附著的 PoW 區(qū)塊鏈。

dPoW 系統(tǒng)中有兩種類型的節(jié)點：公證人節(jié)點和正常節(jié)點。64 個公證人節(jié)點是由 dPoW 區(qū)塊鏈的權(quán)益持有者（stakeholder）選舉產(chǎn)生的，它們可從 dPoW 區(qū)塊鏈向所附加的 PoW 區(qū)塊鏈添加經(jīng)公證確認(rèn)的塊。一旦添加了一個塊，該塊的哈希值將被添加到由 33 個公證人節(jié)點簽署的 Bitcoin 交易中，并創(chuàng)建一個哈希到 Bitcoin 區(qū)塊鏈的 dPow 塊記錄。該記錄已被網(wǎng)絡(luò)中的大多數(shù)公證人節(jié)點公證。

為避免公證人節(jié)點間在挖礦上產(chǎn)生戰(zhàn)爭，進(jìn)而降低網(wǎng)絡(luò)的效率，Komodo 設(shè)計了一種采用輪詢機制的挖礦方法。該方法具有兩種運行模式。在“無公證人”（No Notary）模式下，支持所有網(wǎng)絡(luò)節(jié)點參與挖礦，這類似于傳統(tǒng) PoW 共識機制。而在“公證人激活”（Notaries AcTIve）模式下，網(wǎng)絡(luò)公證人使用一種顯著降低的網(wǎng)絡(luò)難度率挖礦。“公證人激活”模式下，允許每位公證人使用其當(dāng)前的難度挖掘一個區(qū)塊，而其它公證人節(jié)點必須采用 10 倍難度挖礦，所有正常節(jié)點使用公證人節(jié)點難度的 100 倍挖礦。

但這會導(dǎo)致一些問題。我在與 Komodo 創(chuàng)始人的一次談話中提及，這將導(dǎo)致公證人礦工和正常礦工間的哈希率存在很高的差異：

圖 本文作者與 Komodo 創(chuàng)始人間就不一致性問題進(jìn)行交流的截圖

dPoW 系統(tǒng)在設(shè)計上支持區(qū)塊鏈在沒有公證人節(jié)點的情況下繼續(xù)運行。在這種情況下，dPoW 區(qū)塊鏈可以基于初始的共識方法繼續(xù)運行，但將不再具有所附著區(qū)塊鏈增添的安全。

所有使用 dPoW 的區(qū)塊鏈可增加安全，同時降低能耗。例如，Komodo 使用 Equihash 哈希算法防止使用 ASIC 挖礦。其公證人節(jié)點依賴于一種輪詢挖礦方法，獎勵機制考慮了降低節(jié)點間競爭的可能性。這些節(jié)點將會引發(fā)過度耗能或算力。

此外通過非直接提供 Bitcoin 安全，Komodo 這類 dPoW 區(qū)塊鏈可以向其它區(qū)塊鏈添加價值，無需付出任何 Bitcoin 交易的代價。Komodo 此后附著到 Bitcoin，而第三個使用 dPoW 的區(qū)塊鏈可以將自身附著到 Komodo。使用這種方式，dPoW 區(qū)塊鏈不必直接附著到 Bitcoin 區(qū)塊鏈，就從 Bitcoin 的高哈希率中受益。

最后一點，公證人節(jié)點和正常節(jié)點分離的功能，確保了初始共識機制在公證人節(jié)點失敗時繼續(xù)運行。這種相互獨立性建立了一種獎勵機制，使得其它網(wǎng)絡(luò)無需依賴于 Bitcoin 網(wǎng)絡(luò)的直接功能，即可支持 Bitcoin 網(wǎng)絡(luò)的繼續(xù)維護(hù)。
2.9 權(quán)威證明（PoA，Proof-of-Authority）

優(yōu)點：節(jié)能、快速。
不足：略為中心化。雖然可用于公有區(qū)塊鏈，但是通常用于私有區(qū)塊鏈和許可區(qū)塊鏈。

使用者：POA.Network、Ethereum Kovan testnet、VeChain。
類型：協(xié)同型共識。

解釋：基于 PoA 的網(wǎng)絡(luò)、事務(wù)和區(qū)塊，是由一些經(jīng)認(rèn)可的賬戶認(rèn)證的，這些被認(rèn)可的賬戶稱為“驗證者”（Validator）。驗證者運行的軟件，支持驗證者將交易（transaction）置于區(qū)塊中。該過程是自動的，無需驗證者持續(xù)監(jiān)控計算機，但需要維護(hù)計算機（權(quán)威節(jié)點）不妥協(xié)（uncompised）。

驗證者必須滿足以下三個條件：

其身份必須在鏈上得到正式驗證，信息可在公有可用域中交叉驗證。

其資格必須難以獲得，這樣所得到的驗證塊的權(quán)利才彌足珍貴（例如，潛在的驗證者需要獲得公證書）。

建立權(quán)威的檢查和程序必須完全統(tǒng)一。

使用 PoA，每個個體都具有變成驗證者的權(quán)利，因此存在一旦獲取就保持驗證者位置的動機。通過對身份附加一個聲譽，可以鼓勵驗證者去維護(hù)交易的過程。因為驗證者并不希望讓自己獲得負(fù)面聲譽，這會使其失去來之不易的驗證者地位。
2.10 權(quán)重證明（PoWeight，Proof-of-Weight）

優(yōu)點：節(jié)能、高度可定制和可擴(kuò)展
不足：可能難以實現(xiàn)激勵、
采用者：Algorand。
類型：有競爭共識。
解釋：權(quán)重證明（PoWeight）是一類很寬泛的共識算法，它基于Algorand共識模型。其基本理念是在 PoS 中，用戶所擁有的網(wǎng)絡(luò)中令牌的百分比，表示了該用戶“發(fā)現(xiàn)”下一個區(qū)塊的概率。PoWeight 系統(tǒng)中還使用了其它一些相對加權(quán)值，實現(xiàn)包括聲望證明（PoR，Proof of Reputation）和空間證明（Proof of Space）。
2.11. 聲譽證明（PoR，Proof of Reputation）

優(yōu)點：非常適用于私有區(qū)塊鏈和許可區(qū)塊鏈。
不足：只能用于私有區(qū)塊鏈和許可區(qū)塊鏈。
采用者：GoChain。
類型：協(xié)同型共識。
解釋：PoR 類似于 PoA。GoChain 文檔中給出了如下描述：
PoR 共識模型依賴參與者在保持網(wǎng)絡(luò)安全中的聲譽。參與者（區(qū)塊簽名者）必須具有足夠重要的聲譽。一旦他們嘗試欺騙系統(tǒng)，那么他們將要面對嚴(yán)重的財政上的和自己名聲上的后果。這是一個相對的概念，如果他們被抓到試圖欺騙，那么幾乎所有的業(yè)務(wù)將會受到嚴(yán)重的影響。規(guī)模越大的企業(yè)，通常將會失去更多。這樣，相比使用更少的企業(yè)（即更小規(guī)模的商業(yè)），規(guī)模更大的企業(yè)更易于被選定。

一旦一個企業(yè)證明了自己的聲譽，并通過了驗證，那么他們必須經(jīng)投票參與到權(quán)威節(jié)點網(wǎng)絡(luò)中。這時，PoR 的操作與 PoA 網(wǎng)絡(luò)一樣，即只有權(quán)威節(jié)點可以簽名并驗證區(qū)塊。
2.12. 所用時間證明（PoET，Proof of Elapsed Time）

優(yōu)點：
參與代價低。更多人可輕易加入，進(jìn)而達(dá)到去中心化。
對于所有參與者而言，更易于驗證領(lǐng)導(dǎo)者是通過合法選舉產(chǎn)生的。
控制領(lǐng)導(dǎo)者選舉過程的代價，是與從中獲得的價值成正比的。
不足：
盡管 PoET 的代價低，但是必須要使用特定的硬件。因此不會被大規(guī)模采納。
不適用于公有區(qū)塊鏈。

采用者：HyperLedger Sawtooth

類型：有競爭共識

解釋：PoET 共識機制算法通常用于許可區(qū)塊鏈網(wǎng)絡(luò)，它可決定網(wǎng)絡(luò)中獲得區(qū)塊者的挖礦權(quán)利。許可區(qū)塊鏈網(wǎng)絡(luò)需要任何預(yù)期參與者在加入前驗證身份。根據(jù)公平彩票系統(tǒng)的原則，每個節(jié)點具有同等的可能成為勝出者。PoET 機制賦予大量可能的網(wǎng)絡(luò)參與者以平等勝出的機會。

PoET 的工作機制如下：網(wǎng)絡(luò)中的每位參與節(jié)點都必須等待一個隨機選取的時期，首個完成設(shè)定等待時間的節(jié)點將獲得一個新區(qū)塊。區(qū)塊鏈網(wǎng)絡(luò)中的每個節(jié)點會生成一個隨機的等待時間，并休眠一個設(shè)定的時間。最先醒來的節(jié)點，即具有最短等待時間的節(jié)點，喚醒并向區(qū)塊鏈提交一個新區(qū)塊，然后廣播必要的信息到整個對等網(wǎng)絡(luò)中。同一過程將會重復(fù)，以發(fā)現(xiàn)下一個區(qū)塊。

在 PoET 網(wǎng)絡(luò)共識機制中，需要確保兩個重要因素。第一，參與節(jié)點在本質(zhì)上會自然地選取一個隨機的時間，而非某一個參與者為勝出而刻意選取了較短的時間。第二，勝出者的確完成了等待時間。

PoET 理念是由著名的芯片制造巨頭 Intel于 2016 年早期提出的。Intel 為解決“隨機領(lǐng)導(dǎo)者選舉”的計算問題，實現(xiàn)了一個可用的高科技工具。

這種內(nèi)在機制允許應(yīng)用在受保護(hù)的環(huán)境中執(zhí)行受信任的代碼，它確保了上面提出的兩個要求得到滿足，即隨機選擇所有參與節(jié)點的等待時間，以及勝出參與者真正完成了等待時間。

這種在安全環(huán)境中運行可信代碼的機制也同時考慮到了其它一些網(wǎng)絡(luò)的需求。它確保了受信代碼的確運行在安全環(huán)境中，并不可被其它外部參與者更改。它也確保了結(jié)果可被外部參與者和實體驗證，進(jìn)而提高了網(wǎng)絡(luò)共識的透明度。

PoET 通過控制代價實現(xiàn)了共識過程，該代價依然是與從過程中獲得的價值成正比。這是保證加密貨幣經(jīng)濟(jì)持續(xù)繁榮的一個關(guān)鍵需求。
2.13 歷史證明（PoHistory，Proof of History）

采用者：Solana

解釋：其基本理念是不相信交易中的時間戳，而是證明交易在某個事件之前或之后的某個時刻發(fā)生。

如果我們對某期《紐約時報》的封面拍了張照片，那么我們就創(chuàng)建了一個證明，即我們的拍照時間是在該報紙發(fā)行之后，或許也可能是我們有某種途徑影響了紐約時報的正常發(fā)行。我們可以使用 PoHistory 創(chuàng)建一個歷史記錄，證明一個事件是發(fā)生在特定時間之后的。

區(qū)塊鏈共識算法全面詳解

PoHistory 是一種高頻可驗證延遲函數(shù)（VDF，Verifiable Delay Function）。VDF 求值需要完成特定數(shù)量的順序步驟，然后生成一個唯一的輸出。該輸出可被高效地和公開地驗證。

VDF 的一個特定實現(xiàn)使用了持續(xù)運行于其上的順序抗預(yù)映射哈希（Pre-image Resistant Hash），其中前一次循環(huán)生成的輸出將用于下一次循環(huán)的輸入。計數(shù)和當(dāng)前輸出形成周期性記錄。

如果使用了 SHA256 哈希函數(shù)，那么不使用 2128核的暴力攻擊，該過程是不可能并行化的。

因此我們可以確認(rèn)，每個計數(shù)器在生成過程中都的確經(jīng)歷了一定的時間。進(jìn)而，每個計數(shù)器記錄的順序與實時情況是一致的。

2.14 單點共識（SOLO）

使用者：Frabric
解釋：Solo共識模式是指Order節(jié)點為單節(jié)點通信模式，由Peer節(jié)點發(fā)送過來的消息由一個Order節(jié)點進(jìn)行排序和產(chǎn)生區(qū)塊。
由于排序服務(wù)只有一個Order為所有節(jié)點（Peer）服務(wù)，沒有高可用性和可擴(kuò)展性，不適合用于生產(chǎn)環(huán)境，可以用于開發(fā)和測試環(huán)境。
技術(shù)原理：
Solo共識工作時序如下圖所示。圖中所描述的范圍是在SDK發(fā)起交易到交易落地這整個過程。

在Order節(jié)點容器啟動時，啟動Solo排序服務(wù)，開啟監(jiān)SDK發(fā)送過來的消息，收到消息后調(diào)用Solo服務(wù)進(jìn)行數(shù)據(jù)區(qū)塊處理。其中，Solo模式調(diào)用過程說明：
（1）SDK通過gRPC連接Peer，發(fā)送交易信息Tx；
（2）Peer調(diào)用合約后，將返回結(jié)果再回復(fù)給SDK；
（3）SDK通過gRPC連接Order，將（2）的sdkPeerReply發(fā)送給Order，執(zhí)行Solo共識服務(wù)：
A.接收消息
B.消息入列
C.消息排序
D.消息切塊（根據(jù)時間或交易數(shù)量分切）
E.生成區(qū)塊
F.寫入?yún)^(qū)塊文件
G.通知Peers

首先order設(shè)置共識機制為“solo”，多機多節(jié)點部署需要至少兩臺服務(wù)器，一臺 Order 排序服務(wù)節(jié)點，一臺 peer 節(jié)點，每新加一臺額外的服務(wù)器都可作為新的 peer 節(jié)點來加盟。
2.15 活動證明（PoActivity，Proof Of Activity）

使用者：Decred

解釋：為避免出現(xiàn)惡性通貨膨脹（當(dāng)大量貨幣充斥系統(tǒng)時就會發(fā)生），比特幣將只生成兩千一百萬枚。這意味著，在某些時候，比特幣區(qū)塊獎勵補貼將終止，比特幣礦工將只能收取交易費用。

一些人猜測這可能會導(dǎo)致由“公地悲劇（Tragedy of the commons）”所引發(fā)的安全問題，人們出于自身利益考慮行事并破壞系統(tǒng)。因此，人們提出了PoActivity作為一種替代 Bitcoin 的激勵結(jié)構(gòu)。PoActivity 是一種結(jié)合了 PoW 和 PoS 的混合方法。

在 PoActivity 中，挖礦一開始使用的是傳統(tǒng)的 PoW，礦工們爭相解決加密難題。根據(jù)實現(xiàn)，挖掘的區(qū)塊不包含任何交易，它們更像模板。因此，勝出的區(qū)塊將只包含頭部信息，以及礦工的獎勵地址。

此時，系統(tǒng)將切換到 PoS。PoActivity 根據(jù)頭部信息選擇一組隨機驗證者對新區(qū)塊簽名。如果一位驗證者所擁有的系統(tǒng)中代幣越多，那么該驗證者被選中的可能性也會越大。一旦所有驗證者已簽名，那么模板就會變成一個完整的區(qū)塊。

如果在完成區(qū)塊時，某些選定的驗證者是不可用的，那么就選擇下一個勝出區(qū)塊，并選擇一組新的驗證者，依此類推，直到區(qū)塊收到到正確數(shù)量的簽名。費用由礦工和在區(qū)塊上簽名的驗證者分?jǐn)偂?/p>

對 PoActivity 的批評包括挖掘區(qū)塊耗能過高（與 PoW 一樣），以及無法阻止驗證者做雙重簽名（與 PoS 一樣）。

3，參考

（1）分布式共識算法專欄 - 匯集各種共識算法
https://recomm.cnblogs.com/blogpost/11284374?page=1

（2）區(qū)塊鏈共識算法全面詳解 http://www.elecfans.com/blockchain/843819.html

（3）共識算法DPOS原理及實現(xiàn) https://www.meiwen.com.cn/subject/hxqzyftx.html

（4）拜占庭PBFT簡單實現(xiàn) https://www.meiwen.com.cn/subject/prvjuftx.html

（5）PBFT算法 https://www.meiwen.com.cn/subject/owzvyxtx.html

總結(jié)

以上是生活随笔為你收集整理的15种区块链共识算法全面详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。