Vitalik：将重塑以太坊主网，五年内像比特币网络一样简洁

作者：Vitalik

以太坊的目标是成为世界账本：存储文明资产和记录的平台，金融、治理、高价值数据认证等的基础层。这需要两点：可扩展性和弹性。Fusaka硬分叉旨在将L2数据可用的数据空间增加10倍，目前提出的2026年路线图也包含L1的类似大幅增长。同时，合并将以太坊升级为权益证明，以太坊的 客户端多样性迅速提升，零知识证明和抗量子计算方面的工作正在推进，应用程序也越来越健壮。这篇文章的目标是阐明弹性（以及最终的可扩展性）的一个方面，该方面同样重要，但容易被低估：协议的简单性。

比特币的最大优点之一是其协议非常简单：

链由一系列区块组成。

每个区块通过哈希值与前一个区块连接。每个区块的有效性都通过工作量证明进行验证，这意味着……检查其哈希值的前几个字节是否为零。每个区块都包含交易。交易消耗的币要么是通过挖矿过程生成的，要么是由之前的交易输出的。差不多就是这样。即使是聪明的高中生也能完全理解比特币协议。程序员甚至可以把编写客户端作为业余爱好。保持协议简单可以带来许多好处，这些好处对于比特币或以太坊成为可信中立且全球值得信赖的基础层至关重要：它使协议更易于理解，从而增加了理解并参与协议研究、开发和治理的人数。它降低了协议被高门槛的技术官僚阶层所主导的风险。它大大降低了创建与协议接口的新基础设施的成本（例如新客户端、新证明器、新日志和其他开发工具）。降低长期协议维护成本它降低了规范本身和实现中出现灾难性错误的风险。它还能更容易地验证是否存在此类错误。减少了社会攻击面：活动部件更少，因此需要防范特殊利益的地方也更少。从历史上看，以太坊往往未能做到这一点（有时是出于我个人的考虑），这导致了我们过度的开发支出、各种安全风险，以及研发文化的孤立，而我们往往追求那些已被证明是虚幻的利益。这篇文章将描述 5 年后以太坊如何变得像比特币一样简单。

简化共识层

最终性的模拟新的共识层（原名“Beam 链”）旨在运用我们过去十年在共识理论、ZK-SNARK 开发、权益证明经济学以及其他领域积累的所有经验，为以太坊创建一个长期最优的共识层。该共识层的优势在于，它比现有的信标链要简洁得多。

具体而言：3 时隙最终性的重新设计移除了独立时隙和周期的概念、委员会改组以及协议规范中许多其他与有效处理这些机制相关的部分（以及其他细节，例如同步委员会）。

3 时隙最终性的基本实现大约只需要 200 行代码。与 Gasper 不同，3 时隙最终性也具有近乎最佳的安全性。一次活跃验证器数量的减少意味着使用更简单的分叉选择规则实现变得更加安全。基于 STARK 的聚合协议意味着任何人都可以成为聚合器，我们不必担心信任聚合器、为重复的位域支付过高的费用等。聚合密码学本身的复杂性虽然很大，但至少是高度封装的复杂性，对协议的系统性风险要低得多。上述两个因素也可能使p2p 架构更加简单、更加强大我们有机会重新思考验证者的进入、退出、退出、密钥转换、不活动泄露和其他相关机制如何工作，并简化它们——既可以减少代码行（LoC）的数量，也可以创建更清晰的保证，例如弱主观性时期是什么。共识层的优点在于它与 EVM 执行相对脱节，这意味着它有相对较大的空间来继续进行此类改进。更艰巨的挑战是如何在执行层实现同样的改进。

简化执行层

EVM 的复杂性日益增加，而这种复杂性的大部分已被证明是不必要的（在很多情况下是我的错）：一个 256 位虚拟机，针对如今越来越不相关的高度特定形式的加密进行了过度优化，并且预编译了几乎不使用的单一用例。试图零敲碎打地解决这些当前的现实问题根本行不通。移除SELFDESTRUCT操作码（仅仅是部分移除！）耗费了巨大的精力，却只获得了相对较小的收益。最近的 EOF 争论表明，对虚拟机进行同样的操作面临着巨大的挑战。作为替代方案，我最近提出了一个更激进的方法：与其为了获得 1.5 倍的收益而对 EVM 进行中等规模（但仍然具有颠覆性）的更改，不如为了获得 100 倍的收益而迁移到一个全新、更优秀、更简单的虚拟机。与合并一样，我们的颠覆性变更点较少，但我们使每一个变更都更有意义。具体来说，我建议将EVM 替换为 RISC-V，或者用其他可以编写以太坊 ZK 证明器的虚拟机。这样一来，我们：效率的显著提升，因为（在证明器内部）智能合约将直接执行，无需解释器开销。Succinct 的数据显示，在许多情况下，性能提升潜力可达 100 倍以上。

