區(qū)塊鏈技術(shù)是近幾年逐漸變得非常熱門的技術(shù)，以比特幣為首的密碼貨幣其實已經(jīng)被無數(shù)人所知曉系羞，但是卻很少有人會去研究它們的底層技術(shù)，也就是作為一個分布式網(wǎng)絡(luò)比特幣等加密貨幣是如何工作的鸭叙。

cryptocurrency

無論是 Bitcoin觉啊、Ethereum 還是 EOS，作為一個分布式網(wǎng)絡(luò)沈贝，首先需要解決分布式一致性的問題杠人，也就是所有的節(jié)點如何對同一個提案或者值達成共識，這一問題在一個所有節(jié)點都是可以被信任的分布式集群中都是一個比較難以解決的問題宋下，更不用說在復雜的區(qū)塊鏈網(wǎng)絡(luò)中了嗡善。

分布式一致性

在一個分布式系統(tǒng)中，如何保證集群中所有節(jié)點中的數(shù)據(jù)完全相同并且能夠?qū)δ硞€提案（Proposal）達成一致是分布式系統(tǒng)正常工作的核心問題学歧，而共識算法就是用來保證分布式系統(tǒng)一致性的方法罩引。

distributed-system

然而分布式系統(tǒng)由于引入了多個節(jié)點，所以系統(tǒng)中會出現(xiàn)各種非常復雜的情況枝笨；隨著節(jié)點數(shù)量的增加袁铐，節(jié)點失效、故障或者宕機就變成了一件非常常見的事情横浑，解決分布式系統(tǒng)中的各種邊界條件和意外情況也增加了解決分布式一致性問題的難度剔桨。

distributed-system-with-failed-nodes

在一個分布式系統(tǒng)中，除了節(jié)點的失效是會導致一致性不容易達成的主要原因之外徙融，節(jié)點之間的網(wǎng)絡(luò)通信收到干擾甚至阻斷以及分布式系統(tǒng)的運行速度的差異都是解決分布式系統(tǒng)一致性所面臨的難題洒缀。

CAP

在 1998 年的秋天，加州伯克利大學的教授 Eric Brewer 第一次發(fā)布了 CAP 理論欺冀，在 1999 年論文 Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services 正式發(fā)布树绩，其中總結(jié)了 Eric Brewer 提出的 CAP 理論。

cap-theorem

這篇論文證明了兩個非常有意思的理論隐轩，首先是在異步的網(wǎng)絡(luò)模型中饺饭，所有的節(jié)點由于沒有時鐘僅僅能根據(jù)接收到的消息作出判斷，這時完全不能同時保證一致性职车、可用性和分區(qū)容錯性砰奕，每一個系統(tǒng)只能在這三種特性中選擇兩種蛛芥。

不過這里討論的一致性其實都是強一致性，也就是所有節(jié)點接收到同樣的操作時會按照完全相同的順序執(zhí)行军援，被一個節(jié)點提交的更新操作會立刻反映在其他通過異步或部分同步網(wǎng)絡(luò)連接的節(jié)點上仅淑，如果想要同時滿足一致性和分區(qū)容錯性，在異步的網(wǎng)絡(luò)中胸哥，我們只能中心化存儲所有數(shù)據(jù)涯竟，通過其他節(jié)點將請求路由給中心節(jié)點達到這兩個目的。

consistency-and-partition-tolerant

但是在現(xiàn)實世界中其實并不存在絕對異步的網(wǎng)絡(luò)環(huán)境空厌，如果我們允許每一個節(jié)點擁有自己的時鐘庐船，這些時鐘雖然有著完全不同的時間，但是它們的更新頻率是完全相同的嘲更，所以我們可以通過時鐘得知接收消息的間隔時間筐钟，在這種更寬松的前提下，我們能夠得到更強大的服務(wù)赋朦。

