这些中间步骤为维护和潜在的错误创造了更大的表面积，但对于实现高性能的证明来说是必要的。最终，重要的是要清楚，你的程序不是在反映电路中的EVM的zkEVM中运行，它们是在备用的 “zkExecutor ”运行时中运行，它与EVM本身相似但不同。

　　由于这个原因，可能会与在此系统上运行的现有L1应用程序和工具有一些不兼容，尽管大多数Solidity代码可以照常运行。Polygon宣称与 “100%的现有以太坊工具”兼容，并承诺遵守JSON-RPC，他们在文档中提到了这一点。在实践中，这种说法可能是理想的，这将依赖于以太坊本身变得对SNARK更加友好。

　　Polygon的方法产生了比Scroll更高性能的rollup（当然是在中短期内）：

　　大量的自定义代码，因为我们需要创建zkASM

　　可能需要开发人员修改他们的L1代码或工具框架

　　随着时间的推移，与以太坊的偏移可能会扩大

　　方案3：自定义虚拟机+转译器

　　上述解决方案在 “使EVM适用于zk-rollup”方面投入了大量的开发时间，将兼容性置于长期性能和扩展性之上。还有一个选择：创建一个全新的、专门的虚拟机，然后在上面添加对以太坊工具的支持，作为一个附加层。

　　StarkNet

　　这是StarkWare对StarkNet中取的方法，它是目前进展最快的通用rollup。StarkNet运行一个定制的智能合约虚拟机（Cairo VM），并有自己的低级语言（Cairo），两者都是为智能合约rollup而建。这意味着StarkNet没有开箱即用的以太坊兼容性——正如我们之前看到的，即使是操作码级别的虚拟机级别的兼容性也也可能会影响rollup的性能。

　　然而，Nethermind团队（与StarkWare合作）创建了Warp转译器，它能够将任意的Solidity代码转换为Cairo VM字节码。Warp的目标是使普通的Solidity合约可以移植到StarkNet上——实现许多以太坊开发者在 “EVM兼容性 ”方面的主要目标。然而，在实践中，有一些Solidity的功能是Warp不支持的，包括低级别的调用（完整的列表可以在这里找到）。

　　这种构建智能合约rollup的方法是保持 “Solidity兼容”：你没有在EVM内执行程序，也没有保持与任何其他以太坊接口的兼容性，但Solidity开发人员将能够编写可用于你的rollup的代码。因此，你可以保持与以太坊类似的开发者体验，而不必损害你的rollup的基础层。

　　然而，这种方法需要做出几项折衷。首先，建立自己的虚拟机是具有挑战性的——以太坊团队已经有超过五年的时间来解决EVM的问题，并且仍然在频繁地进行升级和修复。更多的自定义rollup将允许更好的性能，但你将失去由每条其他链和rollup对EVM进行的集体改进的好处。 (责任编辑：admin)