從根本出發，探索區塊鏈共識的四個階段

在接下來的祕猿科技小課堂裏，咱們會從技術角度、經濟模型設計角度、以及共識角度來拆解 Nervos 加密經濟網絡中，底層公鏈 CKB 的設計理念。而本文將會做爲技術角度核心設計 Cell 模型的預備文章，經過本文，咱們但願讀者可以理解比特幣以狀態爲中心設計的優點！從而，可以在接下來的幾篇文章中，更加充分的理解 Cell 模型對於比特幣/以太坊模型的傳承與突破。（PS.本文源於 2018 年初，祕猿科技在招商銀行總行舉辦的一次金融區塊鏈閉門會，公鏈 CKB 是對文中思想的具體實現。）

祕猿科技區塊鏈小課堂第 16 期

---

如何對狀態機建模

狀態機是計算機的一個基本模型，它能夠分紅二個部分：狀態和操做。狀態是指計算機裏的數據；操做是指對數據進行的操做。若是把狀態機比喻成平常使用的數學計算器，計算器屏幕上顯示的就是狀態，按「按鍵」就是對計算器的操做。

狀態機模型

區塊鏈用許多的節點共同模擬了一臺多複本的狀態機。在許多區塊鏈或者分佈式系統中，用戶發出的簽名交易包含了對狀態機的操做，節點執行共識協議對全部操做進行排序，而後按共識排好的順序執行操做，計算出新的狀態。

多複本狀態機

舉例：咱們先保證全部節點初始狀態一致，就是讓每人手上的計算器開始狀態爲數字 0。而後咱們把要執行的操做廣播給每一個操做員，這四個操做員算完後，這個計算器上的最終結果是如出一轍的。爲何會有同樣的結果？由於他們有一個相同的初始狀態。接着，咱們用共識算法保證了相同的操做順序。因此最後必定有一個相同的最後狀態。

狀態機的概念在區塊鏈裏面很是重要，但咱們每每忽視其中的基本細節。設計區塊鏈最應該考慮的因素，是應該以狀態爲中心，仍是以操做爲中心進行設計？這二種不一樣的設計理念會對總體架構產生很大影響，這也是比特幣和以太坊架構的一個根本區別：比特幣是以狀態爲中心的設計，以太坊是以事件爲中心的設計。

這二者有很是大的區別。若是以事件爲中心，計算是在節點上發生；以狀態爲中心的話，計算是在客戶端發生。計算轉移到客戶端，節點的計算就相應減小。交易包含最後的狀態的話，節點能夠很方便的判斷交易的相互依賴關係。計算在節點上發生的話，客戶端就能夠很簡單。因此咱們須要根據目標來權衡這個事情。其實很難說誰更好，只是看咱們目標是什麼。

如何設計帳本

區塊鏈被稱爲分佈式帳本，記錄着全部者和資產之間的關係。帳本里有二個概念，一個是資產，一個是全部者。因此能夠從二個方向去設計系統。

帳本設計

帳戶模型以「人」爲核心建模，先創建帳戶的概念，再記錄他們的帳戶裏有多少錢，以太坊、CITA 、Ripple 都是這個模型；以「資產」爲核心建模，最基礎的概念是資產，好比 UTXO，在 UTXO 的基礎上去記錄全部權。以資產爲核心建模，更適合並行處理，一我的所擁有的資產再也不是一個字段，而是可能分紅十份。我能夠獨立去操做這十份資產。

RSM設計

以帳戶爲核心的設計，交易並行處理更難，帳戶更改只能按照交易順序一個一個來。可是，帳戶模型能夠很方便的去記錄帳戶相關的元數據，好比說這個帳戶有哪些權限。因此對於許可鏈來講，帳戶模型是很是適合的選擇。

如何選擇共識

在公有鏈上，比特幣所開創的 Nakamoto 共識，在開放網絡下，引入了經濟激勵，在開放網絡下實現了對拜占庭錯誤的容忍，但也付出了性能上的代價。許可鏈中一般使用傳統拜占庭共識的變種，充分利用了分佈式系統領域過去幾十年的研究成果。優勢是延遲很是低、吞吐量很高。

在網絡分裂時，許可鏈是選擇網絡中止服務，等待網絡的恢復，來保證一致性；公有鏈則偏好可用性，在網絡分裂時能夠容忍帳本分紅二個版本，等網絡恢復以後，選擇其中一個版本做爲正確的版本，廢棄掉另一個版本。公有鏈想要的是 24 小時不間斷的服務；金融行業回滾的代價太大，想要的倒是一致性。因此選擇 C 仍是選擇 A，取決於你的需求是什麼。

區塊鏈共識的四個階段

