在短期内，解决以太坊 L1 扩展的主要瓶颈将通过即将发布的 EIP 来解决，例如块级访问列表、延迟执行、分布式历史存储和 EIP-4444。在中期，我们通过无状态化和 ZK-EVM 来解决更多问题。从长远来看，影响以太坊 L1 扩展的主要因素将是：数据可用性抽样和历史存储协议的稳定性；保持区块生产的竞争市场及 ZK-EVM 的证明能力。我将论证用 RISC-V 替代 ZK-EVM 解决了保持区块生产的竞争市场及 ZK-EVM 的证明能力中的关键瓶颈。 这是 Succinct ZK-EVM 用于证明以太坊执行层不同部分所需的周期数的表格。有四个部分占用了大量的时间：deserialize_inputs、initialize_witness_db、state_root_computation 和 block_execution。initialize_witness_db 和 state_root_computation 都与状态树有关，而 deserialize_inputs 是指将区块和见证数据转换为内部表示的过程。因此，实际上，超过 50% 的时间是与见证大小成正比的。这些部分可以通过将当前的 keccak 16 分支 Merkle Patricia 树 替换为使用 对证明友好的哈希函数 的二叉树来大幅优化。剩下的是 block_execution，它占用了今天证明周期的大约一半。如果我们想要将总的证明效率提高 100 倍，那么不可避免地我们需要至少提高 50 倍的 EVM 证明效率。我们可以做的一个方法是尝试创建更高效的 EVM 实现，以减少证明周期。我们还可以注意到，今天的 ZK-EVM 证明器 已经是通过证明已经编译为 RISC-V 的 EVM 实现 来工作的，接下来可以直接给智能合约开发者访问这个 RISC-V 虚拟机。 实现这种提案有多种方式。最不具破坏性的方式是支持两种虚拟机，并允许合约以任意一种编写。这两种类型的合约将可以访问相同的功能：持久存储（如 SLOAD 和 SSTORE）、持有 ETH 余额的能力、进行和接收调用的能力等。EVM 和 RISC-V 合约可以自由地相互调用；从 RISC-V 的视角来看，调用 EVM 合约就像是进行一个带有特殊参数的系统调用；而接收消息的 EVM 合约将把它解读为 CALL 操作。一种更激进的协议级别方案是将现有的 EVM 合约 转换为调用一个用 RISC-V 编写的 EVM 解释器合约，这个解释器合约执行现有的 EVM 代码。也就是说，如果一个 EVM 合约有代码 C，且 EVM 解释器位于地址 X，那么该合约将被替换为顶层逻辑，当外部调用时，调用 X，传入参数 (C, D)，然后等待返回值并转发。如果 EVM 解释器本身调用该合约，要求执行 CALL 或 SLOAD/SSTORE，则该合约会执行这些操作。 一种中间方案是采用第二种方案，但为此创建一个明确的协议功能 —— 基本上就是将虚拟机解释器概念正式化，并要求其逻辑用 RISC-V 编写。EVM 将是第一个，但也可能会有其他虚拟机（例如 Move 可能是一个候选者）。第二和第三个提案的一个关键好处是，它们大大简化了执行层的规范 —— 实际上，考虑到即便是像移除 SELFDESTRUCT 这样的增量简化也非常困难，这种类型的思路可能是唯一可行的路径。Tinygrad 有一条硬性规定，永远不超过 10000 行代码；一个优化的区块链基础层应该能够轻松满足这些要求，甚至做得更小。beam chain 的努力在大幅简化以太坊共识层方面具有巨大潜力。但要让执行层也看到类似的进展，这种激进的变化可能是唯一可行的路径。【原文为英文】\n原文链接