Simplifying the L1

Special thanks to Fede, Danno Ferrin, Justin Drake, Ladislaus and Tim Beiko for feedback and review

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

Ethereum aims to be the world ledger: the platform that stores civilization's assets and records, the base layer for finance, governance, high-value data authentication, and more.

以太坊的目标是成为世界分类账：存储文明资产和记录的平台，金融、治理、高价值数据认证等的基础层。

This requires two things: scalability and resilience .

这需要两件事：可扩展性和弹性。

The Fusaka hard fork aims to increase the amount of data space available to L2 data by 10x, and the current proposed 2026 roadmap includes a similarly large increase for the L1.

Fusaka 硬分叉的目标是将 L2 数据可用的数据空间量增加 10 倍，当前提出的 2026 年路线图包括 L1 的类似大幅增加。

Meanwhile, the merge upgraded Ethereum to proof of stake, Ethereum's client diversity has improved rapidly, work on ZK verifiability , work quantum resistance is progressing, and applications are getting more and more robust .

同时，合并将以太坊升级为权益证明，以太坊的客户端多样性迅速提高，ZK可验证性、抗量子性工作正在取得进展，应用程序也越来越健壮。

The goal of this post will be to shine the light on an aspect of resilience (and ultimately scalability) that is just as important, and easy to undervalue: the protocol's simplicity .

这篇文章的目标是阐明弹性（以及最终的可扩展性）的一个同样重要且容易被低估的方面：协议的简单性。

One of the best things about Bitcoin is how beautifully simple the protocol is :

比特币最好的事情之一就是它的协议非常简单：

There is a chain, which is made up of a series of blocks.

有一条链，它由一系列块组成。

Each block is connected to the previous block by a hash.

每个块通过哈希值连接到前一个块。

Each block's validity is verified by proof of work, which means...

每个区块的有效性都通过工作量证明来验证，这意味着......

checking that the first few bytes of its hash are zeroes.

检查其散列的前几个字节是否为零。

Each block contains transactions.

每个区块都包含交易。

Transactions spend coins that were either created through the mining process, or outputted by previous transactions.

交易花费的硬币要么是通过采矿过程创建的，要么是先前交易输出的。

And that's pretty much it.

差不多就是这样了。

Even a smart high school student is capable of fully wrapping their head around and understanding the Bitcoin protocol.

即使是聪明的高中生也能够完全理解并理解比特币协议。

A programmer is capable of writing a client as a hobby project.

程序员有能力将编写客户端作为业余爱好项目。

Keeping the protocol simple brings a number of benefits that are key to Bitcoin or Ethereum being a credibly neutral and globally trusted base layer:

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

Historically, Ethereum has often not done this (sometimes because of my own decisions), and this has contributed to much of our excessive development expenditure, all kinds of security risk , and insularity of R&D culture, often in pursuit of benefits that have proven illusory.

从历史上看，以太坊常常没有这样做（有时是因为我自己的决定），这导致了我们过多的开发支出、各种安全风险以及研发文化的狭隘性，往往是为了追求被证明是虚幻的利益。

This post will describe how Ethereum 5 years from now can become close to as simple as Bitcoin .

这篇文章将描述 5 年后以太坊如何变得接近比特币一样简单。

The new consensus layer effort (historically called the "beam chain") aims to use all of our learnings in consensus theory, ZK-SNARK development, staking economics and other fields over the last ten years to create a long-term optimal consensus layer for Ethereum.

新的共识层工作（历史上称为“束链”）旨在利用过去十年来我们在共识理论、ZK-SNARK开发、质押经济学和其他领域的所有知识，为以太坊创建一个长期最优的共识层。

This consensus layer is well-positioned to be much simpler than the status quo beacon chain.

这个共识层比现状的信标链简单得多。

Particularly:

特别是：

The nice thing about the consensus layer is that it is relatively disconnected from EVM execution, which means that there is a relatively wide latitude to continue to make these types of improvements.

共识层的好处是它与 EVM 执行相对脱节，这意味着继续进行此类改进有相对广泛的自由度。

The harder challenge is how to do the same on the execution layer.

更困难的挑战是如何在执行层做同样的事情。

The EVM is increasingly growing in complexity, and much of that complexity has proven unnecessary (in many cases my own fault): a 256-bit virtual machine that over-optimized for highly specific forms of cryptography that are today becoming less and less relevant, and precompiles that over-optimized for single use cases that are barely being used.

EVM 的复杂性日益增加，其中大部分复杂性已被证明是不必要的（在很多情况下是我自己的错）：256 位虚拟机针对高度特定形式的密码学进行了过度优化，而如今这些密码学的相关性越来越低，而预编译则针对几乎不使用的单一用例进行了过度优化。

Attempting to address these present-day realities piecemeal will not work.

试图零敲碎打地解决这些当今的现实是行不通的。

It took a huge amount of effort to (only partially!) remove the SELFDESTRUCT opcode, for a relatively small gain.

我们付出了巨大的努力（仅部分！）删除了 SELFDESTRUCT 操作码，但获得的收益却相对较小。

