ethlambda: 一个瘦身的以太坊共识层客户端

在 LambdaClass，我们一直在开发一个名为 ethlambda 的以太坊 Lean Consensus 客户端。随着以太坊准备进行自 Merge 以来最具雄心的共识层重新设计，客户端多样性将比以往任何时候都更加重要。ethlambda 是我们对未来的贡献——一个极简、快速且模块化的 Lean Ethereum 共识协议实现，用 Rust 编写。

这并不是我们第一次涉足以太坊共识。自 2023 年以来，我们之前一直在开发基于 Elixir 的 Beacon Chain 客户端 lambda_ethereum_consensus。该项目教会了我们共识客户端如何从内部到外部工作。结合我们在 ethrex（我们的执行客户端）上的工作，我们现在对什么使以太坊客户端复杂以及可以简化什么有了深刻的了解。

ethlambda 是我们所学一切的综合。lambda_ethereum_consensus 针对当前的 Beacon Chain，而 ethlambda 从一开始就专门为 Lean Consensus 构建——没有遗留代码，没有向后兼容性问题，只是对新协议的干净实现。

推动 ethlambda 的想法与其他项目具有相同的核心原则：简单性。我们建议阅读 Vitalik 最近关于简化 L1 的 文章；它极大地引起了我们的共鸣，成为一项指导原则，并反映了 Lean Ethereum 旨在实现的许多目标。

为什么 Lean Consensus 很重要

当 Justin Drake 在 2024 年 11 月于曼谷 Devcon 上公布 Lean Consensus 提案（最初称为 Beam Chain）时，它代表着一个难得的机会，可以对以太坊的共识层进行全新设计，并借鉴了前一个 Beacon Chain 五年来的经验教训。

Lean Consensus 中捆绑了很多更改，但在致力于单一有凝聚力重新设计的最关键升级中，有：

• 更快的最终性：从大约 15 分钟缩短到使用 3-slot finality (3SF) 的几秒钟
• 后量子安全：基于哈希的签名 (leanSig) 已为 SNARK 和量子计算机做好准备
• 更低的质押要求：从 32 ETH 降至 1 ETH，极大地改善了去中心化
• SNARKified consensus：实时可证明的状态转换
• 现代网络：Gossipsub v2.0 和高级集合协调，适用于 4 秒的Slot

Lean Consensus 没有逐步修补现有的 Beacon Chain，而是问：如果我们能够以我们现在所知道的一切重新开始，我们会构建什么？

为什么要构建另一个客户端？

Lean Consensus 生态系统已经有几个客户端团队：Ream (Rust)、Zeam (Zig)、Qlean (C++)、Lantern (C) 和 Lighthouse 分支（也是 Rust）。由于已经有两个 Rust 实现正在进行中，为什么 LambdaClass 还要构建第三个？

答案在于我们对软件的态度。

我们在加密货币领域工作得越多，就越会遇到带有不必要复杂性的代码库。具有数十个模块的库用于模块化最细微的东西，具有过多 traits 和泛型的 API 用于抽象每个意外情况，使用宏来节省行数，但以可读性为代价。这些是我们和其他人在与加密货币存储库集成时不断遇到的不便。

ethlambda 是我们尝试构建我们希望存在的共识客户端。

加强多样性需要采用不同架构、抽象和哲学的实现，而不仅仅是用不同的语言实现。

符合 LambdaClass 的工作理念，我们的目标是始终保持简单和最小化。

以简单性作为策略

代码行数很重要。 我们会跟踪所有项目的 LoC，确保我们永远不会超过限制。我们的 ethrex 执行客户端有 9.6 万行代码——包括 EVM、L2 堆栈、ZK prover 和 SDK——而同类客户端甚至在计算外部依赖项之前就超过了 20 万行代码。ethlambda 目前的代码行数不到 5 千行，并且具有完整的 devnet-1 共识功能。

垂直集成优于碎片化。 我们倾向于使用具有自我解释功能的 crates 的扁平结构，而不是将代码拆分为数十个包。如果你无法用一句话解释模块的功能，那么它可能做了太多事情。

