BTCV繁华资讯 > 货币新闻 > 充分理解《神经CKB》的版本控制和区块链进化_

充分理解《神经CKB》的版本控制和区块链进化_

作者:_btcv-繁华资讯来源:_btcv-繁华资讯 货币新闻 2020年08月13日

我是莱纳斯的粉丝。他创建了一个随处可见的开源操作系统,与人合著了一本我非常喜欢的书,并建立了一个几乎每个开发人员每天都在使用的分布式版本控制系统。我一看到Git就开始使用它,并被它的速度和优雅所吸引。开发人员版本控制系统[1

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

我一看到Git就开始使用它,并被它的速度和优雅所吸引。开发人员使用版本控制系统[1]来管理源代码,这样他们就可以跟上代码的更新,与朋友和同事分享更改,并在出现新错误时回滚到没有错误的版本。Git 让生活变得更加有趣,我希望 CKB 也可以做到这一点。

CKB 是 Git

在创建CKB和细胞模型的过程中,我们受到了Git的启发。Git源于Linus对Linux内核开发便利性的渴望,人们可以随时使用它来组织一些东西,从评论、博客帖子到图片。它是一个知识库,具有出色的历史跟踪功能支持。

Git知识库被称为“存储库”,它在内部维护一个不可变且唯一可追加的对象数据库(还记得吗?).Git中的基本存储单元是 Blob(大型二进制对象),它是一个包含存储在存储库中的数据的对象,就像CKB的Cell一样。Git为每个文件的每个版本创建一个blob对象。每当创建新文件时,都会创建一个新的blob。无论何时修改现有文件,都有必要创建一个包含新内容的blob,而不修改旧的blob(这听起来熟悉吗?).每个斑点都被散列,并且斑点散列被用作引用斑点的标识符。工作了几个小时后,您创建了一些新文件,修改了一些现有文件,然后将所有更改提交到存储库,将新提交的内容同步到您的同事,并结束了一天的工作。

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

Git存储库也可以有分叉。人们在不同的分支上工作,但是哪个分支是“正确的”是由存储库维护者决定的,而不是一致同意的。Git是一个没有共识的分布式系统,它依靠特殊的点对点通信(如ssh或电子邮件)进行数据交换。

Git和区块链有相似之处,这意味着我们应该更仔细地将Git的思想融入区块链,而不是将相互冲突的设计选择引入区块链,这样区块链或聪明的合同开发者就可以享受Git的一些已被证明的优势。这就是 CKB 内在的真实样子:一个拥有真正的 p2p 网络、全球共识和增强 blob 的唯一大型 Git 库,由一群匿名者不断进行更新。

全面了解Nervos  CKB的版本控制与区块链演进

这不是区块链

按照你喜欢的方式给 Cell 命名

Git和CKB的核心是数据对象(blob/cell)和哈希引用。在CKB的哈希引用是一个对象的固有名称,是你可以挥舞的魔杖,提取出数据的价值。如果你知道一个对象的名字,你就可以通过引用它,从而获得它的力量。,智能合同的代码和用户数据是分开的,所以散列引用可以让你直接命名一段代码或用户数据,并使它们成为系统中的第一级对象[2]。这种精细的粒度创建了一种灵活而强大的编程模式。这里有一些例子。

重用代码/数据

因为单元是一个可引用的存储单元,所以在CKB上重用代码/数据很容易。假设一些共享代码/数据存储在单元0x牛肉#1(事务0x牛肉的输出1)中。要重用它,首先需要加载单元0xbeef#1作为事务依赖(cell_deps),然后使用ckb_load_cell_data系统调用从中读取数据,如默认锁定脚本所示。一旦单元格0x牛肉#1中的数据被加载到虚拟机内存中,根据您的需要,它可以被视为代码或数据[3]。这样,CKB就像一个代码和数据的共享库,运行在其上的智能合同可以使用它。如果我们能通过组合现有的安全乐高积木来构建一个智能合约[4],是不是很酷?不需要从GitHub上的某个地方复制代码,并一次又一次地部署相同的代码,这在链上浪费了时间和空间。对以太网合同[5][6]的分析表明,95%~99%的合同是重复的。

全面了解Nervos  CKB的版本控制与区块链演进

以太网上重复最多的智能合同

无惧依赖删除

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

在以太博物馆是这样的。如果你在这个领域呆的时间足够长,你可能知道2017年发生的2.8亿美元的事故。整个悲剧是由以太网上一个智能合同的意外删除引起的,该智能合同被许多其他智能合同使用。这种删除会导致依赖它的所有智能合同失效,并且存储在这些智能合同中的所有资产都会被冻结。

然而,在CKB,这样的事故不会造成任何影响,因为任何保存代码副本的人(例如那些运行全节点或复杂轻型客户端的人)都可以在链上再次部署相同的代码,并且代码散列的引用仍然有效。我们只需要使用新的从属单元来构建事务。没有人会因此受到损失,一切都仍将正常运转。

全面了解Nervos  CKB的版本控制与区块链演进

从依赖关系删除中恢复

事实上,我们甚至可以故意用这一点来实现代码的“先使用后部署”。假设您想要使用一个新的自定义锁定脚本(智能契约)来保护您的单元。与使用前部署的通常过程不同,您可以在不部署的情况下使用它。只需将新锁脚本(代码实现)的代码散列放入单元锁,这些单元将受到新锁的保护并立即生效。

实际锁定脚本代码的部署可以延迟,直到您想要解锁这些单元。如果您想要解锁,您需要首先在链上部署脚本代码,然后像往常一样发送另一个事务来解锁这些单元。解锁单元后,您可以删除已部署的代码并回收已占用的CKByte,以减少不必要的存储成本。先使用后部署的额外好处是更好的隐私性:在你解锁之前,没有人知道这个新锁的逻辑是什么。

进化的 CKB

在了解了CKB和吉特的相似之处和优势之后,让我们来讨论一个更有趣的问题:如果 CKB 是一个 git 库,我们可以用 CKB 来管理 CKB 的代码吗?

太好了。这就是为什么CKB的一些核心功能,如交易签名验证[8]和Nervos DAO[9],是以智能合同的形式实现的。以交易签名验证为例。——这是几乎所有区块链的核心功能,它是用本地语言硬编码的(例如,在比特币中用C语言编写,在以太网中用Go语言编写)。

为了升级区块链,人们必须在大多数节点上分发和部署新的软件版本(软/硬分支),这需要大量的协调工作。对于 CKB 来说,交易签名验证可以和其它智能合约一样,通过在链上部署新版本来进行升级。这让 CKB 具备了 Tezos[10]提出的长期可升级性。

我们可以做得更好。在CKB,每个用户都有自己的数据,所以一份合约更像是用户和 CKB 之间的两方协议,个人可以做出独立的选择。如果您通过代码哈希[11]使用合同,它的意思是“我同意了这个特定版本的合约”。您不必担心开发人员有一天会升级合同代码,因为新合同的代码散列是不同的,并且您的锁/类型仍然会引用旧合同而不是新合同。部署新版本时,它将与系统中的旧版本共存。如果您通过系统合同的代码哈希来使用系统合同,新版本不会影响您,您可以决定是否升级。如果答案是肯定的,那么您可以更新所有单元格以使用新版本。如果答案是否定的,那就什么都不用做。继续使用旧版本。

这是对不经常在线的持有者的友好保证,因为他们可以保证附加到他们手机上的合同在创建时不会被更改。人们的资产将始终按照他们锁定时指定的方式进行锁定。这是对 SoV 用户的终极保证,也是 CKB 资产不同于其它区块链上资产的原因。,这与比特币“只跟随软分叉”的方式相同,为持有者提供保护。唯一的缺点是,在进行安全升级时,您必须冒“太晚”的风险。因此,为了方便起见,有些人可能更喜欢一直使用最新版本,因为他们相信开发团队不需要担心审查合同和手动升级。在这种情况下,他们将使用id[12]类型来引用合同。一般来说,类型id类似于Git中的HEAD,可更新的引用总是指向当前版本。通过提供这两种选项(通过代码哈希引用和 type id 引用)我们将选择合适升级策略的权利还给了用户。有选择总是好的。我们可以有不同的选择,没有人会被迫升级。

全面了解Nervos  CKB的版本控制与区块链演进

系统脚本升级

从长远来看,CKB将变得越来越抽象和模块化,更多的核心功能将在连锁智能合同中被提取和实现。在它的完整形式中,我们应该能够升级CKB而不需要软/硬分支。缺少的部分是,我们社区如何决定是否升级系统合同,或者CKB的治理模式是什么?更准确地说,这是我们如何决定升级系统合同的类型id。

如今,CKB使用与比特币相同的线下治理模式,我们仍然依赖软/硬分歧。为了使使用其类型id引用的人能够使用新版本的系统脚本,有必要更新类型id引用以指向最新版本,因为代码单元被不可解锁的锁(https://Explorer.nervos.org/address/ckb1 qgqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq

检查它的代码散列)。不使用由核心团队控制的多重签名锁是一个有意的选择,因为系统脚本的升级应该遵循社区做出的治理决定。

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

Ref:

[1]:https://en . Wikipedia . org/wiki/Version _ control

[2]:https://talk . nevros . org/t/头等舱-资产/405

[3]:https://github.com/nevos network/ckb-system-scripts/blob/master/c/secp 256 k1 _ helper . h # L40-L66

[4]:https://talk . nervos . org/t/RFC-可交换-签名-验证-协议-规范/4802

[5]:https://

[6]:https://security . CSE . iitk . AC . in/sites/default/files/17111011 . pdf

[7]:https://medium.com/hackernoon/what-cause-the-latest-1亿-ether eum-bug-and-a-detection-tool-for-like-bug-7b 80 F8 ab 7279

[8]:https://github.com/nevos network/ckb-system-scripts/blob/master/c/secp 256 k1 _ Blake 160 _ sighash _ all . c

[9]:https://github.com/nevos network/ckb-system-scripts/blob/master/c/Dao . c

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

[11]:https://github.com/nevrosnetwork/rfcs/blob/master/rfcs/0022-transaction-structure/0022-transaction-structure . MD # upgradeable-script

[12]:https://docs . ckb . dev/blog/cksubscript-06

标签: btcv交易平台