然而在部分同步的網(wǎng)絡(luò)環(huán)境中篓冲，我們?nèi)匀粵]有辦法同時保證一致性、可用性和分區(qū)容錯性宠哄，證明的過程其實非常簡單壹将，可以直接閱讀 論文 的 4.2 節(jié)，然而時鐘的出現(xiàn)能夠讓我們知道當前消息有多久沒有得到回應(yīng)毛嫉，通過超時時間就能在一定程度上解決信息丟失的問題诽俯。

由于網(wǎng)絡(luò)一定會存在延時，所以沒有辦法在分布式系統(tǒng)中做到強一致性的同時保證可用性承粤，不過我們可以通過降低對一致性的要求暴区，在一致性和可用性之間做出權(quán)衡，而這其實也是設(shè)計分布式系統(tǒng)首先需要考慮的問題辛臊，由于強一致性的系統(tǒng)會導致系統(tǒng)的可用性降低仙粱，僅僅將接受請求的工作交給其他節(jié)點對于高并發(fā)的服務(wù)并不能解決問題，所以在目前主流的分布式系統(tǒng)中都選擇最終一致性浪讳。

eventually-consistency

最終一致性允許多個節(jié)點的狀態(tài)出現(xiàn)沖突缰盏，但是所有能夠溝通的節(jié)點都能夠在有限的時間內(nèi)解決沖突涌萤，從不一致的狀態(tài)恢復到一致淹遵，這里列出的兩個條件比較重要，一是節(jié)點直接可以正常通信负溪，二是沖突需要在有限的時間內(nèi)解決透揣，只有在這兩個條件成立時才能達到最終一致性。

拜占庭將軍問題

拜占庭將軍問題是 Leslie Lamport 在 The Byzantine Generals Problem 論文中提出的分布式領(lǐng)域的容錯問題川抡，它是分布式領(lǐng)域中最復雜辐真、最嚴格的容錯模型须尚。

在該模型下，系統(tǒng)不會對集群中的節(jié)點做任何的限制侍咱，它們可以向其他節(jié)點發(fā)送隨機數(shù)據(jù)耐床、錯誤數(shù)據(jù)，也可以選擇不響應(yīng)其他節(jié)點的請求楔脯，這些無法預(yù)測的行為使得容錯這一問題變得更加復雜撩轰。

拜占庭將軍問題描述了一個如下的場景，有一組將軍分別指揮一部分軍隊昧廷，每一個將軍都不知道其它將軍是否是可靠的堪嫂，也不知道其他將軍傳遞的信息是否可靠，但是它們需要通過投票選擇是否要進攻或者撤退：

byzantine-generals-problem

在這一節(jié)中木柬，黃色代表狀態(tài)未知皆串，綠色代表進攻，藍色代表撤退眉枕，最后紅色代表當前將軍的信息不可靠恶复。

在這時，無論將軍是否可靠齐遵，只要所有的將軍達成了統(tǒng)一的方案寂玲，選擇進攻或者撤退其實就是沒有任何問題的：

byzantine-generals-problem-with-plans

上述的情況不會對當前的戰(zhàn)局有太多的影響，也不會造成損失梗摇，但是如果其中的一個將軍告訴其中一部分將軍選擇進攻拓哟、另一部分選擇撤退，就會出現(xiàn)非常嚴重的問題了伶授。

byzantine-generals-problem-split-votes

由于將軍的隊伍中出了一個叛徒或者信息在傳遞的過程中被攔截断序，會導致一部分將軍會選擇進攻，剩下的一部分會選擇撤退糜烹，它們都認為自己的選擇是大多數(shù)人的選擇违诗，這時就出現(xiàn)了嚴重的不一致問題。

拜占庭將軍問題是對分布式系統(tǒng)容錯的最高要求疮蹦，然而這不是日常工作中使用的大多數(shù)分布式系統(tǒng)中會面對的問題诸迟，我們遇到更多的還是節(jié)點故障宕機或者不響應(yīng)等情況，這就大大簡化了系統(tǒng)對容錯的要求愕乎；不過類似 Bitcoin阵苇、Ethereum 等分布式系統(tǒng)確實需要考慮拜占庭容錯的問題，我們會在下面介紹它們是如何解決的感论。

