Nervos Network一個可擴充套件和可互操作的區塊鏈網路

Nervos CKB（以下簡稱 CKB）是一個以通用共同知識庫（Appendix: Common Knowledge Base）為設計目標的區塊鏈。CKB 網路由存檔節點、共識節點和輕節點組成：

• 存檔節點：CKB 全節點，對新的區塊和交易進行驗證，中繼傳播區塊和交易，儲存 CKB上所有的交易歷史。存檔節點能提高整個網路的健壯性，為 CKB 上的應用提供歷史查詢。
• 共識節點：參與共識協議的 CKB 節點。共識節點接收新的交易，將交易打包成塊，並對新生成的區塊產生共識。共識節點不需要儲存所有的交易歷史。
• 輕節點：使用者透過輕節點使用 CKB 網路，輕節點只儲存非常少量的資料，可以執行在桌面電腦或者是移動裝置上。

CKB 節點透過點對點網路協議組成一個分散式網路，對區塊和交易資料進行轉發和廣播。共識節點執行混合共識協議，以一定的時間間隔產生新的區塊並形成共識，新區塊會被所有節點承認並追加到區塊鏈尾部，新區塊中的交易會更新 CKB 的狀態。

一個新的DApp正規化

CKB 提出一種全新的分散式應用正規化，該正規化由以下五種元素組成：

• Cell
• Type
• Validator
• Generator
• Identity

透過這五種元素，我們將分散式應用徹底解耦成計算、儲存和身份三個方面。在此基礎上，計算進一步分化為生成（Generator）和驗證（Validator）兩個步驟，儲存（Cell）也進一步通用化，可以支援任意結構化（Type）的資料。CKB 中的分散式應用，可以使用 Type 定義合適的資料結構，將應用資料存放在多個 Cells 中；應用的執行邏輯由 Generator 實現，狀態驗證邏輯由 Validator 實現；Generator 在客戶端執行，使用者進行操作時生成新的應用狀態，新狀態被打包在交易中傳送到全網；網路中的節點先驗證交易傳送者的身份，然後使用 Validator 對交易中新狀態的有效性進行驗證，驗證透過後將新狀態儲存到 CKB 中。

CKB 以狀態為核心設計資料流及經濟激勵，交易中包含的是新的狀態，而不是觸發狀態機的事件。因此，CKB 區塊鏈中直接儲存了狀態資料，狀態隨著區塊一起同步，無需額外的狀態同步協議，降低了系統複雜度，提高了系統可用性。分散式應用的狀態被剝離到 Cells 中儲存，Validator 和 Generator 內部沒有任何狀態，計算結果完全依賴輸入，因此都是確定性的純函式（Pure function），容易組合形成更復雜的邏輯。CKB 分散式應用使用的是一種近似Lambda Calculus 的計算正規化，能夠實現與圖靈機相同的計算能力。

表 1 將 Bitcoin、Ethereum 和 Nervos CKB 進行了比較。

狀態生成和驗證

在 CKB 中狀態生成和驗證分離，兩個階段可以既可以使用不同的演算法，也可以使用相同的演算法。對於一般的場景，目前還沒有通用且高效的簡化驗證演算法的方法。在這種情況下，我們使用相同的演算法進行狀態生成和驗證：客戶端使用該演算法生成新的狀態，節點利用交易中記錄的依賴狀態作為輸入，執行同樣的演算法，對比輸出的狀態是否與交易中記錄的新狀態相同，相同則驗證透過。在使用相同演算法的情況下，狀態生成和驗證只有執行環境的差別，沒有計算複雜度的差別。將生成和驗證分離，生成轉移到客戶端執行的好處是：

• 確定性：交易的確定性是分散式應用的核心訴求之一。交易時延的確定性（Hybrid Consensus）已經得到了廣泛的重視，但交易結果（即由交易產生的新狀態）的確定性卻往往被忽視。如果狀態在節點生成，使用者在發起狀態生成請求時無法完全確定請求被執行時的環境，由此可能產生使用者不希望的執行結果。在 CKB 中，由於新的狀態由使用者生成，由使用者完全確定新狀態之後再廣播，交易所能觸發的狀態變更使用者可以完全確定。要麼交易透過驗證，由使用者生成並確認的新狀態被接受，要麼交易沒有透過驗證，不造成任何狀態改變（圖 2）。

