共计 4534 个字符，预计需要花费 12 分钟才能阅读完成。
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…