FLP

FLP 不可能定理是分布式系統(tǒng)領(lǐng)域最重要的定理之一绅项，它給出了一個非常重要的結(jié)論：在網(wǎng)絡(luò)可靠并且存在節(jié)點失效的異步模型系統(tǒng)中，不存在一個可以解決一致性問題的確定性算法比肄。

In this paper, we show the surprising result that no completely asynchronous consensus protocol can tolerate even a single unannounced process death. We do not consider Byzantine failures, and we assume that the message system is reliable it delivers all messages correctly and exactly once.

這個定理其實也就是告訴我們不要浪費時間去為異步分布式系統(tǒng)設(shè)計在任意場景上都能夠?qū)崿F(xiàn)共識的算法快耿，異步系統(tǒng)完全沒有辦法保證能在有限時間內(nèi)達成一致囊陡，在這里作者并不會嘗試去證明 FLP 不可能定理，讀者可以閱讀相關(guān)論文 Impossibility of Distributed Consensuswith One Faulty Process 了解更多的內(nèi)容掀亥。

共識算法

在上一節(jié)中撞反，我們已經(jīng)簡單了解了分布式系統(tǒng)中面對的問題與挑戰(zhàn)，在這里我們會介紹不同共識算法的實現(xiàn)原理搪花，包括傳統(tǒng)分布式系統(tǒng)領(lǐng)域的 Paxos痢畜、Raft 以及密碼貨幣中使用的工作量證明（POW）、權(quán)益證明（POS）和委托權(quán)益證明（DPOS）鳍侣，通過對這些共識算法原理的介紹和分析丁稀，我相信各位讀者能對分布式一致性和共識算法有更深的理解。

Paxos 和 Raft

Paxos 和 Raft 是目前分布式系統(tǒng)領(lǐng)域中兩種非常著名的解決一致性問題的共識算法倚聚，兩者都能解決分布式系統(tǒng)中的一致性問題线衫，但是前者的實現(xiàn)與證明非常難以理解，后者的實現(xiàn)比較簡潔并且遵循人的直覺惑折，它的出現(xiàn)就是為了解決 Paxos 難以理解并和難以實現(xiàn)的問題授账。

paxos-raft

我們先來簡單介紹一下 Paxos 究竟是什么，Paxos 其實是一類能夠解決分布式一致性問題的協(xié)議惨驶，它能夠讓分布式網(wǎng)絡(luò)中的節(jié)點在出現(xiàn)錯誤時仍然保持一致白热；Leslie Lamport 提出的 Paxos 可以在沒有惡意節(jié)點的前提下保證系統(tǒng)中節(jié)點的一致性，也是第一個被證明完備的共識算法粗卜，目前的完備的共識算法包括 Raft 本質(zhì)上都是 Paxos 的變種屋确。

作為一類協(xié)議，Paxos 中包含 Basic Paxos续扔、Multi-Paxos攻臀、Cheap Paxos 和其他的變種，在這一小節(jié)我們會簡單介紹 Basic Paxos 和 Multi-Paxos 這兩種協(xié)議纱昧。

Basic Paxos

Basic Paxos 是 Paxos 中最為基礎(chǔ)的協(xié)議刨啸，每一個 Basic Paxos 的協(xié)議實例最終都會選擇唯一一個結(jié)果；使用 Paxos 作為共識算法的分布式系統(tǒng)中识脆，節(jié)點都會有三種身份设联，分別是 Proposer、Acceptor 和 Learner：

paxos-roles

我們在這里會忽略最后一種身份 Learner 簡化協(xié)議的運行過程灼捂，便于讀者理解离例；Paxos 的運行過程分為兩個階段，分別是準備階段（Prepare）和接受階段（Accept）纵东，當 Proposer 接收到來自客戶端的請求時粘招，就會進入如下流程：

