“总的来说，我的观点是在短期内，Optimistic rollup 在 EVM 兼容方面占尽优势，而ZKrollup 则有望在简单支付层面、交易以及其他特定用例方面更胜一筹。

不过在中长期来看，ZK rollup 会随着 ZK-SNARK 技术的改进，在所有用例中胜出。”

这是V神在他的博客《An Incomplete Guide to Rollups》一文中的原话。

ZK是ETH的理想, 零知识证明（Zero-Knowledge Proofs, 一下简称ZK）在以太坊生态系统中的应用揭示了其在解决区块链的不可能三角问题（即安全性、可扩展性和去中心化之间的权衡）方面的潜力, 无需访问完整的交易详细信息，提高了系统的可扩展性的同时不损失安全性。

ZK的引入使的ETH系统的去中心化特性进一步加强(节点门槛降低)确保了网络的分散性和抗审查能力, 让ETH如龙入海, 难以抹灭。

这么重要的ZK, 为什么大家的使用感受奇差, 规模化落地又掀不起任何浪花呢？

1.零知识证明rollup目前的问题

我把目前零知识证明之所以还处于瓶颈期, 的原因归结为 三个方面: 兼容性问题、效率问题、 和 数据结构问题。

1.1 最主要也是最迫切的问题：兼容性问题

由于EVM（以太坊虚拟机）已经在区块链领域中崛起为类似JavaScript的地位，它已成为新型价值互联网的通用语言。拥有众多的工具、服务、库和基础设施，EVM的广泛应用在当前的技术环境中几乎成为了一种必然趋势。

互联网中流传这一句话：“凡是能用JavaScript实现的东西，最后都会用JavaScript实现”。

这其中还有一种重要的但是容易混淆的概念就是“EVM兼容”和“EVM等效”。

从“接近程度”和“实现方式”上来理解这两者的差距——

“兼容”：一个系统能够以某种方式执行和理解 EVM 字节码，它能够支持通过 Solidity 或其他 EVM 语言编写的智能合约。

“等效”：EVM 等效性 则是一个更高的标准。一个 EVM 等效的系统不仅能够执行 EVM 字节码，而且在行为和路径上完全匹配 EVM。所有针对 Ethereum 的工具和库应该也能在 EVM 等效的系统上使用，而无需任何修改。

“EVM等效”优势和劣势：

优势:

完全的工具链和基础设施支持：Ethereum拥有一个庞大的工具链和基础设施生态系统，包括各种开发工具、测试框架、代码库和服务。如果一个L2解决方案是EVM等效的，那么所有这些工具和服务都可以无缝地与其集成，因为从他们的视角来看，这个L2解决方案就像是另一个Ethereum网络。

1. 更容易吸引和迁移开发者：Ethereum上的开发者们已经习惯了EVM的行为和特性。如果一个L2解决方案是EVM等效的，那么开发者可以直接使用他们已经熟悉的语言（如Solidity）和工具在这个L2解决方案上进行开发，而无需学习新的编程模型或语言。
2. 更好的合约兼容性：许多现有的Ethereum合约依赖于EVM的特定行为。如果一个L2解决方案是EVM等效的，那么这些合约可以在不修改或只需进行最小修改的情况下在这个L2解决方案上运行。
3. 未来的EVM改进和特性：EVM还在不断发展和改进中，新的EIPs（Ethereum Improvement Proposals）可能会引入新的特性或优化。如果一个L2解决方案是EVM等效的，那么这些改进和特性可以很容易地在这个L2解决方案上实现。

劣势:

1. 技术更复杂：EVM是一个复杂的虚拟机，它的行为和特性需要深入理解并准确实现。在L2解决方案中实现EVM等效性可能需要解决一些技术上的困难，比如如何在一个不同的共识环境或网络模型中模拟EVM的行为。
2. 性能和效率：EVM是为Ethereum设计的，它的设计可能并不完全适合L2解决方案的特性和需求。例如，EVM使用256位整数进行计算，而许多zk-proof系统更自然地工作在质数字段上。直接实现EVM可能需要引入额外的范围检查等操作，这可能会降低性能和效率。
3. 灵活性和创新的限制：坚持EVM等效性可能会限制L2解决方案在某些方面的灵活性和创新能力。例如，如果一个L2解决方案想要引入一个新的特性或优化，那么它必须确保这个变化不会破坏其EVM等效性。

