Vitalik分析:如何让5年后的以太坊变得像比特币一样简单
以太坊的愿景是成为全球性的"世界账本",这意味着它必须同时具备可扩展性和韧性。市面上关于如何扩容、如何提升性能的讨论已经很多了,但今天我想聚焦一个同样关键、却常常被低估的要素:
协议的简单性
没错,就是“简单”。Fusaka 硬分叉计划要把 L2 的数据可用空间扩大10倍,2026年的路线图也打算为 L1 带来类似的提升。与此同时,以太坊已经顺利过渡到权益证明(PoS),客户端多样性在迅速改善,零知识(ZK)验证和量子抗性研究也在稳步推进,整个应用生态越来越稳健。这些进展固然可喜,但如果我们只盯着这些“加法”,忽略了协议本身的复杂度,那就像在给一栋结构日益臃肿的大楼不断加盖新楼层——风险会越来越大。
让我们先看看比特币。比特币最令人叹服的地方,就是那种近乎优雅的简洁性:

1. 一条由区块组成的链,每个区块通过哈希值链接到前一个区块。
2. 区块的有效性通过工作量证明(PoW)来验证——说白了,就是检查哈希值的前几位是不是零。
3. 每个区块里包含若干笔交易,这些交易的“币”要么来自挖矿奖励,要么来自上一笔交易的输出。
仅此而已!一个聪明的高中生就能完全搞懂比特币是怎么运作的,一个程序员甚至可以把写一个比特币客户端当作业余项目来玩。
这种简单性,为比特币(以及以太坊)成为可信、中立、全球性的基础层,带来了无可比拟的优势:
1. 易于理解
2. 降低开发成本
3. 减少维护负担
4. 减少错误风险
5. 缩小攻击面
需要坦诚的是,以太坊历史上在某些决策上(包括我个人参与的部分)未能始终坚持简洁导向。导致的结果是:开发成本过高,安全风险增加,研发文化也变得有些封闭。而那些复杂功能带来的收益,最终往往被证明是虚幻的。这篇文章的核心想法是:五年后的以太坊,能否在简洁性上向比特币看齐?
简化共识层

新的共识层设计(历史上叫“信标链”),其目标就是利用过去十年在共识理论、ZK-SNARK开发、质押经济学等领域积累的经验,构建一个长期来看最优、同时更简单的共识机制。相比现在的信标链,新设计做了大幅简化:
1. 3-slot 最终性设计
2. 减少活跃验证者数量
3. 基于 STARK 的聚合协议
4. 简化 P2P 架构
5. 重新设计验证者机制
共识层有个天然优势:它和EVM执行层相对独立。这意味着我们有很大的空间对它进行持续改进。真正的挑战,其实在于执行层如何实现类似的简化。
简化执行层
EVM的复杂性是逐年递增的,其中很多复杂性后来看完全没必要(有些决策确实是我的失误)。比如:256位的虚拟机过度优化了某种特定形式的密码学——这种形式现在看已经过时了;还有那些预编译(precompiles),为了某一类用例做了极致优化,却大多数时候无人问津。
逐个去给这些问题打补丁,效果是有限的。比如移除SELFDESTRUCT操作码,耗费了大量心力,换来的收益却很小。最近关于EOF(EVM Object Format)的激烈争论,也暴露了类似的困境。
最近有一个更激进的思路浮出水面:与其对EVM做那些中等规模(但依然具有破坏性)的改动、只换来1.5倍的收益,我们不如直接迁移到一个更优秀、更简单的虚拟机上,去争取100倍的收益。就像“The Merge”一样,我们减少破坏性变更的次数,但让每一次变更都变得更有意义。
具体建议是:
用RISC-V,或者以太坊ZK证明器已经使用的某种虚拟机,来替换EVM。
1. 效率大幅提升
2. 简单性大幅改进
3. 支持EOF的动机
4. 更多开发者选择
5. 移除大部分预编译
主要缺点也很明显:和已经准备就绪的EOF不同,换上新虚拟机后,开发者要真正享受到它的好处,需要一段时间的积淀。我们可以通过短期先落地一些高价值的EVM改进(比如增加合约代码大小限制、增加DUP/SWAP17-32等操作码)来缓解这个问题。
总之,我们会得到一个更简单的虚拟机。但核心挑战摆在那里:
如何处理现有的EVM生态?
虚拟机过渡的向后兼容策略
简化(或者说在不增加复杂性的前提下改进)EVM,最大的难点就在于:如何平衡新目标与现有应用之间的向后兼容性。
第一步需要想清楚的是:以太坊的代码库(哪怕只看一个客户端)并不是只有一种定义方式。

