摘要：為了理解底層公鏈的模型，我們前置了幾篇概念性文章，講述了我們應該以狀態為中心設計區塊鏈系統的，以及這么做帶來的好處。交易依然表示狀態的變化遷移。

為了理解底層公鏈 CKB 的 Cell 模型，我們前置了幾篇概念性文章，講述了我們應該以狀態為中心設計區塊鏈系統的，以及這么做帶來的好處。并且在上一篇文章中，詳細分析了比特幣 UTXO 模型和以太坊的 Account 模型，以及進行了對比分析。終于，我們要來了解集大成者 Cell 模型了。（前排提示：一遍看不懂沒關系，多看幾遍就懂了）

秘猿科技區塊鏈小課堂第 18 期

在設計 CKB 的時候，我們想要解決三個方面的問題：

狀態爆炸引起的公地悲劇及去中心化的喪失；

計算和驗證耦合在了一起使得無論是計算還是驗證都失去了靈活性，難以擴展；

交易與價值存儲這兩個目標的內在矛盾，Layer 2 和跨鏈的出現將放大這種矛盾，并對 Layer 1 的經濟產生非常負面的影響。

對這些問題沒有答案，Layer 1 就無法長久運行，區塊鏈給我們的種種承諾自然也是無從談起。這三個問題根植于區塊鏈架構和協議設計的最深處，很難通過打補丁的方式來解決，我們必須從最基本的數據結構開始，重新審視問題的根源，尋找更合適的地基。

幸運的是，這個更合適的地基簡單得令人感到幸福，而且一直就擺在我們眼前。（本文會包含一些非常簡單的代碼，應該不會影響非技術讀者閱讀……）

Bitcoin 把整個賬本分割保存在了一個個 UTXO 里面，UTXO 是未花費交易輸出（Unspent Transaction Output）的簡寫，實際上是交易中包含的輸出（CTxOut）。CTxOut 的結構非常簡單，只有兩個字段：

class CTxOut
{
public:
    CAmount nValue;
    CScript scriptPubKey;
...
}

每一個 CTxOut 代表了一個面值不同的硬幣（Yay bit-“Coin”），其中 nValue代表這個硬幣的面值是多少，scriptPubKey 是一段表示這個硬幣所有者是誰的腳本（通常包含了所有者的公鑰），只有能提供正確參數使這個腳本運行成功的人才能把這個硬幣「轉讓」給另外一個人。

為什么要給「轉讓」打引號？因為在轉讓的時候，并不是簡單地把硬幣中的 scriptPubKey 修改或是替換掉，而是會銷毀和創造新的硬幣（畢竟在數字的世界中銷毀和創造虛擬硬幣的成本很低）。每一個 Bitcoin 交易，都會銷毀一批硬幣，同時又創造一批硬幣，新創造的硬幣會有新的面值和新的所有者，但是被銷毀的總面值總是大于等于新創造的總面值，以保證沒有人可以隨意增發。交易表示的是賬本狀態的變化。

這樣一個模型的特點是：

硬幣（資產）是第一性的；

所有者是硬幣的屬性，每一枚硬幣有且僅有一個所有者；

硬幣不斷的被銷毀和創建。

是不是很簡單？如果你覺得自己已經理解了 Bitcoin 和 UTXO ，恭喜你，你也已經理解了CKB 和 Cell！

Layer 1 的關注點在狀態，以 Layer 1 為設計目標的 CKB 設計的關注點很自然就是狀態。Ethereum 將交易歷史和狀態歷史分為兩個維度，區塊和交易表達的是觸發狀態遷移的事件而不是狀態本身，而 Bitcoin 協議中的交易和狀態融合成了一個維度，交易即狀態，狀態即交易，正是一個以狀態為核心的架構。

同時，CKB 想要驗證和長久保存的狀態，不僅僅是簡單的數字（nValue)，而是任何人認為有價值的、經過共識的數據。顯然 Bitcoin 的交易輸出結構滿足不了這個需求，但是它已經給了我們足夠的啟發：只需要將 nValue 一般化，把它從一個存放整數的空間變成一個可以存放任意數據的空間，我們就得到了一個更加一般化的「CTxOut」，或者叫 Cell：