OP就写过一篇文章 探索EVM兼容和EVM等效, 刚开始的时候OP用的OVM后来转变为EVM等效。这也是我认为OP为什么在初期野蛮生长期没有干过ARB的重要原因, 没有做到EVM等效在兼容性上和ARB有差距, 但现在是改过来了, 而且兼容性上甚至有超越ARB的意思。

从这个角度我们也能理解EVM兼容性的重要意义, 甚至要做到等效才能吸引来开发者,由此有用户,从而有生态。

1.2 ZK rollup的技术环境其实还不成熟

从数据可验证性的角度来看, 数据可验证性是区块链系统中的一项关键特性，确保了系统的透明度和可审计性。

ZK Rollup的证明构造相对复杂，要求所有数据都必须在链上可用。这确保了强大的安全性和完整性，但也增加了数据存储的复杂性和成本, 这一点和OP有很大的不同。

• Optimistic Rollup: OP Rollup采用一种乐观的策略，其中交易被假定为有效，除非有人提出异议。这种方法不需要在链上存储所有数据，只需要存储足够的信息来允许任何人挑战交易的有效性。因此，OP Rollup在数据可验证性方面的要求相对较低。
• ZK Rollup: ZK Rollup利用零知识证明（ZK-SNARKs）来压缩交易并证明其有效性。所有的交易数据都必须在链上可用，以便任何人都可以生成有效性证明。如果数据规模过大，并且全部存储在主链上，可能会遇到容量瓶颈的问题。

随着zkSync的数据规模的增长，将所有数据全部存储在主链上可能变得不可行。这可能需要引入外部数据的验证，从而转变现有的二次验证方式，减少对主网数据的依赖。

这样的改变引发了新的挑战：如何在减少对主链数据依赖的同时确保系统的安全性？

因此，zkSync向STARK的转型也部分是由此引发，因为与SNARK相比，STARK更适合使用外部的可验证数据。

由上述描述所知，ZK rollup的落地还需要依赖ETH进行更多的ZK友好化改进，例如 DA层以及 EVM的改进。

1.3 除此之外 ZK rollup 还有一些其他问题, 例如效率问题:

在区块链领域，Sequencer的速度（通常以每秒交易数，TPS，来衡量）是评估ZK系统性能的关键指标。Sequencer负责交易的排序和处理，其处理能力直接决定了整个链的吞吐量。

然而，在目前的实施中(Zksync)，单一Sequencer的处理能力大约只有几百个交易每秒，这一局限性暴露了一个显着的性能瓶颈。

为了扩大TPS，有两种主要的途径可供考虑：一是继续提高单个Sequencer的能力，但这样做可能会增加系统的中心化风险；二是引入更多的Sequencer以分散处理负载，尽管这样做增强了去中心化的特性，但协调多个Sequencer可能会增加延迟并降低整体TPS。这个问题凸显了一个需要仔细权衡的挑战，即在提高性能与维持去中心化之间找到合适的平衡点。

ZK技术的发展方向，如zkSync所展示的，倾向于推动去中心化的Sequencer进程。这样的选择会让性能继续成为ZK技术发展的一个重要瓶颈。虽然采用多个Sequencer和模块化设计提供了一定的解决方案，但在实际操作中可能会涉及复杂的协调和同步问题。这不仅可能影响系统的响应时间和吞吐量，还可能引入新的安全和可靠性挑战。

性能问题仍是一个待解决的关键挑战。未来的研究和开发可能需要集中在如何在不牺牲去中心化原则的前提下，通过优化算法、协调策略和硬件支持等方式，来提高ZK系统的性能和可扩展性。

2.零知识证明是ETH的终极理想

