【前言】

整个区块链都是构建在密码学之上，因密码学成就了整个分布式账本的一层生态；又因密码学，出现了二层的链下扩容方案，在2022年8月份Vitalik发布《The different types of ZK-EVMs》一文，当当前主流的扩容方案进行了整体对比，参见下图：

图1：The different types of ZK-EVMs Overview

所以，当前zkVM扩容的解决方案也都基本围绕着zkEVM的方案，因为对既有生态的延续和支持上其他的zkVM方案对承前有着一定not compatible的问题，然而在启后的问题上却会是Web2升级Web3的重要组成部分，尤其是以zkWasm为代表的等兼容很多C++、Rust、Go、AssemblyScript、C# 等语言的解决方案出现后，Web2应用的账户系统升级成为了可能；可期的zkEVM向左承前，zkWasm向右启后，共建Web3应用升级大生态，而不是继续围绕困惑了多年的公链之争。

【TL; DR】

1. 以太坊最终核心功能是DA + Settlement + Consensus的一个分布式账本定位，eWASM以zkWasm的解决方案更适合构建Web3.0生态。

2. zkEVM承前优化区块链生态，zkWasm启后，开创Web3.0未来！

3. Build Rollups with zkWasm, not just Blockchains

【zkEVM承前，zkWasm启后】

正如前言所述，真正Web2.0和Web3.0连接打通的生态纪元是AppRollup时代，相较于还沉静在chain思路的生态下，Rollup时代不需要创造出过多的chain,因为chain扮演的是账本，也即账户层脱离于单独的应用，回归到通用层，所属权回归用户；chain天然是这样一个载体，承担着Data Availability （DA），Settlement和Consensus的本质职能。

图2：AppRollup is much more flexible than Appchain

【ZKP，Zero-Knowledge Proof】

密码学中，零知识证明（英语：zero-knowledge proof）或零知识协议（zero-knowledge protocol）是一方（证明者）向另一方（检验者）证明某命题的方法，特点是过程中除“该命题为真”之事外，不泄露任何资讯。因此，可理解成“零泄密证明”。最早由MIT的Shafi Goldwasser、Silvio Micali和Charles Rackoff在1985年一篇名为《互动式证明系统的知识复杂性》（[GMR85]）的论文中提出。作者在论文中提到，证明者（prover）有可能在不透露具体数据的情况下让验证者（verifier）相信数据的真实性。零知识证明可以是交互式的，即证明者面对每个验证者都要证明一次数据的真实性；也可以是非交互式的，即证明者创建一份证明，任何使用这份证明的人都可以进行验证。

图3：零知识证明发展史

zk-SNARK（Succinct Non-Interactive Arguments of Knowledge）可能是最流行的零知识证明形式，最早出现在2011年的Bit+11论文中。到2013年，多亏了Pinocchio PHGR13论文，零知识证明可以在现实应用中使用，该论文使zk-SNARKS适用于一般计算，尽管速度较慢。2016年提出的Groth16算法大大降低了计算复杂性，使zk-SNARKS非常高效，至今仍然是标准。

然而，可信设置对于这些零知识协议的安全性至关重要。必须使用初始过程生成加密参数，以便能够运行零知识协议。由第三方执行此操作，以确保加密参数是随机、不可预测和安全的。

随后在2017年引入了Bulletproofs（BBBPWM17），在2018年引入了zk-STARKs（BBHR18）。与前任不同，它们是不需要初始可信设置的范围证明类型。2019年的PlonK论文实现了通用零知识证明算法，这意味着只需要启动一次可信设置，而与之相比，Groth16需要每个电路都有一个单独的可信设置。

由于领域的发展，零知识证明已经从纯理论过渡到在区块链、安全通信、电子投票、访问控制和游戏中具有有用的实际应用。随着它们继续投入商业应用，将会有更多令人兴奋的发展来推进技术。

所以，zk-SNARKS、zk-STARKS、PLONK以及Bulletproofs构成了当前零知识证明主要实现方式，每种方式在证明大小、证明者时间以及验证时间上都有自己的优缺点。在区块链的扩容解决方案里，基本也是围绕着ZK-SNARK-friendly为主的实现方式。

【 WASM, WebAssembly】

WebAssembly（简写 WASM）是 Web 技术家族（JavaScript、HTML、CSS）中相对较新的成员，于 2019 年 12 月成为 W3C 官方认可的标准。WebAssembly 在浏览器中引入了一个新的运行时，该运行时与 JavaScript 运行时协同工作。相比之下，它更轻量，拥有少量的指令集以及严格的隔离模型（WebAssembly 默认没有 I/O）。开发 WebAssembly 的主要动机之一是为更多的编程语言（C++、Rust、Go 等）提供编译目标，允许开发人员使用更广泛的工具集开发新的 Web 应用程序或移植现有的应用程序。

图4：Wasm版图

不论是Web2还是Web3，对Wasm的支持和使用范围也是越来越广泛的：

图5：WebAssembly 生态中的主要公司和组织

【zkWasm = zkp + WASM 】

zkWasm作为zkVM的一支新秀，本质是通过链下解决复杂运算，链上存储证明，兼容Web2主流语言的思路，实现Web2与Web3的连接升级，复杂的业务逻辑链下计算，有价值的结果和证明进行上链保存，用于溯源、验真和清算，账户体系由现有的钱包体系构成，整个生态可由下图来表示：