简单性上的彻底提升：RISC-V 规范与 EVM 相比极其简单。其他替代方案（例如 Cairo）也同样简单。所有促使 EOF 的好处（例如代码段、更易于静态分析、更大的代码大小限制）为开发者提供更多选择：Solidity 和 Vyper 可以添加后端以编译到新的虚拟机。同时，如果我们选择 RISC-V，那么使用更主流语言编写的开发者将能够将其代码移植到虚拟机。消除大多数预编译的需要，也许除了高度优化的椭圆曲线操作（尽管一旦量子计算机出现，这些操作也会消失）这种方法的主要缺点是，与目前已准备就绪的 EOF 不同，使用新的虚拟机，这些优势需要相对较长的时间才能惠及开发者。我们可以通过添加一些有限但高价值的 EVM 改进（例如，增加合约代码大小限制、DUP/SWAP17-32）来缓解这个问题，这些改进可以在短期内实现。这给了我们一个更简单的虚拟机。

主要的挑战是：我们该如何处理现有的 EVM？VM 过渡的向后兼容策略有意义地简化（甚至改进而不复杂化）EVM 的任何部分的最大挑战是如何在实现预期目标与保持现有应用程序的向后兼容性之间取得平衡。首先要理解的重要一点是：没有单一的方法来描述什么是“以太坊代码库”（即使在单个客户端中）。

目标是最小化绿色区域：节点为了参与以太坊共识必须运行的逻辑：计算当前状态、证明、验证、FOCIL、“原始”区块构建。橙色区域不能减少：如果执行层功能（无论是虚拟机、预编译器还是其他机制）从协议规范中删除，或者其功能发生改变，那么关心处理历史区块的客户端将必须保留它 - 但重要的是，新客户端（或 ZK-EVM 或正式证明者）可以完全忽略橙色区域。

新的类别是黄色区域：这些代码对于理解和解释当前的区块链，或优化区块构建非常有价值，但不构成共识。目前存在的一个例子是Etherscan（以及一些区块构建器）对 ERC-4337 用户操作的支持。如果我们用链上 RISC-V 实现替换某些重要的以太坊功能（例如 EOA，包括它们对各种旧交易类型的支持），那么共识代码将会大大简化，但专用节点可能会继续使用完全相同的代码来解释它们。重要的是，橙色和黄色区域代表了封装的复杂性，任何想要了解协议的人都可以跳过它们，以太坊的实现也可以自由地跳过它们，并且这些区域中的任何错误都不会构成共识风险。这意味着橙色和黄色区域中的代码复杂性比绿色区域中的代码复杂性具有更少的负面影响。将代码从绿色区域移动到黄色区域的想法在本质上与 Apple通过 Rosetta 等翻译层确保长期向后兼容性的方式类似。

受到Ipsilon 团队最近文章的启发，我建议对 VM 进行以下更改流程（以 EVM 到 RISC-V 为例，但也可以用于例如 EVM 到 Cairo，甚至 RISC-V 到更好的版本）：我们要求所有新的预编译代码都必须使用规范的链上 RISC-V 实现来编写。这样可以让生态系统预热，并开始使用 RISC-V 作为虚拟机。我们引入了 RISC-V，供开发者在 EVM 之外编写合约。该协议原生支持 RISC-V 和 EVM，使用其中一种编写的合约可以自由交互。我们将所有预编译（除椭圆曲线运算和 KECCAK 之外，因为它们需要真正最佳的速度） 替换为 RISC-V 实现。也就是说，我们进行一次硬分叉，移除预编译，同时将该地址的代码（DAO-fork 风格）从空代码更改为 RISC-V 实现。RISC-V 虚拟机非常简单，即使我们到此为止，也算是一种纯粹的简化。用 RISC-V 实现了一个 EVM 解释器（由于 ZK-provers 的存在，这一直在进行中），并将其作为智能合约推送到链上。在首次发布几年后，现有的 EVM 合约将切换到通过该解释器进行处理。

