比特币钱包网页：Godwoken中缺失的那一块

- 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模型中，状态是自然分离的，因此我们必须依赖某个链下角色来收集状态。这样的方法是可行的，但是仍然会有一些问题：

- 如何有效地证明收集的结果 - 如何保证在引入了链下角色后的去中心化 - 用户如何与链下角色进行交互

当然，解决这些问题并不难；我们可以通过支付链下角色一些费用来激励他们；使用某种挑战机或者零知识证明（zkproof）来验证收集的结果；定义一些协议来规定和链下角色的交互。我们总能解决这些问题。

等等，我想要的只是一个投票合约。我为什么需要整这么多（复杂的）东西？

一个合约管理一切

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

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

Godwoken由以下几个部分组成：

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

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

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

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

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

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

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

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

因此，如果我们想要在layer1.5层合约之间使用一个状态，