1.1共識機(jī)制

1.1.1核心定義

區(qū)塊鏈上的共識機(jī)制主要解決由誰來構(gòu)造區(qū)塊，以及如何維護(hù)區(qū)塊鏈統(tǒng)一的問題

1.1.2共識機(jī)制分類

1.1.3 共識算法

1.1.3.1 POW(工作量證明)

代表項目：BTC

由于不同的節(jié)點接受數(shù)據(jù)有所區(qū)別，為了保證數(shù)據(jù)一致性，每個區(qū)塊數(shù)據(jù)只能由一個節(jié)點進(jìn)行記錄。BTC通過“工作量證明”（Proof of Work，PoW）來確認(rèn)記賬節(jié)點。每個節(jié)點如果想生成一個新的區(qū)塊并寫入?yún)^(qū)塊鏈，必須解出比特幣網(wǎng)絡(luò)出的PoW問題。其關(guān)鍵的要素是工作量證明函數(shù)、區(qū)塊信息及難度值。工作量證明函數(shù)是這道題的計算方式，區(qū)塊決定了這道題的輸入數(shù)據(jù)，難度值決定了這道題所需要的計算量?？梢院唵卫斫獬删褪菍⒉煌膎once值作為輸入，嘗試進(jìn)行SHA256哈希運算，找出滿足給定數(shù)量前導(dǎo)0的哈希值的過程。而要求的前導(dǎo)0的個數(shù)越多，代表難度越大。

比特幣節(jié)點求解工作量證明問題的步驟大致歸納如下：

1. 生成鑄幣交易，并與其他所有準(zhǔn)備打包進(jìn)區(qū)塊的交易組成交易列表，通過Merkle樹算法生成Merkle根哈希；
2. 把Merkle根哈希及其他相關(guān)字段組裝成區(qū)塊頭，將區(qū)塊頭的80字節(jié)數(shù)據(jù)作為工作量證明的輸入；
3. 不停地變更區(qū)塊頭中的隨機(jī)數(shù)，即nonce的數(shù)值，并對每次變更后的區(qū)塊頭做雙重SHA256運算（即SHA256（SHA256（Block_Header））），將結(jié)果值與當(dāng)前網(wǎng)絡(luò)的目標(biāo)值做對比，如果小于目標(biāo)值，則解題成功，工作量證明完成。

1.1.3.2 POS(股權(quán)證明)

代表項目：目前以太坊的共識機(jī)制正在朝POS方向迭代

由于PoW 方式需要消耗大量的算力，使得大家陷入算力競爭中，導(dǎo)致算力集中于頭部礦場存在安全性風(fēng)險，同時挖礦的過程也沒有實際價值，因此出現(xiàn)了POS機(jī)制。

目前PoS機(jī)制仍然有著問題需要解決，仍然處于發(fā)展之中。目前比較常見的是第一種Peercoin所采用的方式。

以Peercoin（點點幣）為代表的PoW+PoS混合共識
其所采用的股權(quán)證明PoS模式下，有一個名詞叫幣齡，每個幣每天產(chǎn)生1幣齡，在hash計算中使得難度與交易輸入的幣齡成反比。同時在產(chǎn)出區(qū)塊后清空幣齡。但是仍然需要參與區(qū)塊生產(chǎn)的節(jié)點進(jìn)行一定量的哈希值計算，即以類似工作量的方式生產(chǎn)區(qū)塊，只不過各節(jié)點通過計算尋找出合法區(qū)塊的概率與節(jié)點持有的權(quán)益相關(guān)，即根據(jù)權(quán)益選擇生產(chǎn)者，并且采用基于權(quán)益的激勵方式。只是一定程度上解決了POW機(jī)制帶來的能源大量消耗浪費的問題。

以以太坊Casper為代表的新型PoS共識

1. 驗證者押下一定比例的他們擁有的以太幣作為保證金。
2. 然后，開始驗證每一個區(qū)塊高度上的每一個候選塊（由繳納了保證金的驗證人提交的塊）。也就是說，當(dāng)他們發(fā)現(xiàn)一個可以他們認(rèn)為可以被加到鏈上的區(qū)塊的時候，他們將以通過押下賭注來驗證它。
3. 通過多位驗證人的下注，對于每個高度最終會選出唯一一個勝出塊。
4. 如果該區(qū)塊被加到鏈上，然后驗證者們將得到一個跟他們的賭注成比例的獎勵。
5. 但是，如果一個驗證者采用一種惡意的方式行動、試圖做“無利害關(guān)系”的事（如多次下注，反復(fù)下注），他們將立即遭到懲罰。

1.1.3.3 DPOS(委托權(quán)益證明)

代表項目：EOS

對于PoS機(jī)制的加密貨幣，每個節(jié)點都可以創(chuàng)建區(qū)塊。DPoS是由被社區(qū)選舉的可信帳戶（超級賬戶）來創(chuàng)建區(qū)塊。DPoS機(jī)制類似于股份制公司，普通股民進(jìn)不了董事會，要投票選舉代表（受托人）代他們做決策。

1.1.3.4 PBFT(實用拜占庭容錯算法)

