简化 L1

2025 年 5 月 3 日 查看所有文章 简化 L1

特别感谢 Fede, Danno Ferrin, Justin Drake, Ladislaus 和 Tim Beiko 的反馈和审阅

以太坊的目标是成为世界账本：一个存储文明资产和记录的平台，金融、治理、高价值数据认证等的基础层。这需要两个条件：可扩展性（scalability）和韧性（resilience）。 Fusaka 硬分叉旨在将 L2 数据的可用数据空间增加 10 倍，并且当前提议的 2026 年路线图 包括对 L1 的类似大幅增长。 同时， The Merge 将以太坊升级到 PoS，以太坊的 客户端多样性 正在迅速提高，ZK 可验证性 的工作，以及量子抗性的工作正在取得进展，并且应用程序越来越 健壮。

本文的目标是阐明韧性（以及最终的可扩展性）的一个方面，它同样重要，但很容易被低估：协议的简单性。

关于比特币（Bitcoin），最好的事情之一就是其协议的 精美简洁：

存在一条链，它由一系列区块组成。每个区块通过哈希连接到前一个区块。每个区块的有效性都通过工作量证明进行验证，这意味着……检查其哈希的前几个字节是否为零。每个区块都包含交易。交易花费通过挖矿过程创建的，或由先前交易输出的 coins。基本上就是这样。即使是聪明的高中生也能够完全理解比特币协议。程序员可以将编写客户端作为业余项目。

保持协议的简单性带来了许多好处，这些好处对于比特币或以太坊成为一个 可信的中立 且全球信任的基础层至关重要：

• 它使协议更易于推理，增加了理解并可以参与 协议研究、开发和治理的人数。 它降低了协议被具有高准入门槛的技术官僚阶层所支配的风险。
• 它大大地降低了创建与协议交互的新基础设施的成本 (例如，新客户端，新 prover，新的日志记录和其他开发者工具)。
• 它降低了长期协议维护成本
• 它降低了灾难性 bug 的风险，无论是在规范本身还是在实现中。 它还使得_验证_不存在此类 bug 变得更容易。
• 它减少了社会攻击面：活动部件更少，因此需要防范特殊利益的地方也更少。

从历史上看，以太坊通常没有这样做（有时是因为我自己的决定），这导致了我们过度的开发支出，各种 各样 的 安全 风险 和 R&D 文化的封闭性，通常是为了追求已被证明是虚幻的好处。 本文将描述 5 年后的以太坊如何才能变得像比特币一样简单。

简化共识层

在 3sf-mini 中模拟 3-slot 最终性

新的共识层工作（历史上称为“beam chain”）旨在利用我们在过去十年中在共识理论、ZK-SNARK 开发、质押经济学和其他领域的所有经验，为以太坊创建一个长期最佳的共识层。 这个共识层能够比当前的信标链简单得多。 特别是：

• 3-slot 最终性 的重新设计消除了单独的 slots 和 epochs、委员会洗牌，以及与有效处理这些机制相关的协议规范的许多其他部分（以及其他细节，例如 sync committees）。 一个基本的 3-slot 最终性实现可以用 大约 200 行代码完成。 与 Gasper 不同，3-slot 最终性也具有接近最佳的安全属性。
• 在任何给定时间减少活跃验证器的数量意味着使用更简单的分叉选择规则的实现会更安全。
• 基于 STARK 的聚合协议意味着任何人都可以成为聚合器，我们不必担心信任聚合器，为重复的 bitfields 支付过高的费用等等。 聚合密码学本身的复杂性非常高，但至少它是高度 封装的复杂性，这降低了对协议的系统性风险。
• 以上两个因素也可能实现更简单和更强大的 p2p 架构。
• 我们有机会重新思考验证器进入、退出、提款、密钥转换、不活动泄漏和其他相关机制如何工作，并简化它们 - 既要减少代码行数 (LoC) 的意义上，也要创建更清晰的保证，例如，什么是弱主观性周期。

共识层的好处是它与 EVM 执行的连接相对较少，这意味着有相当大的自由度可以继续进行这些类型的改进。 更艰巨的挑战是如何在执行层上做同样的事情。

简化执行层