我们说了ZK目前的问题, 以及面临的困境, 那么死磕ZK的原因是什么呢">先说结论：就是做EVM等效的ZK rollup，并且等待现在的以太坊进行EVM的ZK友好化升级，两头齐头并进共同帮助ZK技术和ETH的完美融合。

3.1 V神口中的 四种类型的 ZKrollup

• Type 1 (完全Ethereum等效)

Type 1 ZK-EVM致力于完全无妥协地与Ethereum等效。它不改变任何部分，即使这会让生成证明变得困难。

优势：完美兼容。

劣势：证明时间长。

谁在开发？：ZK-EVM Community Edition。

• Type 2 (完全EVM等效)

Type 2 ZK-EVM追求与EVM完全等效，但对外部数据结构有所更改。

优势：在虚拟机级别完全等效。

劣势：改善但仍然慢的证明时间。

谁在开发？：Scroll和Polygon Hermez。

• Type 3 (几乎EVM等效)

Type 3 ZK-EVM几乎与EVM等效，但为了进一步提高证明时间和开发便捷性，做了一些妥协。

优势：更容易构建，证明时间更快。

劣势：更多的不兼容性。

谁在开发？：Scroll和Polygon。

• Type 4 (高级语言等效)

Type 4系统通过直接从高级语言编译来工作，不通过EVM执行。

优势：非常快的证明时间。

劣势：更多的不兼容性。

谁在开发？：ZKSync和Nethermind的Warp项目。(注意, StarkNet甚至不是EVM兼容,不在讨论之列)

ZK-EVM的不同类型在兼容性与效率之间呈现了一系列复杂的权衡点。

Type 1以完全的兼容性为目标，却受制于证明时间过长，暴露了以太坊未曾考虑ZK友好设计的现实挑战。

Type 2和Type 3在完全兼容性与证明效率之间寻找平衡，展现了现有技术条件下实际可行方案的探索与妥协。

Type 4则以追求效率为首要目标，但却以牺牲兼容性为代价，使得生态发展起来会略显吃力。

3.2 EVM与ZK的共同升级：一同努力在终点相遇

ETH落地ZK的最佳路径不仅涉及ZK EVM等效的零知识证明的实施，更关键的是EVM自身的升级和改造。

• EVM的ZK友好化改造

EVM的ZK友好化改造是一个复杂但必要的过程。EVM不仅需要与ZK-EVM等效，还必须考虑将来可能的ZK-SNARK ASIC的发展。

• ZK-EVM与EVM的双向协同

ZK-EVM与EVM的协同不仅在于技术层面的兼容性和效率，还涉及开发者工具、预编译支持等多方面的整合。

• 逐步迈向Type 1的未来

通过ZK-EVM和Ethereum本身的不断改进，逐渐实现Type 1，是许多人的愿景。这一进程可能缓慢，但它描绘了一条通向未来的明确路径。

3.3 生态内的共同努力和协同才是亮光

以太坊落地零知识证明（ZK）的挑战并非仅仅是技术问题，而是一场在理想和现实之间寻找最佳路径的探索。这一过程揭示了如何在保持现有基础设施兼容性的同时，逐渐引入更快、更高效的解决方案。

在这一探索过程中，最理想的方案是构建一个与现有EVM完全等效的ZK解决方案，然后等待EVM自身的ZK友好化升级。这一过程的精髓在于双方同步努力，共同前进，以期在某一中间点相遇。

这种共同努力的思路不仅仅体现在技术实现上，更在于如何在保留以太坊独特价值和现有生态的基础上，引导整个社区朝着更加安全、可扩展的方向发展。这一过程需要技术洞察、战略谋划，以及对整个生态系统动态的敏锐理解。

因此，我们可以看到，ZK技术在以太坊上的落地不仅是技术革新，而是一场整个生态系统共同参与的变革之旅。这一旅程将塑造以太坊的未来，寻求平衡创新和稳定、速度和兼容性的区块链环境。

4.总结

ZK时代的开启不仅标志着以太坊生态的崭新篇章，更是一次历史性的跃升。在这一波潮流中，以太坊不仅有望在某些方面超越现有的互联网体系，更预示着一种全新的、更先进的连接方式的诞生。