特别感谢 Fede、Danno Ferrin、Justin Drake、Ladislaus 和 Tim Beiko 提供的反馈与审阅

以太坊的目标是成为全球账本——一个承载人类资产与记录的平台，是金融、治理、高价值数据验证等应用的基础层。要实现这一目标，必须同时具备可扩展性与韧性。Fusaka 硬分叉计划将 L2 数据可用空间提升 10 倍，而当前拟议中的 2026 路线图也包含了类似规模的 L1 数据扩容。与此同时，“合并”（The Merge）已将以太坊升级为权益证明（PoS），客户端多样性迅速提升，ZK（零知识证明）可验证性和抗量子攻击性研发也在稳步推进，应用生态日益成熟强健。

本文的目标，是强调一项同样关键却常被低估的韧性（以及最终的可扩展性）要素：
协议的简洁性。

比特币最令人称道的一点，就是它的协议设计极其优雅且简单：

系统是一条区块链，由一系列区块组成。每个区块通过哈希与前一个区块相连。每个区块的有效性通过工作量证明（PoW）验证，也就是说……只需检查其哈希前几位是否为零。每个区块包含交易。交易要么花费通过挖矿获得的币，要么花费之前交易输出的币。基本就是这样。
即便是一个聪明的高中生，也有能力完全理解比特币协议的全部运作原理。而一个程序员甚至可以把开发比特币客户端当作业余项目来完成。

保持协议简单，带来了一系列关键优势，使比特币和以太坊有潜力成为可信中立、全球信任的基础层：

• 让协议逻辑更容易理解，扩大能够参与协议研究、开发和治理的群体，降低技术壁垒，避免“技术官僚阶层”主导协议。
• 大幅降低与协议集成的新基础设施（如新客户端、新证明器、新日志工具等）的开发成本。
• 减少协议长期维护成本。
• 降低出现灾难性漏洞的风险，无论是在协议规范还是实现代码中；同时也更易于验证协议不存在此类漏洞。
• 缩小社会攻击面：组件越少，可被特定利益方利用和把控的地方越少。

过去，以太坊在这方面做得并不理想（有时甚至是因为我个人的决策），这导致了我们过度的开发支出、@vbuterin/selfdestruct">各种安全风险以及研发文化的封闭性，而这些努力往往换来的只是虚幻的收益。
本文将阐述，五年后的以太坊如何有可能实现接近比特币般的简洁性。

简化共识层

3-slot finality（3槽终结性）模拟图 — 3sf-mini

新的共识层设计（过去被称为「beam chain」）旨在整合过去十年我们在共识理论、ZK-SNARK 开发、质押经济学等领域积累的经验，打造一个长期最优的以太坊共识层。这个新共识层，相较现有信标链（Beacon Chain），有望实现更高的简洁性。尤其体现在：

• 3槽终结性（3-slot finality）重构
  这一设计取消了“slot（槽）”与“epoch（周期）”的区分、委员会洗牌（committee shuffling）及其他与这些机制相关的协议规范细节（如同步委员会等）。一个基本版本的 3-slot finality，大约只需要 200 行代码即可实现。与当前 Gasper 协议相比，3-slot finality 也具备接近最优的安全性。

• 活跃验证者数量减少
  使得采用更简单的分叉选择规则（fork choice rule）变得更安全可行。

• 基于 STARK 的聚合协议
  意味着任何人都可以成为聚合者，无需担心信任聚合者、重复比特字段的过度费用等问题。虽然聚合加密本身存在一定复杂度，但这种复杂性高度封装，对协议整体系统性风险远低得多。

• 以上两点 也很可能支持更简单且更稳健的点对点（p2p）架构。

• 我们有机会重新思考验证者的进场、退出、提现、密钥切换、惰性惩罚等机制，并加以简化 —— 不只是降低代码行数（LoC），还包括提供更清晰的机制保障，例如更明确的「弱主观性（weak subjectivity）」期限。

共识层的优势在于，它与 EVM 执行相对解耦，因此我们有较大空间持续推进这些改进。
更具挑战的是：如何在执行层（execution layer）实现同样的简化。

简化执行层

以太坊虚拟机（EVM）的复杂度正不断攀升，而其中不少复杂性已被证明并非必要（很多情况下也与我个人的决策有关）：我们有一个 256 位虚拟机，过度优化了某些极为特定的加密形式，而这些形式如今正逐渐边缘化；还有一些预编译合约（precompiles）过度聚焦于极少使用的单一用例。

