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

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

• Cell 是通用版的 UTXO
• 一个 cell 是一个包含任意数据和可定制脚本的 UTXO
• 当一笔交易尝试销毁或建立一个 cell，cell 中的脚本将被加载并执行，在执行脚本中返回任何错误，都将致使交易失败。

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 由如下几个部分组成：

• 主合约 —— 一个维护全部帐户、全部区块的全局状态的类型脚本（layer 1.5 层）
• 挑战合约 —— 一个处理挑战需求的类型脚本
• 聚合器 —— 一个收集 layer 1.5 层交易的链下程序，并按期向主合约提交 layer 1.5 层的区块。
• 验证器 —— 一个持续监控两个合约的链下程序。验证器在一个无效区块被提交时会发送一个挑战请求，在一个错误的挑战请求被提交时会发送一个无效的挑战请求。

你可能发现，这听起来像是最近很是流行的 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 code
fn 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/godwo...

• Sparse merkle tree

  https://justjjy.com/An-optimi...