EVM 的复杂性日益增加，其中许多复杂性已被证明是不必要的（在许多情况下是我自己的错误）：一个 256 位的虚拟机，它过度优化了当今越来越不相关的特定形式的密码学，以及过度优化了几乎没有使用的单个用例的预编译。

试图零敲碎打地解决这些现实问题是行不通的。 花了大量的精力来（仅部分地！） 移除 SELFDESTRUCT 操作码，获得的收益相对较小。 最近的 EOF 辩论表明了对 VM 执行相同操作的挑战。

作为替代方案，我最近提出了一个更激进的方法：与其为了 1.5 倍的收益而对 EVM 进行中等大小（但仍然具有破坏性）的更改，不如为了 100 倍的收益而过渡到一个新的、更好、更简单的 VM。 就像 The Merge 一样，我们具有更少的破坏性变更点，但是我们使每个变更都更有意义。 具体来说，我建议我们 将 EVM 替换为 RISC-V，或者以太坊 ZK-provers 将用其编写的另一个 VM。 这为我们提供了：

• 效率的根本性提高，因为（在 prover 中）智能合约执行将直接运行，而无需解释器开销。 来自 Succinct 的数据显示，在许多情况下，性能可能会提高 100 倍以上。
• 简单性的根本性提高：与 EVM 相比，RISC-V 规范 非常简单。 替代方案 (例如 Cairo) 同样简单。
• 所有促使 EOF 的好处（例如，代码段、更友好的静态分析、更大的代码大小限制）
• 开发人员有更多选择：Solidity 和 Vyper 可以添加后端来编译为新的 VM。 同时，如果我们选择 RISC-V，那么用更主流的语言编写的开发人员将能够将他们的代码移植到 VM。
• 消除了对大多数预编译的需求，也许除了高度优化的椭圆曲线运算（尽管一旦量子计算机出现，这些运算也会消失）

这种方法的主要缺点是，与今天就可以使用的 EOF 不同，新 VM 需要相对较长的时间才能使这些好处惠及开发人员。 我们可以通过添加一些有限但高价值的 EVM 改进（例如 合约代码大小限制增加，DUP/SWAP17-32）来缓解这种情况，这些改进可以在短期内实施。

这为我们提供了一个更简单的 VM。 主要的挑战是：我们如何处理现有的 EVM？

VM 转换的向后兼容性策略

有意义地简化（甚至 改进而不复杂化）EVM 的任何部分的最大挑战是如何平衡实现所需目标与为现有应用程序保留向后兼容性。

首先要了解的重要一点是：没有_一种单一的_方式来描述什么是“以太坊代码库”（即使在单个客户端中）。

目标是最大程度地减少绿色区域：节点 必须 运行才能参与以太坊共识的逻辑：计算当前状态、证明、验证、FOCIL、“vanilla”区块构建。

橙色区域无法减少：如果从协议规范中删除执行层功能（无论是 VM、预编译还是其他机制），或者其功能发生更改，那么关心处理历史区块的客户端将必须保留它 - 但重要的是，新客户端（或 ZK-EVM，或形式 prover）可以完全忽略橙色区域。

新的类别是黄色区域：对于 理解和解释 当今的链或 最佳区块构建 非常有价值，但不是共识的一部分的代码。 今天存在的一个例子是 Etherscan（以及一些 区块构建器）对 ERC-4337 用户操作的支持。 如果我们将一些大型以太坊功能（例如 EOAs，包括它们对各种旧交易类型的支持）替换为链上 RISC-V 实现，那么共识代码将大大简化，但专门的节点可能会继续使用它们完全相同的代码来解释它们。

重要的是，橙色和黄色区域是 封装的复杂性，任何想要了解协议的人都可以跳过它们，以太坊的实现可以自由地跳过它们，并且这些区域中的任何 bug 都不会构成共识风险。 这意味着橙色和黄色区域中的代码复杂性比绿色区域中的代码复杂性带来的不利影响要小得多。

将代码从绿色区域移动到黄色区域的想法在精神上类似于 Apple 如何 通过像 Rosetta 这样的翻译层 确保长期的向后兼容性。

我建议，受到 Ipsilon 团队最近文章的启发，对于 VM 更改的以下流程（以 EVM 到 RISC-V 为例，但它也可以用于例如 EVM 到 Cairo，甚至 RISC-V 到更好的东西）：

