再见EVM?Vitalik要为以太坊动一场“心脏手术”

ETH-2.11%
ARB1.75%
OP1.03%

作者:灰色龙虾,深潮 TechFlow

以太坊开发者有一个心照不宣的习惯:能不碰 EVM,就不碰 EVM。

过去几年,每当链上需要一个新的密码学操作,开发者的第一反应不是在 EVM 里实现它,而是申请增加一个"预编译合约",一种绕过虚拟机、直接在协议层硬编码的快捷方式。

3 月 1 日,Vitalik Buterin 在 X 上发了一篇长帖,把这层窗户纸彻底捅破了。他的原话大意是:以太坊的全部意义在于它的通用性,如果 EVM 不够好,那我们就应该正面解决这个问题,造一个更好的虚拟机。

他给出了两把具体的手术刀。

第一刀:换"数据结构"

第一个改动针对以太坊的状态树。这东西你可以理解为以太坊的"账本索引系统",每次有人查余额、验证交易,都要沿着这棵树往下翻。

问题是,现在这棵树太"胖"了。以太坊用的是一种叫"六叉 Keccak 默克尔帕特里夏树"的结构(名字长得像咒语)。Vitalik 提出的 EIP-7864,要把它换成一棵更简洁的二叉树。

打个比方:原来你查一条数据,要在一个六岔路口反复选方向,现在改成只有左和右。结果是什么?默克尔分支长度直接缩短到原来的四分之一。对轻客户端来说,验证数据需要的带宽大幅下降。

但 Vitalik 不满足于只换树的形状。他还要换"树叶上的字体",也就是哈希函数。候选方案有两个:Blake3 和 Poseidon。

  • Blake3 能带来稳定的提速;
  • Poseidon 更激进,理论上能把证明效率再提升几十倍,但安全性还需要更多审计。

值得一提的是,这个方案实际上取代了此前社区讨论多年的 Verkle Trees。Verkle 曾经是 2026 年硬分叉的首选方案,但因为其底层依赖的椭圆曲线密码学面临量子计算威胁,从 2024 年年中开始逐渐失宠,二叉树方案趁势上位。

第二刀:换"虚拟机",把 EVM 变成一个智能合约

第二个改动更大胆,也更有争议:长期用 RISC-V 架构替换 EVM。

RISC-V 是一种开源指令集,原本跟区块链没什么关系,但现在几乎所有 ZK 证明系统内部都在用它。Vitalik 的逻辑很直接:既然证明器已经在说 RISC-V 这门语言了,那为什么虚拟机还要说另一种,然后中间再加个翻译?把翻译层拿掉,效率自然上去。

一个 RISC-V 解释器只需要几百行代码。Vitalik 说,这才是区块链虚拟机该有的样子。

他规划了三步走:第一步,先用新虚拟机跑预编译合约,把现有 80% 的预编译用新 VM 代码重写;第二步,允许开发者直接部署新虚拟机的合约,与 EVM 并行运行;第三步,EVM 退役,但不是消失——它会被改写成一个运行在新虚拟机上的智能合约,实现完全的向后兼容。

老车主不用换车。只是发动机悄悄换了,方向盘还是那个方向盘。

这两件事加在一起有多重要?Vitalik 给了一个数字:状态树和虚拟机合计占据了以太坊证明瓶颈的 80% 以上。换句话说,如果不动这两块,以太坊在 ZK 时代的扩容就是在原地踏步。

Arbitrum 不同意:你不能因为仓库用叉车,就让快递员也开叉车

但这不是一个所有人都点头说好的故事。

去年 11 月,Arbitrum 的核心开发团队 Offchain Labs 发表了一篇详细的技术反驳。四位研究员的核心观点是:RISC-V 确实适合做 ZK 证明,但它不适合做合约的"交付格式"。

他们提出了一个关键区分,**“交付指令集”(dISA)和"证明指令集"(pISA)不需要是同一个东西。**你的仓库用叉车搬货效率最高,但不意味着快递员也要开叉车送到你家门口。

Offchain Labs 主张用 WebAssembly(WASM)做合约层,理由相当扎实:WASM 在标准硬件上执行效率高,而大多数以太坊节点并不运行 RISC-V 芯片,强行切换意味着需要模拟器;WASM 有成熟的类型安全验证机制;WASM 的工具链生态已经在数十亿执行环境中经过实战检验。

更关键的是,他们不只是嘴上说说。Offchain Labs 已经在 Arbitrum 上跑通了一个原型:用 WASM 作为合约的交付格式,然后编译成 RISC-V 进行 ZK 证明。两层各干各的活,互不干扰。

他们还提了一个值得深思的风险:ZK 证明领域的技术变化极快,最近 RISC-V 的实现已经从 32 位切换到了 64 位。如果现在就把 RISC-V 焊死在以太坊 L1 上,万一两年后出现更好的证明架构呢?把赌注押在一个正在快速移动的靶心上,不是以太坊的风格。

