CKB，版本控制與區塊鏈演進

From Jan Xie

我是 Linus 的粉絲。他創造了一個隨處可見的開源操作系統，與人合著了一本我非常喜歡的書，還建立了一個幾乎每個開發者每天都在使用的分散式版本控制系統。

我在見到 Git 的那一刻就開始用上了 Git，並被它的速度和優雅所吸引。開發者用版本控制系統[1]來管理源代碼，這樣他們就可以隨時掌握代碼的更新情況，與朋友和同事共享修改，在出現新錯誤時回滾到之前沒有 bug 的版本等等。Git 讓生活變得更加有趣，我希望 CKB 也可以做到這一點。

CKB 是 Git

我們在創建 CKB 和 Cell 模型的過程受到了 Git 的啟發。Git 的出現是出於 Linus 對 Linux 內核開發方便的渴望，人們無論何時想要組織一些東西，從注釋到博客文章，到圖片，都可以使用它。它是一個具有極好歷史跟蹤功能支持的知識庫。

Git 知識庫被稱為「存儲庫（repository）」，在內部維護著一個不可變的只可追加的對象資料庫（想起來了嗎？）。Git 中的基本存儲單元是 Blob（二進位大對象)，它是一個包含人們存儲在存儲庫中數據的對象，就像 CKB 中的一個 Cell 一樣。Git 會為每個文件的每個版本都創建一個 blob 對象。每當創建一個新文件時，都將創建一個新的 blob。每當修改現有文件時，都要創建一個具有新內容的 blob，而不需要修改舊的 blob（是不是聽起來很熟悉？）。每個 blob 都會被哈希，並且該 blob 哈希會被用作引用 blob 的標識符。工作了幾個小時之後，您創建了一些新文件並修改了一些現有文件，然後將所有更改提交到存儲庫中，將新的提交同步給同事們，便收工了。

一個提交是 Git 中的基本歷史點，存儲庫歷史由一系列提交組成，這些提交包括從存儲庫的起源到最近的更新。提交是某個特定時間的存儲庫版本，包括版本元數據，如作者、時間戳、上一個提交和對 blob tree 的引用。就像區塊頭通過寫下礦機地址、時間戳、父塊哈希和交易 merkle tree 的根來為區塊鏈的每次更新保存元數據一樣。您和您的同事們通過擴展 git 存儲庫的歷史來獲得報酬，就像礦工通過擴展區塊的歷史來獲得區塊獎勵一樣。

Git 存儲庫也可以有 Fork。人們在不同的分支上工作，但是哪個分支是「正確的」是由存儲庫維護者決定的，而不是通過共識。Git 是一個沒有共識的分散式系統，依賴於特殊的點對點通信（如 ssh 或電子郵件）進行數據交換。

Git 和區塊鏈之間有著相似之處，這也意味著我們應該更謹慎地將 Git 的想法融入到區塊鏈中，而不應該將相互衝突的設計選擇引入到區塊鏈中，這樣區塊鏈或智能合約開發者就可以享受到 Git 的一些已被證明的優點。這就是 CKB 內在的真實樣子：一個擁有真正的 p2p 網路、全球共識和增強 blob 的唯一大型 Git 庫，由一群匿名者不斷進行更新。

這不是一個區塊鏈

按照你喜歡的方式給 Cell 命名

Git 和 CKB 的核心都是數據對象（blob/cell）和哈希引用。哈希引用是一個對象的固有名稱，是你可以揮舞的魔杖，提取出數據的價值。如果你知道一個對象的名字，你就可以通過引用它，從而獲得它的力量。在 CKB 上，智能合約的代碼和用戶數據是分離的，所以哈希引用可以讓你直接命名一段代碼或用戶數據，讓它們成為系統中的一級對象[2]。這種精細的顆粒度創造了一個靈活而強大的編程模式。下面是一些例子。

重用代碼/數據

