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...