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

from Jan

我是 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/a...，檢查一下它的代碼哈希)。不使用核心團隊控制的多籤簽名鎖是一個有意的選擇，由於系統腳本的升級應該遵循社區制定的治理決策。

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

Ref:

[1]: https://en.wikipedia.org/wiki...control

[2]:https://talk.nervos.org/t/fir...

[3]:https://github.com/nervosnetw..._helper.h#L40-L66

[4]:https://talk.nervos.org/t/rfc...

[5]:https://www.researchgate.net/..._Characterizing_Code_Clones_in_the_Ethereum_Smart_Contract_Ecosystem

[6]:https://security.cse.iitk.ac....

[7]:https://medium.com/hackernoon...

[8]:https://github.com/nervosnetw..._blake160_sighash_all.c

[9]:https://github.com/nervosnetw...

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

[11]:https://github.com/nervosnetw...

[12]:https://docs.ckb.dev/blog/ckb...