CKB，版本控制与区块链演进

我是 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 命名

Gi