本文是Sin7Y的研究对话记录，聚焦于zkEVM在以太坊虚拟机中的应用和挑战。专家们讨论了如何证明Prover使用正确合约逻辑， zk-friendly方案的优缺点，以及zkEVM的潜在升级问题。他们还触及了编译器和原生zkEVM的对比，以及可能的替代哈希函数如Poseidon。对话强调了兼容性、开发人员支持和安全性的重要性。
本文为 Sin7Y 发布的第一篇对话记录，我们邀请了匿名业内专家，以问答的形式讨论了一些关于以太坊虚拟机亟待解决问题的想法和方向。
问：如何证明 Prover 使用了正确的合约逻辑？
答：你需要在链上调用数据，这将定义“制定合约”，之后我们需要从存储中加载该合约的字节码，并确保这些是状态验证传递给以太坊虚拟机证明的操作码。
问：那么过程应该是这样的：
• Prover 从存储中加载合约字节码；
• 在状态证明中检查字节码，然后传递给以太坊虚拟机证明
但是如何确保状态证明和 zkEVM 证明中使用的字节码的确是从存储中加载的呢？是在电路中证明？还是需要像 HERMEZ 方案一样使用 Plookup 技术？
答：是的，Plookup 可用于构建键值映射。
问：对于基于原生的zkEVM和基于编译器的zkEVM，您有什么想法吗？来自 ZKSync 的 Alex 说基于原生的 zkEVM （我认为我们目前就是这样设计的）“要复杂一个数量级”。
答：基于编译器的方案会有很大的不同。智能合约的安全属性，尤其是它需要考虑对新的以太坊虚拟机行为进行安全审计。这就会要求开发人员学习这些新行为，并在构建智能合约时更为仔细。过去发现过这样一个错误：有人构建了某些程序，我们就假定开发人员会学些如何去使用它。我们能从乐观的汇总团队学到的一点是：支持开发人员而不是要求他们重建一切，这
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