PBFT的設(shè)計思想在很多共識機(jī)制中都有借鑒，同時也被很多聯(lián)盟鏈采用。

支持容錯故障節(jié)點之外，還支持容錯作惡節(jié)點。假設(shè)集群節(jié)點數(shù)為 N，有問題的節(jié)點為 f。pbft 算法的最大容錯節(jié)點數(shù)量是（n-1）/3。有問題的節(jié)點中，可以既是故障節(jié)點，也可以是作惡節(jié)點，或者只是故障節(jié)點或者只是作惡節(jié)點。

假設(shè)故障節(jié)點和作惡節(jié)點都是不同的節(jié)點。那么就會有 f 個問題節(jié)點和 f 個故障節(jié)點，當(dāng)發(fā)現(xiàn)節(jié)點是問題節(jié)點后，會被集群排除在外，剩下 f 個故障節(jié)點，那么根據(jù)小數(shù)服從多數(shù)的原則，集群里正常節(jié)點只需要比f個節(jié)點再多一個節(jié)點，即 f+1 個節(jié)點，確節(jié)點的數(shù)量就會比故障節(jié)點數(shù)量多，那么集群就能達(dá)成共識。所以，所有類型的節(jié)點數(shù)量加起來就是 f+1 個正確節(jié)點，f個故障節(jié)點和f個問題節(jié)點，即 3f+1=n

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

1. 客戶端發(fā)送請求給主節(jié)點
2. 主節(jié)點廣播請求給其它節(jié)點，節(jié)點執(zhí)行 pbft 算法的三階段共識流程。
3. 節(jié)點處理完三階段流程后，返回消息給客戶端。
4. 客戶端收到來自 f+1 個節(jié)點的相同消息后，代表共識已經(jīng)正確完成。
   為什么收到 f+1 個節(jié)點的相同消息后就代表共識已經(jīng)正確完成？從上一小節(jié)的推導(dǎo)里可知，無論是最好的情況還是最壞的情況，如果客戶端收到 f+1 個節(jié)點的相同消息，那么就代表有足夠多的正確節(jié)點已全部達(dá)成共識并處理完畢了。

1.1.3.5 RAFT

Fabric：已實現(xiàn)了raft算法
與PBFT不同，RAFT不支持作惡節(jié)點，因此更多的用于私鏈中。raft 算法包含三種角色，分別是：跟隨者（ follower ），候選人（candidate ）和領(lǐng)導(dǎo)者（ leader ）。集群中的一個節(jié)點在某一時刻只能是這三種狀態(tài)的其中一種，這三種角色是可以隨著時間和條件的變化而互相轉(zhuǎn)換的。

raft 算法主要有兩個過程：一個過程是領(lǐng)導(dǎo)者選舉，另一個過程是日志復(fù)制，其中日志復(fù)制過程會分記錄日志和提交數(shù)據(jù)兩個階段。raft 算法支持最大的容錯故障節(jié)點是（N-1）/2，其中 N 為 集群中總的節(jié)點數(shù)量。

在Raft中，每個結(jié)點會處于下面三種狀態(tài)中的一種：

1. follower：所有結(jié)點都以follower的狀態(tài)開始。如果沒收到leader消息則會變成candidate狀態(tài)
2. candidate：會向其他結(jié)點“拉選票”，如果得到大部分的票則成為leader。這個過程就叫做Leader選舉(Leader Election)
3. leader：所有對系統(tǒng)的修改都會先經(jīng)過leader。每個修改都會寫一條日志(log entry)
   leader收到修改請求后的過程如下，這個過程叫做日志復(fù)制(Log Replication)：
4. 復(fù)制日志到所有follower結(jié)點(replicate entry)
5. 大部分結(jié)點響應(yīng)時才提交日志
6. 通知所有follower結(jié)點日志已提交
7. 所有follower也提交日志
8. 整個系統(tǒng)處于一致的狀態(tài)

Raft算法動畫：https://link.zhihu.com/?target=http%3A//thesecretlivesofdata.com/raft/

1.1.4共識算法對比

1.1.4.1 PBFT VS RAFT

1.1.4.2 主流算法對比

1.1.4.3 ZAB協(xié)議與Raft協(xié)議比較

ZAB 是通過“一切以領(lǐng)導(dǎo)者為準(zhǔn)”的強(qiáng)領(lǐng)導(dǎo)者模型和嚴(yán)格按照順序處理、提交提案，來實現(xiàn)操作的順序性的。主節(jié)點是基于 TCP 協(xié)議來廣播消息的，并保證了消息接收的順序性。出來的比較早。

Raft協(xié)議是Raft協(xié)議就是一切以領(lǐng)導(dǎo)者為準(zhǔn)的方式，實現(xiàn)一系列值的共識和各節(jié)點日志的一致性。通過日志的連續(xù)性來保證消息或者說是數(shù)據(jù)的順序性以及完整性。Raft協(xié)議中日志不僅是數(shù)據(jù)的載體，同時，日志的完整性還會影響領(lǐng)導(dǎo)者選舉的結(jié)果（注：選舉的因素不僅僅只有日志的完整性來保證，還有任期等其他因素）。

