从分布式一致性算法到区块链共识机制
引言
分布式一致性是一個很“古典”的話題，即在分布式系統中，如何保證系統內的各個節點之間數據的一致性或能夠就某個提案達成一致。這個問題想必對于很多技術同學而言并不陌生，幾乎在所有的分布式系統中都會遇到，比如hdfs、mq、zookeeper、kafka、redis、elasticsearch等。然而這個問題卻歷久彌新，隨著分布式網絡的蓬勃發展與復雜化，對于該問題解法的探索也一直在進行中。
而近年來，隨著區塊鏈技術的興起，特別是開放網絡中的公有鏈與有權限網絡中的聯盟鏈的蓬勃發展，一致性問題再次得到關注，并從新的視角來審視該問題。
本文將從傳統的分布式一致性問題說起，再次重溫我們需要面對的問題挑戰、已有的理論研究、以及相應的一致性算法，并簡要分析這些一致性算法的適用性與局限性，以及這些傳統一致性算法與嶄新的區塊鏈技術的結合。另外，將從區塊鏈中一致性問題的全新視角“人的可信”出發，重點闡述公有鏈領域中的共識算法與機制。因此，本文圍繞“一致性”技術問題，重點從技術視角闡述傳統計算機科學中的分布式一致性算法與區塊鏈中的共識機制的關聯，以及公有鏈對于一致性問題的重新思考。
分布式一致性問題的挑戰
要清楚理解分布式一致性，首先需要對分布式網絡的特性有清晰的認識。那么分布式網絡具有哪些特點呢？或者通俗理解，在分布式網絡中，可能遇到哪些問題呢？
Crash Fault
故障錯誤（Crash Fault）很好理解，就是說分布式網絡中：
- 節點或副本可能隨時宕機、可能暫停運行但隨后又恢復；
- 網絡可能隨時中斷；
- 發送的消息可能在傳遞的過程中丟失，對方一直收不到；
- 發送的消息可能出現延遲，過了很久對方才能收到；
- 消息在傳遞的過程中可能出現亂序；
- 網絡可能出現分化，如中美集群因通信不暢，而導致整體網絡分化為中美兩個子網絡；
這些問題，其實就是我們在分布式環境中最常實際遇到的問題，這些問題實質上都是由于分布式系統中的物理硬件的不可靠、不穩定所帶來的必然風險，比如：網絡（信道）不可能是永遠穩定可靠的、物理機磁盤或CPU等不可能是永遠良好的。故障錯誤可以說是分布式系統中必須考慮并解決的最基本、最常見的一類錯誤。
Byzantine Fault
上文的故障錯誤，仍然基于一個很簡單的假設：節點要么不正常工作或響應，要么能正常工作或響應，但不能口是心非、陽奉陰違、表里不一，即可以不干事、但不能干壞事。一旦網絡中存在作惡節點，可能會隨意篡改或偽造數據，那么一致性問題的難度就大幅增加。我們常把這類存在“搗亂者”，可能會篡改或偽造數據或響應信息的錯誤，稱之為拜占庭錯誤（Byzantine Fault），而前面所說的故障類錯誤也稱之為非拜占庭錯誤。
拜占庭這一稱呼，源于Lamport最初的論文，可以說是分布式領域最復雜、最嚴格的容錯模型。簡而言之，n個將軍準備一起進攻某個城堡，每個將軍都可以選擇進攻或是撤退，但所有將軍必須行動一致才能成功。各個將軍之間相隔很遠，不能直接通訊，必須通過信使來傳遞消息。但是信使并不可靠，信使可能過了很久才送到消息、可能一直也沒有把消息送到、甚至可能會故意篡改消息；而將軍也并不可靠，里面可能存在叛徒，并不按照提案來行動。顯然，這個故事中的信使用來代表分布式網絡中的不可靠信道，而將軍就是各個不可靠的節點。
拜占庭問題示意圖（https://lisk.io/academy/blockchain-basics/how-does-blockchain-work/byzantine-fault-tolerance-explained）
應對風險—Fault Tolerance
如何在充滿風險與不確定的分布式網絡中，尋找到某種確定性與一致性，使得整個分布式網絡輸出穩定可靠的一致性結果，就是分布式一致性算法要解決的核心問題。顯而易見，解決故障類錯誤更容易一些，通常把這類一致性算法叫做故障容錯算法（Crash Fault Tolerance）或者非拜占庭容錯算法。而拜占庭類錯誤，因為有惡意篡改的可能性存在，復雜性更高、解決難度更大，通常把解決這類問題的算法稱作拜占庭容錯算法（Byzantine Fault Tolerance）。
那么我們忍不住要問，兩類容錯算法的界限在哪里？或者說兩類錯誤都在什么樣的場景下出現？惡意篡改這種情況真的需要考慮嗎？問題的答案可能取決于我們所處的網絡環境與業務場景。
CFT
通常而言，如果系統處于可信的內部網絡環境中，只需要考慮故障容錯（CFT）可能就足夠了。比如我們經常見到的公司內的分布式存儲、消息隊列、分布式服務等各種分布式組件，其實只需要考慮故障容錯就足夠了。因為公司內整個網絡是封閉的，又有多重防火墻的保護，外界很難接入或攻擊；各個節點是由公司統一部署的，機器或運行的軟件遭到篡改的可能性極小；此時的分布式網絡環境相對“單純”，我們唯一的敵人只是：通信網絡與機器硬件。我們需要考慮的是網絡的延遲、不穩定，以及機器隨時可能出現的宕機、故障。
BFT
而拜占庭類錯誤(BFT)，是把整個分布式網絡放到了更大的環境中去看，除了物理硬件之外，還考慮了一些“人”的因素。畢竟，機器是不會作惡的，作惡的只有人。假如我們所處的分布式網絡是較為開放的網絡，比如行業內幾十上百家公司組成的聯盟網絡；或者是完全開放的網絡，比如任何人都可以隨意接入到網絡中；而節點機器和上面部署的軟件也是由各個公司或個人自己提供和部署的，那么如果利益足夠大，很可能會有人對網絡中的某個節點發起DDoS攻擊、故意篡改軟件代碼改變其執行邏輯、甚至可能故意篡改磁盤上持久化的數據。顯然，我們此時面臨的挑戰更大了，我們除了要考慮通信網絡和機器硬件的不可靠之外，還必須要考慮和應對系統中的“搗亂者”。
不可能三角
這些實踐中遇到的問題，也引發了諸多計算科學家進行了非常多的理論研究。這些理論研究對于工程技術人員而言或許過于抽象繁瑣，有些甚至是無趣的數學問題，但這些理論對于指導我們解決這些問題意義重大。這些理論相當于是告訴了我們這類問題解法的理論極限，以及哪些方向可以探索、哪些方向是死路一條。站在前人的肩膀上，才不至于花畢生精力去研制“永動機”。這些理論大家應該都有所了解，這里只簡單回顧。
FLP impossibility
早在1985年，Fisher、Lynch、Paterson三位科學家就發表了關于分布式一致性問題的不可能定理：在完全異步的分布式網絡中，故障容錯問題無法被解決。（ We have shown that a natural and important problem of fault-tolerant cooperative computing cannot be solved in a totally asynchronous model of computation. ）說得更直白點：在異步網絡中，不可能存在能夠容忍節點故障的一致性算法，哪怕只有一個節點故障。并且這里并沒有考慮拜占庭錯誤，而是假設網絡非常穩定、所有的消息都能被正確傳遞、并且僅被傳遞一次，即便如此都不可能找到能容忍哪怕只有一個節點失效的一致性協議，可見該結論有多強。（ 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 reliableit delivers all messages correctly and exactly once. ）
當然了，這只是理論上的。它的意義在于告訴我們此類問題的理論極限，并不意味著此類問題在實踐中也不可能被“解決”。如果我們愿意放寬限制、做出犧牲，在工程上是可以找到切實可行的解法的。
FLP不可能定理的最大適用前提是異步網絡模型。何為同步、異步模型呢？
- 所謂異步模型，是說從一個節點到另一個節點的消息延遲是有限的，但可能是無界的（finite but can be unbounded）。這就意味著如果一個節點沒有收到消息，它無法判斷消息到底是丟失了，還是只是延遲了。也就是說，我們無法通過超時時間來判斷某個節點是否故障。
- 所謂同步模型，是說消息傳遞的延遲是有限的，且是有界的。這就意味著我們可以通過經驗或采樣精確估算消息的最大可能延遲，從而可以通過超時時間來確定消息是否丟失、節點是否故障。
所幸的是，我們所處于的真實的網絡世界更接近同步模型，在很多場景上，我們都可以通過經驗或采樣確定最大超時時間。舉個通俗點的例子：你給朋友快遞了一本書，朋友過了3天還沒收到，此時朋友很難判斷到底是快遞延遲了，還是快遞出問題送丟了。但是如果過了一個月，朋友仍沒收到書，基本就可以斷定快遞送丟了。而背后的推論就是基于經驗或統計：通常快遞都能在1-2周內送達。顯然，異步模型其實是反映了節點間通訊的最差情況、極端情況，異步模型包含了同步模型，即能在異步模型上有效的一致性協議，在同步模型上也同樣有效。而同步模型是對異步模型做了修正和約束，從而使得更接近真實世界，也使得在實踐中一致性問題有可能得到有效解。
另外，即便是在異步網絡模型下，FLP也并不意味著一致性永遠無法達成，只是說無法保證在有界的時間（in bounded time）內達成。在實踐上，如果放寬對bounded time的限制，仍然是有可能找到實踐中的解法的。
而根據DLS的研究（http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf ），一致性算法按照網絡模型可以分為三大類：
- 部分同步網絡模型（partially synchronous model）中的一致性協議可以容忍最多1/3的任意錯誤。這里的部分同步模型是指網絡延遲是有界的，但是我們無法提前得知。這里的容錯也包含了拜占庭類錯誤。
- 異步網絡模型（asynchronous model）中的確定性協議無法容忍錯誤。這里的異步模型即是前文所說的網絡延遲是無界的。該結論其實就是FLP不可能定理的含義，在完全異步網絡中的確定性協議不能容忍哪怕只有一個節點的錯誤。
- 同步網絡模型（synchronous model）可以達到驚人的100%容錯，雖然對錯誤節點超過1/2時的節點行為有限制。這里的同步模型是指網絡延遲一定是有界的，即小于某個已知的常數。
從另一個角度來理解，FLP實際上考慮了分布式系統的3個屬性：安全(safety)、活性（liveness)、容錯：
- 安全是說系統內各個節點達成的值是一致的、有效的。safety其實是保證系統一致性運行的最低要求，其核心是cannot do something bad，即不能干壞事、不能做錯事。
- 活性是說系統內各個節點最終（在有限時間內）必須能夠達成一致，即系統必須能夠向前推進，不能永遠處于達不成一致的狀態。liveness其實是更高要求，意味著不能只是不干壞事，也不能一直不干事，you must do something good，即必須使得整個系統能良好運轉下去。
- 容錯是說該協議在有節點故障的情況下也必須能有效。
FLP不可能定理其實意味著在異步網絡中，不可能存在同時滿足這三者的分布式一致性協議。因為分布式環境中，節點故障幾乎是必然的，因此容錯是必須要考慮的因素，所以FLP不可能定理就意味著一致性協議在能做到容錯的情況下，沒辦法同時做到安全性與系統活性。通常在實踐中，我們可以做出部分犧牲，比如犧牲一部分安全性，意味著系統總能很快達成結論，但結論的可靠性不足；或者犧牲一部分系統活性，意味著系統達成的結論非常可靠，但可能長時間、甚至永遠都在爭論中，無法達成結論。所幸的是，很多時候現實世界的魯棒性很強，使一致性協議失效的倒霉事件發生的概率也很可能極低。
??
FLP不可能定理示意圖（https://www.slideshare.net/oryband/the-stellar-blockchain-and-the-story-of-the-federated-consensusblockchain-academy）
另外，FLP并未排除Las Vegas類隨機算法，許多一致性算法采用了這種隨機性來規避FLP不可能定理對于確定性異步網絡的限制。此類非確定性一致性算法涉及Las Vegas規則：網絡最終一定能達成一致，但是達成一致所需要的時間可能是無界的。此類算法每輪共識決策都有一定的概率，并且系統在T秒內能夠達成一致的概率P隨著時間T的增加而指數增長并趨近于1。事實上，該方法被許多成功的一致性算法所采用，是在FLP不可能定理籠罩下的安全地帶（escape hatch），后面將會講到比特幣的共識機制就是采用了這樣的方法。
CAP theorem
眾所周知、大名鼎鼎的CAP原理，從另一個維度，簡單明了、直截了當地告訴我們：可用性、一致性與網絡分區容錯性這三者不可能同時實現，而只能實現任意其中的兩個。( "Of three properties of shared-data systems (data consistency, system availability and tolerance to network partitions) one can only achieve two at any given time".) CAP與FLP看起來有相似之處，其實二者并不盡相同，二者是從不同的維度思考問題，另外即使是很相似的概念，內涵也并不完全一樣。比如：
- FLP面對的是分布式一致性問題，而CAP面對的是分布式網絡中的數據同步與復制。
- FLP是說在異步網絡模型中，三者不可能同時實現；而CAP是說在所有場景下，三者都不可能同時實現。
- FLP中的liveness強調的是一致性算法的內在屬性；而CAP中的availability強調的是一致性算法對外呈現的外在屬性。
理論上，只能從CAP三者中選擇兩者，然而，這種選擇的邊界并非是非此即彼的（not binary），很多時候混合考慮不同程度的各個因素，結果可能是更好的。（ The whole spectrum in between is useful; mixing different levels of Availability and Consistency usually yields a better result.）
?
CAP理論示意圖（https://www.researchgate.net/figure/Visualization-of-CAP-theorem_fig2_282679529）
在實踐中，我們通常需要根據實際業務場景做折中權衡。比如：
- 傳統的關系型數據庫如mysql等多采用ACID（atomicity, consistency, isolation and durability）理論，通過同步事務操作保證了強一致性；因節點較少（一般只有主從），可用性也比較一般；網絡拓撲較為簡單，而弱化了分區容錯性。
- NoSQL存儲系統如hbase等多采用BASE（Basically Available、Soft state、Eventually consistent）理論，通過多節點多副本保證了較高的可用性；另外因節點數增多、網絡環境也更復雜，也考慮了網絡分區容錯性；但一致性較弱，只能保證最終一致性。
?
ACID與BASE對比（https://people.eecs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf）
當然，這些并不是定論，各個系統都在各自不斷的進化完善中，今天的結論明天可能就會被打破。更好的系統一定是不斷探索適合自己的場景，找到更佳的平衡點。
分布式一致性算法
面對分布式環境中各種真實、復雜的問題與挑戰，基于理論上的指引，各種應對現實問題的解法也被提出。我們這里不探究各類算法的實現細節與具體差異，僅做大體介紹，以便放到更大的維度，從整體上做比較。
Paxos
最大名鼎鼎的分布式一致性算法當屬Lamport提出的paxos算法，雖然其復雜性也同樣“臭名昭著”。Lamport開創性地提出了一種在工程實踐上切實可行的、能夠最大程度地保證分布式系統一致性的機制。paxos被廣泛應用在諸多分布式系統中，如Chubby、Zookeeper等。在basic paxos（單一法令，即每次僅對一個值進行決策）中有兩種角色：proposer可以處理客戶端請求、主動提出某個議案值；acceptor被動響應proposer發出的信息、對提案進行投票、持久化存儲決策過程中的值和狀態。(為簡化模型，可以忽略learner角色，不影響模型決策。)
如圖所示，共識決策過程采用了兩階段提交：
- 第1階段，廣播Prepare RPC命令，即找出協議決定的最終值、阻斷尚未完成的舊提案；
- 第2階段，廣播Accept RPC命令，即要求acceptor接受共識協商出的特定值。而multi-paxos是由多個basic paxos實例組成，可以對一系列的值進行決議。
Paxos之所以在實踐中可行，其實也做了諸多假設和約束。從處理的問題上來看，Paxos僅能處理故障容錯，并不難處理拜占庭錯誤，所以屬于非拜占庭容錯算法。從FLP的視角，Paxos做到了故障容錯和安全性，但放棄了liveness（safe but not live）,也就是說該算法可能永遠無法結束，或者說永遠無法達成共識，雖然這種可能性極小。從CAP的視角，Paxos只保證了CP，即做到了分區容錯性和一致性，但弱化了可用性。有時為了增強paxos系統的可用性，可以考慮增加learner角色的數目。
即便并不完美，Paxos在實踐中仍然是可靠、有效且久經考驗的。Paxos本質上是異步系統的分布式一致性協議，并且在該領域具有支配地位。Chubby之父甚至聲稱世界上只有一種一致性算法，那就是paxos（ there is only one consensus protocol, and that’s Paxos），其他一致性算法都是paxos的broken version。Paxos之所以在實踐中有效是因為可能影響paxos系統liveness和可用性的條件并不容易被觸發，即便真的出現，所帶來的代價也可能并非是難以接受的。
?
Basic Paxos RPC通信與決策過程（https://ongardie.net/static/raft/userstudy/paxos.pdf）
Raft
有感于Paxos的晦澀難懂，Ongaro在2014年提出了更容易理解的Raft算法。Raft把易于理解、易于工程實現提到了很高的重要級別，甚至是raft的初心和存在理由，因而在不影響功能性的前提下，盡可能多地做了易于理解的精細設計。
Raft算法是leader-based的非對稱模型，系統中的任意一個節點在任意時刻，只能處于leader、follower、candidate這3種狀態之一。初始狀態所有節點都是follower狀態，follower想變成leader必須先成為candidate，然后發起選舉投票；如果投票不足，則回到follower狀態；如果投票過半，則成為leader；成為leader后出現故障，若故障恢復后已有新leader，則自動下臺，回歸follower狀態。
Raft還引入了term的概念用于及時識別過期信息，類似于zookeeper中的epoch；term值單向遞增，每個term內至多一個leader；若不同term的信息出現沖突，則以term值較大的信息為準。
Raft還采用了心跳包和超時時間，leader為了保持自己的權威，必須不停地向集群中的其他節點發送心跳包；一旦某個follow在超過了指定時間（election timeout）仍沒有收到心跳包，則就認為leader已經掛掉，自己進入candidate狀態，開始競選leader。
不難發現，raft的leader選舉是通過heartbeat和隨機timeout時間來實現的；而日志復制（log replication）階段是以強leadership來實現的：leader接收client的command，append到自身log中，并將log復制到其他follower；而raft對安全性的保證是通過只有leader可以決定是否commit來實現的。
詳細的競選、復制等過程，這里不再贅述，有興趣的同學可以參考筆者之前的文章（https://yq.aliyun.com/articles/675031 ）。值得一提的是，raft中的leader選舉過程和leader任期內的正常運作過程都比較簡單，復雜的其實是leader的變更過程。
然而，雖然raft的原理機制與paxos不盡相同，但二者所解決的問題，以及所采取的折中權衡策略，可以認為是類似的。也就是說raft仍然只能解決故障錯誤，仍然強調了故障容錯與安全性、一致性，弱化了liveness和可用性。
?
Raft協議概覽（https://ongardie.net/static/raft/userstudy/raft.pdf）
PBFT
自從1982年Lamport提出拜占庭將軍問題之后，雖然有諸多關于拜占庭容錯解決方案的討論，但長期以來，此類問題的解決方案都效率低下、運行緩慢、復雜度過高，直到1999年Castro和Liskov提出實用拜占庭容錯算法（Practical Byzantine Fault Tolerance），首次將此類算法的復雜度從指數級降到了多項式級，TPS可以達到幾千，也使得節點故意作惡類問題在實踐中找到了可行的解法。可以證明，如果系統內作惡節點數目不超過總節點數目的1/3，PBFT算法就能生效。
在PBFT中，所有的節點被順序編號，其中1個是leader，其余的都是backup。系統內的所有節點間都互相通訊，依據多數原則達成一致。PBFT中的每輪共識都被稱為一個view，而在不同的view之間，leader都會發生變化；如果超過給定的時間，leader沒有廣播出消息，則leader就會通過view change協議被替換掉。通過這種replica timeout機制，保證了crashed或malicious leader會被檢測出來，從而通過重新選舉新的leader，而進入到新的view中。
如圖所示，從客戶端發起請求到收到回復結果，可以分為5個階段，而共識過程采用了3階段協議。下面簡要敘述5個階段的大致過程：
?
PBFT算法正常運作過程（http://www.pmg.csail.mit.edu/papers/bft-tocs.pdf）
PBFT基于異步網絡模型做到了安全性，但需要依賴消息超時時間來做周期性的同步。因為采用了leader-based方案，消息同步過程很快，也做到了完全的順序寫入。但是leader的重新選舉過程很困難，某些惡意leader可以在臨近timeout窗口期時才發送消息，這樣會導致系統嚴重緩慢。而利用這一不利特點，可以攻擊網絡使正確的leader看起來也出問題，從而導致無窮無盡的leader選舉過程。
PBFT與Paxos、Raft相比，所能處理應對的問題更為完備，除了能應對故障崩潰類錯誤之外，還能處理存在“搗亂者”的惡意篡改類拜占庭錯誤。然而，從所采取的折中權衡策略來看，PBFT仍然與Paxos、Raft很類似。從FLP的視角來看，PBFT同樣更關注容錯性和安全性，而弱化了liveness。從CAP的角度，PBFT同樣強調網絡分區容錯與一致性，而弱化了可用性。
即便如此，只要故障或作惡節點不超過總節點數的1/3，PBFT在實踐中還是有效可行的。而拜占庭容錯算法（BFT）也不止PBFT一種，BFT類算法也在不斷進化，如Lamport就提出過改進版的Paxos算法BFT Paxos以處理拜占庭錯誤，近來也有人結合PBFT與Raft提出了 BFT Raft 算法。但從問題領域與原理機制上來說，仍然與原有的思路和框架較為類似，不再一一贅述。
適用場景
從Paxos、Raft到PBFT，再到目前層出不窮的Paxos變種、Raft變種、BFT類混合新算法，分布式一致性算法在不斷發展、完善、進化。甚至各大公司也在結合自己的業務實際，研發各種適合自己場景的分布式一致性算法。這些算法雖然并不完美，但都在適合自己場景的業務實踐中發揮著重大作用。那么這些算法的適用場景到底是什么？自身又有哪些局限性呢？
對于Paxos、Raft這類非BFT算法而言，只能處理機器硬件故障，而無法處理存在作惡節點的情況。顯然，這類非BFT算法只能運行在非常可信的網絡環境中，比如公司內部網絡中，在這樣的較為封閉的網絡中，訪問需要嚴格授權，從而保證各個節點的身份是已知的、可信的，基本排除了節點作惡的可能性，這類算法才能有效運行。
而BFT類算法，對于網絡環境的要求不再那么苛刻，即使存在作惡節點，只要作惡節點數目不超過總節點數的1/3，整個系統依然是安全的。但問題就在于，你怎么知道網絡中到底有多少作惡節點？作惡節點占總節點的比例到底有多高？顯然，如果網絡的接入是需要權限控制的，那么這個問題就相對容易解決。比如10家業務關聯公司組成的聯盟網絡，只有這10家授權的公司才能訪問，即便里面有個別公司（少于3家）蓄意作惡、妄圖篡改數據，整個系統仍然是安全可靠的。在這種permissoned網絡中，隱含著對于網絡中可能作惡節點數目的預估，即便真的作惡了，也能方便快速地定位出其真實身份，間接提高了網絡的安全性。
局限性
然而，在permissonless（開放權限、無權限控制）的公有網絡中，BFT類算法很可能會有問題。因為，如果分布式網絡是開放的，誰都能進進出出，而接入網絡系統的成本又很低，那么沒人知道網絡中到底可能有多少作惡節點，即便真有作惡，也很難定位出真實身份。比如，一種比較典型的女巫攻擊（Sybil attack）場景，作惡者可以通過大量偽造身份來控制集群中的大量節點，從而控制整個分布式網絡。
另外，BFT類算法最大的局限性還在于僅能協調少量的節點，如幾個到幾十個，若節點數目成千上萬，整個系統的性能將會非常低下，甚至可能無法達成共識，從而影響系統的liveness和可用性。想必大家已經注意到，在PBFT的三階段協議中，都需要多點廣播（multicast）：在pre-prepare階段，主節點向所有備節點廣播；在prepare節點，備節點向其他所有節點廣播；在commit階段，各個節點向其他所有節點廣播。由此可見，通訊次數的數量級是節點數目的平方，當節點數目龐大時，這種兩兩廣播的機制將會是災難，系統幾乎不可能在較短時間內達成一致。
綜上可知，這些傳統的分布式一致性算法，無論是Paxos、Raft，還是PBFT，通常適用于存在權限控制的、節點數目較少的、較為可信的分布式網絡環境中。
在聯盟鏈中的應用
事實上，這些傳統的一致性算法在區塊鏈時代也煥發了新的活力，得到了進一步的認識和使用。在網絡環境較為可信的聯盟鏈場景中，這些一致性算法得到了大量的應用。聯盟鏈因如下特點而被業內看好其應用前景：
- 接入需授權：聯盟鏈并不完全對外開放，一般只有幾家或幾十家企業組成，只有經過授權的公司或組織才能加入到網絡中，并且一般是實名認證參與。
- 數據保護：聯盟鏈信息數據并不完全對外開放，而只有授權方可見。這對于保護行業或公司的數據安全比較重要，如跨境轉賬中的交易信息等對于銀行業至關重要、鏈上稅務系統中的稅務信息也很敏感。
- 可監管：聯盟鏈中一般可以設立監管觀察節點，對于敏感信息進行審計與監管，滿足合法性要求。
在當前階段，聯盟鏈不失為快速落地、解決行業痛點的不錯選擇，也是對區塊鏈后續發展的積極探索。因為聯盟鏈需要授權才能參與，這其實相當于已經提前建立了相當程度的信任，網絡環境較為可信，網絡中的惡意行為和攻擊行為發生的可能性都非常低，并且即便發生也很容易快速追責。因此在這樣的場景下，傳統的一致性算法也可以得到應用。比如：
- HyperLedger Fabric(https://www.hyperledger.org/projects/fabric ) 在v1.0中可以使用Solo和Kafka pubsub系統來實現ordering；在v1.4版本也引入了Raft算法（https://hyperledger-fabric.readthedocs.io/en/release-1.4/orderer/ordering_service.html ）；目前這些均是CFT類算法，而raft的引入主要也是為后期支持BFT類算法鋪平道路（ Raft is the first step toward Fabric’s development of a byzantine fault tolerant (BFT) ordering service. As we’ll see, some decisions in the development of Raft were driven by this. ）。
- R3 Corda(https://www.r3.com/corda-platform/ )也采用了可插拔式的共識算法設計，不僅可以選擇高速度、高可信環境的Raft算法，也可以選擇低速度、低可信環境的BFT類算法（https://docs.corda.net/key-concepts-notaries.html ）。
- 以太坊企業聯盟EEA(https://entethalliance.org/ )也支持BFT類算法、Raft算法，以及PoET算法（https://entethalliance.org/wp-content/uploads/2018/05/EEA-TS-0001-0-v1.00-EEA-Enterprise-Ethereum-Specification-R1.pdf ）。
- 螞蟻區塊鏈BaaS平臺（https://tech.antfin.com/blockchain )也采用了PBFT算法。
Permissionless網絡的挑戰
那么我們忍不住要問，如果網絡是完全開放的、無需權限許可的（permissionless），誰都可以隨時進出，那么整個系統還能在有限的時間內達成一致嗎？如果網絡中的節點數目不再是幾十個，而是一萬個，那么又該如何協調這些數量龐大的節點呢？
在回答這些問題之前，其實更應該反問：為什么需要網絡是完全開放、無需許可的？什么場景會需要一萬個節點？這到底是偽需求，還是真實存在的場景？這個問題的答案直接關系到區塊鏈中公有鏈的存在意義，而要回答這個問題，我們需要回到分布式系統的初心和目的。
去中心化的意義
我們為什么需要分布式系統？顯然，這個問題不難回答，通常的理解，分布式系統可以增強容錯能力（Fault tolerance)，畢竟系統依賴眾多不同的節點，而眾多節點同時失敗的可能性遠低于一個節點發生故障的可能性；另外，分布式系統還可以抵御攻擊（Attack resistance），畢竟攻擊或摧毀眾多節點的難度遠大于攻擊單點的難度。
然而，以上這些依然是局限在物理硬件的維度，都是用來降低機器物理硬件發生故障的可能性，而沒有考慮“人”的因素。如果一個系統足夠重要，比如電子貨幣系統等，除了考慮機器故障之外，更多需要考慮的是人的因素。部署節點的人會不會故意作惡呢？如何防止系統內不同節點間的腐敗串通呢？
如下圖所示，以太坊創始人Vitalik Buterin曾經深入地探討過去中心化的含義。如果說傳統的分布式系統做到了architectural decentralization（系統有多少物理機器構成？系統能夠容忍最多多少臺機器同時故障？），考慮的是fault tolerance和attack resistance；那么現在我們需要考慮的是如何做到political decentralization，如何能夠collusion resistance? 到底有多少人或組織最終控制了系統內的節點？如何防止這些人之間的腐敗串通？如果說傳統的分布式系統考慮的問題是網絡或機器硬件的可信，那現在我們想考慮的是“人的可信”：是否存在這樣的技術手段來防范人的作惡？如何確保重要網絡中的大部分節點不被一個人或一個組織惡意控制？
?
去中心化的三個維度（https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274）
值得一提的是，這個問題的必要性依然充滿爭議，很多人根本不曾想過、或者認為根本沒有必要考慮人的腐敗串通，也可能認為對于這個問題技術也無能為力，畢竟這與我們生活的真實世界相去甚遠。我們生活在一個中心化平臺擁有極高聲譽、提供信用背書、控制一切規則流程的世界，比如極少有人擔心銀行會故意做假賬，侵吞你在銀行的資產，畢竟大家普遍認為銀行是值得信賴的。如果認為銀行都不可信，那很可能一切商業活動都無法開展。
然而，我們只是“假設”銀行是可信的，在“信任”與“懷疑”之間，我們只是被迫選擇了信任，畢竟不信任銀行，商業活動無法開展，經濟也將停滯。然而實際上，并沒有切實可行的措施來向所有人“證明”銀行是可信的。
如果你認為這個問題是必要的、有意義的，那么能否找到一種解決方案，可以讓這個世界變得更可信，讓你不再需要“被迫相信”某個陌生人，而是提供一種“證明”，足以確保與你交易的某個陌生人是可信的？Don’t Trust, Please Verify. 你不需要相信我，你也不必相信我，你只需要去驗證我。
如果要解決這個問題，所有人的身份應該是對等的，每個人都可以平等、自由地參與決策過程，每個人都可以自由地進出“議會”，這事實上是一種技術上的democracy，隱含的技術要素是：網絡必須是permissonless的，誰都可以隨時加入隨時離開；節點之間必須是對等的，可以直接通訊；無任何中間人，無任何中心權威存在，完全的點對點（peer to peer）；每個節點都有希望成為記賬者。
因為網絡無權限控制，完全的開放、透明、民主，所以參與的節點數目很可能非常眾多，節點作惡的可能性也很高。那如何在這種permissionless的、節點數目眾多、存在較大作惡可能的分布式網絡環境中，通過某種機制協調節點間的行為，保證整個系統的一致性呢？顯然，如前所述的一致性算法并不能做到這一點，我們需要尋求新的解法。
另外，去中心化可能是區塊鏈領域最充滿爭議的詞匯。一些人認為去中心化是區塊鏈的價值觀和公有鏈的靈魂與存在前提，應該盡可能地保證系統的去中心化程度；而另一些人認為完全的去中心化過于理想、不太可能實現，應該結合實際場景，在兼顧效率的情況下考慮弱中心化或多中心化。這里拋開價值判斷，單純從技術角度理性分析，去中心化程度越高確實系統的安全性會越高，所以在公有鏈的系統設計中確實應該盡可能地保證系統的去中心化程度。不過，結合Vitalik Buterin對于去中心化含義的詮釋，在追求去中心化的過程中，我們不應該停留在單純的表面上看起來的去中心化，而應該綜合考慮去中心化的各個維度，結合實際情況，做出必要的trade-off。
PoW
對開放網絡中的分布式一致性問題比較創新的解法當屬比特幣中的Proof-of-work（PoW、工作量證明）機制。
不得不提的Bitcoin
2008年10月31日，中本聰發表了比特幣白皮書《Bitcoin: A Peer-to-Peer Electronic Cash System》，天才般地為此類問題提供了創造性的解決思路，使得協調復雜網絡環境中的成千上萬節點成為可能。事實上，中本聰并不是為了解決這個技術問題而發表了比特幣白皮書。相反，中本聰想象的更加宏大，他創造性地發明了比特幣這種完全點對點的電子現金系統，以消除傳統支付中需要依賴的可信第三方中間人，而在實現的過程中恰好依賴并解決了開放網絡中眾多節點間的一致性問題。也可以說，比特幣所解決的最核心問題是點對點網絡中電子貨幣的雙花問題。然而，比特幣的實現機制絕不僅僅是分布式網絡技術問題，還結合了密碼學、經濟學、博弈論等思想，并以一種非確定性的概率方式實現了節點間的一致性。因此，單純地稱為算法已不太能準確表達其含義，可能叫作共識機制（consensus mechanism）更為恰當，因為其實現的確依賴了一整套的完整策略與制度。這里我們不過多闡述比特幣的思想意義與實現細節，而僅聚焦在其共識機制的實現上。
比特幣實際上是電子簽名鏈，幣的owner可以通過對前一個交易的哈希值和下一個owner的公鑰進行簽名，并將簽名添加到幣的末尾，從而實現轉賬。接受者通過校驗簽名來驗證幣的owner構成的鏈。然而，問題是幣的接受者沒有辦法確保幣的owner沒有進行雙花（double-spend），即有可能某個幣的owner將同一個幣先后轉給了兩個人。因此我們需要一種機制來讓接收者確保幣的前一個owner并沒有在此之前將幣轉給其他人，為了確保這一點，唯一的辦法就是讓所有人知曉所有的交易。而在無可信第三方的情況下，想實現這一點，所有的交易必須廣播給所有人。因此我們需要一個系統，其中的所有參與者對他們接收幣的順序達成一致，形成唯一的順序記錄歷史。不難發現，這其實就是分布式一致性問題。
而比特幣提供的方案就是需要一個由所有節點組成的時間戳服務器（timestamp server），時間戳服務器可以對交易區塊的哈希加蓋時間戳，并將該哈希廣播出去。每一個時間戳都在其哈希中包含了前一個時間戳，從而形成一條鏈，而每一個新的時間戳都是對其之前所有時間戳的確保與強化。為了在點對點的網絡中實現分布式的時間戳服務器，比特幣采用了工作量證明機制（proof-of-work，PoW）。PoW涉及在做哈希運算時，需要尋找某個值，使得總體哈希值的開頭前幾位都為零，而所需要的平均工作量隨著零位數目的增多而指數增加。另外，該哈希沒有任何規律，為了保證開頭前幾位為零，只能通過暴力的方法不斷地隨機試錯。一旦消耗了足夠的CPU的算力，找到了符合條件的哈希值，則該區塊就無法變更，除非再耗費CPU重做一遍。
另外，PoW也解決了大多數決策問題。在比特幣中，最長的那條鏈就代表了大多數的決策。因為如果誠實的節點控制了大部分的算力，則誠實的鏈就會快速增長并超過其他鏈。如果想篡改某個過去的區塊，攻擊者必須重做相應的區塊和其后面所有區塊的PoW任務，然后追趕并趕超誠實的節點。這種難度是非常巨大的，從數學上不難證明，隨著后續節點數目的增多，較慢的攻擊者想追趕上來的概率指數下降，一般認為經過6個區塊之后，想追趕上來幾乎是不可能的。另外，PoW任務的難度并不是固定的，而是用移動平均的方法動態調整的，這主要是考慮到硬件運算速率的提高和挖礦人數的增減變化，算的快就加大難度、算的慢就減小難度，通過動態調節難度使得比特幣的出塊時間大致穩定在10分鐘左右。
整個網絡的運行過程如下：
?
比特幣交易過程（https://www.giottus.com/Bitcoin）
關于交易、挖礦等細節，這里不過多闡述，有興趣的同學可以參考筆者之前的入門介紹文章（https://www.atatech.org/articles/126343 ）。簡而言之，在比特幣中總是以最長鏈的信息為準，若某個節點發現了比自己更長的鏈會自動切換到最長的鏈工作。
我們忍不住要問，既然PoW成本如此之高，那如何激勵大家貢獻算力、成為節點，以保證整個比特幣網絡的安全呢？比特幣中提供了兩種激勵策略：
這些激勵策略也隱含地鼓勵了節點保持誠實，若某個貪婪的攻擊者真的擁有了過半的CPU算力，他不得不做出選擇：到底是篡改交易記錄，把他已經花出去的比特幣再轉回來呢？還是老老實實地挖礦賺錢新幣和手續費呢？很可能，老老實實地挖礦是更有利的，畢竟能賺到的幣比其他所有節點加起來都要多；而破壞比特幣體系也將會破壞自身財富的有效性，畢竟若比特幣不再可靠，其價值也會迅速崩潰。這里多提一點，攻擊者并不像一般人想象的那樣可以為所欲為、任意篡改或偽造交易記錄，他能做的只可能是將其最近花出去的比特幣偷回來。
PoW為什么有效？
比特幣在沒有任何組織或團體維護的情況下，僅僅依靠社區志愿者自發維護，穩定運行了10年之久，期間從未發生過重大問題，這不能不說是個奇跡，也足以證明了比特幣背后共識機制的有效性。我們忍不住要問，為什么比特幣能夠做到？為什么比特幣背后的共識機制能夠如此有效？bitnodes數據顯示目前比特幣節點數目超過1萬（比特幣節點類型較多，不同口徑數量可能不一致，這里僅考慮全節點）。為什么比特幣能夠在permissionless的網絡環境中，協調上萬的節點保持一致性？
筆者粗淺的認為，可能有以下幾個原因：
- 有效的激勵策略：通過激勵策略有效地激勵了更多節點參與到比特幣的點對點網絡中，節點越多比特幣網絡越安全。
- PoW：挖礦出塊需要消耗CPU算力，人為地制造障礙、增加成本，提高了攻擊者的作惡成本。
- 博弈論思想：激勵策略也考慮了博弈平衡，理性節點保持誠實的收益更大。
- 通訊效率：比特幣節點間的通訊效率并不低效，大家可能注意到其中也涉及到了交易和區塊的廣播，不過這種廣播并非是兩兩廣播，而是由某個節點（發生交易或算出PoW的節點）將信息廣播到其他所有節點。另外，交易廣播并不要求觸達所有節點，只要有許多節點接受，不久之后就會被打包。2014年也有Miller等人（Anonymous Byzantine Consensus from Moderately-Hard Puzzles: A Model for Bitcoin）嚴格證明，消息復雜度并不隨網絡大小而增大，而是一個常數。另外，區塊廣播也容許消息丟失，若某個節點未收到某個區塊，則當它接收到下個區塊時，會意識到自己遺漏了上個區塊，而主動向其他節點請求該區塊。
- 概率性的一致性：相比其他一致性算法，比特幣的共識機制最特別的是不再追求確定性的一致性，而是追求概率性的一致性。當某個區塊剛被挖出的時候，其包含的交易信息并非被所有節點最終確認、其包含的數據并非是最終一致性的結果，還是有可能被攻擊者篡改的；但是隨著后續節點數目的增多，這種被篡改的可能性指數下降，最終一致性的概率顯著增大；一旦后續節點超過6個（也就是經過約60分鐘），這種一致性就可以被認為是確定的、最終的。
顯然，比特幣的共識機制不再拘泥于分布式算法層面，而是包含了更多經濟學、博弈論、概率論等思想，因此可能叫作共識機制更為恰當。不過，我們仍然可以將比特幣的PoW共識機制放到一致性問題的框架內來思考，從FLP和CAP的角度來看：
綜合來看，不難看出，比特幣的PoW共識機制在FLP和CAP的限制下，做到了比較好的折中權衡，在實踐中確實提供了開放復雜網絡中分布式一致性問題的可行解法，比特幣近十年來的穩定可靠運行也有力地證明了這一點。
另外，比特幣的PoW算法也被Miller等人（https://socrates1024.s3.amazonaws.com/consensus.pdf ：Anonymous Byzantine Consensus from Moderately-Hard Puzzles: A Model for Bitcoin）嚴謹地分析并證明：
- 比特幣網絡可以看作是由近似無窮節點組成的，每個節點貢獻一小部分算力，并且相應地每個節點都有較小概率可以創造區塊。
- PoW算法依賴于同步網絡模型。在該模型中，若網絡延遲為0，則算法可以容忍50%錯誤；而以目前真實觀測的網絡延遲來看，比特幣可以容忍49.5%的錯誤；若網絡延遲等于區塊時間（即10分鐘），則只能容忍33%的錯誤；若網絡延遲接近無窮，則算法的容錯也趨近于0。
- 比特幣PoW算法具有擴展性（scalable），這是因為共識時間和消息復雜度都與網絡大小（網絡中的節點數目）無關，而只與錯誤節點的相應算力有關，可以認為是一個無量綱常數。
可見，PoW算法不僅在實踐中可靠，在理論上也能經受考驗。PoW算法采用了同步模型與隨機概率來規避FLP的確定性異步模型不可能定理。而PoW獨立于網絡大小的可擴展性，與PBFT算法O(n2)復雜度相比優勢巨大：節點越多，系統效率并未降低，而系統卻更安全。
PoW到底是什么？
我們忍不住要問，PoW機制到底有何神奇之處呢？
其實，大家可能也意識到了，PoW的思想并不高深，事實上也并非是中本聰首創。早在1993年這一思想就被提出用于對抗垃圾郵件(Pricing via Processing or Combatting Junk Mail)，但直到中本聰創造比特幣之前，這一思想都尚未得到廣泛應用。PoW思想的精髓就在于故意制造障礙、增加參與者的成本，以盡量降低參與者的惡意企圖。比如要求請求者做些額外的工作以檢測DDoS攻擊、垃圾郵件等，也比如最常見的登錄網站需要輸入驗證碼，也是為了增加登錄成本，防止網站被攻擊。這類任務最核心的特征是非對稱：對于服務請求者來說，完成任務必須有一定難度；而對服務提供者來說，驗證任務必須很簡單快速。對于比特幣PoW而言，顯然符合非對稱性：不斷試錯，尋找使哈希符合條件的nonce（隨機數）需要消耗大量算力，而驗證尋找到的nonce是否符合條件只需要做一次簡單的哈希運算驗證即可。
比特幣的PoW本質上是one-CPU-one-vote，一個CPU投一票。為什么選擇CPU，而不是IP地址呢？這仍然是基于任務難度考慮，若是one-IP-one-vote，則系統可以被擁有大量IP地址的人（如ip供應商）輕易控制。相對而言，至少在當時（尚未出現ASIC和FPGA）CPU仍然是比較昂貴的硬件，想擁有大量的算力（CPU+電力）并不容易。當然，這其實也隱含地為比特幣的價值提供了現實錨定：虛擬的貨幣體系通過算力找到了現實物理世界的價值錨定，雖然在很多人看來這種算力的消耗是毫無意義、浪費能源的。
也有很多人提出如何降低比特幣的挖礦成本，當然這種思考嘗試有其積極意義，這種工作量證明的成本需要適宜：難度過大、成本過高確實浪費能源較多，不過比特幣網絡的安全性也得到了提高；難度過小、成本過低則會起不到防攻擊的目的，進而也會降低比特幣網絡的安全性。這其實是一個需要做tradeoff的問題，也是一個偏主觀的價值判斷，取決于大眾對比特幣的認識和定位。價值判斷總是充滿了主觀偏見，目前對于比特幣的爭論如此之大，其實也正是因為社會大眾尚未達成共識，尚未構建出對于比特幣未來共同一致的想象。
簡言之，比特幣的PoW是一整套的機制，包含了技術上的權衡、經濟和博弈的考量，這一整套的策略和機制共同保障了比特幣網絡的安全可靠。
PoW機制的局限性
凡事沒有完美，PoW機制也不可例外地存在局限，其實從大家對比特幣的諸多批評也可見一二，通常地大家認為PoW機制存在以下局限性：
PoS
在這些新的解決思路中，無疑最引人注目的就是Proof-of-stake（PoS、權益證明），同樣面對開放復雜網絡中的一致性問題，提出了全新的解決方案。
基本思想
2011年在bitcointalk論壇一個名為QuantumMechanic的用戶率先提出了proof-of-stake的思想（https://bitcointalk.org/index.php?topic=27787.0 ），而后不斷發展完善，得到越來越多人的信賴。
PoS的基本思想大致如下：
- 所有節點不再同時競爭挖礦，而是每次僅有1個節點做驗證者：在比特幣網絡中，所有節點都需要做PoW任務，也就是說都需要做復雜的哈希運算而消耗大量CPU算力，而只有最先找到答案的節點才能獲得獎勵。這種所有節點間的同時競爭挖礦無疑需要消耗大量資源，那么是否可以每次只有一個節點工作呢？如果可以，那怎么選定這個幸運兒呢？PoS中不再需要挖礦，不再有miner，而是每次只需要選出一個節點作為validator去驗證區塊的有效性。如果某個節點被選為validator來驗證下一個區塊，它將驗證該區塊內的所有交易是否有效。如果所有交易都驗證有效，則該節點對該區塊進行簽名，并添加到區塊鏈上。作為回報，該validator將會收到這些交易相關的交易費用。顯然，在PoS中每次共識只有一個節點付出了勞動，且該勞動非常輕松，從而達到了節約資源的目的。
- 想成為validator必須提供保證金：為了防止validator作惡，想成為validator必須提前往指定賬戶存入代幣作為保證金或抵押擔保金，一旦被發現作惡，則保證金即會被罰沒，而誠實工作將會得到激勵。顯然，只要作惡帶來的收益不超過保證金額度，節點就會老老實實地保持誠實。
- 被選為validator并不是完全隨機的，而是被選定概率與提供的保證金金額成正比：例如Alice提供100個幣的保證金，而Bob提供500個幣的保證金，則Bob被隨機選為validator從而產出下一個區塊的概率是Alice的5倍。這其實就類似于股份制公司，按照出資比例來劃分發言權、最終受益權等，大股東出資多、承擔責任大、相應的回報也大。
?
PoW與PoS對比圖（https://hackernoon.com/consensus-mechanisms-explained-pow-vs-pos-89951c66ae10）
不難發現，PoS也是采用了經濟和博弈的思想，通過激勵策略和懲罰機制來確保了網絡的安全可靠。
PoS為什么有效？
PoS協議仍然符合傳統的拜占庭容錯算法研究的結論。目前圍繞PoS的研究可以分為兩條主線：一條圍繞同步網絡模型、一條圍繞部分異步網絡模型。而基于鏈的PoS算法幾乎總是依賴于同步網絡模型，并且其有效性與安全性可以像PoW算法一樣被嚴格證明（https://nakamotoinstitute.org/static/docs/anonymous-byzantine-consensus.pdf ）。
另外，從CAP的角度來看，基于鏈的PoS算法與PoW算法類似，也是盡可能地做到了容錯性，另外在可用性與一致性之間，更多地保證了可用性。
如果說傳統的一致性算法（Paxos、Raft和PBFT）實現的是確定性的最終性(finality)或一致性，那么PoS與PoW類似，轉而尋求概率性的最終一致性。從傳統CAP的視角，這其實是對一致性的弱化，然而從實踐可行性的視角來看，也是一種全新的思維和突破。
而從PoS的設計策略來看，也可以分為兩大陣營（https://arxiv.org/pdf/1710.09437.pdf ）：
- 一類是如前所述的chain-based PoS，主要是模仿PoW機制，通過偽隨機地把區塊創造權分配給stakeholders來模擬挖礦過程，典型代表如PeerCoin、Blackcoin等。其安全性與有效性可以參考類比pow來看。
- 另一類是BFT based PoS，基于近30年來的BFT類一致性算法研究。基于BFT算法來設計PoS的思想最初在Tendermint中提出，以太坊2.0中的Casper也遵從了這一傳統并做了一些修改完善。這類PoS的安全性與有效性可以參考BFT類算法來看，如可以從數學上證明，只要協議參與者的2/3以上節點都誠實地遵照協議，不管網絡延遲有多大，算法都能保證最終狀態不會出現沖突區塊。不過此類算法也并不完美，特別是針對51%攻擊問題，也尚未完全解決，目前該領域仍然處于開放探索階段。
PoS的爭論
PoS的思想并不復雜，而其中比較容易被詬病的恰恰就是這種與現實世界類似的按出資比例獲取收益的制度。大家對現實世界的馬太效應已經非常警惕，這種制度顯然容易帶來富者越富、窮者越窮的結果：擁有更多代幣的人，將會有更多機會成為validator，從而參與網絡并獲得更多收益。
然而，對這一問題的看法爭議很大，很多人提出了完全不同的看法，認為PoS相比PoW更公平、更有助于對抗中心化趨勢。理由主要是：PoW挖礦依賴現實世界的物理硬件和電力資源，而這很容易帶來規模經濟（Economies of scale）優勢。購買10000臺礦機的公司相比購買1臺礦機的個人更有議價權，甚至可以自主研發成本更低的礦機；而擁有10000臺礦機的礦場，對電費的議價權也更高，甚至可以搬遷到電費便宜的國家和地區的電站旁邊，甚至可以自建成本更低的電站。由此帶來的后果就是越龐大的組織的綜合挖礦成本越低，而這正是現實世界真實已經發生的事實。相比之下，PoS不需要依賴現實硬件，不存在規模經濟優勢，在不考慮價格操縱的情況下，買1個幣的價格和買10000個幣的價格是線性增加的，從這個角度理解，PoS可能更公平，更有助于去中心化。
對PoS的另一個擔憂是其安全性，畢竟PoS不再像PoW那樣做復雜的CPU運算以證明自己。在PoW中，若想發動攻擊，需要控制51%的算力（近來也有研究發現只需25%算力即有可能攻擊成功），這也就意味著需要擁有大部分的礦機和算力資源。而在PoS中，若想控制整個體系，需要擁有51%的代幣。究竟哪個更安全？其實也不太好講，不過可以從現實世界的例子來看，如果比特幣算法切換為PoS，則控制比特幣體系需要大約比特幣市值的一半，大概是400~1600億美金（比特幣價格區間5000~20000美金），顯然這一數字遠遠高于礦機成本，想擁有這么大資金量發動攻擊幾乎是不可能的，從這個角度來講，PoS可能更安全。
除此之外，PoS因為部署成本很低（對硬件要求很低），在真實世界中會導致代幣非常容易分叉，從而產生一堆山寨幣，而PoW不存在這個問題。因為PoW依賴硬件挖礦，若想把比特幣的某個參數改改，這很容易；但真想跑起來，則需要大量算力的支持，需要爭取大量miner的支持，比如bitcoin cash從bitcoin中分叉出來就歷經波折。而PoS完全沒這個顧慮，隨便某個人都可以下載開源代碼、隨意改下，拉幾個節點就可以聲稱自己創造了一種全新的代幣，比如從EOS（代幣名）中可以輕易分叉出幾十上百個山寨兄弟幣，每個都聲稱自己很獨特。這確實是事實，不過也不太容易說孰好孰壞。
PoS的改進優化
PoS機制中最關鍵的當屬下一個區塊validator或creator的選擇機制，究竟誰來做這個幸運兒？前文所說的根據賬戶資金按比例按概率選擇其實是最簡單的一種方式，這種方式確實容易導致有錢人獲得一勞永逸的收益，從而損害網絡中其他參與者的積極性。目前有很多種思路來改善這一問題，其中比較有意思的是coin age-based方法，在選擇creator的時候，除了考慮資金量，還會考慮coin age（幣齡）。所謂的coin age指的是幣在某個賬戶上的停留時間，比如1個幣轉入指定賬戶經過10天，可以認為幣齡是10，而每次幣發生變動幣齡都會從0開始重新計算。通過這樣，可以限制大資金量節點頻繁成為creator，比如可以設定幣齡達到30才有機會成為creator，而成為creator之后幣齡立即清零。這其實是限制了大參與者的利益，為其他中小參與者提供了更多的參與機會。
基于PoS改進的比較有名的方案當屬Delegated Proof-of-Stake（DPoS），其中采用了代理人委托機制。在DPoS中不再是所有節點都有可能成為creator，而是節點間相互投票，只有得票最高的一些節點才可能參與區塊創造過程。具體如下：
- 代理人的職責包含保證自身節點持續運行、收集交易信息并打包到區塊中、簽名驗證并廣播區塊、解決網絡中可能存在的一致性問題。
- 對于大多數DPoS鏈來說，網絡中的所有持幣人（token holders）都可以向代理人投票，且投票權與持幣數量成正比。用戶也可以不直接投票，而把投票權委托給其他人來代表他們投票。
- 投票是動態的、可變的，意味著某個代理人隨時可能被選進來或選出去。而一旦某個代理人被發現作惡或欺詐，就將失去收入和名譽，這就起到了激勵代理人保持誠實、保證網絡安全的目的。代理人可以將收到的區塊獎勵按比例分給向他投票的用戶（這其實相當于賄選，在有些方案中不被允許）。
- 不像傳統的PoS，代理人不再需要持有大量的代幣，而是必須相互競爭從持幣者那里爭取投票。
- DPoS限制了交易區塊的驗證者人數，這相當于犧牲了一定程度的去中心化，但卻帶來了效率的提升，因為網絡達成共識所需的工作量大幅降低。
?
DPoS選舉validator/witness過程（https://www.nichanank.com/blog/2018/6/4/consensus-algorithms-pos-dpos）
不難發現，DPoS通過引入投票機制，盡可能地保證了節點的廣泛參與；而對validator數目的限制（一般是21-101個），盡可能地提高了系統的運行效率。雖然充滿很大爭議，DPoS仍然不失為一種可行的解法，越來越多的區塊鏈系統也在嘗試對其進行改進和探索。
在公有鏈中的應用
在公有鏈中，眾多項目都采用了PoS機制，比較有名的有：
- 以太坊（Ethereum：https://www.ethereum.org/ ）：目前階段以太坊仍然采用的是PoW挖礦機制，不過作為以太坊的創始人和公有鏈領域的領軍人物Vitalik Buterin對于PoS機制顯然更為青睞，也多次闡述過PoS的設計哲學（https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51 ），以及PoS相比PoW的優勢（https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work ）。目前以太坊正在開發基于PoS的Casper協議（https://arxiv.org/pdf/1710.09437.pdf ），預計將于今年下半年發布，這種從PoW到PoS的轉變也標志著以太坊進入2.0時代。如下圖所示，在以太坊2.0 phase0階段，將會發布采用Casper協議的PoS beacon chain，作為coordination layer(https://github.com/ethereum/wiki/wiki/Sharding-roadmap )。
?
以太坊2.0 layers和phases(https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/)
- EOS(https://eos.io/ )：作為DPoS思想的提出者Daniel Larimer發起了EOS公有鏈項目，其中眾多節點會一起競爭，期望成為擁有記賬權的21個Supernodes中的其中一員。這種類似現實世界議會制度的設計引起了非常大的爭議，而超級節點的競選也可能蘊含著巨大的商業利益，這些都已經超越了技術討論的范疇，在此不做過多討論。
Proof of X?
其實，PoS機制的興起除了其本身具備的低成本、高效率、去中心化等特點之外，還在于它打開了一扇新的大門——基于博弈論機制來設計如何降低中心化風險的一系列技術，如何預防中心化壟斷巨頭的形成，以及在已有巨頭的情況下如何防范它們損害網絡（ Proof of stake opens the door to a wider array of techniques that use game-theoretic mechanism design in order to better discourage centralized cartels from forming and, if they do form, from acting in ways that are harmful to the network）。
而隨著近年來區塊鏈（特別是公有鏈）的蓬勃發展，其他各種Proof of機制也層出不窮。從這里面的諸多機制中都可以看到PoS思想的影子，即如何從經濟角度和博弈視角來設計制度盡可能地保證去中心化、安全性與高效率。下面對這些機制做簡要說明：
- Leased Proof of Stake:持幣量非常低的眾多節點可以將代幣出租給其他節點，從而形成合力，增加成為validator的幾率；而一旦選舉勝出得到獎勵，則按比例分配手續費，其實與礦池的思想比較類似。
- Proof of Elapsed Time:所有節點都必須等待一定的時間才能成為記賬者，而等待時間是完全隨機的。而要想保證公平，核心的兩個問題是：如何保證等待時間確實是完全隨機的？如何保證某個節點真的等待了指定的時間？目前的解法依賴于Intel的特殊CPU硬件Intel SGX 系統，目前通常也僅能應用在permissioned網絡環境中，如前所述的以太坊企業聯盟EEA中。
- Proof of Activity:PoA同時結合了PoW和PoS的思想。在PoA中，起始過程與PoW類似，仍然是miners間競爭解題挖礦，只不過所挖的區塊僅僅包含頭信息和礦工地址。而一旦區塊被挖出，則系統自動切換成PoS模式，區塊頭信息指向一個隨機的持幣者（stakeholder），由該持幣者來驗證該pre-mined區塊。
- Proof of Importance:有感于PoS機制傾向于鼓勵人持幣而不是流通、也容易導致富者越富的問題，PoI在計算節點對系統的重要性上吸納了更多的維度：除了考慮幣的數量、幣在賬戶上的停留時間之外，還考慮了交易對手（與其他賬戶的凈交易越多分數越高）以及最近30天交易數目和大小（交易越頻繁、數額越大分數越高）。
- Proof of Capacity:也稱作Proof of Space，思想與PoW類似，只是不再以CPU算力為衡量標準，而是以存儲空間來衡量。
- Proof of Burn:礦工必須燒毀一定量的代幣，即將一定量的代幣轉入eater address(黑洞地址，只進不出，即私鑰未知的地址)，以此來證明自己。本質上與PoW的思想接近，只是工作量證明消耗了算力資源，而PoB直接消耗了代幣本身。
- Proof of Weight:PoWeight是在PoS考慮代幣量的基礎之上，增加考慮了更多的權重因子。比如FileCoin（IPFS分布式文件系統上的代幣）考慮了你擁有的IPFS數據大小；其他的一些權重因子也包含但不限于Proof-of-Spacetime、Proof-of-Reputation等。
?
一致性算法概覽（https://101blockchains.com/consensus-algorithms-blockchain/）
不難發現，雖然這些Proof-of機制層出不窮、不盡相同，但其要解決的核心本質問題是相同的，即：讓誰來成為能夠記賬的幸運兒？這些Proof-of機制只不過是采取了各種不同的策略來制定游戲規則，讓各個節點盡可能公平地證明自己，從中公平地選出幸運兒。所有這些策略，包括基于CPU算力、持有代幣數量、存儲空間大小、隨機等待時間、銷毀代幣數量、節點活躍度、節點貢獻度等，都是在特定的場景下對于開放網絡中一致性問題的探索。
一切關乎信任
從PoW到PoS，再到Proof of "Everything you can think"，對于permissionless網絡中的一致性問題一直在探索中。“一致性”的內涵也在發生變化，從傳統的如何防范網絡與機器硬件的故障，保證網絡節點間的數據一致性，到開放網絡中，如何防范網絡中人的作惡，保證網絡中節點數據間的真實一致。可以說是從硬件的可信，邁進了“人的可信”，公有鏈技術也被視為“信任的機器”。不過顯然，人的可信問題過于復雜，甚至也超越了單純的技術范疇。目前階段所能做到的也遠遠未能保證“人的可信”，更多的仍停留在人對于機器的信任、人對于“協議”的信任。不過可喜的是，我們終于邁出了這一步，開始直面這個棘手的問題，探索創新性的解法。
?
信任的機器（https://www.economist.com/leaders/2015/10/31/the-trust-machine）
總結
這個世界充滿了不確定性，計算機科學也一樣。從計算機出現開始，我們就不得不面對機器硬件的不確定性：意外故障可能帶來的問題。從互聯網興起開始，我們就不得不面對網絡的不確定性：通訊消息可能的延遲、亂序、丟失。而應對不確定性問題最自然的解法就是冗余，通過大量節點來實現系統整體的安全性，避免單點故障，增強容錯能力和抵御攻擊的能力。正是基于此，才帶來了大型分布式網絡的蓬勃發展，而如何在不確定的網絡和節點間尋找到某種確定性，協調眾多節點間的一致性，正是分布式一致性算法需要解決的問題。能夠應對故障類錯誤的CFT算法包括最經典的Paxos算法和更簡單的Raft算法，可以在網絡中正常節點超過一半的情況下保證算法的有效性。這類算法通常應用在環境可信的封閉網絡中，協調幾個到幾十個節點間的一致性，如公司內部的分布式存儲、分布式服務協議、分布式消息系統等。另外，也可以應用于由少數機構組成的需要授權才能訪問的聯盟鏈網絡中。
然而，不確定的不止是網絡與機器本身，還有控制網絡中各個節點的人的行為。如何在可能存在搗亂者惡意篡改數據或攻擊網絡的情況下，保證分布式網絡的一致性，正是拜占庭容錯類算法BFT需要考慮的問題。BFT類算法中最常見的就是PBFT算法，可以在網絡中正常節點超過1/3的情況下保證算法的有效性。即便如此，PBFT對于網絡中惡意行為的應對能力仍然是有限的，另外其性能也會隨著網絡中節點數目的增多而顯著下降。這些局限性也導致PBFT算法僅能用于環境較為可信的、有權限控制的網絡中，協調幾個到幾十個節點間的一致性，比如聯盟鏈場景中。
而在無權限控制的permissionless開放網絡中，不確定性更加嚴峻，特別是網絡節點背后的人的行為的不確定性。如何防止網絡中的控制人之間通過腐敗串通組成寡頭，從而控制網絡中的過半節點，達到控制、損害、攻擊網絡的目的，即是開放網絡需要考慮的問題。從這一角度看，開放網絡中的一致性還隱含了安全性的前提：即不僅要求節點間能夠達成共識，還要求該共識確實是由節點眾多控制人真實表達而形成的。而為了達到這種一致性與安全性，不僅需要實現物理硬件節點在結構上的decentralization，還需要盡可能地保證節點背后實際控制人的decentralization。為了實現這一點，需要保證任何人都可以隨時部署運行網絡協議而成為網絡中的節點、可以隨時進出網絡；節點之間點對點通訊，無任何中心化控制節點；節點的角色是完全對等的，按照規則有公平的可能性參與記賬。而如何協調開放網絡中數量龐大的上萬個節點間的行為，保證網絡的一致性與安全性，即是公有鏈共識機制要解決的問題。其中，最典型的當屬比特幣首創的基于工作量證明的PoW共識機制，以及隨后興起的基于權益證明的PoS共識機制。這些共識機制不再局限于技術上的一致性本身，而是更多地引入了經濟學和博弈論的思想，從經濟和博弈的角度盡可能保證網絡的一致性與安全性。
從傳統的封閉分布式網絡環境中的一致性，到有權限控制的聯盟鏈場景中的一致性，再到無權限控制的公有鏈開放網絡環境中的共識機制，面對的問題越來越復雜，應對的挑戰也越來越嚴峻。從單純的技術視角來看，其中對于consensus的研究是一脈相承的，這些一致性算法或共識機制同樣也都受到傳統分布式一致性理論研究中FLP impossibility和CAP theorem的制約。Paxos、Raft和PBFT都強調了fault tolerance與safety/consistency，而弱化了liveness與availability。而PoW與PoS則采用了全新的視角來考慮該問題，盡可能地保證了fault tolerance，以及liveness與availability，放棄了對于安全性與一致性確定性的追求，而僅僅以概率性的方式追求最終的safety與consistency。
另外，對于consensus的思考，也在不斷深入，從單純的節點間的數據一致性，到強調節點背后的人之間的共識與認同；從保證網絡與硬件的可信，到盡可能地確保組成網絡的節點背后的人的可信。雖然人與人之間的可信非常復雜，也超越了單純的技術范疇，可喜的是我們已經走在路上，而目前在該領域正在進行的創新性的積極探索，也必將讓世界變得更加可信。
注：本文篇幅較長、寫作時間跨度較長、本人水平也有限，所參考資料可能有疏漏或個人理解偏差，歡迎大家指正、討論、交流、建議，后續將進行更新。
參考資料
?
https://yq.aliyun.com/articles/702243?utm_content=g_1000057448
總結
以上是生活随笔為你收集整理的从分布式一致性算法到区块链共识机制的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Linux crond 每分钟，每小时，
- 下一篇： 《微服务：从设计到部署》中文版