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

对于开发者来说，cell 编程模型无疑是 Nervos CKB 中最有趣的部分。在这里，我们先对 cell 模型作一个简短的描述：

Cell 模型不同于账户模型：

当你比较两个模型时，你会发现还有许多其他的不同之处，如果你对该话题感兴趣，可以在talk.nervos.org上找到更多关于 cell 模型 VS 账户模型的讨论。

Cell 模型中缺失的那一块

UTXO 是一个非常棒的模型，cell 模型继承了它的灵活性。我们（通过 cell 模型）可以发行 UDT（用户自定义代币，类似于 ERC20），存储链上资产，玩石头剪刀布游戏，或者与比特币实现原子交换等。Cell 模型可以实现很多人们最初认为不可能实现的事情。

不幸的是，有一些合约确实很难在 cell 模型上实现：

这些难题合约有一个共性，那就是需要共享状态。
在一个 UTXO 类的模型内，状态是自然分离的。
在 CKB 中，用户可以在独立的 cell 中进行投票。这样我们就需要一个链下的角色收集这些投票的 cells 并计算结果。

当我们只想「看到」结果时，它实现的非常好。但是我们不能在另一个合约中使用投票结果，比如一个基于投票的 DAO 合约。我们很难在一个链上合约中验证统计后的结果。所以我们必须证明每一个投票 cell 的存在，交易时就需要引用每一个投票的 cell，这可能非常昂贵。

再举个例子，我们来看一个众筹合约：

一个 cell 中有所有的众筹代币，用户可以支付 CKB 来获得相应数量的代币。

问题在于，当我们分割这个 cell，众筹 cell 的 outpoint 就被改变了；其他用户必须等到下一个区块才能看到新的 outpoint。所以在一个区块时间内，只有一个用户可以参与众筹，这是不可接受的。

与投票的例子类似，一个典型的解决方案就是引入一个链下角色，用户在个人的 cells 中发出众筹请求；然后链下角色需要收集这些 cells 并将结果放在一个 cell 中。

我们可以看到，由于在 cell 模型中，状态是自然分离的，因此我们必须依赖某个链下角色来收集状态。

这样的方法是可行的，但是仍然会有一些问题：

当然，解决这些问题并不难；我们可以通过支付链下角色一些费用来激励他们；使用某种挑战机或者零知识证明（zk proof）来验证收集的结果；定义一些协议来规定和链下角色的交互。我们总能解决这些问题。
等等，我想要的只是一个投票合约。我为什么需要整这么多（复杂的）东西？

一个合约管理一切

可不是嘛！我们可不想为每一个合约都整这么多东西，我们只需要构建一次：

Godwoken 是一个建立在 CKB 上的基于账户模型的编程层，目标就是管理一切状态共享的合约。

Godwoken 由以下几个部分组成：

你可能发现，这听起来像是最近非常流行的 rollup 的解决方法。是的，没错。但是我们关注的是聚合的问题，而非可扩展性的问题。Godwoken 提供了 CKB 基于账户模型的编程能力来解决聚合问题。

一些人将 Rollup 称之为 layer 1.5 层；也有一些人认为它是 layer 2 层；还有人认为它是 layer 1 层（根据信任级别）。本文将 Godwoken 称为 layer 1.5 层，以便将其与 layer 1 层的 CKB 区分开。

Godwoken 使用和原生 CKB 合约相同的技术栈。唯一的区别在于 Godwoken 合约是基于账户模型的；它将验证账户的状态而不是 cells 的状态。账户状态和 layer 1 层的 cells 之间的映射关系是由 Godwoken 的主合约处理的，对于 layer 1.5 层的合约来说，是透明的。

对于需要创建一个投票合约的开发者来说，只需要使用脚本简单地创建一个账户，这个脚本就会验证输入的数据和账户状态。

// pseudo codefn verify_voting(i, votes) -> bool { state[i] += votes; merkle_root(state) == output_account_root}

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

Godwoken 主合约使用了一个稀疏 merkle tree来存储所有的账户和账户状态。

因此，如果我们想要在 layer 1.5 层合约之间使用一个状态，我们可以简单的为这个状态生成一个 merkle proof，并在合约中验证 merkle proof。

如果我们想在 layer 1 层的合约中使用一个 layer 1.5 层的状态，我们可以在交易的 cell_deps 字段中引用 Godwoken 主合约 cell，并从 cell 中读取 Godwoken 中的全局状态来获得 merkle root，这样就可以验证状态和 merkle proof 了。

通过创建一个抽象的账户层，我们可以在 CKB 上通过最小的成本创建一个状态共享的合约。

在后续的文章中，我们将会讨论 Godwoken 中的详细信息，我们如何维护 layer 1.5 层的账户和合约，以及基于账户模型的合约是如何工作的。

Godwoken 设计文档

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

Sparsemerkle tree

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

本文来源：NervosNetwork
原文标题：Godwoken —— Cell 模型中缺失的那一块

—-

编译者/作者：NervosNetwork

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。