Git 讓生活變得更加有趣,我希望 CKB 也可以做到這一點。

原文標題:《CKB,版本控制與區塊鏈演進》
撰文:謝晗劍(Jan Xie),Nervos 首席架構師,祕猿科技首席執行官,前以太坊核心研發團隊成員

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

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

謝晗劍: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 庫,由一羣匿名者不斷進行更新。

謝晗劍:CKB,版本控制與區塊鏈演進
這不是一個區塊鏈

按照你喜歡的方式給 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% 的合約都是重複的。

謝晗劍:CKB,版本控制與區塊鏈演進
Ethereum 上重複最多的智能合約

無懼依賴刪除

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

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

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

謝晗劍:CKB,版本控制與區塊鏈演進
從依賴刪除中恢復

實際上,我們甚至可以有意地利用這一點來實現代碼的「先使用後部署」。假設您想使用一個新的自定義鎖定腳本(智能合約)來保護你的 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。這其中缺失的一環是,我們,即社區如何決定升級系統合約與否,或者說 CKB 的治理模式是什麼?更準確地說,是我們如何決定升級一個系統合約的 type id。

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

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