EVM 2.0：以证明为中心与以执行为中心的方法

EVM 2.0 - 以证明为中心 vs. 以执行为中心的方法

这篇文章来自 StarkWare。感谢 Vitalik Buterin、Tomasz Stańczak、Justin Drake、Ventali Tan、Federico Carrone (Fede)、Bobbin Threadbare、Morgan Thomas、Guilamme Ballet、Mamy Ratsimbazafy ( @mratsim)、Alexander Hicks、Kevaundray Wedderburn 和 Jeremy Bruestle 的仔细审查和评论。

概要

我们提供了选择下一个 EVM 的方法的前景。我们看到了三种潜在的途径，每种途径都呈现出不同的权衡：

1. 优先考虑快速执行和标准工具链，但牺牲快速 ZK 证明，
2. 优先考虑快速证明，但牺牲执行和标准工具链，以及
3. 一种两步法，先通过一个对区块链友好的 VM，然后再通过一个 ZK-VM，这也以牺牲标准工具链为代价（尽管不一定牺牲快速执行）。

几年前，Starknet 面临着类似的问题，并选择了第三种方案。我们相信这也是下一个 EVM 的最佳路径。至少，我们建议认真研究这个选项以及其他选项。

背景：重新思考以太坊执行层

以太坊——“世界计算机”——是第一个也是最成功的支持智能合约和通用计算的区块链。在最近的一对有影响力的帖子 [ 1, 2\ ]中，Vitalik 建议“我们用 RISC-V或另一个 VM 替换 EVM，这个 VM 是以太坊 ZK 证明器将用其编写的 VM。”

“我们应该使用哪个 VM？”这个问题是 StarkWare 在过去 7 年中一直在处理的问题，并且随着我们将越来越多的系统投入生产，我们的见解发生了转变和成熟。以下文档基于我们的集体经验，是 StarkWare 对围绕以太坊面临的重大架构问题的重要讨论的贡献：

以太坊的下一代执行层应该是什么样的？

这个问题跨越了多个维度：

• 执行效率：以太坊能否设计一种 VM，该 VM 允许更快的合约执行，降低用户的延迟，并更好地利用排序器和完整节点的资源？
• 可证明性：VM 是否应该针对与零知识证明的集成进行优化，从而通过 zk-rollup 或 ZK 证明的 Layer 1 实现可验证的执行和无需信任的可扩展性？
• 开发者体验、人体工程学和安全性：以太坊如何改进语言工具、调试和形式验证，同时确保执行模型安全、确定且易于推理？
• 开源：作为一个去中心化和无需许可的区块链，重要的是以太坊选择的任何堆栈都应具有足够的访问性和可用性，这意味着开源所有相关的核心组件。
• 向后兼容性：当前以太坊智能合约和系统的代码库是数千个开发者年的成果，其安全性得到了数千个审计年的支持。任何与现有 VM 显着不同的 VM 都将导致 (1) 无限期地维护两个 VM 和代码库，以及 (2) 成本增加和安全性降低。

下面，我们将分解以执行为中心和以证明为中心的 VM 设计之间的主要权衡，评估区块链安全执行的要求，并解释我们对将这些不同目标融合以形成统一架构的最佳方式的看法。

关键概念

与传统的计算环境不同，区块链执行必须遵守围绕安全性、确定性和可验证性的严格约束。这些约束会影响我们如何推理底层代码行为（例如，通过清理），运行时隔离（沙箱）以及 VM 是否针对零知识证明进行了优化。本节介绍这些核心概念，并解释为什么它们对于设计安全且可扩展的区块链执行环境至关重要。在介绍这些概念之后，我们将深入探讨针对下一代 EVM 的具体建议。

区块链执行安全

在执行区块链交易时，会出现安全问题，因为我们希望确保在各种平台上的平稳、安全和一致的执行。安全执行除其他外，还需要：

• 限制对主机资源的直接访问（例如，文件系统、系统调用）
• 防止状态转换之外的副作用
• 确保所有节点上的确定性行为
• 限制资源使用，可以通过 gas 计量（如以太坊上）或通过限制 VM 本身（如比特币上）来实现

ZK 友好性

ZK 友好的 VM 是一种在设计时考虑到高效的零知识证明生成的 VM。关键属性包括：

• 通过算术约束表示有效执行时的最小开销
• 高效的内存模型，避免动态访问模式或复杂的系统级功能
• 可追溯性，便于生成证明 witness
• 递归友好的执行，允许聚合证明

zkVM 是专门为高效的零知识证明生成而设计的虚拟机。它们优先考虑结构化计算、可追溯性和内存确定性，以实现简洁、可验证的证明。这些系统在实时或低延迟证明至关重要时是理想的选择，例如在 ZK-rollup 或链上可验证性中。

注意： 这篇简短且快速编写的文章省略了许多对讨论至关重要的细微差别，例如：