试图逐步修修补补地解决这些现实问题，行不通。移除 @vbuterin/selfdestruct">SELFDESTRUCT 指令就耗费了巨大精力，收效却有限。最近关于 EOF（EVM Object Format）的辩论，更显示了对虚拟机进行类似改动的困难。

因此，作为替代方案，我近期提出了一个更激进的思路：与其为了 1.5 倍提升不断做中等规模（但仍具破坏性）的改动，不如直接迁移到一个全新且远优且更简洁的虚拟机，争取 100 倍的收益。 就像「合并」（The Merge）一样，我们减少变革次数，但每一次都意义重大。具体而言，我建议用 RISC-V（或其他以太坊 ZK 证明器将使用的虚拟机）替代现有 EVM。这样我们将获得：

• 效率大幅提升：因为（在证明器内）智能合约可直接运行，无需解释器开销。Succinct 的数据表明，许多场景下性能可提升 100 倍以上。
• 极致简洁性：相较 EVM，RISC-V 规范极其简单。其他备选方案（如 Cairo）同样简洁。
• 继承 EOF 预期优势：如代码分段、更友好的静态分析、更大代码容量上限等。
• 开发者选择更多元： Solidity 和 Vyper 可支持编译到新虚拟机后端。若选择 RISC-V，主流语言开发者也能轻松移植代码。
• 大幅减少预编译需求：可能仅保留极少数高度优化的椭圆曲线运算（不过一旦量子计算普及，这些也将不复存在）。

这种路径的主要缺点是：与 EOF（已可立即部署）不同，新虚拟机需要更长时间才能让开发者受益。为缓解这一点，我们可以短期内适当引入一些小但高价值的 EVM 改进（如提高合约代码大小上限、增加 DUP/SWAP17-32 指令等）。

最终，这将赋予我们一个大幅简化的虚拟机。但最大的问题是：现有的 EVM 怎么办？

VM 过渡的向后兼容策略

在有意义地简化（甚至只是改善而不增加复杂度）以太坊虚拟机（EVM）任何部分时，最大的挑战在于：如何在实现目标的同时，保持对现有应用程序的向后兼容性。

首先要明确的一点是：并不存在一种单一的方式来界定“以太坊代码库”的范围（即使是在同一个客户端内部）。

目标是尽量缩小绿色区域的范围：也就是节点为了参与以太坊共识所必须运行的逻辑，包括计算当前状态、证明、验证、FOCIL（First-Order Consensus Integrity Layer）、基础版区块构建等。

橙色区域无法缩减：如果某个执行层特性（无论是虚拟机、预编译还是其他机制）被移除出协议规范，或者其功能被更改，关心历史区块处理的客户端仍然必须保留它——但重要的是，新客户端（比如ZK-EVMs或形式化验证器）可以完全忽略橙色区域。

新增的类别是黄色区域：这类代码对理解和解析当前链状态、以及进行最优区块构建来说非常重要，但它并不是共识的一部分。现有一个例子是 Etherscan（以及部分区块构建者）对ERC-4337用户操作的支持。如果我们用链上RISC-V实现来取代以太坊某些大型功能（例如EOA账户及其对各种旧交易类型的支持），那么尽管共识代码大幅简化，但一些专业节点仍可能会沿用原来的代码来解析这些功能。

重要的是，橙色和黄色区域属于“封装复杂度”，任何希望理解协议的人都可以跳过它们，实现以太坊的客户端也可以选择不实现它们，而且这些区域的Bug不会带来共识风险。这意味着，橙色和黄色区域的代码复杂度，带来的负面影响远小于绿色区域。

将代码从绿色区域转移到黄色区域，这个思路类似于苹果公司通过 Rosetta 翻译层来保障长期兼容性。

我提出（借鉴了@ipsilon/eof-ethereums-gateway-to-risc-v"> Ipsilon 团队最近的观点）以下虚拟机迁移流程（以EVM迁移至RISC-V为例，但同样适用于EVM迁移至Cairo，甚至未来迁移至更优VM）：

1. 所有新预编译必须用标准的链上RISC-V实现编写，这样可以让生态开始熟悉并使用RISC-V作为虚拟机。
2. 引入RISC-V，作为开发者与EVM并行的合约编写选项。协议原生支持RISC-V和EVM，两种语言编写的合约可以自由交互。
3. 将所有预编译（除椭圆曲线运算和KECCAK外）替换为RISC-V实现。我们通过一次硬分叉移除这些预编译，并同时把对应地址的代码（DAO分叉式）改为空转RISC-V实现。由于RISC-V VM极度简洁，即使仅做到这一步，整体也是净简化。
4. 实现一个用RISC-V编写的EVM解释器，并作为智能合约部署到链上。在初步发布数年后，现有EVM合约会通过这个解释器来处理。

