其他
CKB Style 的区块链乐高：Godwoken 上的 Polyjuice
在研究 Godwoken、Polyjuice 或其他与区块链相关的东西之前，让我们首先从过去数据库领域的故事开始说起。
几十年前，人们由于需要更好的工具来组织数据，所以 SQL 数据库 (https://en.wikipedia.org/wiki/SQL) 应运而生。ACID 属性 (https://en.wikipedia.org/wiki/ACID) 的设计是为了让数据可以在原始创建数年后，依然可以安全地写入和读取。在那个时代，一个数据库只服务于有限数量的人，一台机器（大型机，或后期强大的微型计算机）就足以支撑一个数据库。
渐渐地，电脑开始普及，互联网的爆炸式发展更是加快了这一进程。很快，单台机器已经无法为数据库提供应有的支持，于是分布式数据库开始出现。然而，CAP 定理的发现（从一致性、可用性、分区容错性这三个特性中最多只能选择两个）给软件工程师带来了巨大的挑战。最终，他们被迫在 CP 和 AP 数据库之间做出选择。为了方便参考，我们用一个简单的（虽然是单方面的）方法来区分 CP 数据库和 AP 数据库：
CP 数据库保证了整个分布式系统的全局一致性视图； AP 数据库可能为不同的逻辑部分或分区提供不同的视图。
AP 数据库，来源：
https://kgrvamsi.wordpress.com/2013/05/28/riak-in-depth/
但故事并没有结束。几年后，AP 数据库的缺陷开始浮出水面：当人们在设计系统架构时，来自不同分区的不同视图确实会影响人们的决策。
举个例子，假设你是一个基于传统 SQL 数据库构建的开发人员，你只需要关心逻辑表和它们之间的连接即可。偶尔可能会需要更多的性能查询，但你的数据始终是保持有序的。然而在 AP 数据库中，你只配备了键值（KV）存储或文档存储。我们必须首先设计模式，但在此之上，你必须处理数据库不同分区发生的不一致写入。这大大增加了应用开发者的工作量，在很多情况下，这也会导致混乱的数据存储。
即使从 CP 数据库解决方案 DynamoDB 上线并使用至今的 AWS 来看，传统的 SQL 数据库仍然在被人们广泛使用。只有在特殊情况下，比如购物车逻辑中存在特殊的合并功能，DynamoDB 才会得到大量采用。对于日常开发者正在构建的绝大部分应用来说，AP 数据库很难作为一个很好的选择。
现在我们来看看今天讨论的热点话题：NewSQL，它保持了原来 SQL 模型的 ACID 属性，在大多数用例中作为 NoSQL 的替代品而得到普及。由于设计上的要求，NewSQL 的解决方案大多甚至全部都建立在 CP 模型上：
Google Spanner 是 Google 面向未来的、全球规模的数据库。它遵循 CP 设计，旨在提供比基于 AP 的 BigTable 更好的替代方案； CockroachDB 和 TiDB 都是基于 CP 模型构建的现代开源分布式 SQL 数据库； CitusDB，一个典型的基于 PostgreSQL 的可扩展数据库，也是基于 CP 模型构建的。
从这个故事中，我们可以看到，开发者最终还是会选择那些让他们更有效率的工具。
在 Nervos 中，我们坚信分层的解决方案。这从来都是我们深思熟虑的结果，是基于我们在软件行业的丰富经验而得出的结论。分层让我们具备了一种设定边界、封装复杂性和提供假设的方法。
我们行业中有很多东西都是建立在分层架构之上的：网络堆栈、编译器基础设施、CPU 架构等等，这样的例子不胜枚举。在这个行业，以及人类创建的许多其他行业中，我们可以看到一些层在构建时隐藏了细节，并同时为上层提供支持。
即使对于那些认为区块链是一项全新技术的人来说，层的使用也呈现出明显的差异：
在一个分层网络中，核心区块链确保了其交易的全局一致性； 分片区块链的设计提供了不同的分片，每个分片都可以独立工作。
假以时日，我们相信分层将会为所有 dApp 开发者带来更明显的好处，就像 NewSQL 数据库的崛起一样。
很多人一直都想知道 CKB 上的 Layer 2 解决方案会是什么样子的，所以今天，我们就在这里向大家介绍两个互补的项目：
Godwoken 的初始版本：
https://github.com/nervosnetwork/godwoken
Polyjuice 的全面更新：
https://github.com/nervosnetwork/polyjuice
Godwoken：无需许可的 Rollup 框架
在 Nervos 上，我们完全可以支持所有的这些方案，但实际上，我们必须从一个方案开始。在现有的解决方案中，Rollup 是最优的，也是最没有缺陷的。因此，我们从 Rollup 开始了我们的旅程。稍后我们还会看到，由于 CKB 独特的设计，Rollup 比单纯提升 TPS 这种像类固醇般的方案来的更有意义。基于近一年的研究、设计和实现，我们已经发布了 Godwoken 的初始版本，也就是我们的无需许可 Rollup 框架。
Godwoken 的工作原理是通过一组 aggregator 节点收集专门设计的 Layer 2 交易，然后将它们打包成 CKB 交易，提交给 Layer 1 CKB 接收。从这个意义上来说，Godwoken 确实是以 Layer 2 的方式工作的：
除了 CKB 节点外，还运行着特殊的 Godwoken 聚合器节点 采用专门设计的 Layer 2 交易格式，来代替 CKB 的交易格式 由 Godwoken 节点提交一个特殊的 CKB 交易，也可以看作是 Layer 2 区块
尽管是 Layer 2 解决方案，但 Godwoken 背后的一个重要设计理念是，我们正在构建一个无需许可的 Layer 2 解决方案。
就像 Layer 1 区块链提供的那样，Layer 2 交易用交易费用激励聚合器节点； 在 Nervos CKB 上可以进行多个单独的 Godwoken 部署。每个部署都可以自由地做出自己的选择。如果一个部署不能满足你的要求，你还可以自由地切换到另一种部署，甚至可以启动自己的部署； 虽然一些部署可能会产生额外的限制，但 Godwoken 的核心设计是让每个人都能向 Layer 2 区块链提交区块，使其像真正的无需许可 Layer 1 区块链一样扩展。
(为了展示更多关于 Godwoken 的内部信息，我们将在近期发布一篇名为《Life of A Godwoken Transaction》的文章，在文章中我们将介绍更多关于 Godwoken 设计和实现的细节。)
值得一提的是，目前我们只发布了 Godwoken 的第一个版本，它仅限于以下设计选择：
将使用基于 Optimistic Rollup 的设计；
通过 Proof-of-Authority 来控制 Layer 2 区块的发行。
一个真正基于 Proof-of-Stake 的区块发行协调机制
基于 ZK Rollup 的设置
以及更多！
不过，使用 Rollup 框架只能解决问题的一半。一个只能发送原生代币转账的解决方案终究不能解决所有问题。在竞争激烈且不断增长的区块链领域，往往需要一个智能合约解决方案来释放更多的潜力。为了解决这另一半的问题，我们还打造了 Polyjuice，它将与 Godwoken 互补运作。
Polyjuice：CKB 上 100% 兼容 EVM 的 Ethereum 解决方案
任何在 Ethereum 上运行的基于 Solidity 的智能合约都可以在 Polyjuice 上运行； Polyjuice 甚至可以提供更多今天在以太坊上无法实现的功能。比如你现在急需一个 EIP，Polyjuice 可以实现它来辅助你的 dApp；
不过，我们将确保
a) 智能合约不需要更改；
b) 两套 RPC 彼此相似。
我们在 2020 年 7 月份推出了 Polyjuice，之所以再次提到它，是因为我们对 Polyjuice 进行了全面的审查和检修，并修复了它最大的问题：处理共享状态。
为了演示共享状态，我们假设开发者已经将一个 Ethereum 智能合约部署到 Polyjuice 上。在我们之前的模型中，人们会创建这样一个 Cell：
要调用这个智能合约，必须要创建一个 CKB 交易，消耗该合约 cell 并创建一个新的合约 cell。
这就是问题所在：当多个用户调用同一个智能合约时，他们都需要消耗并重新创建合约 cell。实际上，他们在竞争共享的合约状态 cell。在大多数情况下，用户不会知道其他人正在创建的交易；他们中的每一个都会使用链上最新的实时合约状态 cell 创建一个交易。
这会导致多个交易消耗同一个合约状态 cell，矿工不得不选择一个交易，而这会导致所有其他交易无效。这是 CKB 选择基于 cell 模型造成的结果，但这不一定是缺点：
不需要单一共享状态的情况还有很多，sUDT 就是这样一个例子。对于这些情况，基于 cell 的模型提供了改进，比如提高了可扩展性和确定性； 即使在共享状态不可避免的情况下（如投票应用，或 AMM），也有解决方案：
在许多情况下，可以利用简单的重试逻辑：可以创建这样一条规则「只要交易包含输入 1 和输出 1&2，我就不关心输入 0 是什么，只需签名并发送交易」。也可以给规则附加一个超时时间，比如 10 分钟的窗口。对于相对较小的 dApp 来说，比如投票应用，这已经足够了。
如果有些情况有其他需求，例如更高的 TPS 需求，那么重试逻辑就不可行了。Rollup 在这里提供了一个不同的方案。通过在 Godwoken 之上构建 Polyjuice，每个单独的 Polyjuice 交易就可以只是一个 Layer 2 的 Godwoken 交易。这样就避免了共享状态问题，因为只有打包好的 Godwoken CKB 交易才会消耗合约状态 cell，并重新创建一个更新后的状态 cell。
在这里，Godwoken 和 Polyjuice 是互补的：Polyjuice 提供了一种将自定义逻辑注入到 Godwoken 的 Rollup 解决方案，Godwoken 解决了 Polyjuice 的共享状态问题，同时也提供了更高的 TPS 潜力。我们希望 Godwoken 和 Polyjuice 的结合，能对 Nervos CKB 仙境中的分层 dApp 设计有所启发。
值得指出的是，Polyjuice 并不是 Godwoken 的唯一虚拟机解决方案。我们还可以将其他虚拟机与 Godwoken 集成，提供不同的 dApp 构建方式。例如，纯粹的 JavaScript 虚拟机 (https://github.com/xxuejie/ckb-duktape) 是完全可以实现的，因此我们只需在区块链中直接用 JavaScript 编写即可。或者作为更远大的目标，在 Godwoken的帮助下 CKB 上的 Diem (https://www.diem.com/en-us/) 也完全可以实现。
(为进一步解释 Polyjuice 的内部结构，我们也将于近期发表另一篇题为《Life of A Polyjuice Transaction》的文章。)
展望未来
对于忙碌的应用开发者来说，我们希望提供一站式的解决方案，让他们可以直接利用 Layer 2 EVM 驱动的区块链来发布他们想要的任何东西。例如，如果我们告诉你，Uniswap (https://uniswap.org/) 只需进行少量的调整，就可以部署到 CKB 上，那会怎样？ 对于更有冒险精神的人来说，CKB 提供了完美的乐高风格部件，你可以自己拆卸和重新组装。 不喜欢通过 Solidity 来编写智能合约？为什么不在 Godwoken 上搭建自己的虚拟机来实现不一样的 Rollup 链呢？ Optimistic Rollup 听起来很无聊？您可以随意将其取出，并将其替换为更具挑战性的部分，比如 ZK Rollup。 PoA 的机制对你来说像是定时炸弹？那就把它删掉，用你自己的 PoS 甚至 PoW 方案吧。
总而言之，我们希望这个全新的 Layer 2 Godwoken/Polyjuice 在 CKB 上的部署，可以类似于你可能习惯的汽车：你可以从经销商处购买后将它开走（原厂），也可以打开它加装涡轮增压器，从而获得更强劲的动力。我们已经做好了准备，你最终会对你全新「汽车」的所有改装感到惊讶。