CKB、版本控制和区块链演化

来自Jan Xie

我是莱纳斯的粉丝。他创建了一个无处不在的开源操作系统，与他人合著了一本我非常喜欢的书，并构建了一个几乎每个开发人员每天都在使用的分布式版本控制系统。

我一看到git就开始使用git，并被它的速度和优雅所吸引。开发人员使用版本控制系统[1]来管理源代码，以便及时了解代码更新，与朋友和同事共享更改，并在出现新错误时回滚到无bug版本。Git让生活更有趣，我希望CKB也能这样做。

CKB是GIT

在创建CKB和cell模的过程中，我们受到了git的启发。Git诞生于Linus对Linux内核开发的便利性的渴望。人们可以随时使用git来组织内容，从评论到博客文章再到图片。它是一个具有**历史跟踪支持的知识库。

Git存储库被称为“存储库”，它在内部维护一个不可变的可附加对象数据库（还记得吗？）。Git中的基本存储单元是blob（二进制大对象），它是一个包含人们存储在存储库中的数据的对象，就像CKB中的单元一样。Git为每个文件的每个版本创建一个blob对象。每当创建新文件时，都会创建一个新的blob。无论何时修改现有文件，都会创建一个包含新内容的blob，而不是修改旧的内容（这听起来耳熟吗？）。每个blob都被哈希化，blob散列被用作引用blob的标识符。工作几个小时后，创建一些新文件并修改一些现有文件，然后将所有更改提交到存储库，将新提交的内容同步到同事，就完成了。

提交是git中的基本历史点，存储库历史记录由一系列从存储库源到最近更新的提交组成。提交是特定时间的存储库版本，包括版本元数据，如作者、时间戳、上一次提交和对blob树的引用。正如块头通过写下miner地址、时间戳、父块散列和事务Merkle树的根来为区块链的每次更新保存元数据。您和您的同事通过扩展GIT存储库的历史来获得报酬，就像矿工通过扩展块的历史获得块奖励一样。

Git存储库也可以有fork。人们在不同的分支上工作，但是哪个分支是“正确的”是由存储库维护人员决定的，而不是一致同意的。Git是一个没有共识的分布式系统，它依赖于特殊的点对点通信（如SSH或email）进行数据交换。

GIT和区块链有相似之处，这也意味着我们应该更加小心地将GIT的思想融入到区块链中，而不是在区块链中引入相互冲突的设计选择，这样区块链或智能合约开发者就可以享受到GIT已经证明的一些优势。这就是CKB内部真正的样子：一个独特的大git库，具有真正的P2P网络、全球共识和增强的blob，由一群匿名者不断更新。

这不是区块链

按你喜欢的方式命名

git和CKB的核心是数据对象（blob/cell）和散列引用。哈希引用是对象的固有名称。这是一个神奇的魔杖，你可以挥舞它来提取数据的价值。如果你知道一个物体的名字，你可以通过引用它来获得它的力量。在CKB中，智能合约的代码与用户数据是分离的，因此哈希引用可以让您直接命名一段代码或用户数据，使其成为系统中的第一级对象[2]。这种精细的粒度创建了一个灵活而强大的编程模。这里有一些例子。

重用代码/数据

因为单元是一个参考存储单元，所以很容易在CKB上重用代码/数据。假设某些共享代码/数据存储在cell 0xbeefා1（事务0xbeef 1的输出）中，要重用它，首先需要将cell 0xbeef 1加载为事务依赖（cell）DEPs，然后使用CKB_2;load?cell 系统调用从中读取数据，如默认锁脚本中所示。一旦单元0xbeefා1中的数据加载到VM内存中，就可以根据需要将其视为代码或数据使用[3]。通过这种方式，CKB类似于运行在其上的智能合约的代码和数据共享库。如果我们能结合现有的安全乐高积木构建一个智能合约，会不会很酷？与其从GitHub上的某个地方**代码并反复部署相同的代码，这是在浪费时间和空间。对火币网合同的分析[5][6]表明，95%-99%的合同是重复的。

火币全球最 ereum上重复次数最多的智能合约

无惧依赖删除

在上面的代码/数据重用示例中，您不需要担心有人修改存储在依赖单元中的代码/数据，因为该单元是不可变的，也就是说，没有人可以修改它。但是如果从属单元的所有者直接从CKB中删除它呢？这会使我的智能合约无法使用吗？

和HT5-ereum上的完全一样。如果你在这个领域呆得够久，你可能会知道2017年2.8亿美元的事故[7]。整个悲剧是由火币全球最 ereum上的一个智能合约意外删除造成的，该合约被许多其他智能合约所使用。这一删除导致依赖它的所有智能合约失效，存储在这些智能合约中的所有资产都被冻结。

在CKB上，这样的意外不会有任何影响，因为任何保留代码副本的人（例如运行完整节点或复杂轻客户端的人）都可以在链上再次部署相同的代码，并且对代码哈希的引用仍然有效。我们只需要使用新的依赖单元来构造事务。没有人会受苦，一切都会继续。

从依赖项删除中恢复

