聊一下 Lean Ethereum 这两年的演变。 这个概念最早叫 Beam Chain，是 Justin Drake 在 24 年 Devcon（曼谷）上提出的。当时这个 talk 提前很久就在预热，号称是以太坊共识层的下一次重大升级，我正好在现场，可以说是整个 Devcon 最火爆的一场。核心内容是：抗量子 + 更快的 finality + 共识层 SNARK 化（zkVM）。而且因为 Beacon Chain 五年下来积累了不少技术债，方案是不在现有客户端上改，而是从零开发全新的共识客户端。 后来因为 "Beam" 这个名字有商标的争议，项目被迫改名。25 年 7 月，Justin 借着以太坊十周年把它升级成了 "Lean Ethereum"：不再只是共识层，而是 lean consensus / lean data / lean execution 三条线，覆盖整个 L1 技术栈。原来的 Beam Chain 变成了其中的 lean consensus。这个方向吸引了一批新客户端团队同步开发，比如 Ream (Rust)、Zeam (Zig)、Qlean (C++)、Lantern (C) 等，并且已经在专门的 pq-devnet 上做了好几轮多客户端 interop 测试。我们也在持续跟进，每周参加 Ethereum PQ 的 weekly meeting 了解进展。 最近一个大变化是 Vitalik 发了这条 post（nitter.net/VitalikButerin/status/…），给 Lean Ethereum 正式定了性： 它是以太坊的第三次重大迭代——The Merge 是第二次，这次几乎所有主要协议组件都会被替换：recursive STARKs 验证取代重放执行、全面抗量子、共识重构、多维 gas、新的 state 类型等等，但它不再是一次性的大升级，而是未来三到四年通过多个 fork，把规划的功能一点一点集成进主网，尽量不打扰现有应用——路径上更像 The Merge 而不是推倒重来。 Vitalik 还专门提到了 client architecture 会有变化。在我看来，既然走的是"主网渐进式 fork"路线，大概率意味着这些升级最终要落在现有主网客户端上，而不是当年设想的"全新客户端整体替换"。 如果这个判断成立，那当初为 Beam Chain 组建的那批新客户端团队，角色可能会从"未来的主网客户端"转变为"探索和研究的先遣队"——他们在 devnet 上验证过的 PQ 签名、聚合方案、SNARK 化状态转换，会以规范和经验的形式反哺现有客户端团队。这不是白干，而是以太坊一贯的做法：用最激进的方式做研究，用最保守的方式上主网。 回头看这两年，Lean Ethereum 的演变其实是一个很典型的样本：一个宏大的"从零重写"叙事，如何在现实的工程约束和生态惯性中，被逐渐改造成一条渐进但可执行的路径。愿景负责定方向，devnet 负责试错，主网 fork 负责收敛。以太坊的升级从来不是靠某一次革命完成的，而是靠这种"激进研究 + 保守交付"的节奏一步步磨出来的。The Merge 是这样，Lean Ethereum 大概率也会是这样。