basic-paxos-phases

以上截圖取自 Paxos lecture (Raft user study) 的第 12 頁啥寇。

在整個共識算法運行的過程中偎球，Proposer 負責提出提案并向 Acceptor 分別發(fā)出兩次 RPC 請求洒扎，Prepare 和 Accept；Acceptor 會根據(jù)其持有的信息 minProposal衰絮、acceptedProposal 和 acceptedValue 選擇接受或者拒絕當前的提案袍冷，當某一個提案被過半數(shù)的 Acceptor 接受之后，我們就認為當前提案被整個集群接受了猫牡。

paxos-example

我們簡單舉一個例子介紹 Paxos 是如何在多個提案下保證最終能夠達到一致性的胡诗，上述圖片中 S1 和 S5 分別收到了來自客戶端的請求 X 和 Y，S1 首先向 S2 和 S3 發(fā)出 Prepare RPC 和 Accept RPC淌友，三個服務(wù)器都接受了 S1 的提案 X煌恢；在這之后，S5 向 S3 和 S4 服務(wù)器發(fā)出 Prepare(2.5) 的請求震庭，S3 由于已經(jīng)接受了 X瑰抵，所以它會返回接受的提案和值 (1.1, X)，這時服務(wù)器使用接收到的提案代替自己的提案 Y器联，重新向其他服務(wù)器發(fā)送 Accept(2.5, X) 的 RPC二汛，最終所有的服務(wù)器會達成一致并選擇相同的值。

想要了解更多與 Paxos 協(xié)議在運行過程中的其他情況可以看一下 Paxos lecture (Raft user study) 視頻拨拓。

Multi-Paxos

由于大多數(shù)的分布式集群都需要接受一系列的值肴颊，如果使用 Basic Paxos 來處理數(shù)據(jù)流，那么就會導致非常明顯的性能損失渣磷，而 Multi-Paxos 是前者的加強版婿着，如果集群中的 Leader 是非常穩(wěn)定的，那么我們往往不需要準備階段的工作醋界，這樣就能夠?qū)?RPC 的數(shù)量減少一半祟身。

multi-paxos-example

上述圖片中描述的就是穩(wěn)定階段 Multi-Paxos 的處理過程剥啤，S1 是整個集群的 Leader废菱，當其他的服務(wù)器接收到來自客戶端的請求時翠肘，都會將請求轉(zhuǎn)發(fā)給 Leader 進行處理酷勺。

當然诲泌，Leader 角色的出現(xiàn)自然會帶來另一個問題澜倦，也就是 Leader 究竟應(yīng)該如何選舉仇参，在 Paxos Made Simple一文中并沒有給出 Multi-Paxos 的具體實現(xiàn)方法和細節(jié)咧纠，所以不同 Multi-Paxos 的實現(xiàn)上總有各種各樣細微的差別官研。

Raft

Raft 其實就是 Multi-Paxos 的一個變種秽澳，Raft 通過簡化 Multi-Paxos 的模型，實現(xiàn)了一種更容易讓人理解的共識算法戏羽，它們兩者都能夠?qū)σ幌盗羞B續(xù)的問題達成一致担神。

Raft 在 Multi-Paxos 的基礎(chǔ)之上做了兩個限制，首先是 Raft 中追加日志的操作必須是連續(xù)的始花，而 Multi-Paxos 中追加日志的操作是并發(fā)的妄讯，但是對于節(jié)點內(nèi)部的狀態(tài)機來說兩者都是有序的孩锡，第二就是 Raft 對 Leader 選舉的條件做了限制，只有擁有最新亥贸、最全日志的節(jié)點才能夠當選 Leader躬窜，但是 Multi-Paxos 由于任意節(jié)點都可以寫日志，所以在選擇 Leader 上也沒有什么限制炕置，只是在選擇 Leader 之后需要將 Leader 中的日志補全荣挨。