The recent EOF debate shows the challenges of doing the same thing to the VM.

最近的 EOF 争论表明了对虚拟机做同样的事情所面临的挑战。

As an alternative I recently proposed a more radical approach: instead of making medium-sized (but still disruptive) changes to the EVM for the sake of a 1.5x gain, perform a transition to a new and much better and simpler VM for the sake of a 100x gain.

作为替代方案，我最近提出了一种更激进的方法：不是为了获得 1.5 倍的增益而对 EVM 进行中等规模（但仍然具有破坏性）的更改，而是为了获得 100 倍的增益而过渡到新的、更好、更简单的 VM。

Like the Merge, we have fewer points of disruptive change, but we make each one much more meaningful.

与合并一样，我们的颠覆性变革点较少，但我们使每一个变革都变得更有意义。

Specifically, I suggested we replace the EVM with either RISC-V , or another VM that is the VM that Ethereum ZK-provers will be written in.

具体来说，我建议我们用 RISC-V 或另一个 VM 替换 EVM，该 VM 是以太坊 ZK-provers 将写入的 VM。

This gives us:

这给了我们：

The main downside of this approach is that unlike EOF, which is ready today, with a new VM it will take a relatively longer amount of time for these benefits to reach developers.

这种方法的主要缺点是，与目前已准备就绪的 EOF 不同，使用新的 VM，开发人员需要相对较长的时间才能获得这些好处。

We can mitigate this by also adding some limited but high-value EVM improvements (eg.

我们还可以通过添加一些有限但高价值的 EVM 改进来缓解这一问题（例如

contract code size limit increase , DUP/SWAP17-32) that could be implemented in the short term.

合约代码大小限制增加，DUP/SWAP17-32）可以在短期内实施。

This gives us a much simpler VM.

这给了我们一个更简单的虚拟机。

The main challenge is: what do we do with the existing EVM?

主要挑战是：我们如何处理现有的 EVM？

The biggest challenge with meaningfully simplifying (or even improving without complexifying ) any part of the EVM is how to balance accomplishing the desired goals with preserving backwards compatibility for existing applications.

有意义地简化（甚至在不复杂化的情况下进行改进）EVM 任何部分的最大挑战是如何在实现预期目标与保留现有应用程序的向后兼容性之间取得平衡。

The first thing that is important to understand is: there isn't one single way to delineate what is the "Ethereum codebase" (even within a single client) .

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

The goal is to minimize the green area : the logic that nodes have to run in order to participate in Ethereum consensus: computing the current state, proving, verifying, FOCIL, "vanilla" block building.

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

The orange area cannot be decreased : if an execution layer feature (whether a VM, a precompile, or another mechanism) is either removed from the protocol spec, or its functionality is altered, clients that care about processing historical blocks will have to keep it - but, importantly, new clients (or ZK-EVMs, or formal provers) can simply ignore the orange area entirely.

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

The new category is the yellow area : code that is very valuable for understanding and interpreting the chain today, or for optimal block building , but is not part of consensus.

新类别是黄色区域：对于理解和解释当今的链或对于最佳区块构建非常有价值的代码，但不是共识的一部分。

