开发者驳斥Vitalik：前提假设有误，RISC-V并非最佳选择

本文来自：以太坊开发者 levochka.eth

编译｜Odaily星球日报（ @OdailyChina ）； 译者｜Azuma（ @azuma_eth ）

编者按：

昨日，以太坊联合创始人 Vitalik 发布了一篇关于以太坊执行层升级的激进文章（详见《 Vitalik 激进新文：执行层扩容“不破不立”，EVM 未来必须被迭代 》），文中提到希望 用 RISC-V 取代 EVM 作为智能合约的虚拟机语言。

此文一出，立即在以太坊开发者社区激起了轩然大波，多位技术大佬对该方案表达了不同看法。文章发布后不久， 一线以太坊开发者 levochka.eth 在原文下文撰写长文反驳了 Vitalik 的观点，其认为 Vitalik 对证明系统及其性能进行了错误的前提假设，RISC-V 无法兼顾“可扩展性”和“可维护性”，或许并非最佳选择。

以下为 levochka.eth 原文内容，由 Odaily 星球日报编译。

请不要这样做。

这个计划并不合理，因为你对证明系统及其性能进行了错误的前提假设。

验证假设

据我理解，该方案的主要论点是“可扩展性”（scalability）和“可维护性”（maintainability）。

首先，我想讨论可维护性。

事实上， 所有 RISC-V zk-VM 都需使用“预编译”（precompiles）来处理计算密集型操作 。SP 1 的预编译列表可见于 Succinct 的文档，你会发现它几乎涵盖了 EVM 中所有重要的“计算性”操作码。

因此， 对基础层加密原语的所有修改都需要为这些预编译编写并审计新的“电路”，这是一个严重的限制。

确实，如果性能足够好， 执行客户端中“非 EVM”部分的可维护性可能会相对容易。我不确定性能是否会足够好，但我对这部分的信心较低，原因如下：

• “状态树计算”（state tree computation）确实可以通过友好型预编译（如 Poseidon）大幅加速。

• 但能否以优雅且可维护地方式处理“反序列化”（deserialization）尚不明确。

• 此外，还存在一些棘手细节（如 Gas 计量和各种检查），这些环节可能属于“区块评估时间”，但实际上更应归类为“非 EVM”部分，且这些部分往往更容易面临维护压力。

其次，关于可扩展性的部分。

我需要重申一点， RISC-V 不可能在不使用预编译的情况下处理 EVM 负载，绝对不行。

所以， 原文中“最终证明时间将主要由当前的预编译操作主导”这一说法虽然技术上正确，但过于乐观 —— 它假设未来不会有预编译，而事实上（在这个未来场景中），预编译仍会存在，且与 EVM 中计算密集型操作码（比如签名，哈希，以及可能出现的大型数模运算）完全一致。

关于“斐波那契”（Fibonacci）示例， 很难在不深入极底层细节的情况下做出判断 ，但其优势至少部分来自：

• “解释器”（Interpretation）与“执行开销”（execution overhead）的差异；

• 循环展开（减少 RISC-V 的“控制流”，Solidity 能否实现尚不确定，但即便单个操作码仍会因解释开销而产生大量控制流/内存访问）；

• 使用更小的数据类型；

这里我想指出，要实现第 1 点以及第 2 点优势，必须消除“解释开销”（interpretation overhead）。 这与 RISC-V 的理念一致， 但这不是我们目前讨论的 RISC-V，而是一种类似的“ （?）RISC-V” —— 它需要具备某些额外能力，比如支持合约概念。

问题来了

所以，这里存在一些问题。

• 若要提升可维护性，你需要一个能编译 EVM 的 RISC-V（带预编译）—— 这基本就是现状。

• 若要提升可扩展性，则需要完全不同的东西 —— 一种可能类似 RISC-V 的新架构，它能理解“合约”概念，兼容以太坊运行时限制，并能直接执行合约代码（且无“解释开销”）。

我现在假设你指的是第二种情况（因为文章的其余部分似乎暗示了这一点）。我需要提醒你注意，此环境外的所有代码仍将用当前 RISC-V zkVM 语言编写，这对维护有重大影响。

其他可能性

我们可以将字节码从高级 EVM 操作码中编译出来。编译器负责确保生成程序保持不变量，例如不会出现“栈溢出”（stack overflow）。我希望看到在普通 EVM 中展示这一点。正确编译的 SNARK 可以与合约部署指令一起提供。

我们还可以构建一个“形式化证明”（formal proof），证明某些不变量得以保留。据我所知，这种方法（而不是“虚拟化，virtualization”）已在某些浏览器上下文中使用。通过生成这种形式化证明的 SNARK，你也可以实现类似的结果。

当然了，最简单的选择是 硬着头皮去做……

构建一个最小的“链式”MMU

你在文章可能隐含表达了这一点，但请允许我提醒： 若想消除虚拟化开销，必须直接执行编译后的代码 —— 这意味着你需要以某种方式防止合约（现在是可执行程序）写入内核（非 EVM 实现）内存。

因此，我们需要某种“内存管理单元”（MMU）。传统计算机的分页机制可能不必要，因为“物理”内存空间近乎无限。此 MMU 应尽可能精简（ 因为它与架构本身处于同一抽象级别 ），但某些功能（如“交易原子性， atomicity of transactions” ）可移至该层。

此时，可证明的 EVM 将成为运行于此架构的内核程序。

RISC-V 可能不是最佳选择

有趣的是， 在所有这些条件下，适合这项任务的最佳“指令集体系结构”（ISA）可能不是 RISC-V，而是某中类似于 EOF-EVM 的东西 ，原因在于：

• “小型”操作码实际会导致大量内存访问，现有证明方法难以高效处理。

• 为减少分支开销，我们在近期的论文 Morgana 展示了如何以预编译级性能证明“静态跳转”（ static jumps，类似 EOF ）代码。

我的建议是，构建一个对证明友好的新架构，配备一个最小的 MMU，允许将合约作为单独的可执行文件运行。 我不认为它应是 RISC-V，而应是一种专为 SNARK 协议限制优化的新 ISA ，甚至部分继承 EVM 操作码子集的 ISA 都可能更好 —— 如我们所知，不管我们愿不愿意，预编译都会一直存在，所以 RISC-V 在这里并没有带来任何简化。