multi-paxos-and-raft-log

在 Raft 中，所有 Follower 的日志都是 Leader 的子集朴摊，而 Multi-Paxos 中的日志并不會做這個保證默垄，由于 Raft 對日志追加的方式和選舉過程進行了限制，所以在實現(xiàn)上會更加容易和簡單甚纲。

從理論上來講厕倍，支持并發(fā)日志追加的 Paxos 會比 Raft 有更優(yōu)秀的性能，不過其理解和實現(xiàn)上還是比較復雜的贩疙，很多人都會說 Paxos 是科學讹弯，而 Raft 是工程，當作者需要去實現(xiàn)一個共識算法这溅，會選擇使用 Raft 和更簡潔的實現(xiàn)组民，避免因為一些邊界條件而帶來的復雜問題。

這篇文章并不會展開介紹 Raft 的實現(xiàn)過程和細節(jié)悲靴，如果對 Raft 有興趣的讀者可以在 The Raft Consensus Algorithm 找到非常多的資料臭胜。

POW(Proof-of-Work)

上一節(jié)介紹的共識算法，無論是 Paxos 還是 Raft 其實都只能解決非拜占庭將軍容錯的一致性問題癞尚，不能夠應(yīng)對分布式網(wǎng)絡(luò)中出現(xiàn)的極端情況耸三，但是這在傳統(tǒng)的分布式系統(tǒng)都不是什么問題，無論是分布式數(shù)據(jù)庫還是消息隊列集群浇揩，它們內(nèi)部的節(jié)點并不會故意的發(fā)送錯誤信息仪壮，在類似系統(tǒng)中，最常見的問題就是節(jié)點失去響應(yīng)或者失效胳徽，所以它們在這種前提下是有效可行的积锅，也是充分的。

這一節(jié)介紹的 工作量證明（POW养盗，Proof-of-Work）是一個用于阻止拒絕服務(wù)攻擊和類似垃圾郵件等服務(wù)錯誤問題的協(xié)議缚陷，它在 1993 年被 Cynthia Dwork 和 Moni Naor 提出，它能夠幫助分布式系統(tǒng)達到拜占庭容錯往核。

proof-of-work-puzzle

工作量證明的關(guān)鍵特點就是箫爷，分布式系統(tǒng)中的請求服務(wù)的節(jié)點必須解決一個一般難度但是可行（feasible）的問題，但是驗證問題答案的過程對于服務(wù)提供者來說卻非常容易，也就是一個不容易解答但是容易驗證的問題虎锚。

這種問題通常需要消耗一定的 CPU 時間來計算某個問題的答案硫痰，目前最大的區(qū)塊鏈網(wǎng)絡(luò) - 比特幣（Bitcoin）就使用了工作量證明的分布式一致性算法，網(wǎng)絡(luò)中的所有節(jié)點計算通過以下的謎題來獲得當前區(qū)塊的記賬權(quán)：

bitcoin-puzzle

SHA-256 作為一個哈希函數(shù)翁都，想要通過 SHA-256 函數(shù)的輸出推斷出輸入在目前來看可能性是可以忽略不計的，比特幣網(wǎng)絡(luò)就需要每一個節(jié)點不斷改變 NONCE 來得到不同的結(jié)果 HASH谅猾，如果得到的 HASH 結(jié)果在小于某個范圍柄慰，目前（2017.12.17）的難度是：

0x0000000000000000000000000000000000000000000000000000017268d8a21a

也就是如果只計算一次 SHA-256 的值能夠小于上述結(jié)果的可能性是 1.37?10?65，當前的全網(wǎng)算力也達到了 13,919 PH/s税娜，這是一個非匙Γ恐怖的數(shù)字，隨著網(wǎng)絡(luò)算力的不斷改變比特幣也會不斷改變當前問題的難度敬矩，保證每個區(qū)塊被發(fā)現(xiàn)的時間在 10min 左右概行；在整個比特幣網(wǎng)絡(luò)中，誰先得到當前問題的答案就能夠獲得這個區(qū)塊的記賬權(quán)并將當前區(qū)塊通過 Gossip 協(xié)議發(fā)送給盡可能多的比特幣節(jié)點弧岳。

