1.1共識機制
1.1.1核心定義
區(qū)塊鏈上的共識機制主要解決由誰來構(gòu)造區(qū)塊盆耽，以及如何維護區(qū)塊鏈統(tǒng)一的問題
1.1.2共識機制分類
1.1.3 共識算法
1.1.3.1 POW(工作量證明)
代表項目：BTC
由于不同的節(jié)點接受數(shù)據(jù)有所區(qū)別，為了保證數(shù)據(jù)一致性，每個區(qū)塊數(shù)據(jù)只能由一個節(jié)點進行記錄摄杂。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ù)，難度值決定了這道題所需要的計算量柑船∶背牛可以簡單理解成就是將不同的nonce值作為輸入，嘗試進行SHA256哈希運算鞍时，找出滿足給定數(shù)量前導(dǎo)0的哈希值的過程亏拉。而要求的前導(dǎo)0的個數(shù)越多，代表難度越大寸癌。
比特幣節(jié)點求解工作量證明問題的步驟大致歸納如下：
- 生成鑄幣交易专筷，并與其他所有準(zhǔn)備打包進區(qū)塊的交易組成交易列表弱贼，通過Merkle樹算法生成Merkle根哈希蒸苇；
- 把Merkle根哈希及其他相關(guān)字段組裝成區(qū)塊頭，將區(qū)塊頭的80字節(jié)數(shù)據(jù)作為工作量證明的輸入吮旅；
- 不停地變更區(qū)塊頭中的隨機數(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)證明)
代表項目：目前以太坊的共識機制正在朝POS方向迭代
由于PoW 方式需要消耗大量的算力，使得大家陷入算力競爭中罕拂，導(dǎo)致算力集中于頭部礦場存在安全性風(fēng)險揍异，同時挖礦的過程也沒有實際價值，因此出現(xiàn)了POS機制爆班。
目前PoS機制仍然有著問題需要解決衷掷，仍然處于發(fā)展之中。目前比較常見的是第一種Peercoin所采用的方式柿菩。
以Peercoin（點點幣）為代表的PoW+PoS混合共識
其所采用的股權(quán)證明PoS模式下戚嗅，有一個名詞叫幣齡，每個幣每天產(chǎn)生1幣齡，在hash計算中使得難度與交易輸入的幣齡成反比懦胞。同時在產(chǎn)出區(qū)塊后清空幣齡替久。但是仍然需要參與區(qū)塊生產(chǎn)的節(jié)點進行一定量的哈希值計算，即以類似工作量的方式生產(chǎn)區(qū)塊躏尉，只不過各節(jié)點通過計算尋找出合法區(qū)塊的概率與節(jié)點持有的權(quán)益相關(guān)侣肄，即根據(jù)權(quán)益選擇生產(chǎn)者，并且采用基于權(quán)益的激勵方式醇份。只是一定程度上解決了POW機制帶來的能源大量消耗浪費的問題稼锅。
以以太坊Casper為代表的新型PoS共識
- 驗證者押下一定比例的他們擁有的以太幣作為保證金。
- 然后僚纷，開始驗證每一個區(qū)塊高度上的每一個候選塊（由繳納了保證金的驗證人提交的塊）矩距。也就是說，當(dāng)他們發(fā)現(xiàn)一個可以他們認(rèn)為可以被加到鏈上的區(qū)塊的時候怖竭，他們將以通過押下賭注來驗證它锥债。
- 通過多位驗證人的下注，對于每個高度最終會選出唯一一個勝出塊痊臭。
- 如果該區(qū)塊被加到鏈上哮肚，然后驗證者們將得到一個跟他們的賭注成比例的獎勵。
- 但是广匙，如果一個驗證者采用一種惡意的方式行動允趟、試圖做“無利害關(guān)系”的事（如多次下注，反復(fù)下注）鸦致，他們將立即遭到懲罰潮剪。
1.1.3.3 DPOS(委托權(quán)益證明)
代表項目：EOS
對于PoS機制的加密貨幣，每個節(jié)點都可以創(chuàng)建區(qū)塊分唾。DPoS是由被社區(qū)選舉的可信帳戶（超級賬戶）來創(chuàng)建區(qū)塊抗碰。DPoS機制類似于股份制公司，普通股民進不了董事會绽乔，要投票選舉代表（受托人）代他們做決策弧蝇。
1.1.3.4 PBFT(實用拜占庭容錯算法)
PBFT的設(shè)計思想在很多共識機制中都有借鑒，同時也被很多聯(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 算法的基本流程主要有以下四步：
- 客戶端發(fā)送請求給主節(jié)點
- 主節(jié)點廣播請求給其它節(jié)點脂凶，節(jié)點執(zhí)行 pbft 算法的三階段共識流程。
- 節(jié)點處理完三階段流程后愁茁，返回消息給客戶端蚕钦。
- 客戶端收到來自 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)中的一種：
- follower：所有結(jié)點都以follower的狀態(tài)開始。如果沒收到leader消息則會變成candidate狀態(tài)
- candidate：會向其他結(jié)點“拉選票”梨州，如果得到大部分的票則成為leader痕囱。這個過程就叫做Leader選舉(Leader Election)
- leader：所有對系統(tǒng)的修改都會先經(jīng)過leader。每個修改都會寫一條日志(log entry)
leader收到修改請求后的過程如下暴匠，這個過程叫做日志復(fù)制(Log Replication)： - 復(fù)制日志到所有follower結(jié)點(replicate entry)
- 大部分結(jié)點響應(yīng)時才提交日志
- 通知所有follower結(jié)點日志已提交
- 所有follower也提交日志
- 整個系統(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)”的強領(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目前是工程上使用較為廣泛的強一致性、去中心化岸霹、高可用的分布式協(xié)議疾层。在這里強調(diào)了是在工程上，因為在學(xué)術(shù)理論界贡避，最耀眼的還是大名鼎鼎的Paxos痛黎。
異同點：
領(lǐng)導(dǎo)者選舉：
ZAB 采用的“見賢思齊、相互推薦”的快速領(lǐng)導(dǎo)者選舉（Fast Leader Election）刮吧，節(jié)點間通過PK競爭（資本是所持有的信息）看哪個節(jié)點更適合做Leader湖饱，一個節(jié)點PK后，會將選票信息廣播出去杀捻，最終選舉出了大多數(shù)節(jié)點中數(shù)據(jù)最完整的節(jié)點井厌。
Raft 采用的是“一張選票、先到先得”的自定義算法（注：里面包含了一個隨機等待時間的概念致讥，來保證最多幾次選舉就能完整選舉過程仅仆。），這里簡單說一下就是一個節(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ù)更少授舟，選舉也更快。日志復(fù)制：
Raft 和 ZAB 相同贸辈，都是以領(lǐng)導(dǎo)者的日志為準(zhǔn)來實現(xiàn)日志一致释树，而且日志必須是連續(xù)的，也必須按照順序提交擎淤。
ZAB通過TCP來保證操作的順序性奢啥。
Raft協(xié)議通過Log Entry 加自己的校驗來實現(xiàn)日志的連續(xù)性。建議看上面的博客文章讀操作和一致性：
ZAB 的設(shè)計目標(biāo)是操作的順序性嘴拢，在 ZooKeeper 中默認(rèn)實現(xiàn)的是最終一致性桩盲，讀操作可以在任何節(jié)點上執(zhí)行；（注：很多地方說ZK是CP這沒有毛病席吴，但是并不是指ZK中的讀寫時強一致性赌结，是指在發(fā)生P的時候，ZK是C孝冒，或者看到這個很懵柬姚，看下上面的博客，以及仔細(xì)看下CAP理論的圖庄涡，里面也清晰的標(biāo)記著在沒發(fā)生P的時候量承，AC是可以共存的）
而 Raft 的設(shè)計目標(biāo)是強一致性（也就是線性一致性），所以 Raft 更靈活（可以自己配置）穴店，Raft 系統(tǒng)既可以提供強一致性撕捍，也可以提供最終一致性，但是一般為了保證性能泣洞，默認(rèn)提供的也是最終一致性忧风。寫操作：
Raft 和 ZAB 相同，寫操作都必須在領(lǐng)導(dǎo)者節(jié)點上處理斜棚。成員變更：
Raft 和 ZAB 都支持成員變更阀蒂，其中 ZAB 以動態(tài)配置（dynamic configuration）的方式實現(xiàn)的。那么當(dāng)你在節(jié)點變更時弟蚀，不需要重啟機器，集群是一直運行的酗失，服務(wù)也不會中斷义钉。設(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è)計是沒有額外的意義和價值的引润。設(shè)計獨立性
ZAB 和 ZooKeeper 強耦合巩趁，你無法在實際系統(tǒng)中獨立使用；而 Raft 的實現(xiàn)（比如 Hashicorp Raft）是可以獨立使用的淳附，編程友好议慰。