Traits 是最后的手段。 Rust 的类型系统非常强大，但强大很容易变得复杂。ethrex 仅包含 12 个 traits，我们已经认为太多了。我们仅在绝对必要时才使用 traits——用于序列化、存储后端和加密操作。拥有丰富的类型系统并不意味着你应该将每个问题都具体化到其中。

不赞成使用宏。 它们节省了行数，但以可调试性为代价。ethrex 只有四个宏，三个用于测试，一个用于指标。每个宏都是你在凌晨 3 点出现问题时支付利息的技术债务。

并发是受限的。 并发增加了复杂性。我们避免将其分散在整个代码库中，仅在绝对必要时才使用它——而不是作为默认的架构模式。

没有历史包袱。 Lean Consensus 在设计上是一个全新的开始。我们不需要实现已弃用的功能或维护与 pre-merge 基础设施的向后兼容性。这提高了投资回报率，因为它使我们能够以较小的团队开发和维护客户端。

后量子势在必行

Lean Consensus 的一个关键动机是为后量子世界准备以太坊。当前的 BLS 签名最终将落入量子计算机之手。Lean Consensus 使用基于哈希的签名 (leanSig) 和 XMSS 聚合 (leanMultisig)，这两种签名对经典和量子对手都保持安全。

除了防止理论上的未来攻击之外，还有一个性能方面：基于哈希的签名对 SNARK 友好，并可以实现高效的证明聚合。相同的原语具有两个目的——这是 Lean Ethereum 优雅设计的完美示例。

当前状态

Lean Consensus 的开发遵循分阶段的方法，devnet 逐步增加复杂性：

• pq-devnet-0（2025 年 9 月）：具有修改后的 3SF-mini 共识的基本多客户端协调
• pq-devnet-1（2025 年 11 月）：在客户端之间集成的 leanSig 签名和验证

在 ethlambda 方面，我们已经完成了所有核心客户端功能：

• 网络：通过 libp2p 连接到对等方，响应 STATUS 消息，通过 gossipsub 侦听区块和质押
• 状态管理：从创世生成初始状态，实现状态转换函数，在每个新区块上转换状态
• Fork 选择：根据收到的质押实现并应用 fork 选择规则
• 验证者职责：生成和广播质押，计算当前提议者，构建和广播新区块

该客户端与 lean-quickstart 集成，因此使用 ethlambda 以及 Zeam 和 Ream 启动本地 devnet 只是一个命令。

我们正在与更广泛的 Lean Consensus 社区密切合作——参与每周的 PQ 互操作分组会议，在 leanSpec 上为共享规范做出贡献，并向其他客户端团队（尤其是 Zeam）学习。

接下来是什么

Lean Consensus 的下一步是 pq-devnet-2（目标是 2026 年 1 月），它将集成使用 leanMultisig 的完整签名聚合。

随着核心共识功能的完成，我们目前的重点转移到：

1. Devnet 2 支持：实现 leanMultisig 签名聚合
2. 弹性：数据持久性和历史同步
3. 可观察性：扩展的指标、结构化日志记录和 Grafana 仪表板
4. 性能：针对 Lean Consensus 要求的 4 秒Slot进行优化

预计在 2029-2030 年进行生产部署（尽管最近的事件可能会改变时间表）。真正的工作现在就开始了——在规范讨论、devnet 以及将研究转化为运行代码的艰苦工程中。

LambdaClass 的愿景

在 LambdaClass，我们认为以太坊应该具有前瞻性、加速主义的态度。这意味着快速行动，拥抱变化，并通过不害怕在有必要时进行重大重新设计来保持精简。Lean Consensus 正是这种必要的飞跃。

我们再怎么强调客户端多样性不仅仅是拥有多个实现，而且还要确保各种实现体现不同的方法和理念。ethlambda 代表了我们的理念：简单不是能力的对立面，而是它的基础。

ethlambda 从第一天起就是开源的：

• GitHub：github.com/lambdaclass/ethlambda
• Telegram：t.me/ethlambda_client

以太坊的下一个时代正在建设中。我们很高兴能参与其中。

• 原文链接： blog.lambdaclass.com/int...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～