• 可並行性：如果狀態在節點生成，節點在處理交易前無法判斷該交易依賴哪些狀態，也就無法判斷交易的相關性。在 CKB 中，由於交易顯式地包含了交易依賴的舊狀態以及生成的新狀態，節點可以直接判斷交易之間的相關性（Transaction）。無相關性的交易可以透過各種方式並行處理，包括多核並行及分片。並行處理交易是解決區塊鏈效能擴充套件問題的關鍵。

• 計算分散式程度高：充分利用客戶端計算資源，減輕節點計算負擔，整體效率更高。

• 客戶端更靈活，容易與客戶端所在平臺整合：雖然使用相同的演算法，但是生成和驗證可以使用不同的方法實現。客戶端可以靈活選擇合適的程式語言來實現生成演算法，計算效率可以更高，生成程式可以無縫整合到執行平臺中，提供最好的使用者體驗。

對於許多特定型別的場景，我們可以找到計算複雜度遠低於生成演算法的驗證演算法，最典型的例子是UTXO 賬本和非對稱簽名。一個很有趣的例子是涉及排序和搜尋的演算法：平均複雜度最好的排序演算法 QuickSort 的計算複雜度是 O(NlogN)，而驗算排序的複雜度總是隻有 O(N)；如果要搜尋一個元素在陣列中的位置，在陣列已經排好序的情況下計算複雜度為 O(logN)，而驗算的複雜度是 O(1)。對於越複雜的場景，出現生成與驗算複雜度不對稱情況的概率更高。

下文將對 CKB 的 Cell 資料模型及交易資料結構作示意性的描述，目的是更好的解釋 CKB 的功能。在 CKB 的具體實現中，需要考慮包括激勵一致、執行效率在內的其它因素，資料結構會更為複雜，相關細節將在專門的技術文件中描述。

Cell

CKB 中資料的可信度來源有兩種，一種是資料可以客觀驗證，一種是資料經過特定身份使用者的背書。因此，CKB 中資料的最小單元必須包含以下要素：

• 資料本身
• 資料的驗證方法
• 資料提交者的身份

Cell 是 CKB 中的最小資料單元，可以存放任意的資料。Cell 包含以下基本內容：

• type: Cell 的資料型別。
• capacity: Cell 容量，可存放資料的最大位元組數。
• data: Cell 實際儲存的二進位制資料，可以為空。包含 data 在內，cell 佔用的位元組數總是小於等於 capacity。
• owner_lock: 透過指令碼表示的 Cell 所有者。Cell 所有者可以轉讓 Cell。
• data_lock: 透過指令碼表示的 Cell 使用者。Cell 使用者可以更新 data。

Cell 一旦建立無法更改，是一種不可更改（immutable）的資料單元。對 Cell 的更新，實質上是透過建立所有權相同的新 Cell 來實現。使用者透過交易提交包含新資料的新 Cell，同時使老的 Cell 失效（見Life Cycle）。因此，CKB 也可以看作是一個支援版本的資料倉儲，最新的Cells 代表了資料倉儲的當前版本，已經失效的 Cells 代表了資料倉儲的歷史。

對 Cell 的操作權分為兩種，所有權和使用權。Cell 的 owner_lock 規定了所有權，即轉讓Cell capacity 的權利；Cell 的 data_lock 規定了使用權，即建立新的 Cell 來更新 Cell 內容的權利。Cell capacity 可以一次全部轉讓，也可以部分轉讓，部分轉讓會建立新的 Cell（比如一個 capacity 為 10 的 cell 變成兩個 capacity 各為 5 的 cell）。Cell capacity 的增長速度由共識參與度及流動投票決定。

Cell 的 lock 指令碼由 CKB 支援的虛擬機器執行，使用者在更新 Cell 資料或是轉讓 Cell 時需要提供相應的證明作為 lock 指令碼輸入，如果 lock 指令碼執行結果為 True 則證明使用者具有相應的許可權，可以進行操作。

