在接下來的祕猿科技小課堂裏，我們會從技術角度、經濟模型設計角度、以及共識角度來拆解 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合約，又可以跑原生合約。
未來，我們還可以做什麼呢？比如現在的共識算法的選擇傾向，已經很明顯的顯示出了混合共識的趨勢。我們是不是也可以做到這一點？以狀態爲中心的設計還是以事件爲中心的設計，是不是也能兼得？這正是我們最近在做的一些嘗試。如果能夠同時擁有魚和熊掌，我們可能能夠找到一種更好的區塊鏈，尤其是公有鏈架構。