一旦步骤 4 完成，许多“EVM 的实现”将保留下来，用于优化区块构建、开发者工具和链分析，但它们将不再需要成为关键共识规范的一部分。以太坊共识将“原生”地仅理解 RISC-V。通过共享协议组件进行简化降低总体协议复杂度的第三个也是最容易被低估的方法是尽可能在堆栈的不同部分共享一个标准。在不同的地方使用不同的协议来做同样的事情通常几乎没有好处，甚至根本没有好处，但这种模式无论如何都会出现，主要是因为协议路线图的不同部分彼此之间不通信。

以下是一些具体的例子，我们可以通过确保组件在整个堆栈中最大限度地共享来简化以太坊。

单一共享擦除码

我们在三个地方需要擦除码：
数据可用性采样——客户端验证区块是否已发布更快的 P2P 广播- 节点在收到 n 个区块中的 n/2 个后即可接收一个区块，从而在延迟减少和冗余之间实现最佳平衡分布式历史存储——以太坊的每一段历史都存储在许多块中，这样 (i) 每个块都可以独立验证，(ii) 每组中的 n/2 个块可以恢复剩余的 n/2 个块，从而大大降低了任何单个块丢失的风险如果我们在这三个用例中使用相同的擦除码（无论是 Reed-Solomon、随机线性码还是其他），我们将获得一些重要的优势：尽量减少代码行数。提高效率，因为如果各个节点必须为某个用例下载区块的各个部分（而不是整个区块），那么该数据可以用于另一个用例。确保可验证性：所有三个上下文中的块都可以根据根进行验证。如果使用不同的擦除码，它们至少应该是兼容的擦除码：例如，对于 DAS 块，水平方向使用 Reed-Solomon 码，垂直方向使用随机线性码，其中这两个代码在同一字段上操作。

单一共享序列化格式

目前，以太坊的序列化格式可以说只是半神圣化的，因为数据可以以任何格式重新序列化和广播。唯一的例外是交易的签名哈希，因为哈希计算需要规范的格式。然而，未来序列化格式的神圣化程度将进一步提高，原因有二：通过完整的帐户抽象（EIP-7701），完整的交易内容将对虚拟机可见随着 gas 限制的提高，执行区块数据将需要放入 blob 中当这种情况发生时，我们就有机会协调当前需要它的以太坊的三个层的序列化：（i）执行层，（ii）共识层，（iii）智能合约调用 ABI。我建议我们使用SSZ，SSZ 是：易于解码，包括智能合约内部（因为其基于 4 字节的设计且边缘情况较少）已在共识层广泛使用与现有 ABI 高度相似，使得工具相对容易适应我们已在努力更全面地迁移到 SSZ；在规划未来的升级时，我们应该牢记这些努力，并在此基础上继续发展。
一棵共享树

一旦我们从 EVM 迁移到 RISC-V（或其他小型虚拟机），即使在一般情况下，十六进制 Merkle Patricia 树也将成为证明区块执行的最大瓶颈。迁移到基于更优化哈希函数的二叉树将大大提高证明器效率，并降低轻客户端和其他用例的数据成本。当我们这样做时，我们也应该对共识层使用相同的树形结构。这确保了以太坊的所有内容，包括共识和执行，都可以使用相同的代码进行访问和解释。从这里到那里简单性在很多方面与去中心化相似。两者都是人性目标的上游。明确重视简单性需要一些文化变革。其好处往往难以察觉，额外付出的努力和放弃一些亮眼功能的代价也显而易见。

然而，随着时间的推移，其好处会越来越明显——比特币本身就是一个很好的例子。我建议我们效仿 tinygrad，为以太坊的长期规范设定一个明确的最大代码行数目标，目标是使以太坊共识关键代码接近比特币的简洁程度。与处理以太坊历史规则相关的代码将继续存在，但应将其置于共识关键代码路径之外。除此之外，我们应该秉持一种普遍的理念：尽可能选择更简单的方案，优先考虑封装的复杂性而非系统性复杂性，并做出能够提供清晰易懂的属性和保证的设计选择。