以太坊最终核心功能可能是 DA + Settlement + Consensus 的一个分布式账本定位，eWASM 以 zkWasm 的解决方案更适合构建应用。zkEVM 承前优化区块链生态，zkWasm 启后接受更多的开发可能。Build Rollups with zkWasm, not just Blockchains。

前言

去年 8 月份 Vitalik 发布《The different types of ZK-EVMs一文，对当前主流的扩容方案从兼容性和性能两个角度进行了整体对比（参见下图），引发整个社区诞生了诸多讨论和思考直到今天。

The different types of ZK-EVMs Overview

当前 zkVM 扩容的解决方案也都基本围绕着 zkEVM 的方案，因为对既有生态的延续和支持上其他的 zkVM 方案对承前有着一定 not compatible 的问题，然而在启后的问题上却会是 Web2 升级 Web3 的重要组成部分。

尤其是以 zkWasm 为代表的等兼容很多 C++、Rust、Go、AssemblyScript、C# 等语言的解决方案出现后，Web2 应用的账户系统升级成为了可能；可期的 zkEVM 向左承前，zkWasm 向右启后。

zkEVM 承前，zkWasm 启后

Rollup 时代不需要创造出过多的 chain, 因为 chain 扮演的是账本，也即账户层脱离于单独的应用，回归到通用层，所属权回归用户；chain 天然是这样一个载体，承担着 Data Availability（DA），Settlement 和 Consensus 的本质职能。

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）相信数据的真实性。零知识证明可以是交互式的，即证明者面对每个验证者都要证明一次数据的真实性；也可以是非交互式的，即证明者创建一份证明，任何使用这份证明的人都可以进行验证。

零知识证明发展史

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 的主要动机之一是为更多的编程语言（C++、Rust、Go 等）提供编译目标，允许开发人员使用更广泛的工具集开发新的 Web 应用程序或移植现有的应用程序。

Wasm 版图

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

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

zkWasm = zkp + WASM

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

zkWasm 生态

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

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

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

ETH 2.0 整体规划

虽然 eWASM 在近期的规划并未提及，但是 eWASM 能带来的好处也是被认可的。从一开始，EVM 就是为了强调正确性而非效率而设计的。这反映在网络上的所有节点必须完全准确地运行 EVM 这一事实上。

Wasm 虽然与 EVM 相似，但它是为 web 而发明的。与正确性不同的是，Wasm 强调的是效率和快速加载。以太坊开发者 Lane Rettig 表示，EVM 的创建不具备「大量的设计思想」，他认为 EVM 是从理论角度上而非实际角度设计的，因此，虽然它内部健全，但在现实世界中无法发挥最佳的作用。

Nick Johnson 同意这种看法，相比之下，Wasm 的编写更接近于实际的硬件指令，这使得它在翻译实际的编码逻辑时更加有效。事实上，Wasm 指令可直接将一对一映射到机器使用的指令，这将使性能大大提高。同时 Ewasm 可以减少甚至消除对预编译的需求，互操作性上将支持更多的语言，并将受益于比 EVM 更广泛的工具集。

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

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

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

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

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

然而，对于以太坊来说，这可能是个超长远期的规划，而且替换过程中的各种安全风险和现有生态的影响也不容小觑。也许这也是最新的规划中 eWASM 并未被过多提及的原因。

很多社区成员意识到以太坊最终核心功能是 DA + Settlement + Consensus 的一个分布式账本定位，这样对很多拓展性上的需求并不需要以太坊本身做出过多修改而带来其他未知风险。鱼和熊掌兼得的方式便是分层分工，将 eWASM 放在二层应该是一个更合理有效的解决方案。

尤其是与 zk 结合之后，zkWasm 的技术方案就能很好继承 eWASM 想要实现的效果，这样，通过 zkEVM+zkWasm 两套方案左右配合，向前可以继承传统的 EVM Dapp，向后可以拓展用更多语言编写的应用，进而实现真正的「承前启后」。

zkWasm = zkp + WASM