完成第4步后，仍然会有很多“EVM实现”继续用于优化区块构建、开发工具和链上分析，但它们将不再属于关键共识规范。届时，以太坊共识将“原生”只理解RISC-V。

通过共享协议组件来简化

第三种、且最容易被低估的简化方法，就是尽可能在协议栈的各个部分共享统一标准。通常，没什么理由要在不同场景使用不同协议来做相同的事，但现实中这种情况仍然频繁出现，主要是因为协议路线图的不同部分彼此缺乏沟通。以下是一些通过“最大化组件共享”来简化以太坊的具体例子：

一个统一的纠删码

我们需要纠删码的场景有三处：

• 数据可用性抽样 - 客户端验证区块是否已发布
• 更快的 P2P 广播 - 节点能够在收到 n 块中的 n/2 后接受块，从而在减少延迟和冗余之间建立最佳平衡
• 分布式历史存储 - 以太坊的每一段历史记录都存储在许多块中，这样（i）这些块可以被独立验证，并且（ii）每组中的n/2个块可以恢复剩余的n/2个块，大大降低了任何单个块丢失的风险

如果我们在三个用例中使用相同的纠删码（无论是 Reed-Solomon、随机线性码还是其他），我们将获得一些重要的优势：

1. 最小化总代码行数
2. 提高效率 因为如果各个节点必须为其中一个用例下载块的各个部分（而不是整个块），则该数据可以用于另一个用例
3. 确保可验证性： 所有三个上下文中的块都可以根据根进行验证

如果确实需要不同纠删码，至少应保证“兼容性”：比如DAS场景中，横向使用Reed-Solomon，纵向使用随机线性码，但两者都基于相同的数学域。

一个统一的序列化格式

目前以太坊的序列化格式严格来说只是“半标准化”，因为数据可以用任意格式重新序列化并广播。唯一例外是交易签名哈希，这里需要规范格式用于哈希计算。
但未来序列化格式的标准化程度会进一步提升，原因有二：

• 全面账户抽象（EIP-7701）：虚拟机将能看到完整交易内容
• Gas上限提高：执行区块数据需打包进 blob

届时，我们有机会统一目前三个层面都需要的序列化方案：1）执行层；2）共识层；3）智能合约调用ABI。

我建议采用 SSZ（Simple Serialize），因为SSZ具备以下优势：

• 易于解码：包括在智能合约内部（基于4字节设计，边界情况少）
• 已广泛用于共识
• 与现有ABI高度相似：工具链迁移成本低

目前已有将更多组件迁移至SSZ的工作，我们在规划未来升级时，应充分考虑并利用这些进展。

一个统一的树结构

一旦我们从EVM迁移至RISC-V（或其他极简VM），十六进制Merkle Patricia树将成为证明区块执行的最大瓶颈，即使在平均场景下也是如此。迁移至基于更优哈希函数的二叉树，将极大提升证明器效率，并降低轻节点和其他场景的数据成本。

完成树结构迁移时，我们还应让共识层使用同一树结构，确保整个以太坊——共识与执行两层——均可用同一套代码访问和解析。

从现在到未来

简化与去中心化有许多相似之处。两者都是为了实现系统韧性这一更高目标所必须的上游条件。明确地重视简化，实际上需要一种文化上的转变。简化带来的好处往往在初期难以看见，但拒绝那些“光鲜亮丽的新功能”所带来的机会成本与额外工作量却是立竿见影的。然而，随着时间推移，简化的长期价值会变得愈加明显——比特币本身就是一个绝佳例子。

我建议我们借鉴 tinygrad 的做法，为以太坊的长期规范设定一个明确的代码行数上限目标，目标是让以太坊的共识关键代码尽量接近比特币那种极简风格。处理以太坊历史规则的代码仍然会存在，但应当被隔离在共识关键路径之外。与此同时，我们应当形成一种普遍的设计理念：在可能的情况下选择更简单的方案，优先采用封装式复杂性而非系统性复杂性，并倾向于那些能提供清晰可验证属性与保障的设计决策。

免责声明：

1. 本文转载自【vitalik】。所有版权归原作者 [vitalik] 所有。如对本次转载有异议，请联系 Gate Learn 团队，他们会及时处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. Gate Learn 团队将文章翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭翻译文章。