• 执行环境和需要证明的元数据（Patricia-Merkle 树与其他承诺方案）应在下一个 EVM 的选择中发挥重要作用。
• 这里介绍的每个主题都值得更多关注（我们假设 ZK 友好性基于哪个证明系统？应该支持多个证明系统和多个有限域吗？等等）

我们希望以太坊社区比我们在这里讨论的更深入地进行这项研究。

设计选项

在解释了区块链执行和 ZK 友好性带来的约束之后，我们继续研究可用的架构选择。 broadly，这些分为三类，每类都反映了不同的优先级：优化执行性能和开发者体验；优化可证明性；或通过分层方法结合两者的优势。每个选项都会在性能、安全性、工具、向后兼容性和未来可扩展性之间进行权衡。在接下来的章节中，我们将概述每种路径的含义，高亮显示著名的现实世界示例，并解释这些设计如何应对区块链环境独有的挑战。

选项 1：以执行为中心的区块链 VM

如果主要目标是创建一个新的区块链 VM，该 VM 提供高性能和开发者友好的工具，那么应该倾向于使下一个 EVM 尽可能接近已建立的工具链，该工具链在区块链世界之外得到很好的维护。这种方法优先考虑：

• 快速执行：在常用硬件上进行合约执行的本机级性能，以最大限度地减少区块生产和验证计算及延迟。请注意，快速执行需要优化的不仅仅是 CPU，因为在现代计算机中，CPU 的速度远快于内存和 I/O 操作。
• 开发者友好的工具：与流行的语言（区块链和非区块链语言）、IDE 支持、测试框架和调试工具的兼容性。

但是，上述区块链特定要求导致选择区块链堆栈或修改流行的标准堆栈，以确保满足独特的区块链要求，包括：

• 确定性、共识安全行为：所有合约执行都必须进行沙箱化，并在网络中的所有节点上产生确定性结果。执行必须与主机内部隔离。这禁止系统调用、文件访问和无限制的内存操作。
• 安全且可预测的资源使用：包括内置的 gas 计量、有界内存和受限的指令集——确保合约不会过度消耗资源或违反共识规则。
• 可升级和模块化设计：理想情况下，VM 允许以向后兼容的方式添加可升级的组件（例如，自定义预编译、密码学原语）。

为执行优化的现有区块链 VM 示例包括：

1. FuelVM（由 Fuel 网络使用）

• 可并行执行（通过 UTXO）
• 最小且可分析的 IR
• 具有明确的副作用控制的自定义语言 (Sway)
• 强烈关注模块化。

2. MoveVM（由 Aptos 和 Sui 使用）

• 面向资源的编程模型强制执行严格的所有权，并防止数据竞争或未经授权的状态突变。
• 没有不受限制的全局状态访问，从而减少了运行时错误并提高了安全性。
• Gas 计量直接集成在字节码级别。
• 极度安全和确定，尤其是在 DeFi 环境中。
• 良好的语言人体工程学和可分析性。

3. CosmWasm（用于 Cosmos 的 WASM，由 Cosmos 使用）

• 在 Cosmos SDK 链中运行编译为 WASM 的智能合约。
• 使用 Rust + no_std、编译为 WASM 的 C 或类似的编译路径，以确保合约无法访问不安全的系统 API。
• 由于 Cosmos 的 IBC（区块链间通信），支持多链部署。
• 内置 gas 记账和内存限制。
• 安全地利用 WASM 生态系统，同时在区块链原生运行时中对执行进行沙箱化。
• 非常适合已经熟悉 Rust 或 AssemblyScript 的开发者。

选项 2：以 ZK 证明为中心的语言/VM

如果以太坊的优先级是构建一个 ZK 友好的系统，那么需要一个专门为可证明性设计的 VM。这样的 VM 通常会最大限度地减少电路大小，删除寄存器（或大幅减少其数量），启用递归，并使用简单、良好约束的指令集。

为 ZK 证明优化的现有 VM 示例（适当披露：CairoVM 由 StarkWare 构建，StarkWare 是本文的共同作者）

1. CairoVM（由 Starknet 使用）

• 从头开始为基于 STARK 的证明系统设计
• 使用最小的、算术友好的指令集
• 避免诸如动态内存、间接跳转或系统调用之类的有问题的功能
• 无堆栈、无寄存器的架构
• 与 Sierra 配对，Sierra 是一种高级、类型化的中间表示，可提供安全性和防止未定义的行为。
• 高效地编译为可追踪，可证明的 CASM 代码。

2. Valida VM（由 Valida 项目使用）

• 31 位字段兼容性
• 用于从高级语言（包括 Rust、C、WASM 等）编译的 LLVM 后端。
• 最小指令集，由 3 度约束定义
• 无堆栈架构，具有直接的内存操作

3. Miden VM（由 Miden 项目使用）