第一階段是「加入共識」

加入共識階段決定了什麼樣的節點能夠參與共識協議。好比：在比特幣中，一開始是任意節點均可以加入共識。如今則能夠認爲比特幣的共識加入機制變成了買礦機，有礦機才能參與共識。在 PoS 裏面，則是須要持有代幣或者交保證金才能參與共識。在 DPoS 裏面，代理人須要得到足夠多的投票才能參與共識。學術界也有其餘的研究，好比是加入共識也須要提供一個工做量證實。

經過加入共識階段的設計，咱們能夠把參與共識的節點範圍縮小。好比公有鏈上有一萬個節點，可是咱們只要設計一個加入共識的機制，就能夠把共識範圍縮小到 100 個節點，一旦咱們能夠縮小這個共識範圍，後面就能夠用任意的方法去實現共識。

第二階段是「出塊」

這個階段須要選擇一個節點來將交易打包，生成一個新的區塊。一般有三種方式：

1.共識節點按輪流順序出塊，好比 PoA。
2.採用隨機出塊方式，從 共識節點裏隨機挑一個節點出塊，好比 PoW, NXT-PoS，DPoS。
3.在不出問題的狀況下一直保持一個節點出塊，目前只有許可鏈會用這種方式。

第三階段是「進行驗證和投票」

涉及到共識投票的過程，這裏的設計就很是多。如今你們常常在討論的一些新的共識方法，每每只是第二和第三階段的方案。

投票主要有用區塊投票和用消息投票兩種方式。在 Nakamoto 共識中，新制造的區塊是一張投票，下一個礦工挖出的塊是對以前一系列區塊的投票。每個區塊都是一張票（嚴格來講票有權重，例如工做量證實），最後那條高度最長，包含的區塊（票數）最多，就是勝出的那條鏈。在許可鏈裏面，經常經過節點之間交換投票消息來對新出的塊進行投票，因此在下一個塊沒有出以前就能夠對這一個塊完成共識。

第四階段是「退出共識」

這是經常被忽略的部分。在比特幣系統中，退出共識很簡單，中止挖礦就好了。在許可鏈中，咱們原本是共識節點，如今不想作共識節點了，則須要有相應的設計，進行共識節點變動。

以上四個步驟是區塊鏈共識的一個完整流程。傳統 BFT 共識算法，發揮做用通常是在第三階段，在網絡異步的時候會涉及第二階段，基本上不討論其它兩個階段。因此咱們若是要將傳統的共識算法融入到區塊鏈中，須要另外考慮的問題是很是多的。

將來咱們能作什麼

在設計 CITA 的時候，咱們是爲企業級的用戶考慮的。他們擁有很好的計算資源，因此咱們能夠經過內部並行和分片的方式解決區塊鏈面臨的性能擴展的問題，把區塊鏈裏每個節點的能力放大一百倍，那麼整個網絡的能力就會放大一百倍。這是咱們 CITA 提出微服務的起因。咱們把一個節點拆散，將節點內部變成一個集羣是 CITA 可以提高吞吐量的根本緣由。在 CITA 裏面有不少的微服務，好比 auth 服務是交易驗證的，是能夠並行處理的。因此咱們經過這個方式去解決性能瓶頸問題。

微服務

CITA 的設計目標是多中心的區塊鏈網絡。這樣的網絡不須要太多的節點，就能夠創造很高的信任。這是咱們本身在某雲平臺上作的一個實測。用了一箇中型的雲服務器，通常交易處理能夠達到 15000 TPS，測試用例包括存證，合約建立和代幣轉移， 都有比較好的性能。特別指出的，CITA 這種架構對雲計算很友好。咱們更加傾向從架構的角度、從軟件的角度解決各類問題。儘可能避免去依賴硬件。

性能對比

在咱們工程設計和實現中咱們會遇到不少選擇，咱們每每是選了一邊。有沒有可能兼得呢？我認爲在一些地方是能夠的。好比以太坊上的智能合約很是的輕量，經過 evm 合約構造分佈式應用時，能夠生成成千上萬的合約共同來完成一個使命。Fabric 上的合約能夠用任意原生語言實現，執行環境比較重。CITA 則同時支持二種方式，既能夠跑evm合約，又能夠跑原生合約。

將來，咱們還能夠作什麼呢？好比如今的共識算法的選擇傾向，已經很明顯的顯示出了混合共識的趨勢。咱們是否是也能夠作到這一點？以狀態爲中心的設計仍是以事件爲中心的設計，是否是也能兼得？這正是咱們最近在作的一些嘗試。若是可以同時擁有魚和熊掌，咱們可能可以找到一種更好的區塊鏈，尤爲是公有鏈架構。