Polyjuice：CKB 上 100% 兼容 EVM 的 Ethereum 解决方案

Polyjuice 是 CKB 上的以太坊解决方案，这意味着人们可以通过最小的改动，来将他们现有的运行在 Ethereum 上的 dApp 迁移到 CKB 上。Polyjuice 的设计目标是与 EVM 100%，甚至 120% 兼容，这意味着：

• 任何在 Ethereum 上运行的基于 Solidity 的智能合约都可以在 Polyjuice 上运行；
• Polyjuice 甚至可以提供更多今天在以太坊上无法实现的功能。比如你现在急需一个 EIP，Polyjuice 可以实现它来辅助你的 dApp；

需要注意的是，兼容性设计只适用于 EVM，Ethereum 也有支持的 RPC，应用程序可以通过 RPC 与链通信。遗憾的是，由于 Polyjuice 和 Ethereum 之间的设计不同，我们不能保证与 RPC 完全兼容。这意味着将您现有的 Ethereum dApp 在部署到 Polyjuice 之前需要做一些工作。

不过，我们将确保

a) 智能合约不需要更改；
b) 两套 RPC 彼此相似。

我们会将这些差异清楚地记录下来。这样一来，移植工作会尽可能地减少。我们还将构建与 Portal Wallet 的集成，因此终端用户可以获得无缝的体验。

我们在 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 来说，比如投票应用，这已经足够了。 (责任编辑：admin)