工作量證明的原理其實非常簡單凳忙，比特幣網(wǎng)絡(luò)選擇的謎題非常好的適應(yīng)了工作量證明定義中的問題，比較難以尋找同時又易于證明禽炬，我們可以簡單理解為工作量證明防止錯誤或者無效請求的原理就是增加客戶端請求服務(wù)的工作量涧卵，而適合難度的謎題又能夠保證合法的請求不會受到影響。

由于工作量證明需要消耗大量的算力腹尖，同時比特幣大約 10min 才會產(chǎn)生一個區(qū)塊柳恐，區(qū)塊的大小也只有 1MB，僅僅能夠包含 3热幔、4000 筆交易乐设，平均下來每秒只能夠處理 5~7（個位數(shù)）筆交易，所以比特幣網(wǎng)絡(luò)的擁堵狀況非常嚴重绎巨。

POS(Proof-of-Stake)

權(quán)益證明是區(qū)塊鏈網(wǎng)絡(luò)中的使用的另一種共識算法近尚，在基于權(quán)益證明的密碼貨幣中，下一個區(qū)塊的選擇是根據(jù)不同節(jié)點的股份和時間進行隨機選擇的场勤。

由于創(chuàng)造新的區(qū)塊并不會消耗大量的 CPU肿男，如果它不誠實也不會失去什么，這也就給了很多節(jié)點作弊的理由却嗡，每一個節(jié)點為了最大化利益會在多條鏈上同時挖礦舶沛。

pos-problem

在早期的所有權(quán)證明算法中，整個網(wǎng)絡(luò)只會獎勵創(chuàng)建區(qū)塊的節(jié)點窗价，不存在任何懲罰如庭，在這時每個節(jié)點在創(chuàng)造的多條鏈上同時投票才能夠最大化利益，在這種情況下網(wǎng)絡(luò)中的節(jié)點很難對一條鏈達成共識。

有兩種辦法能夠解決缺乏利害關(guān)系（nothing-at-stake）造成的問題坪它，一種是使用 Slasher 協(xié)議骤竹，懲罰同時在多條鏈上投票的節(jié)點，第二種方法時直接懲罰在錯誤的鏈上創(chuàng)建塊的節(jié)點往毡，總而言之就是通過算法之外的事情解決這個問題蒙揣，引入激勵和懲罰。

與工作量證明相比开瞭，權(quán)益證明不需要消耗大量的電力就能夠保證區(qū)塊鏈網(wǎng)絡(luò)的安全性懒震，同時也不需要在每個區(qū)塊中創(chuàng)建新的貨幣來激勵礦工參與當前網(wǎng)絡(luò)的運行，這也就在一定程度上縮短了達成共識所需要的時間嗤详，基于權(quán)益證明的 Ethereum 每秒大概能處理 30 筆交易左右个扰。

DPOS(Delegated Proof-of-Stake)

前面介紹的權(quán)益證明算法可以將整個區(qū)塊鏈網(wǎng)絡(luò)理解為一家公司，出資最多葱色、占比最大的人有更多的機會得到話語權(quán)（記賬權(quán)）递宅；對于小股東來說，千分之幾甚至萬分之幾的股份很難有什么作為苍狰，只能得到股份帶來的分紅和收益办龄。

但是在這里介紹的委托權(quán)益證明（DPOS，Delegated Proof-of-Stake）能夠讓每一個人選出可以代表自己利益的人參與到記賬權(quán)的爭奪中淋昭，這樣多個小股東就能夠通過投票選出自己的代理人土榴，保障自己的利益。整個網(wǎng)絡(luò)中選舉出的多個節(jié)點能夠在 1s 中之內(nèi)對 99.9% 的交易進行確認响牛，使用委托權(quán)益證明的 EOS 能夠每秒處理幾十萬筆交易玷禽，同時也能夠比較監(jiān)管的干預(yù)。