pub struct CellOutput {
    pub capacity: Capacity,
    pub data: Vec,
    pub lock: Script,
    pub type_: Option

交易依然表示狀態的變化 / 遷移。狀態的變化，或者說 Cell 內容的「更新」實際上也是通過銷毀和創建來完成的（并不是真的去修改原有 Cell 中的內容）。每一筆交易實際上都會銷毀一批 Cells，同時創建一批新的 Cells；新創造的 Cells 會有新的所有者，也會存放新的數據，但是被銷毀的 capacity 總和總是大于等于新創建的 capacity 總和，由此保證沒有人可以隨便增發 capacity。因為 capacity 可以轉讓，無法增發，擁有 capacity 等于擁有相應數量的共識狀態空間，capacity 是 CKB 網絡中的原生資產。Cell 的銷毀只是把它標記為「已銷毀」，類似 Bitcoin 的 UTXO 從未花費變為已花費，并不是從區塊鏈上刪掉。每一個 Cell 只能被銷毀一次，就像每一個 UTXO 只能被花費一次。
這樣一個模型的特點是：

狀態是第一性的；
所有者是狀態的屬性，每一份狀態只有一個所有者；
狀態不斷的被銷毀和創建。

所以說，Cell 是 UTXO 的一般化（generalized）版本。
Verify
僅僅有一塊可以保存任意狀態的空間還不夠。Bitcoin 之所以有價值，是因為網絡中的全節點會對每一筆交易進行驗證 ，使得所有用戶都相信（并且知道別人也相信）Bitcoin 協議中寫下的規則（例如 2100 萬的上限）會得到保證。
共同知識之所以能成為共同知識，是因為每個人都知道其他人認可這些知識 ，區塊鏈之所以能讓知識變成共同知識，是因為每個人都知道其他人都能獨立驗證這些知識并由此產生認可。任何共識的過程都包含了一系列的驗證以及相互之間的反復確認，這個過程正是網絡中共同知識形成的過程。（需要注意的是，驗證知識是相對事先確定的驗證規則來說的，通過驗證的知識不代表命題為真。）
我們如何驗證 Cell 中保存的數據呢？這時候就需要 Cell 中的另一個字段 type 發揮作用了。type 與 lock 一樣，也是一段腳本， type 定義了 data 字段中保存的數據在狀態遷移過程中必須要遵守的規則，是對狀態的約束。CKB 網絡在共識的過程中，會在 CKB-VM 中執行 type 腳本，驗證新生成的 Cell 中保存的狀態符合 type 中預先定義好的規則。滿足同一種 type 約束的所有 Cell，保存的是同一種類型的數據。
舉個例子，假設我們想定義一個叫做 SatoshiCoin 的代幣（UDT，UserDefinedToken），它的狀態遷移必須滿足的約束是什么？只有兩條：
用戶必須證明自己是輸入代幣的所有者；
每一次轉賬的時候，輸入的代幣數量必須大于等于輸出的代幣數量。
第一條約束可以通過 lock 腳本來表達，如果有興趣可以查看這里的示例代碼[1]，與 Bitcoin 的 scriptPubKey 原理相同；第二條約束，在 Bitcoin 中是在底層硬編碼實現的，在 CKB 中則是通過 type 腳本來實現。每個 Cell 代表的 SatoshiCoin 數量是一種狀態，我們首先定義其狀態結構，即每個 type 等于 SatoshiCoin 的 Cell 在 data 保存的狀態為一個長度為 8 的字節串，代表的是序列化過后的數量：
{
    "amount": "Bytes[8]" // serialized integer
}
type 腳本在執行中，需要讀入交易中所有同類型的 Cells（根據 type 字段可以判斷），然后檢查同一類型下的輸入 Cells 中保存的 amount 之和大于等于輸出 Cells 中保存的 amount 之和 。于是通過 lock 和 type 兩個腳本，我們就實現了一個最簡單的代幣。
lock  和 type 腳本不僅可以讀取自身 Cell 中保存的狀態，也能夠引用和讀取其它 Cell 中保存的狀態，所以 CKB 的編程模型是一個有狀態的編程模型。值得指出的是，Ethereum 的編程模型之所以強大，更多是因為它有狀態，而不是因為它的有限圖靈完備。我們可以把 type 腳本保存在一個獨立的 Cell 里面，然后在每一個 SatoshiCoin Cell 的 type 字段引用它，這樣做的好處是相同的 type 腳本只需要一份空間保存，像這樣保存數字資產定義的 Cell 我們把它叫做 ADC（Asset Definition Cell）。
SatoshiCoin 的另一個特點是，具體的資產與所有者之間的記錄，分散保存在多個獨立的 Cell 里面，這些 Cell 可以是開發者提供給用戶的，也可以是用戶自己擁有的，甚至是租來的。只有在共識空間所有權明確的情況下，所有者才能真正擁有共識空間里面保存的資產（任何數據都是資產）。在 CKB 上，因為用戶可以真正擁有共識空間，所以用戶可以真正擁有數字資產（當你能真正擁有土地的時候，才能真正擁有土地上的房子）。
Cell 是抽象的狀態驗證模型，Cell 提供的存儲（data）沒有任何內部結構，Cell 支持任意的狀態驗證規則（type）和所有權驗證規則（lock），我們可以在 Cell 模型上模擬 UTXO 模型（就像上面的 SatoshiCoin），也可以在 Cell 模型上構建 Account 模型。lock 腳本在驗證交易輸入的時候執行，確保用戶對輸入有所有權，有權銷毀輸入的 Cells；type 腳本在驗證交易輸出的時候執行，確保用戶生成的新狀態符合類型約束，正確生成了新的 Cells。由于狀態模型迥異，以及計算和驗證分離，CKB 的編程模型與 Ethereum 的編程模型有非常大的不同，什么是 CKB 編程模型上的最佳實踐還需要大量的探索。

通用驗證網絡（General Verification Network）
Bitcoin 是一個驗證網絡（Verification Network）。在轉賬時，用戶告訴錢包/本地客戶端轉賬的數量和收款人，錢包根據用戶提供的信息進行計算，在本地找出用戶擁有的數量合適的硬幣（UTXO），同時產生一批新的硬幣，這些硬幣有些歸收款人所有，有些是找零。之后錢包將這些花費掉的硬幣和新生成的硬幣打包到一個交易里面，將交易廣播，網絡對交易驗證后將交易打包到區塊里面，交易完成。
在這個過程中，網絡中的節點并不關心老的狀態（被銷毀的硬幣）是怎樣被搜索出來的，也不關心新的狀態（新硬幣）是怎樣生成出來的，只關心這些硬幣的面值總和在交易前后沒有改變。在轉賬過程中，計算在用戶端完成，因此用戶在交易發送時就能確定計算結果（新狀態）是什么。
Ethereum 是一個通用計算網絡（General Computation Network）。在使用 DApp 的時候，用戶告訴錢包/本地客戶端想要進行的操作，錢包將用戶的操作請求原樣打包到交易里面，并將交易廣播。網絡節點收到交易之后，根據區塊鏈的當前狀態和交易包含的操作請求進行計算，生成新的狀態。在這個過程中，計算在遠端完成，交易結果（新狀態）只有在交易被打包到區塊之后才能確定，用戶在交易發送的時候并不能完全確定計算結果。

（圖中，上面是 Ethereum 的流程，交易中包含的是用戶請求或者說事件/Event；下面是 Bitcoin/CKB 的流程，交易中包含的是鏈下生成的狀態/State。）
CKB 是一個通用驗證網絡（General Verification Network）。在使用 DApp 的時候，用戶告訴錢包/本地客戶端想要進行的操作，錢包根據當前狀態和用戶的操作請求進行計算，生成新的狀態。在這個過程中，計算在用戶端完成，計算結果（新狀態）在交易發出的時候就已經確定了。
換句話說，Bitcoin 和 CKB 都是先計算再共識，而 Ethereum 是先共識再計算。有趣的是，在許可鏈架構里面也有同樣派別之分：Fabric 是先計算再共識，而 CITA（實際上不僅僅是許可鏈）是先共識再計算。（思考題：哪一種架構更適合許可鏈？）
計算與驗證的分離同時也使得 Layer 2 與 Layer 1 自然分開了。Layer 1 關心的是新的狀態是什么，并不關心新的狀態是如何得到的。無論是 State channel，Plasma 還是其他 Layer 2 方案，其實質都是在鏈外進行計算，在特定時候將最終狀態提交到 Layer 1上進行驗證。

為什么 CKB 的 Cell 模型更好？
現在我們得到了一個非常不同的基礎數據結構，在這個結構之上我們設計了獨特的經濟模型，這個結果真的更好嗎？回顧一開始的三個問題也許能給我們一些啟示。
capacity 是原生資產，受到預先確定的發行規則約束，其總量有限；
capacity 同時又是狀態的度量，有多少 capacity ，CKB 上就能放多少數據，CKB 狀態空間的最大值與 capacity 總量大小相等，CKB 上保存的狀態不會超過 capacity 總量。
這兩點決定了 CKB 不會有狀態爆炸的問題。在 capacity 發行規則適當的情況下，網絡應該可以長久的保持去中心化的狀態。每一個 Cell 都是獨立狀態，有明確的所有者，原本屬于公共資源的狀態空間被私有化，寶貴的共識空間可以被更有效的使用。
CKB 是一個通用驗證網絡，計算和驗證得到了分離，各自的靈活性和擴展性都得到了提高。更多的計算被推到了用戶端執行，計算發生在離場景和數據更近的地方，數據處理的方式更靈活，工具更多樣。這也意味著，在 CKB 架構中，錢包是一個能做的事情更多，能力更大的入口。在驗證端，由于計算結果已經完全確定，交易的依賴分析變得非常輕松，交易的并行處理也就更加容易。
在基于 Cell 建立的經濟模型中，存儲的使用成本與占用空間大小和占用時間成正比，礦工可以通過提供共識空間獲得相應的收益。CKB 提供的 Utility 是安全的共識空間，價值來自于其安全性和可用性（accessability），并不是來自于交易處理能力（TPS），與 Layer 2 負責交易的特點相輔相成，在分層網絡和跨鏈網絡中具有更好的價值捕獲能力。
最后，CKB 不是……
IPFS
CKB 是一種存儲這一點可能會使人感到迷惑：「這不就是 IPFS/Filecoin/（任何分布式存儲）嗎？」
CKB 不是分布式存儲，關鍵的區別在于分布式存儲只有存儲，沒有驗證，也就不會對其存儲的數據形成共識。分布式存儲的容量可以隨著存儲技術的增長而等比例的增長，而 CKB 的容量則收到形成全球共識效率的限制。
CKB 也不需要擔心容量不夠。在 Layer 2 以及分層技術成熟的階段，極端情況下，Layer 1 上可能只需要放一個 merkle root 就足夠了。在 Layer 1 上進行驗證所需要的狀態，也可以通過交易提交給節點，節點通過 merkle proof 驗證狀態是有效的，在此基礎之上再驗證狀態遷移是有效的，這個方向已經有一些研究。
Qtum
Qtum 是嘗試在 UTXO 模型上引入更強大的智能合約的先行者之一，具體做法是保持 Bitcoin 原有的 UTXO 模型不變，在其上引入賬戶抽象層（Account Abstraction Layer），支持 EVM 或是 x86  虛擬機。
在 Qtum 中，Bitcoin 的驗證是第一層，EVM 的計算是第二層（注意這是一個區塊連協議內部的分層，不是 Layer 1 和 Layer 2）。Qtum 對 UTXO 中 scriptPubKey 的處理邏輯進行修改，以實現在交易打包后，將 Bitcoin Transaction 中攜帶的請求傳遞給 EVM 進行執行的效果。
Qtum 將 Bitcoin 和 Ethereum 的執行模型橋接到了一起，網絡節點先驗證交易輸入部分（同 Bitcoin），再調用合約進行計算（同 Ethereum），狀態分散在 UTXO 模型和 EVM 自己的狀態存儲兩個地方，整體架構比較復雜。
CKB 所做的是繼承 Bitcoin 的架構思路，對 UTXO 模型進行一般化（Generalization）處理得到 Cell 模型，整體架構保持了一致性以及 Bitcoin 的簡潔。CKB 上的所有狀態都在 Cell 里面，計算在鏈下完成（類似 Bitcoin），網絡節點只做驗證。