因為 cell 是可引用的存儲單元，所以在 CKB 上重用代碼/數據很容易。假設在 cell 0xbeef#1（交易 0xbeef 的輸出 1）中存儲了一些共享代碼/數據，要重用它，首先需要載入 cell 0xbeef#1 作為交易依賴項（cell_deps），然後使用 ckb_load_cell_data 系統調用從它那裡讀取數據，如默認的鎖定腳本所示。一旦將 cell 0xbeef#1 中的數據載入到 VM 內存中，那麼就可以根據您的需要[3]，將其視為代碼或數據使用。通過這種方式，CKB 就類似於一個代碼和數據共享庫，供運行在上面的智能合約使用。如果我們能通過組合現有的安全樂高積木來構建一個智能合約[4]，是不是很酷？而不需要從 GitHub 上的某個地方複製代碼，並且一次又一次地部署相同的代碼，這既浪費了時間，也浪費了鏈上的空間。一項對以太坊合約[5][6]的分析中表明，95%~99%的合約都是重複的。

Ethereum 上重複最多的智能合約

無懼依賴刪除

在上面的代碼/數據重用例子中，你不需要擔心有人修改存儲在依賴 cell 中的代碼/數據，因為 cell 是不可變的，也就是說，沒有人有辦法修改它。但是如果依賴 cell 的所有者直接將其從 CKB 中刪除呢？那會不會讓我的智能合約無法使用呢？

在 Ethereum 上的確是這樣的。如果你在這個領域待的時間足夠長，你可能會知道 2017 年關於 2.8 億美元的意外事故[7]。整個悲劇是由 Ethereum 上一個智能合約的意外刪除引發的，這個合約被許多其他智能合約使用。這次刪除導致所有依賴它的智能合約都功能失調，所有存儲在這些智能合約中的資產都被凍結。

而在 CKB 上，這樣的意外並不會造成什麼影響，因為任何保存代碼副本的人（例如那些運行全節點或複雜的輕客戶端）都可以在鏈上再次部署相同的代碼，代碼哈希的引用仍然有效。我們只需使用新的依賴 cell 來構造交易即可。沒有人會因此受到損失，一切都仍將正常運轉。

從依賴刪除中恢復

實際上，我們甚至可以有意地利用這一點來實現代碼的「先使用後部署」。假設您想使用一個新的自定義鎖定腳本（智能合約）來保護你的 cell。與通常的先部署後使用流程不同，您可以在不進行部署的情況下使用它。只需要將新的鎖定腳本（代碼實現）的代碼哈希放入 cell lock（代碼使用）中，那麼這些 cell 就會被新的 lock 保護，且立即生效。

實際鎖定腳本代碼的部署可以延遲到您想要解鎖這些 cell 之時。如果想要解鎖，首先需要在鏈上部署腳本代碼，然後像往常一樣發送另一個交易來解鎖這些 cell。在 cell 被解鎖之後，您可以刪除部署的代碼並索回被佔用的 CKByte，以減少不必要的存儲成本。先使用後部署的額外好處是更好的隱私性：在你解鎖之前，沒有人知道這個新鎖的邏輯是什麼。

進化的 CKB

在了解了 CKB 和 Git 之間的相似性及其優點之後，我們來探討一個更有趣的問題：如果 CKB 是一個 git 庫，我們可以用 CKB 來管理 CKB 的代碼嗎？

是的！這就是為什麼一些 CKB 核心功能，如交易簽名驗證[8]和 Nervos DAO[9]都是以智能合約形式實現的原因。以交易簽名驗證為例——這是幾乎所有區塊鏈的核心功能，並且是用原生語言硬編碼的（比如比特幣中用 C 語言編寫，go-ethereum 中用 Go 語言編寫）。

為了升級區塊鏈，人們必須在大多數節點上分發和部署新的軟體版本（軟/硬分叉），這需要大量的協調工作。對於 CKB 來說，交易簽名驗證可以和其它智能合約一樣，通過在鏈上部署新版本來進行升級。這讓 CKB 具備了 Tezos[10]提出的長期可升級性。

