其次，通过转译器支持Solidity有可能失去可组合性——如果开发者同时用CAIRO和Solidity编写合约，那么支持两者之间接口的工具有很大的可能性是脆弱的。到目前为止，绝大多数的StarkNet项目都直接使用CAIRO，它们可能不容易与未来的Solidity项目组合。最后，可能也是最重要的一点，StarkNet团队目前的目标不是与其他以太坊组件兼容——他们正在推出自己的客户端API、javascript库和钱包系统，这将迫使兼容以太坊的工具手动添加StarkNet支持。这极具挑战性，但并非不可能——如上所述，Solana已经成功地使其自定义标准得到一些以太坊工具的尊重，但将依靠StarkWare团队的能力来吸引那些不介意重建的开发者。

　　然而，如果他们能够成功地做到这一点，StarkWare团队将寻求通过第一个为Zk-rollup优化的智能合约虚拟机复制EVM的先发优势。

　　zkSync

　　另一个采用这种策略的项目是zkSync。zkSync已经创建了他们自己的虚拟机（SyncVM），它是基于寄存器的，并定义了自己的AIR (代数中间代码表示) 。然后，他们建立了一个专门的编译器，将Yul（一种中间语言，可以为不同的EVM版本编译成字节码，就像低级别的Solidity一样）编译成LLVM-IR，然后将其编译成指令，用于他们的自定义虚拟机。这与StarkWare采取的方法类似，但理论上提供了围绕基础语言的更多灵活性（尽管目前只支持Solidity 0.8.x）。zkSync团队最初创建了他们自己的类似CAIRO的语言 (Zinc)，但他们已经将大部分精力转移到了Solidity编译器上，以使L1开发者的迁移更加简单。总的来说，他们的策略是重用更多的以太坊工具集——我希望他们的客户端API等也能更 “兼容以太坊”。

　　zkSync利用这个自定义虚拟机来提供非EVM兼容的功能，如账户抽象（Account Abstraction），这一直是以太坊核心协议的目标。这是自定义虚拟机所提供的好处的一个很好的例子——你不必等待以太坊建立新的功能！

　　下图进行了总结，你可以清楚地看到每个团队所遵循的不同策略：

　　Vitalik的zkEVM类型

　　Vitalik Buterin关于zkEVM的博客文章强调了rollup团队目前面临的基本困境：EVM并不是为 “可验证 ”的程序建立的。事实上，正如我们通过上面的分析所显示的，你越是寻求与以太坊兼容，你的 “可验证格式 ”中的程序的性能就越差。Vitalik根据与现有EVM基础设施的兼容程度，确定了通用rollup的几个大类别。

　　我对其观点的唯一拓展是注意到，即使在每个 “类型”中，也有很大程度的变化——我们正在处理一个范围，而不是完全细分的类别。从开发者体验的角度来看，对应用层进行单一的、小的改变的第3类rollup与第2类rollup有更多的共同点，第3类rollup对应用层进行了全面的改变，但在技术上没有引入新的虚拟机而成为第4类。 (责任编辑：admin)