delegated-proof-of-stake-witnesses

在委托權(quán)益證明中呀打，每一個參與者都能夠選舉任意數(shù)量的節(jié)點生成下一個區(qū)塊矢赁，得票最多的前 N 個節(jié)點會被選擇成為區(qū)塊的創(chuàng)建者，下一個區(qū)塊的創(chuàng)建者就會從這樣一組當選者中隨機選取贬丛，除此之外撩银，N 的數(shù)量也是由整個網(wǎng)絡(luò)投票決定的，所以可以盡可能地保證網(wǎng)絡(luò)的去中心化豺憔。

總結(jié)

在這篇文章中额获，我們首先介紹了分布式系統(tǒng)中面對的最重要問題，分布式一致性恭应，隨后又介紹了五種不同的共識算法抄邀，從解決非拜占庭問題下一致性的 Paxos 和 Raft 到解決拜占庭問題下的 POW、POS 和 DPOS昼榛，簡單回憶一下境肾，解決拜占庭問題的多個共識算法的實現(xiàn)反而更加簡單，這是一件非常有意思的事情。

當整個網(wǎng)絡(luò)需要實現(xiàn)拜占庭容錯時奥喻，僅靠算法確實是比較難以實現(xiàn)的偶宫，往往都需要使用其他方面的激勵或者懲罰，讓誠實表現(xiàn)的節(jié)點利益最大化才是解決一致性的最佳方案环鲤；從工作量證明纯趋、權(quán)益證明再到委托權(quán)益證明，共識算法的不同導致性能也有著非常大的差異冷离，我們可以看到隨著網(wǎng)絡(luò)中進行『投票』的節(jié)點越少吵冒，網(wǎng)絡(luò)的處理能力就會越強和性能就會越快，委托權(quán)益證明選舉了 N 個節(jié)點來保證性能和去中心化程度確實是一件非常聰明的事情酒朵。

中心化的網(wǎng)絡(luò)確實能夠帶來性能的提升桦锄，但是在密碼貨幣中扎附，參與者往往更相信去中心化的機制蔫耽，因為沒有激勵和懲罰我們并不能保證下一個負責記賬的節(jié)點是否是誠實的，由此來看留夜，如何在保證去中心化的同時提升網(wǎng)絡(luò)的性能是每一個區(qū)塊鏈網(wǎng)絡(luò)都需要考慮的事情匙铡。

Reference

• Consensus (computer science)
• 區(qū)塊鏈共識算法（POW,POS,DPOS,PBFT）介紹和心得
• Paxos 與 Raft
• Proof-of-work system
• Proof-of-stake
• Proof of Stake FAQ · Ethereum Wiki
• Delegated Proof of Stake
• Delegated Proof-of-Stake Consensus
• DPOS共識算法 – 缺失的白皮書
• 共識算法
• CAP theorem
• Paxos Made Simple
• The Raft Consensus Algorithm
• In Search of an Understandable Consensus Algorithm
• 談?wù)?paxos, multi-paxos, raft
• Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services
• “Eventual Consistency” vs “Strong Eventual Consistency” vs “Strong Consistency”?
• Impossibility of Distributed Consensuswith One Faulty Process
• The Byzantine Generals Problem
• Byzantine fault tolerance
• A Brief Tour of FLP Impossibility
• Paxos Made Simple
• Neat Algorithms - Paxos
• FLP Impossibility 的證明
• 白話區(qū)塊鏈
• Paxos
• Paxos lecture (Raft user study)
• Bitcoin: A Peer-to-Peer Electronic Cash System
• Proof of Stake · Bitcoin Wiki
• Slasher
• Proof of Stake FAQ