• 具有用于字段和 32 位算术运算的本机指令的 ISA。
• 具有结构化控制流的汇编语言，以简化来自 WASM 的转移并启用 WASM 作为更高级别语言的中间表示的使用。
• 基于 MAST（Merkelized Abstract Syntax tree）的程序表示，以确保确定性链接和程序承诺。
• 支持在 VM 级别强制执行的多个隔离的执行上下文，包括根上下文和用户上下文之间的分离。
• 可配置的内核，无需修改 VM 的核心算术电路即可实现可扩展性。
• 专注于递归友好性和客户端证明（即，相对较低的内存要求）。

选项 3：结合两者：区块链安全语言 + ZK 友好 VM

如果以太坊的目标是结合 ZK 效率、执行性能和语言安全性，那么我们首先应该承认，目前没有在区块链之外广泛使用的、自然的框架。区块链相关的清理和沙箱化要求朝着一个方向发展，而 ZK 友好性则朝着另一个方向发展。明确地朝着一个方向发展将意味着另一个方向没有得到很好的服务。

这是 StarkWare 过去面临的问题，值得回顾我们的经验。在 2020 年夏天部署了我们的第一个产品——StarkEx 之后，我们想改进它并添加新功能。但是我们构建第一个系统的方式，通过手工编写多项式约束，无法安全地扩展。我们的第一个图灵完备的 VM 是 Cairo VM，它是一个 ZK-VM，但不是区块链安全的。在最初，我们设想只有 StarkWare 为其客户（Dex 和交易所）运行此 VM，因此，当我们为这些系统编写代码时，区块链的清理和沙箱化属性在内部强制执行。

但是，当我们选择将 Starknet 开发为通用 L2 时，区块链安全问题浮出水面。为了解决这个问题，我们选择了一种两步法：

• HLL → 安全的区块链中间表示（Sierra）：一种高级语言（如 Starknet 中的 Cairo，或以太坊中类似 Solidity 的语言）被编译为区块链安全的中间表示（Sierra）。Sierra 是一种结构化的、类型化的中间表示，专为安全性、确定性和清晰的语义而设计。
• Sierra → zkVM：Sierra 代码已经安全且经过 gas 计量，现在被编译为 ZK 友好的 VM 以进行执行，从而支持高效的证明生成。Starknet 使用 Cairo VM，但任何上述 ZK 友好的 VM 都适用于此目的。

这种方法也适合于快速的本机执行。为了获得这一点，可以将 Sierra 代码编译为本机执行（例如，在 x86 机器上）。实际上，Starknet 通过 LambdaClass 构建的 Cairo-native 编译器使用了这种方法。

这种两步法支持：

• 安全执行（并且，通过本机编译，还可以快速执行）
• 使用 STARK 和递归证明组合的高效证明
• 灵活的开发者人体工程学，对高级智能合约语言的支持越来越多

这种方法的优点是执行安全性和语言结构，而不会影响证明性能。这种方法的缺点是，它是一种非标准的（Starknet 区块链上下文之外的）编程语言和编译堆栈，这意味着开发者体验、现有工具、本机执行性能以及新开发者的入门难度比标准非区块链工具链更差。此外，必须建立 zkVM 和本机执行的等效性。

RISC-V 作为下一个 EVM-挑战和未解决的问题

回想一下，引发这篇文章的是 Vitalik 关于使用 RISC-V 作为下一个 EVM 的建议。引用 Vitalik 的话，他的建议

旨在大大提高以太坊执行层的效率，解决主要的可扩展性瓶颈之一，并且还可以大大提高执行层的简单性——实际上，这可能是唯一的方法。

RISC-V 的优点很多——它是一种通用 ISA，它是开源的，并且具有广泛的工具、良好的开发者体验以及对众多高级语言的支持。在模拟环境中运行绕过了一些与 gas 计量、不安全的操作码等有关的主要挑战。这可能会以牺牲一些生态系统优势为代价，因为大多数 RISC-V 库都假定不受限制的环境。

这导致了以下未解决的问题，我们建议在决定将其作为下一个 EVM 之前回答这些问题：

1. 经过沙箱化、清理和 gas 计量的 RISC-V VM 的速度有多快？
2. 新兴代码的 zk 证明效率如何？

结论

• 使用像 RISC-V 这样的现有架构需要进行重要的修改，这可能会损害快速执行的优势。
• ZK 证明通用 VM 可能不如 ZK 证明 ZK 友好 VM 效率高，并且比较这两种方法的效率应该是选择下一个 EVM 的研究过程的一部分（假设 ZK 证明是新 EVM 的目标之一）
• 应该将像 Sierra + Cairo 这样的两步法与其他两种方法一起考虑——纯标准 ISA（如 RiscV/MIPS/x86）和纯 ZK-VM（如 Valida/Cairo/Miden）。

• 原文链接： ethereum-magicians.org/t...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～