lock 指令碼表達了 Cell 的操作許可權，可以代表單使用者，也可以是門限簽名或者更復雜的許可權。Cell 具有很好的隱私性，使用者透過使用不同的 lock 指令碼，可以很輕鬆地使用不同的假名（Pseudonomy）來管理自己的 Cells。Cell 的所有者和使用者可以是相同的使用者，也可以是不同的使用者，這也意味著 CKB 使用者不需要擁有 Cell 就可以使用 CKB，使用門檻低。

生命週期Cell 生命週期有兩個階段，新建立的 Cell 處於第一個階段 P1。Cell 是不可變資料物件，一旦被建立其內容不能被修改，Cell 的更新透過 Transaction 實現：Transaction 以需要被更新的 P1 Cell 作為輸入，以 Generator 產生的包含新狀態的 P1 Cell 作為輸出。

一個 P1 Cell 只能被使用一次，不能被用作兩個不同 Transaction 的輸入。P1 Cell 被使用後進入第二個階段 P2，P2 Cell 不能再用作 Transaction 輸入。我們把所有的 P1 Cells 形成的集合稱為 P1 Cell Set（P1CS），P1CS 中儲存了 CKB 當前所有的共同知識；所有的P2 Cells 形成的集合稱為 P2 Cell Set（P2CS），P2CS 中儲存了 CKB 所有的歷史狀態。

CKB 網路上的全節點只需要 P1CS 就可以驗證 Transaction，P2CS 可以按照一定的策略清理。P2CS 可以儲存在存檔節點（Archive Node）或者是分散式儲存網路上。CKB 輕節點只需要儲存區塊頭和特定的 Cells，不需要儲存完整的 P1CS 和 P2CS。

型別

CKB 為 Cell 提供了型別系統，使用者可以建立自定義的 Cell 型別。透過型別系統，我們可以在CKB 中定義不同結構的共同知識以及相應的生成驗證規則。

建立新的 Cell 型別需要定義 Data Schema 和 Validator 兩個要素：

• Data Schema: 定義新型別的資料結構。
• Validator: 定義新型別的驗證程式。

Data Schema 和 Validator 的定義也是一種共同知識，存放在 Cell 中。每一個 Cell 都有一個且僅僅一個型別，多個 Cell 可以屬於同一個型別，也可以屬於不同的型別。

Data Schema 提供該型別的資料結構定義，使 Validator 可以理解和使用 Cell 中儲存的資料。Validator 為驗證程式，由每一個節點使用 CKB 支援的虛擬機器執行，以交易的 Deps,Inputs 和 Outputs 作為程式輸入（Transaction），能夠透過驗證就返回 True，不能則返回False。Cell 的建立、更新和銷燬可以使用不同的驗證規則。

指數

使用者在定義 Data Schema 時可以設定索引，新增了索引的資料欄位能夠獲得額外的支援，包括能夠在 Validator 或是 owner_lock/data_lock 中使用的條件查詢指令以及聚合函式。例如，眾籌發起方可以生成一個 Identity Cell（Identity），在其 data_lock 中利用條件查詢和聚合函式判斷屬於這個 identity 的代幣總數是否已經達到眾籌目標，實現有上限的眾籌。

Identity

Identity 是一種系統型別，使用者可以任意建立屬於自己的 Identity Cell。Identity Cell 可以作為 Cell data_lock/owner_lock 使用，Cell 更新或者轉讓時，需要提供對應 IdentityCell data_lock 的解鎖指令碼（圖 3）。

Identity 是廣義的身份，Identity 可以對應個人或者機器實體的任何身份側面。Identity 是Nervos 網路中分散式身份協議 NIP（詳見 Nervos Identity Protocol Paper）的基礎。透過 NIP，Nervos 網路引入 CA 證書，可以相容現有的 PKI 體系，使用者可以表達自己的社會身份，分散式應用可以基於身份構建。Identity Cell 中可以存放公開身份資訊，或者是身份資訊摘要，由使用者在必要時與分散式應用互動，提供所需的詳細資訊。

Transaction

Transaction 表達了 Cells 的轉讓和更新。在一個 Transaction 裡面使用者可以轉讓 Cell，或是更新一個或者多個 Cell 的內容。Transaction 包括以下基本內容：

