问题在于，当我们支解这个 cell，众筹 cell 的 outpoint 就被改变了；其他用户必需比及下一个区块才气看到新的 outpoint。所以在一个区块时间内，只有一个用户可以参加众筹，这是不行接管的。
挑战合约 —— 一个处理惩罚挑战需求的范例剧本
当我们只想「看到」功效时，它实现的很是好。可是我们不能在另一个合约中利用投票功效，好比一个基于投票的 DAO 合约。我们很难在一个链上合约中验证统计后的功效。所以我们必需证明每一个投票 cell 的存在，生意业务时就需要引用每一个投票的 cell，这大概很是昂贵。
· 用户如何与链下脚色举办交互merkle_root(state) == output_account_root
· 投票
可不是嘛！我们可不想为每一个合约都整这么多对象，我们只需要构建一次：
Godwoken 设计文档
· 当一笔生意业务实验销毁或建设一个 cell，cell 中的剧本将被加载并执行，在执行剧本中返回任何错误，都将导致生意业务失败。
这样的要领是可行的，可是仍然会有一些问题：
https://github.com/jjyr/godwoken/blob/master/docs/design.md
对付需要建设一个投票合约的开拓者来说，只需要利用剧本简朴地建设一个账户，这个剧本就会验证输入的数据和账户状态。
· 一个 cell 是一个包括任意数据和可定制剧本的 UTXO
主合约 —— 一个维护所有账户、所有区块的全局状态的范例剧本（layer 1.5 层）
聚合器 —— 一个收集 layer 1.5 层生意业务的链下措施，并按期向主合约提交 layer 1.5 层的区块。
一个合约打点一切
…
fn verify_voting(i, votes) -> bool {
在 CKB 中，用户可以在独立的 cell 中举办投票。这样我们就需要一个链下的脚色收集这些投票的 cells 并计较功效。
Godwoken 是一个成立在 CKB 上的基于账户模子的编程层，方针就是打点一切状态共享的合约。// pseudo code
}
Cell 模子差异于账户模子：
Cell 模子中缺失的那一块
· 去中心化订价的虚拟机
一个 cell 中有所有的众筹代币，用户可以付出 CKB 来得到相应数量的代币。
不幸的是，有一些合约确实很难在 cell 模子上实现：
Godwoken 主合约利用了一个稀疏 merkle tree来存储所有的账户和账户状态。
Sparse merkle tree
验证器 —— 一个一连监控两个合约的链下措施。验证器在一个无效区块被提交时会发送一个挑战请求，在一个错误的挑战请求被提交时会发送一个无效的挑战请求。假如我们想在 layer 1 层的合约中利用一个 layer 1.5 层的状态，我们可以在生意业务的 cell_deps 字段中引用 Godwoken 主合约 cell，并从 cell 中读取 Godwoken 中的全局状态来得到 merkle root，这样就可以验证状态和 merkle proof 了。
· Cell 是通用版的 UTXO
从上面的伪代码中，，我们可以看到验证模子雷同于 layer 1 层。
· 众筹
https://justjjy.com/An-optimized-compact-sparse-merkle-tree与投票的例子雷同，一个典范的办理方案就是引入一个链下脚色，用户在小我私家的 cells 中发出众筹请求；然后链下脚色需要收集这些 cells 并将功效放在一个 cell 中。
等等，我想要的只是一个投票合约。我为什么需要整这么多（巨大的）对象？
在后续的文章中，我们将会接头 Godwoken 中的具体信息，我们如何维护 layer 1.5 层的账户和合约，以及基于账户模子的合约是如何事情的。
UTXO 是一个很是棒的模子，cell 模子担任了它的机动性。我们（通过 cell 模子）可以刊行 UDT（用户自界说代币，雷同于 ERC20），存储链上资产，玩石头铰剪布游戏，可能与实现原子互换等。Cell 模子可以实现许多人们最初认为不行能实现的工作。
当你较量两个模子时，你会发明尚有很多其他的差异之处，假如你对该话题感乐趣，可以在 talk.nervos.org 上找到更多关于 cell 模子 VS 账户模子的接头。
一些人将 Rollup 称之为 layer 1.5 层；也有一些人认为它是 layer 2 层；尚有人认为它是 layer 1 层（按照信任级别）。本文将 Godwoken 称为 layer 1.5 层，以便将其与 layer 1 层的 CKB 区分隔。
· 将数据存储在单独的 cell 中，而不是将数据存储在一个账户中
· 如何有效地证明收集的功效
对付开拓者来说，cell 编程模子无疑是 Nervos CKB 中最有趣的部门。在这里，我们先对 cell 模子作一个简短的描写：
我们可以看到，由于在 cell 模子中，状态是自然疏散的，因此我们必需依赖某个链下脚色来收集状态。
你大概发明，这听起来像是最近很是风行的 rollup 的办理要领。是的，没错。可是我们存眷的是聚合的问题，而非可扩展性的问题。Godwoken 提供了 CKB 基于账户模子的编程本领来办理聚合问题。
· 如何担保在引入了链下脚色后的去中心化
· 验证而非计较
虽然，办理这些问题并不难；我们可以通过付出链下脚色一些用度来鼓励他们；利用某种挑战机可能零常识证明（zk proof）来验证收集的功效；界说一些协议来划定和链下脚色的交互。我们总能办理这些问题。
再举个例子，我们来看一个众筹合约：
通过建设一个抽象的账户层，我们可以在 CKB 上通过最小的本钱建设一个状态共享的合约。
Godwoken 利用和原生 CKB 合约沟通的技能栈。独一的区别在于 Godwoken 合约是基于账户模子的；它将验证账户的状态而不是 cells 的状态。账户状态和 layer 1 层的 cells 之间的映射干系是由 Godwoken 的主合约处理惩罚的，对付 layer 1.5 层的合约来说，是透明的。
在一个 UTXO 类的模子内，状态是自然疏散的。
因此，假如我们想要在 layer 1.5 层合约之间利用一个状态，我们可以简朴的为这个状态生成一个 merkle proof，并在合约中验证 merkle proof。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