我們還可以做到更好。在 CKB 上，每個用戶都擁有自己的數據，所以一份合約更像是用戶和 CKB 之間的兩方協議，個人可以做出獨立的選擇。如果你通過代碼哈希[11]來使用合約，這意味著「我同意了這個特定版本的合約」。你不必擔心有一天開發者會升級合約代碼，因為新合約的代碼哈希是不一樣的，你的 lock/type 仍然會引用舊的合約而不是新的合約。新版本部署後，會與系統中的舊版本共存。如果您通過其代碼哈希使用系統合約，那麼新版本對您不會造成影響，您可以自主決定是否升級。如果答案是 yes，那麼你可以更新所有 cell 以使用新版本。如果是 no，則什麼都不需要做，繼續使用舊版本。

這對那些可能不經常在線的持有者來說是一個友好的保證，因為他們可以保證在創建時附加在他們 cell 上的合約不會被更改。人們的資產將始終按照他們鎖定時指定的方式進行鎖定。這是對 SoV 用戶的終極保證，也是 CKB 資產不同於其它區塊鏈上資產的原因。這和比特幣通過「只遵循軟分叉」的方式來為持有者提供保障是一樣的。唯一的缺點是，當進行安全升級時，您需要承擔「太晚」的風險。因此，為了方便起見，有些人可能還是喜歡一直使用最新的版本，因為他們相信開發團隊，不需要操心去審核合約和手動升級，在這種情況下，他們會使用 type id[12]來引用合約。大致來說，type id 就類似於 Git 中的 HEAD，一個可更新的引用總是指向當前的版本。通過提供這兩種選項（通過代碼哈希引用和 type id 引用）我們將選擇合適升級策略的權利還給了用戶。有選擇總是好的。我們可以有不同的選擇，沒有人會被強迫升級。

系統腳本升級

從長遠來看，CKB 將越來越抽象化、模塊化，更多的核心功能將會在鏈上智能合約中被提取和實現。在其完整的形態下，我們應該可以無需通過軟/硬分叉就能升級 CKB。這其中缺失的一環是，我們，即社區如何決定升級系統合約與否，或者說 CKB 的治理模式是什麼？更準確地說，是我們如何決定升級一個系統合約的 type id。

今天，CKB 使用的是和比特幣一樣的鏈下治理模式，我們仍然依賴於軟/硬分叉。為了讓使用其 type id 引用的人啟用新版本的系統腳本，需要硬分叉來更新 type id 引用以指向最新版本，因為代碼 cell 是被一個可解鎖的 lock 鎖定(https://explorer.nervos.org/address/ckb1qgqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqhzeqga，檢查一下它的代碼哈希)。不使用核心團隊控制的多簽簽名鎖是一個有意的選擇，因為系統腳本的升級應該遵循社區制定的治理決策。

正如我們在定位白皮書中所說的那樣，雖然目前有很多有趣的建議，但我們還沒有看到一個切實可行的治理模式。一旦我們找到了合適的治理模式，我們就可以用「治理鎖」來代替不可解鎖的鎖，讓系統智能合約在徵得社區同意的情況下進行升級，比如投票的結果。在此之前，我們會暫時堅持不完善的鏈下治理模式，但 CKB 治理和演進的脊樑已經存在。

Ref:[1]:https://en.wikipedia.org/wiki/Version_control

[2]:https://talk.nervos.org/t/first-class-asset/405

[3]:https://github.com/nervosnetwork/ckb-system-scripts/blob/master/c/secp256k1_helper.h#L40-L66

[4]:https://talk.nervos.org/t/rfc-swappable-signature-verification-protocol-spec/4802

[5]:https://www.researchgate.net/publication/332799463_Characterizing_Code_Clones_in_the_Ethereum_Smart_Contract_Ecosystem
[6]:https://security.cse.iitk.ac.in/sites/default/files/17111011.pdf

[7]:https://medium.com/hackernoon/what-caused-the-latest-100-million-ethereum-bug-and-a-detection-tool-for-similar-bugs-7b80f8ab7279

[8]:https://github.com/nervosnetwork/ckb-system-scripts/blob/master/c/secp256k1_blake160_sighash_all.c

[9]:https://github.com/nervosnetwork/ckb-system-scripts/blob/master/c/dao.c

[10]:https://tezos.com/ 

[11]:https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0022-transaction-structure/0022-transaction-structure.md#upgradable-script[12]:https://docs.ckb.dev/blog/ckbscript-06