• deps: 依賴集合，對交易進行驗證所依賴的只讀資料，只能是 P1 Cells 的引用或者使用者輸入。
• inputs: 輸入集合，包含需要被轉讓/更新的 Cells，只能是 P1 Cells 的引用及相應的解鎖指令碼。
• outputs: 輸出集合，包含新產生的 P1 Cells。

由於 Cell 的不可變更性，更新 Cell 時不會直接修改舊的 Cell，而是會產生一個新版本的 Cell，這些 Cell 版本可以前後銜接在一起，形成 Cell 的 “版本鏈”：某一次 Cell capacity 轉讓時建立了這個 Cell 的第一個版本，對 Cell 的後續更新形成了這個 Cell 的一系列歷史版本，在版本鏈的最後 (Head) 是 Cell 的最新版本。CKB 是所有 Cell 版本鏈的集合，所有 Cell Heads的集合是 CKB 的當前版本。

CKB Transaction 中包含的 deps 和 inputs 使節點可以方便地判斷交易間的依賴關係，對交易進行並行驗證（圖 4）。Transaction 中可以混合多種型別的 Cell，可以方便的實現跨型別的原子性操作。

CKB Cell 模型和 Transaction 的設計使 CKB 對輕節點更友好。由於所有的狀態都在區塊中，區塊同步協議也支援了狀態同步。輕節點只需要同步區塊，不需要計算（生成狀態），就可以獲得新的狀態。如果區塊中只儲存事件，則需要全節點支援額外的狀態同步機制。在缺乏激勵的情況下，區塊鏈協議之外的額外機制很難大範圍的部署。在區塊鏈協議內同步狀態，使輕節點與全節點之間的地位更平等，系統更加健壯和去中心化。

Generator

Generator 是生成程式，用來生成符合型別定義的新的 Cells。Generator 在發起交易的客戶端本地執行，以使用者的輸入以及現有的 Cells 作為輸入，生成包含新狀態的 Cells 作為輸出。Generator 用到的輸入以及產生的輸出共同構成一個 Transaction（圖 5）。Validator 和 Generator 可以使用相同的演算法，也可以使用不同的演算法（Overview）。Generator 可以接受一個或者多個相同或者不同型別的 Cell 引用作為輸入，可以產生一個或者多個相同或者不同型別的新 Cells 作為輸出。

透過定義 Data Schema, Validator 和 Generator，我們可以在 CKB 中實現任意共同知識的驗證和儲存。例如，我們可以定義一個 AlpacaCoin 的新型別：

Data Schema = {amount: “uint”}

// pseudo code of checker check():
// 1. 檢查 inputs 列表中的項都有正確的解鎖資料
// 2. 計算 inputs 列表中 AlpacaCoin 的 amount 之和 IN
// 3. 計算 outputs 列表中的 AlpacaCoin 的 amount 之和 OUT
// 4. 比較 IN 和 OUT 是否相等，並返回結果

Validator = validate(context ctx, inputs, outputs)

// pseudo code of generator gen():
// 1. 查詢使用者能夠花費的，屬於 AlpacaCoin 型別的 Cells
// 2. 根據使用者輸入的轉賬地址和金額，生成型別為 AlpacaCoin 的屬於收款人的 Cell 和找零 Cell
// 3. 返回被使用的 Cells 列表，以及新生成的 Cells 列表，這些 Cells 將用於構造交易

Generator = gen(context ctx, address to, uint amount, ...)

Figure 5. Transaction and Cell Generation/Validation

Layered Network

在 Nervos 網路中，CKB 和 Generator 構成上下層的關係，CKB 是共同知識層，而Generator 是生成層。CKB 只關心 Generator 產生的新狀態，不關心狀態產生的具體方式，因此 Generator 的具體實現形式是非常多樣化的（圖 6）。