Raft目前是工程上使用較為廣泛的強(qiáng)一致性、去中心化、高可用的分布式協(xié)議。在這里強(qiáng)調(diào)了是在工程上，因為在學(xué)術(shù)理論界，最耀眼的還是大名鼎鼎的Paxos。

異同點：

1. 領(lǐng)導(dǎo)者選舉：
   ZAB 采用的“見賢思齊、相互推薦”的快速領(lǐng)導(dǎo)者選舉（Fast Leader Election），節(jié)點間通過PK競爭（資本是所持有的信息）看哪個節(jié)點更適合做Leader，一個節(jié)點PK后，會將選票信息廣播出去，最終選舉出了大多數(shù)節(jié)點中數(shù)據(jù)最完整的節(jié)點。
   Raft 采用的是“一張選票、先到先得”的自定義算法（注：里面包含了一個隨機(jī)等待時間的概念，來保證最多幾次選舉就能完整選舉過程。），這里簡單說一下就是一個節(jié)點發(fā)現(xiàn)leader掛了，就選舉自己為leader，然后通知其他節(jié)點，其他節(jié)點把選票投給第一個通知它的節(jié)點。（注：這里其實也會涉及到PK，根據(jù)數(shù)據(jù)的完整性以及任期等信息，如果通知它的節(jié)點 沒有當(dāng)前節(jié)點的數(shù)據(jù)完整等那么 當(dāng)前節(jié)點是不會將選票投給該節(jié)點）
   以上看來，Raft 的領(lǐng)導(dǎo)者選舉，需要通訊的消息數(shù)更少，選舉也更快。

2. 日志復(fù)制：
   Raft 和 ZAB 相同，都是以領(lǐng)導(dǎo)者的日志為準(zhǔn)來實現(xiàn)日志一致，而且日志必須是連續(xù)的，也必須按照順序提交。
   ZAB通過TCP來保證操作的順序性。
   Raft協(xié)議通過Log Entry 加自己的校驗來實現(xiàn)日志的連續(xù)性。建議看上面的博客文章

3. 讀操作和一致性：
   ZAB 的設(shè)計目標(biāo)是操作的順序性，在 ZooKeeper 中默認(rèn)實現(xiàn)的是最終一致性，讀操作可以在任何節(jié)點上執(zhí)行；（注：很多地方說ZK是CP這沒有毛病，但是并不是指ZK中的讀寫時強(qiáng)一致性，是指在發(fā)生P的時候，ZK是C，或者看到這個很懵，看下上面的博客，以及仔細(xì)看下CAP理論的圖，里面也清晰的標(biāo)記著在沒發(fā)生P的時候，AC是可以共存的）
   而 Raft 的設(shè)計目標(biāo)是強(qiáng)一致性（也就是線性一致性），所以 Raft 更靈活（可以自己配置），Raft 系統(tǒng)既可以提供強(qiáng)一致性，也可以提供最終一致性，但是一般為了保證性能，默認(rèn)提供的也是最終一致性。

4. 寫操作：
   Raft 和 ZAB 相同，寫操作都必須在領(lǐng)導(dǎo)者節(jié)點上處理。

5. 成員變更：
   Raft 和 ZAB 都支持成員變更，其中 ZAB 以動態(tài)配置（dynamic configuration）的方式實現(xiàn)的。那么當(dāng)你在節(jié)點變更時，不需要重啟機(jī)器，集群是一直運行的，服務(wù)也不會中斷。

6. 設(shè)計階段：
   相比 ZAB，Raft 的設(shè)計更為簡潔，比如 Raft 沒有引入類似 ZAB 的成員發(fā)現(xiàn)和數(shù)據(jù)同步階段，而是當(dāng)節(jié)點發(fā)起選舉時，遞增任期編號，在選舉結(jié)束后，廣播心跳，直接建立領(lǐng)導(dǎo)者關(guān)系，然后向各節(jié)點同步日志，來實現(xiàn)數(shù)據(jù)副本的一致性。
   ZAB協(xié)議的數(shù)據(jù)同步的階段，ZAB集群式無法對外提供服務(wù)。
   其實，ZAB 的成員發(fā)現(xiàn)，可以和領(lǐng)導(dǎo)者選舉合到一起，類似 Raft，在領(lǐng)導(dǎo)者選舉結(jié)束后，直接建立領(lǐng)導(dǎo)者關(guān)系，而不是再引入一個新的階段；數(shù)據(jù)同步階段，是一個冗余的設(shè)計，可以去除的，因為 ZAB 不是必須要先實現(xiàn)數(shù)據(jù)副本的一致性，才可以處理寫請求，而且這個設(shè)計是沒有額外的意義和價值的。

7. 設(shè)計獨立性
   ZAB 和 ZooKeeper 強(qiáng)耦合，你無法在實際系統(tǒng)中獨立使用；而 Raft 的實現(xiàn)（比如 Hashicorp Raft）是可以獨立使用的，編程友好。文章來源地址http://www.zghlxwxcb.cn/news/detail-499106.html

到了這里，關(guān)于區(qū)塊鏈基礎(chǔ)之共識機(jī)制的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！