1. 我们要求任何新的预编译都使用规范的链上 RISC-V 实现来编写。 这可以让生态系统热身并开始使用 RISC-V 作为 VM。
2. 我们引入 RISC-V 作为一个选项，供开发人员与 EVM 一起编写合约。 该协议原生支持 RISC-V 和 EVM，并且以一种或另一种方式编写的合约可以自由地相互交互。
3. 我们替换所有预编译，除了椭圆曲线运算和 KECCAK（因为这些需要真正最佳的速度），用 RISC-V 实现。 也就是说，我们进行一次硬分叉，删除预编译，同时将该地址的代码（DAO-fork-style）从空更改为 RISC-V 实现。 RISC-V VM 非常简单，即使我们停在这里，这也是一个净简化。
4. 我们用 RISC-V 实现一个 EVM 解释器（无论如何都会发生，因为 ZK-provers），并将其作为智能合约推送到链上。 在初始版本发布几年后，现有的 EVM 合约切换到通过通过该解释器运行来处理。

一旦完成步骤 4，许多“EVM 的实现”将保留并用于优化的区块构建、开发人员工具和链分析目的，但它们不再需要成为_关键共识规范的一部分。_ 以太坊共识将“原生”地只理解 RISC-V。

通过共享协议组件简化

减少总协议复杂性的第三种也是最容易被低估的方法是在堆栈的不同部分尽可能多地共享一个标准。 通常，使用不同的协议在不同的地方做相同的事情几乎没有好处，但这种模式仍然会出现，主要是因为协议路线图的不同部分没有相互沟通。 以下是一些具体的例子，说明我们可以通过确保组件在堆栈中最大程度地共享来简化以太坊。

一个单一的共享纠删码

我们需要在三个地方使用纠删码：

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

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

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

如果使用了不同的纠删码，它们至少应该是_兼容的_纠删码：例如，水平方向的 Reed-Solomon 码和垂直方向的随机线性码用于 DAS 块，其中这两个码在同一字段上运行。

一个单一的共享序列化格式

如今，以太坊的序列化格式可以说是半确定的，因为数据可以用任何格式重新序列化和广播。 唯一的例外是交易的签名哈希，因为那里需要规范格式进行哈希处理。 但是，将来，序列化格式的确定性程度将会进一步提高，原因有两个：

• 有了 完全帐户抽象 (EIP-7701)，整个交易内容将对 VM 可见
• 随着 gas 限制的提高，执行区块数据将需要放入 blobs

发生这种情况时，我们有机会协调当前需要它的以太坊的三个层中的序列化：（i）执行层，（ii）共识层，（iii）智能合约调用 ABI。

我建议我们使用 SSZ。 SSZ 是：

• 易于解码，包括在智能合约中（因为其基于 4 字节的设计和更少的边缘情况）
• 已在共识层中广泛使用
• 与现有的 ABI 高度相似，使得工具相对容易适应

已经有 努力 迁移 更完全地迁移到 SSZ； 在计划未来的升级时，我们应该牢记这些努力，并在此基础上进行构建。

一个单一的共享树

一旦我们从 EVM 迁移到 RISC-V（或另一种最小 VM），即使在平均情况下，十六进制 Merkle Patricia 树也将成为证明区块执行的最大瓶颈。 迁移到 基于更佳哈希函数的二叉树 将大大提高 prover 效率，此外还可以降低轻客户端和其他用例的数据成本。

当我们这样做时，我们还应该对共识层使用相同的树结构。 这可确保可以使用相同的代码访问和解释以太坊的所有内容，无论是共识还是执行。

从这里到那里

简单性在许多方面与去中心化相似。 两者都在韧性的目标之上。 明确地重视简单性需要一些文化变革。 好处通常不明显，并且立即感受到额外努力和拒绝一些闪亮功能的成本。 但是，随着时间的流逝，好处变得越来越明显 - 而比特币本身就是一个很好的例子。

我建议我们 遵循 tinygrad 的领导，并为长期以太坊规范设置一个明确的最大代码行数目标，目的是使以太坊共识关键代码接近比特币一样简单。 必须处理以太坊历史规则的代码将继续存在，但应保留在共识关键代码路径之外。 与此同时，我们应该普遍秉持尽可能选择更简单选项的精神，偏爱封装的复杂性而不是系统性的复杂性，并做出提供清晰可读属性和保证的设计选择。