分層架構將資料與計算分離，使每層都可以獲得各自的靈活性與可擴充套件性，使用不同的共識協議。CKB 作為最底層，擁有最廣泛的共識，是整個 Nervos 網路的基礎。不同的應用所需要的共識範圍不同，強制所有應用都在最廣泛的共識下進行會導致效率低下。在 Nervos 網路中，業務參與方可以根據自己所需的共識範圍選擇合適的 Generator，只在需要與區域性共識範圍外的其他服務互動時，將區域性狀態提交到 CKB 上，使其獲得更廣泛的認同。

Generator 可以包括（但不限於）以下幾種形式：

• 客戶端
在使用者裝置上直接執行 Generator 生成新狀態。透過輕客戶端提供的介面或是客戶端程式庫，生成演算法可以用任何程式語言實現。

• 狀態服務
使用者使用中心化服務，由伺服器執行生成演算法，生成新狀態。目前所有的網際網路服務都可以透過狀態服務的方式使用 CKB，使服務狀態資料獲得更大的信任和流動性。例如，遊戲公司可以使用狀態服務架構，在中心化服務中執行遊戲邏輯，生成道具資訊；在 CKB 中定義道具型別和總量等規則，將生成的道具登記並確權。

結合 Nervos Identity Protocol，資訊釋出機構提供基於身份的可信 Oracle，為Nervos 網路中的其他服務提供必要的資訊。

• 狀態通道
兩名或多名使用者使用點對點網路連線通訊，共同生成新的狀態。狀態通道的參與者可以透過CKB 登記和獲取參與者資訊，建立通道連線。參與者可以在 CKB 上提供保證金，使其它參與者相信通道能夠順利執行。狀態通道參與者之間可以使用共識協議或是多方安全計算技術來生成新狀態。

• 生成鏈
一個用於生成 CKB 新狀態的區塊鏈。生成鏈可以是公有鏈（例如任何使用 EVM 的區塊鏈），也可以是許可鏈（例如 CITA 以及 Hyperledger Fabric）。使用許可鏈可以將狀態計算限定在一定參與範圍內，保護計算隱私，同時獲得很好的效能。在應用鏈中，參與者共同執行狀態生成並相互驗證計算過程，在狀態需要更廣泛共識時，將其提交到 CKB中，使之成為接受度更高的共同知識。

Hybrid Consensus

共識演算法追求在網路延遲和各類節點故障存在的情況下實現兩個目標：正確性和效能。正確性又包括一致性，指分散式系統中每一個節點的資料副本完全相同，以及可用性，指分散式系統能夠在有限的時間內響應使用者的請求。效能也包括兩個方面，一是交易延遲，即從客戶端提交 Transaction到客戶端獲得確定性結果所需要的時間，越短越好；二是吞吐量，即系統每秒中可以處理多少筆交易。

公有鏈執行在開放的分散式網路中，節點可以自由的加入和退出，線上節點不固定且變更頻繁，這些都是傳統 BFT 共識演算法很難處理的問題。Satoshi Nakamoto 巧妙的引入經濟激勵以及概率性共識應對這些難點 [2]，因此要保證正確性需要額外的開放性與公平性。開放性使共識節點的加入退出無阻礙，無論是有 100000 個節點還是 1 個節點，公有鏈都能正常工作；公平性使共識節點可以獲得與所付出的努力成比例的回報。公有鏈共識演算法的效能指標除延遲和吞吐量外，還需要考慮執行開銷。

以比特幣工作量證明（Proof of Work）為代表的 Nakamoto 共識擁有極佳的開放性和可用性，比特幣網路中的節點可以任意的加入和退出，網路效能隨著共識節點數量的增加能夠保持不變。但 Nakamoto 共識吞吐量低，以比特幣 7 筆交易每秒的處理速度，難以消化商業場景的日常需求。即使透過次級通道技術（例如閃電網路）將大部分交易轉移到鏈下，通道的建立與關閉依然受到鏈上處理速度的制約，在網路擁堵時甚至會影響到次級通道的安全性。Nakamoto 共識以區塊投票，交易確認速度慢，通常需要 10 分鐘到一個小時，使用者體驗不佳。在分割槽的情況下，比特幣網路能夠繼續提供服務，但交易是否被完全確認無法保證，無法滿足對交易確定性要求較高的商業場景。