实际上，我们甚至可以使用它来实现“在部署之前使用”代码。假设您想要使用一个新的自定义锁脚本（智能合约）来保护您的单元。与通常的先部署后使用流程不同，您可以在不部署的情况下使用它。只要将新锁脚本（代码实现）的代码哈希放入单元锁中，单元就会受到新锁的保护并立即生效。
实际锁脚本代码的部署可以延迟，直到您想解锁单元。如果要解锁，首先需要在链上部署脚本代码，然后像往常一样发送另一个事务来解锁单元。在单元解锁后，您可以删除部署的代码并检索占用的ckbyte，以减少不必要的存储成本。部署前使用的另一个好处是更好的隐私：在您解锁新锁之前，没有人知道它的逻辑是什么。

进化CKB

在理解了CKB和git的相似性和优点之后，让我们来探讨一个更有趣的问题：如果CKB是一个git库，我们可以使用CKB来管理CKB代码吗？

是的！这就是为什么CKB的一些核心功能（如交易签名验证[8]和neros Dao[9]）以智能合约的形式实现。以交易签名验证为例——这是几乎所有区块链的核心功能，并且是用母语硬编码的（例如火币使用C语言，go-火币全球最 EREUM使用go语言）。

为了升级区块链，人们必须在大多数节点上分发和部署新的软件版本（软/硬分叉），这需要大量的协调。对于CKB，可以通过在链上部署新版本来升级事务签名验证，就像其他智能合约一样。这使得CKB具有tezos[10]提出的长期可伸缩性。

我们可以做得更好。在CKB中，每个用户都有自己的数据，因此合同更像是用户和CKB之间的一种双方协议，个人可以自主选择。如果您通过代码哈希[11]使用合同，则意味着“我同意合同的这个特定版本。”您不必担心有一天开发人员会升级合同代码，因为新合同的代码哈希不同，而且您的锁/类仍将引用旧合同而不是新合同。新版本部署后，将与系统中的旧版本共存。如果您通过系统契约的代码哈希使用它，新版本不会影响您，您可以决定是否升级。如果答案是“是”，则可以更新所有单元格以使用新版本。如果不是，则无需执行任何操作，旧版本将继续。

这是一个友好的保证，为持有人谁可能不经常在线，因为他们可以保证，合同附加到他们的细胞在创建时不会改变。当人们锁定时，他们的资产总是以他们指定的方式被锁定。这是SOV用户的最终保障，也是CKB资产与区块链上其他资产不同的原因。这与火币采用“仅限软分叉”的方法保护支撑相同。唯一的缺点是，在执行安全升级时，您需要冒“太迟”的风险。因此，为了方便起见，有些人可能更喜欢一直使用**版本，因为他们认为开发团队不需要担心审查合同和手动升级。在这种情况下，他们将使用类ID[12]来引用合同。一般来说，type ID类似于git中的head，其中可更新的引用总是指向当前版本。通过提供这两个选项（通过代码哈希引用和类ID引用），我们给了用户选择适当升级策略的权利。有选择总是好的。我们可以有不同的选择，没有人会被迫升级。

系统脚本升级

从长远来看，CKB将越来越抽象化、模块化，越来越多的核心功能将在链上的智能合约中提取和实现。在它的完整配置中，我们应该能够升级CKB而不使用软/硬fork。缺失的环节是社区如何决定是否升级系统契约，或者CKB的治理模式是什么？更确切地说，这是我们决定升级系统合同类ID的方式。

今天，CKB使用与HT2相同的链外治理模，我们仍然依赖软/硬分叉。为了让用户使用其类ID引用来启用系统脚本的新版本，需要使用硬叉来更新类ID；引用指向**版本，因为代码单元被不可锁定的锁（HT）锁定tps://explorer.neros.org/address/CKB1QGQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQGA检查它的代码哈希）。不使用由核心团队控制的多签名锁是有意的选择，因为系统脚本的升级应该遵循社区做出的治理决策。

正如我们在定位白皮书中所说，虽然有许多有趣的建议，但我们还没有看到一个实用的治理模式。一旦我们找到了合适的治理模式，就可以用“治理锁”代替非解锁锁，这样系统智能合约就可以在社区同意的情况下升级，比如投票结果。在此之前，我们会暂时坚持不完善的链下治理模式，但CKB治理和演进的中坚力量已经存在。

参考号：[1]：HTtps://en.***.org/wiki/Version控制

[2] ：HTtps://talk.neros.org/t/first-class-asset/405

[3] ：HTtps://github.com/nerosnetwork/ckb-system-scripts/blob/master/c/secp256k1助手。h#L40-L66

[4] ：HTtps://talk.neros.org/t/rfc-swappable-signature-erification-protocol-spec/4802

[5] ：HTtps://www.researchgate.net/publication/332799463在生态系统
[6]：HT中，描述“代码”克隆体tps://security.cse.iitk.ac.in/sites/DeFiault/files/17111011.pdf

[7] ：HTtps://medium.com/hackernoon/what-caused-the-latest-1亿-HT5 ereum-bug-and-a-detection-tool-for-LIQUA-bug-7b80f8ab7279

[8] ：HTtps://github.com/nerosnetwork/ckb-system-scripts/blob/master/c/secp256k1布莱克160

[9] ：HTtps://github.com/nerosnetwork/ckb system scripts/blob/master/c/dao.c

[10] ：HTtps://tezos.com/；

[11] ：HTtps://github.com/nerosnetwork/rfcs/blob/master/rfcs/0022 transaction structure/0022 transaction structure.md可升级-文[12]：HTtps://docs.ckb.de/blog/ckbscript-06