图6：zkWasm生态

整体的数据逻辑走向可以用下图表示：

图7：On-Chain Contracts + Off-Chain Virtual Machine (VM) + WASM Composability

在最初以太坊2.0更新的一个重要核心，也包括从EVM过渡到eWASM；但是实际2.0的进展并不如预期，所以在最新的规划计划里，eWASM并未有过多的提及。

图8：ETH 2.0整体规划

虽然eWASM在近期的规划并未提及，但是eWASM能带来的好处也是被认可的。从一开始，EVM就是为了强调正确性而非效率而设计的。这反映在网络上的所有节点必须完全准确地运行EVM这一事实上。Wasm虽然与EVM相似，但它是为web而发明的。与正确性不同的是，Wasm强调的是效率和快速加载。以太坊开发者Lane Rettig表示，EVM的创建不具备“大量的设计思想”，他认为EVM是从理论角度上而非实际角度设计的，因此，虽然它内部健全，但在现实世界中无法发挥最佳的作用。Nick Johnson同意这种看法，相比之下，Wasm的编写更接近于实际的硬件指令，这使得它在翻译实际的编码逻辑时更加有效。事实上，Wasm指令可直接将一对一映射到机器使用的指令，这将使性能大大提高。同时Ewasm可以减少甚至消除对预编译的需求，互操作性上将支持更多的语言，并将受益于比EVM更广泛的工具集。

主流认可使用 eWASM 优于 EVM 的优势主要有以下几点：

1. 性能：与 EVM 相比，eWASM 提供更好的性能，因为它使用 WebAssembly，其设计目的是比 EVM 字节码更快、更高效。WebAssembly 提供接近本机的性能，这可以显着提高以太坊网络的速度和可扩展性。

2. 互操作性：eWASM 提供比 EVM 更好的互操作性，因为它支持多种编程语言，包括 C++、Rust 和 AssemblyScript。这使开发人员能够用他们喜欢的语言编写智能合约，从而提高代码质量和开发人员的工作效率。

3. 安全性：eWASM 提供比 EVM 更好的安全性，因为它包含多个安全功能，例如内存沙箱，它可以将智能合约彼此隔离并防止它们访问彼此的内存。此外，eWASM 提供更好的保护，防止常见的智能合约漏洞，例如重入攻击和整数溢出。

4.灵活性：eWASM 提供了比 EVM 更好的灵活性，因为它支持动态链接，这使得智能合约可以由多个可以独立更新的模块组成。这可以带来更好的代码组织和更轻松的智能合约维护。

5.社区支持：eWASM 获得了以太坊社区的大力支持，几个主要的以太坊客户，包括 Geth 和 Parity，已经实施了 eWASM 支持。这意味着开发人员在使用 eWASM 构建智能合约时可以访问范围广泛的工具和资源。

然而，作为底层的以太坊网络真的需要把EVM换成eWasm么？替换过程中的各种安全风险和现有生态的影响其实是不容小觑的，也许这也是最新的规划中eWASM并未被过多提及的原因。

图9：Vitalik Buterin 提出了最新以太坊线路图

根据对以太坊架构的影响，该路线图将升级分为几个类别。这包括：

Merge：涉及从工作量证明转为权益证明的升级

Surge：涉及通过卷叠和数据分片进行扩展的升级

Scourge：涉及抗审查性、去中心化和最大可提取价值的协议风险的升级

Verge：涉及更轻松地验证区块的升级

Purge：涉及降低运营节点的计算成本和简化协议的升级

Splurge：不属于上述类别的其他升级

大家意识到以太坊最终核心功能是DA + Settlement + Consensus的一个分布式账本定位，这样对很多拓展性上的需求并不需要以太坊本身做出过多修改而带来其他未知风险，鱼和熊掌兼得的方式便是分层分工，将eWASM放在二层应该是一个更合理有效的解决方案，尤其是与zk结合之后，zkWasm的技术方案就能完美的继承eWASM想要实现的效果，同时可以对Web2和Web3均提供服务，连接彼此。zkEVM承前优化区块链生态，zkWasm启后，开创Web3.0未来！

图10：zkWasm = zkp + WASM

【参考文献】

https://jhc.sjtu.edu.cn/~hongfeifu/manuscriptb.pdf

https://delphinuslab.com/wp-content/uploads/2023/04/zksummit-presentation-zkwasm-game-1.pdf

https://vitalik.ca/general/2021/01/05/rollup.html

https://vitalik.ca/general/2021/01/26/snarks.html

https://vitalik.ca/general/2022/08/04/zkevm.html

https://twitter.com/VitalikButerin/status/1588669782471368704

https://github.com/DelphinusLab/zkWasm

https://sapphireventures.com/blog/whats-up-with-webassembly-computes-next-paradigm-shift/

https://almanac.httparchive.org/en/2022/webassembly

https://www.circularise.com/blogs/zero-knowledge-proofs-explained-in-3-examples

https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/Put-WebAssembly-on-the-front-end-and-back-end-in-2023

https://github.com/privacy-scaling-explorations/zkevm-specs/blob/master/specs/introduction.md

https://academy.moralis.io/blog/breaking-down-eth-2-0-ewasm-and-evm-explained