經歷了 30 年發展的傳統拜占庭容錯（Byzantine Fault Tolerance）共識可以實現媲美中心化系統的吞吐量和交易確認速度，但其開放性不佳，節點動態增減難度大，網路效能隨參與共識的節點數量增加而迅速下降。傳統 BFT 共識對故障的容忍能力較低，在網路分割槽時節點無法達成一致，網路無法正常提供服務，難以滿足公有鏈對可用性的要求。

在研究和實踐中我們認識到，傳統 BFT 演算法在正常路徑下邏輯簡單，但需要以複雜的邏輯應對故障情況；Nakamoto 共識則以不變應萬變，無論是正常還是故障情況都是同樣的邏輯，但也因此影響了正常路徑下的系統效能。如果將 Nakamoto 和傳統拜占庭容錯兩類共識協議有機的結合在一起，新的混合共識在一致性、可用性、公平性及執行開銷等方面可以形成最佳組合 。

CKB 將按照混合共識的思路，設計並實現自己的混合共識演算法，為交易提供見證。透過將Nakamoto 共識和傳統 BFT 共識結合，我們既可以保留開放性和可用性，又可以在正常路徑下獲得傳統 BFT 共識的優秀效能，將交易時延降到最低，最大程度的提升系統吞吐量。

CKB 以 Cell Capacity 作為參與共識的條件。想要參與共識的節點需要抵押一定數量的 CellCapacity 作為保證金，用於確定共識節點的投票和獎勵分配權重。如果某個共識節點作惡，觀察到作惡行為的其它共識節點可以將證據提交到鏈上，導致作惡節點的保證金被系統罰沒。保證金機制能增加共識節點作惡的成本，提高共識的安全性。
CKB 混合共識的詳細設計請參考 CKB Consensus Paper。

Economics

經濟模型是公有鏈的靈魂。透過引入經濟激勵，比特幣第一次解決了開放網路上的共識難題。每一個區塊鏈網路都是一個透過經濟激勵結合在一起的自治共同體。一個優秀的經濟激勵制度應該引導區塊鏈的參與者為這個自治共同體作出貢獻，最大化區塊鏈的效用。

CKB 經濟模型應該能夠激勵使用者、開發者和節點執行者合力為共同知識的形成與儲存貢獻力量。CKB 的經濟模型同樣以狀態為核心進行設計，透過 Cell Capacity 增發和手續費兩部分獎勵產生激勵。

CKB 狀態的形成與儲存都需要一定的成本。狀態的形成需要節點驗證，消耗計算資源，狀態的儲存則需要節點持續提供儲存空間。現有的公有鏈經濟模型只在處理交易時收取一次性手續費，一旦資料上鍊成為共同知識，則可以無需再付出任何成本，永久佔用所有節點的本地空間。

在 CKB 中，Cell 是狀態的儲存單元。未被佔用的 Cell Capacity 可以轉讓，具有流動性，但是被佔用的 Capacity 不能被轉讓，失去流動性。因此，Cell 的使用者需要為狀態的儲存支付流動性作為成本。Cell 的使用時間越長，需要付出的流動性成本越高。透過使用流動性成本而不是預付費的方式，避免了預付費用完導致 Cell 被強制回收的問題。

Cell Capacity 的價格是對 CKB 中共同知識價值的直接度量。需要注意的是，Cell 的使用者和所有者可能是不同的，所有者可以幫使用者支付流動性成本。更新 Cell 中的資料或是轉讓Cell Capacity 則需要支付手續費。共識節點可以設定自己願意接受手續費水平，交易手續費高低是由市場決定的。手續費也可以由 Cell 所有者代替使用者支付。

當前主流使用者難以使用區塊鏈的一個重要原因是，交易手續費必須以原生代幣進行支付，由此要求使用者在使用服務之前自行尋找方法先獲取原生代幣，提高了使用門檻。另一方面，使用者已經習慣了基本服務免費，增值服務收費的商業模式，無論做什麼都要收費也不符合主流使用者習慣。CKB 透過允許 Cell 所有者代替使用者付費的設計解決了這兩個問題，為應用開發者提供了更多的商業模式選項。