我们的目标是尽量缩小
绿色区域
橙色区域
新增的
黄色区域
举例来说:Etherscan和一些区块构建者会支持ERC-4337用户操作。如果我们用链上RISC-V实现替换掉某些以太坊功能(比如EOA及其支持的旧交易类型),共识代码会显著简化。但专用的节点依然可以用原有的代码来解析这些历史数据。
橙色和黄色区域的复杂性,是
封装复杂性
把代码从“绿色区域”搬到“黄色区域”的思路,有点像苹果通过Rosetta翻译层来保证长期向后兼容的做法。
受Ipsilon团队近期文章的启发,我梳理了一个虚拟机变更的流程(以EVM到RISC-V为例,但这个流程也适用于EVM到Cairo,或者RISC-V到更优的虚拟机):
1. 要求新的预编译提供链上RISC-V实现
2. 引入RISC-V作为开发者选项
3. 替换大部分预编译
4. 在RISC-V中实现EVM解释器

走完第4步之后,虽然大量的“EVM实现”依然会为了优化区块构建、开发者工具和链分析而存在,但它们已经不再是关键共识规范的一部分了。以太坊共识,将“原生地”只理解RISC-V。
通过共享协议组件简化
还有第三种降低协议复杂度的方式,也是最容易被低估的一种:
在协议栈的不同部分,尽可能共享统一的标准。
统一纠删码

我们在三种场景下都需要纠删码:
1. 数据可用性采样
2. 更快的P2P广播
3. 分布式历史存储
如果这三种场景使用同一种纠删码(不论是Reed-Solomon码还是随机线性码),好处是明摆着的:
1. 最小化代码量
2. 提高效率
3. 确保可验证性
退一步说,即使因为某些原因不能使用完全相同的纠删码,至少也要保证它们的兼容性——比如,数据可用性采样用的水平Reed-Solomon码,和垂直随机线性码在同一个域中操作。
统一序列化格式

以太坊目前的数据序列化格式只有部分是标准化的,因为数据可以用任意格式重新序列化后再广播。唯一的例外是交易签名哈希,它必须用标准格式进行哈希。未来,序列化的标准化程度会进一步提高,原因有二:
1. 完全账户抽象(EIP-7701)
2. 更高的Gas限制
到那时,我们正好有机会去统一以太坊三个层级(执行层、共识层、智能合约调用ABI)的序列化格式。
我个人的建议是使用
SSZ
1. 它易于解码:即使在智能合约内部也能轻松解码,因为SSZ基于4字节设计,几乎没有边缘情况。
2. 它已经在共识层被广泛使用了。
3. 它和现有的ABI非常相似,工具改造起来也会相对容易。
其实已经有向SSZ全面迁移的努力在进行中,我们在规划未来升级时,应该认真考虑并延续这些已有的成果。
统一树结构

如果我们真的从EVM迁移到了RISC-V(或者其他最小化的虚拟机),那么十六进制的Merkle Patricia树,将成为证明区块执行效率的最大瓶颈——即使在平均情况下也是如此。迁移到基于更优哈希函数的二叉树,会显著提升证明器的效率,同时也能降低轻客户端等场景下的数据成本。
既然要迁移,那应该借这个机会,让共识层也使用同样的树结构。这样一来,以太坊的共识层和执行层,就可以通过同一套代码来访问和解析数据了。
从现在到未来
“简单性”在很多方面和“去中心化”地位相似,它们都是实现“韧性”这个终极目标的上游条件。但真正把“简单性”提到一个受重视的高度,需要整个社区在文化上有所转变。因为简单性的收益往往难以量化,而为此付出的额外努力、放弃某些炫酷功能时的阵痛却是立竿见影的。然而,所有的收益都会随着时间慢慢浮现——比特币本身,就是最好的例子。
我建议效仿tinygrad的做法,为以太坊的长期规范设定一个明确的
最大代码行数目标
总而言之,我们应该把“选择更简单的方案”作为一条核心原则来坚守:优先选择“封装的复杂性”,而非“系统性的复杂性”;优先做出那些能提供清晰属性和明确保证的设计选择。