一个更大的背景:L2 们开始"断奶"

理解这次提案,还需要一个更宏观的背景。

就在一个月前,Vitalik 公开质疑以太坊是否还需要一个"专门的 L2 路线图",引发了 L2 阵营的集体回应。Espresso Systems 的 CEO Ben Fisch 对 CoinDesk 说了一句很到位的话:Vitalik 的意思其实是,L2 最初的目的就是帮以太坊扩容,现在以太坊自己要变快了,L2 的定位自然要变。

有意思的是,L2 们非但没有恐慌,反而开始主动"去以太坊化"。OP Labs 的联合创始人 Jing Wang 把 L2 比作独立的网站,以太坊则是底层的开放结算标准。Polygon 的 CEO Marc Boiron 说得更直白:真正的挑战不是扩容,而是为支付这样的真实场景打造独特的区块空间。

换句话说,Vitalik 这次对执行层的大改,是一个更大趋势的技术注脚:以太坊正在收回对自身核心能力的控制权,而 L2 们则在被迫或者说终于找到自己独立存在的理由。

这事能成吗?

Vitalik 自己也坦承,虚拟机替换目前还没有开发者社区的广泛共识状态树改革更成熟,EIP-7864 已经有具体的草案和推进团队。但 RISC-V 替换 EVM?这还停留在"路线图"阶段,离写进代码还有距离。

不过 Vitalik 上周给了一个让人印象深刻的表态:以太坊已经在飞行中换过一次喷气发动机了(指 The Merge),接下来还能再换大约四次——状态树、精简共识、ZK-EVM 验证、虚拟机替换。

以太坊 Glamsterdam 升级预计 2026 年上半年落地,Hegota 紧随其后。两次硬分叉的具体内容还没最终敲定,但状态树改革和执行层优化是确定的主线。

以太坊的故事从来不是"能不能"的问题。从 PoW 转 PoS,从 L1 all-in 到 Rollup 中心,它已经证明了自己有在万米高空拆卸引擎的能力和胆量。

这次要动的是更深层的东西——不是加新功能,而是把旧地基挖开重浇。这到底是一场深谋远虑的翻新,还是一个越修越复杂的无底洞?答案大概要到 2027 年才见分晓。

但至少有一件事是确定的:以太坊不打算在 ZK 时代当一个"打补丁的老系统"。至于补丁该怎么拆、发动机该换成什么型号,这场争论本身,可能比结论更有价值。

免责声明:本页面信息可能来自第三方,不代表 Gate 的观点或意见。页面显示的内容仅供参考,不构成任何财务、投资或法律建议。Gate 对信息的准确性、完整性不作保证,对因使用本信息而产生的任何损失不承担责任。虚拟资产投资属高风险行为,价格波动剧烈,您可能损失全部投资本金。请充分了解相关风险,并根据自身财务状况和风险承受能力谨慎决策。具体内容详见声明

相关文章

昨日美国比特币现货ETF净流入2.25亿美元,以太坊ETF净流出1080万美元

3月4日,美国比特币现货ETF净流入达2.252亿美元,其中贝莱德IBIT流入最多,富达FBTC流出较多;以太坊现货ETF则净流出1080万美元,富达FETH流出最多。

GateNews14 分钟前

Vitalik Buterin 呼吁以太坊将使命扩展到金融之外

简要 Vitalik Buterin 表示以太坊应构建一个超越去中心化金融的全栈生态系统。 他敦促开发者支持隐私工具、去中心化协调和开放基础设施。 一些观察人士认为以太坊应专注于 DeFi,而其他人则支持该项目的多元发展。

Decrypt 31 分钟前

数据:若 ETH 突破 2,060 美元,主流 CEX 累计空单清算强度将达 8.9 亿美元

ChainCatcher 消息,据 Coinglass 数据显示,若 ETH 突破 2,060 美元,主流 CEX 累计空单清算强度将达 8.9 亿美元。反之,若 ETH 跌破 1,866 美元,主流 CEX 累计多单清算强度将达 7.96 亿美元。

GateNews1小时前

ETH 跌破 1950 USDT

Gate News bot 消息,Gate 行情显示,ETH 跌破 1950 USDT,现价 1949.45 USDT。

Crypto Radar1小时前

以太坊的Vitalik Buterin:打造“避难所”技术,别试图成为苹果或谷歌

Thạch Sanh

Tap Chi Bitcoin1小时前

分析:以太坊验证者入场队列激增至约340万枚ETH,或由大型投资者驱动

随着大型投资者选择质押以太坊以获取收益,ETH验证者入场队列激增至340万枚,形成最长待处理记录,预计等待时间60天。这一变化反映出市场对收益生成的强烈需求,特别是大型企业和交易所的参与者。

GateNews1小时前
评论
0/400
暂无评论
交易,随时随地
qrCode
扫码下载 Gate App
社群列表
简体中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)