Godwoken —— Cell 模型中缺失的那一块

2020-07-01 18:34 栏目:经验之谈 来源:网络整理 查看()

对于开发人员来说,单元编程模型无疑是内尔沃斯CKB最有趣的部分。在这里,我们首先对细胞模型做一个简要的描述:

单元是UTXO的通用版本

单元是包含任意数据和可定制脚本的UTXO

当事务试图销毁或创建单元时,单元中的脚本将被加载并执行,执行脚本中返回的任何错误都将导致事务失败。

单元格模型不同于帐户模型:

验证,而不是计算

将数据存储在单独的单元格中,而不是存储在帐户中

当你比较这两种模型时,你会发现许多其他的不同。如果你对这个话题感兴趣,你可以在talk.nervos.org找到更多关于细胞模型和账户模型的讨论。

细胞模型中缺失的部分

UTXO是一个伟大的模型,细胞模型继承了它的灵活性。我们可以发行UDT(用户定义的令牌,类似于ERC20),在链中存储资产,玩石头、剪刀和纸的游戏,或者用比特币实现原子交换。细胞模型可以实现许多人们起初认为不可能的事情。

不幸的是,有些合同在单元模型上很难实现:

*投票

众筹

定价分散的虚拟机

.

这些困难的合同有一个共同点,那就是它们需要共享状态。

在UTXO类的模型中,状态是自然分离的。

在CKB,用户可以在独立的手机上投票。通过这种方式,我们需要一个链下的角色来收集这些投票单元并计算结果。

Godwoken —— Cell 模型中缺失的那一块

当我们只想“看到”结果时,它就非常好。但是我们不能在另一个合同中使用投票结果,比如基于投票的DAO合同。在连锁合同中,我们很难核实统计结果。因此,我们必须证明每个投票单元的存在,我们需要在交易时引用每个投票单元,这可能非常昂贵。

Godwoken —— Cell 模型中缺失的那一块

再举一个例子,让我们看看众筹合同:

一个手机里有所有的众筹代币,用户可以向CKB支付相应数量的代币。

问题是,当我们分割这个细胞时,众筹细胞的输出发生了变化;其他用户必须等到下一个块才能看到新的输出。因此,在一个时间段内,只有一个用户可以参与众筹,这是不可接受的。

类似于投票的例子,一个典型的解决方案是引入一个离线角色,用户通过个人手机发送众筹请求;然后,链下的角色需要收集这些细胞并将结果放入一个细胞中。

我们可以看到,在细胞模型中,状态是自然分离的,所以我们必须依靠某种连锁作用来收集状态。

这种方法是可行的,但仍存在一些问题:

如何有效证明收集的结果

在引入供应链下的角色后,如何确保权力下放

用户如何与链下的角色互动

当然,解决这些问题并不难;我们可以通过支付一些费用来激励下面的角色;使用某种挑战机器或zk证明来验证收集的结果;定义一些协议来规范与链下角色的交互。我们总能解决这些问题。

等等,我只想要一份投票合同。为什么我需要这么多(复杂的)东西?

一份合同管理一切

Godwoken —— Cell 模型中缺失的那一块

没错。我们不想为每份合同都建立那么多东西,我们只需要建立一次:

Godwoken是一个基于CKB账户模型的编程层,它的目标是管理所有的国家共享合同。

Godwoken由以下部分组成:

主合同——是一个类型脚本,它维护所有帐户和块的全局状态(第1.5层)

挑战契约——是一个处理挑战需求的类型脚本

聚合器——是一个离线程序,它收集第1.5层事务,并定期向主合同提交第1.5层块。

验证器——是一个离线程序,持续监控两个合同。当提交无效块时,验证器将发送一个质询请求,当提交不正确的质询请求时,验证器将发送一个无效的质询请求。

Godwoken —— Cell 模型中缺失的那一块

您可能会发现,这听起来是最近非常流行的汇总解决方案。是的,没错。但是我们关心的是聚合,而不是可伸缩性。Godwoken提供了CKB基于帐户模型的编程能力来解决聚合问题。

有些人将汇总层称为1.5;也有人认为这是第二层;其他人认为是第1层(根据信任级别)。在本文中,Godwoken被称为第1.5层,以区别于第1层的CKB。

Godwoken使用与本地CKB合同相同的技术堆栈。唯一不同的是,God Wacked契约是基于账户模型的;它验证帐户的状态,而不是单元格的状态。第1层中账户状态和单元之间的映射关系由God Wacked的主合同处理,它对第1.5层中的合同是透明的。

对于需要创建投票合同的开发人员来说,他们只需要使用一个脚本来简单地创建一个帐户,这个脚本将验证输入数据和帐户状态。

//伪代码

fn验证_投票(I,票)- bool {

状态[i]=投票;

merkle_root(状态)=output_account_root

}

从上面的伪代码中,我们可以看到验证模型类似于第1层。

Godwoken主合同使用稀疏merkle树来存储所有帐户和帐户状态。

因此,如果我们想在第1.5层合同之间使用一个状态,我们可以简单地为这个状态生成一个merkle证明,并在合同中验证merkle证明。

如果我们想在第1层契约中使用第1.5层状态,我们可以在事务的cell_deps字段中引用God Wacked的主契约单元,并从该单元读取God Wacked中的全局状态以获得merkle根,这样我们就可以验证状态和merkle证明。

通过创建一个抽象的帐户层,我们可以用最小的成本在CKB创建一个州共享合同。

在下面的文章中,我们将讨论God Wacked中的细节,我们如何在第1.5层维护帐户和合同,以及基于帐户模型的合同如何工作。

Godwoken设计文件

https://github.com/jjyr/godwoken/blob/master/docs/design.md

稀疏merkle树

https://justjjy.com/An-optimized-compact-sparse-merkle-tree

微信二维码
售前客服二维码

文章均源于网络收集编辑侵删

提示:仅接受技术开发咨询!

郑重申明:资讯文章为网络收集整理,官方公告以外的资讯内容与本站无关!
NFT开发,NFT交易所开发,DAPP开发 Keywords: NFT开发 NFT交易所开发 DAPP开发