系統手續費收入的大部分由出塊節點獲得，剩餘的部分將用於支援 Nervos 網路的開發、研究、運營等工作，以保證網路的持續良性發展。手續費分配比例由流動投票（流動投票）決定。

除了用於支付共同知識的形成和儲存成本，Cell Capacity 還可以被用在共識抵押、流動投票等多個場景中。CKB 的安全程度與共識節點抵押的代幣數量息息相關。共識抵押代幣越多，節點作惡成本越高，整個系統也更加安全。CKB 的 Cell Capacity 增發調節的目標之一是保證一定的共識保證金抵押水平，以此保證系統安全。透過調節增發比例，調節共識參與者可以獲得的無風險收益比例，進而調節共識的參與度。

治理機制

作為 Nervos 網路的基礎設施，CKB 必須能夠與其所承載的生態同步進化，在不間斷執行的同時進行調整執行引數，或是進行更深程度的網路升級。從區塊鏈發展歷史中我們能夠看到，社羣達成共識或是網路升級的成本過高將會阻礙創新，使網路難以進化，無法生態發展的需求。

因此，CKB 內建了流動投票和熱部署機制，使 CKB 成為一個能夠自我進化的分散式網路。

流動投票

CKB 的執行依賴一組系統引數，其中有一些能夠自動調節，有一些需要進行投票達成共識；CKB的程式碼中可能會有 bug，修復方案有可能需要投票共識；隨著 Nervos 生態的發展，CKB 的功能需要持續升級，實現和部署新的功能也需要投票共識。因此，投票工具是 CKB 長期穩定執行必不可少的元件之一。

CKB 支援流動投票 [5]（圖 7）。每一位 Cell 所有者都可以參與到與 CKB 發展有關的決策中來，投票權重由使用者所持有的 Cell Capacity 決定。在流動投票中，使用者可以設定自己的投票代表，由其進行代理投票。投票代表也可以設定自己的投票代表。考慮到提案專業度和參與激勵的問題，不同的提案可以設定不同的接受條件，例如參與率和支援率。

Neuron

得益於 Cell 資料模型的抽象性，CKB 的功能模組可以利用 Cell 來實現和存放。我們把承擔CKB 系統功能的 Cell 稱為 Neuron，Neuron 實質上是一種特殊的 Cell 型別，其使用者是CKB 自身。
在功能變更/升級提案被實現為 Neuron 之後，社羣使用流動投票對是否部署進行表決。在獲得社羣共識後，新的 Neuron 將被部署到鏈上，修復系統 bug 或是提供新的系統功能。細粒度的Neuron 升級能夠大大降低 CKB 的進化難度。

輕客戶端

節點完全對等的區塊鏈架構已經受到了嚴重的挑戰。公有鏈網路上節點效能參差不齊，對等節點架構不僅對使用者硬體要求越來越高，也無法充分發揮高效能節點的潛力。越來越多的使用者放棄執行全節點，轉而使用輕客戶端以及中心化客戶端。全節點需要對所有區塊和交易資料進行驗證，對信任依賴最小，但開銷最大，使用非常不便。中心化客戶端則完全信任中心伺服器提供的資料，放棄了驗證。輕客戶端則透過稍微增加對全節點的信任，大大降低了驗證開銷，對使用者體驗有很大的提升。

同時，移動裝置已經成為人們日常使用網際網路服務的主要裝置，原生應用也越來越流行。因此，對移動裝置友好是 CKB 的設計原則之一，Nervos 應用應該能夠流暢的執行在移動裝置上，與移動平臺無縫的銜接。

CKB 支援輕客戶端。CKB 使用可證資料結構組織區塊頭，可以極大地加快輕客戶端的同步速度。得益於 CKB 以狀態為中心的設計，輕客戶端無需重複計算就能夠方便地直接同步到最新的狀態（P1CS）。使用本地儲存使用者關心的少量 P1 Cells 及網路頻寬，輕客戶端可以提供更好的分散式應用體驗。

Summary

Nervos CKB 為一個全新的分散式應用網路提供了共同知識層。Nervos CKB 以狀態為中心設計，採用更為通用的儲存模型，更好的平衡了激勵機制，得到了一個更具可擴充套件性的分散式應用正規化。

關於更多Nervos資訊：