One example that exists today is Etherscan (and some block builders ') support for ERC-4337 user operations.

目前存在的一个例子是 Etherscan（以及一些区块构建器）对 ERC-4337 用户操作的支持。

If we replace some large Ethereum feature (eg.

如果我们替换一些大型以太坊功能（例如。

EOAs, including their support for all kinds of old transaction types) with an onchain RISC-V implementation, then consensus code would be considerably simplified, but specialized nodes would likely continue using their exact same code to interpret them.

EOA（包括对各种旧交易类型的支持）通过链上 RISC-V 实现，那么共识代码将大大简化，但专用节点可能会继续使用完全相同的代码来解释它们。

Importantly, the orange and yellow areas are encapsulated complexity , anyone looking to understand the protocol can skip them, implementations of Ethereum are free to skip them, and any bugs in those areas do not pose consensus risks .

重要的是，橙色和黄色区域封装了复杂性，任何想要了解协议的人都可以跳过它们，以太坊的实现可以自由地跳过它们，并且这些区域中的任何错误都不会造成共识风险。

This means that code complexity in the orange and yellow areas has far fewer downsides than code complexity in the green area.

这意味着橙色和黄色区域中的代码复杂性比绿色区域中的代码复杂性的缺点要少得多。

The idea of moving code from the green area to the yellow area is similar in spirit to how Apple ensures long-term backwards compatibility through translation layers like Rosetta .

将代码从绿色区域移动到黄色区域的想法在本质上类似于 Apple 通过 Rosetta 等转换层确保长期向后兼容性的方式。

I propose, inspired by recent writings from the Ipsilon team , the following process for a VM change (using EVM to RISC-V as an example, but it could also be used for eg.

受 Ipsilon 团队最近著作的启发，我建议采用以下 VM 更改流程（以 EVM 到 RISC-V 为例，但它也可以用于例如：

EVM to Cairo, or even RISC-V to something even better):

EVM 到 Cairo，甚至 RISC-V 到更好的东西）：

Once step 4 is done, many "implementations of the EVM" will remain and be used for optimized block building, developer tooling and chain analysis purposes, but they will no longer need to be part of the critical consensus spec.

一旦完成第 4 步，许多“EVM 的实现”将保留并用于优化区块构建、开发人员工具和链分析目的，但它们将不再需要成为关键共识规范的一部分。

Ethereum consensus would "natively" understand only RISC-V .

以太坊共识“本机”仅理解 RISC-V。

The third and most easily underrated way to reduce total protocol complexity is to share one standard across different parts of the stack as much as possible.

降低总协议复杂性的第三种也是最容易被低估的方法是尽可能在堆栈的不同部分之间共享一个标准。

There is typically very little or no benefit to using different protocols to do the same thing in different places, but such patterns appear anyway, largely because different parts of protocol roadmapping don't talk to each other.

使用不同的协议在不同的地方做同样的事情通常没有什么好处或没有好处，但这种模式无论如何都会出现，很大程度上是因为协议路线图的不同部分不会相互通信。

Here are a few specific examples of places where we can simplify Ethereum by ensuring that components are maximally shared across the stack.

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

If we use the same erasure code (whether Reed-Solomon, random linear codes, or otherwise) across the three use cases, we get some important advantages:

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

If different erasure codes are used, they should at least be compatible erasure codes: for example, a Reed-Solomon code horizontally and a random linear code vertically for DAS chunks, where the two codes operate over the same field.

如果使用不同的纠删码，它们至少应该是兼容的纠删码：例如，对于DAS块，水平方向是里德-所罗门码，垂直方向是随机线性码，这两个码在同一字段上操作。

Ethereum's serialization format is today arguably only semi-enshrined, because the data can be re-serialized and broadcasted in any format.

以太坊的序列化格式今天可以说只是半神圣的，因为数据可以重新序列化并以任何格式广播。

The only exception is signature hashes for transactions, as there a canonical format is required for hashing.

唯一的例外是交易的签名哈希，因为哈希需要规范的格式。

In the future, however, the degree of enshrinement of serialization formats will increase further, for two reasons:

然而，在未来，序列化格式的供奉程度将进一步提高，原因有二：

When this happens, we have an opportunity to harmonize serialization across the three layers of Ethereum that currently need it: (i) execution layer, (ii) consensus layer, (iii) smart contract calling ABI.

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

There are efforts to migrate more fully to SSZ already; we should keep these efforts in mind when planning future upgrades, and build on them.

已经在努力更全面地迁移到 SSZ；在规划未来的升级时，我们应该牢记这些努力，并以此为基础。

Once we migrate from EVM to RISC-V (or an alternative minimal VM), the hexary Merkle Patricia tree will become by far the largest bottleneck to proving block execution, even in the average case.

一旦我们从 EVM 迁移到 RISC-V（或替代的最小 VM），即使在平均情况下，六进制 Merkle Patricia 树也将成为迄今为止证明块执行的最大瓶颈。

Migrating to a binary tree based on a much more optimal hash function will greatly improve prover efficiency, in addition to reducing data costs for light clients and other use cases.

迁移到基于更优化的哈希函数的二叉树将大大提高证明者的效率，此外还可以降低轻客户端和其他用例的数据成本。

When we do this, we should also use the same tree structure for the consensus layer.

当我们这样做时，我们也应该为共识层使用相同的树结构。

This ensures that all of Ethereum, consensus and execution alike, can be accessed and interpreted using the same code.

这确保了所有以太坊，无论是共识还是执行，都可以使用相同的代码进行访问和解释。

Simplicity is in many ways similar to decentralization.

简单性在很多方面与去中心化相似。

Both are upstream of a goal of resilience.

两者都是弹性目标的上游。

Explicitly valuing simplicity requires some cultural change.

明确重视简单性需要进行一些文化变革。

The benefits are often illegible, and the cost of extra effort and turning away some shiny features is felt immediately.

好处往往是难以辨认的，额外的努力和拒绝一些闪亮功能的成本是立即感受到的。

However, as time goes on, the benefits become more and more evident - and Bitcoin itself is an excellent example.

然而，随着时间的推移，好处变得越来越明显——比特币本身就是一个很好的例子。

I propose that we follow the lead of tinygrad , and have an explicit max line of code target for the long-term Ethereum specification , with the goal of making Ethereum consensus-critical code close to as simple as Bitcoin.

我建议我们效仿tinygrad，为以太坊长期规范制定明确的最大代码行目标，目标是让以太坊共识关键代码接近比特币一样简单。

Code that has to do with processing Ethereum's historical rules will continue to exist, but it should stay outside of consensus-critical code paths.

与处理以太坊历史规则有关的代码将继续存在，但它应该位于共识关键代码路径之外。

Alongside this, we should have a general ethos of choosing the simpler option where possible, favoring encapsulated complexity over systemic complexity, and making design choices that provide clearly legible properties and guarantees.

除此之外，我们应该有一种普遍的精神，即尽可能选择更简单的选项，优先考虑封装的复杂性而不是系统的复杂性，并做出提供清晰易读的属性和保证的设计选择。