构建一个极简的后量子以太坊客户端：ethlambda 的架构

这是我们关于借助共享工具构建后量子以太坊客户端的后续文章，我们在其中介绍了 devnet 的进展、基线客户端需求和生态系统工具。在这里，我们将详细介绍 ethlambda 的架构。

ethlambda 正在参与 pq-devnet-2，这是以太坊 Lean Consensus 的最新后量子互操作性 devnet。此 devnet 侧重于集成 leanMultisig，这种签名聚合方案使得后量子签名在规模上具有实用性。

在这篇文章中，我们将介绍 ethlambda 的架构：我们如何处理并发、密码学、网络和指标。

Repo 结构

ethlambda 的结构由 10 个 Rust crate 组成：

bin/ethlambda/              # 入口点，CLI，编排
crates/
  blockchain/               # Fork 处理 actor
    ├─ fork_choice/         # LMD GHOST 实现
    └─ state_transition/    # 处理 slots、blocks、attestations
  common/
    ├─ types/               # 核心类型
    ├─ crypto/              # XMSS 聚合 (leansig 包装器)
    └─ metrics/             # Prometheus 指标
  net/
    ├─ p2p/                 # libp2p: gossipsub + req-resp
    └─ rpc/                 # HTTP REST API
  storage/                  # Storage API (RocksDB 和 InMemory 后端)

这就是整个项目。在理解启动时发生的事情之前，无需浏览三十个 crate 工作区或特征层次结构。入口点将各个组件连接在一起并开始侦听。

并发

BlockChain 组件是 ethlambda 的核心，并使用 spawned 作为 actor 运行。它通过消息传递处理 fork 选择、状态转换和验证器职责：没有共享的可变状态或显式锁。

P2P 和 RPC 层目前使用普通的 async，尽管我们计划也将它们迁移到 spawned。重要的是，该架构已经强制执行了清晰的边界：P2P 从 gossip 接收到一个 block，并将其发送给 BlockChain 进行处理。

BlockChain 转换状态，如果轮到我们进行 attestation，则将 attestation 发送回 P2P 进行广播。网络与共识分离，并且彼此都不知道对方的内部结构。

我们为 BlockChain 选择了 actor 模型，因为并发应该被包含，而不是分散。Lean Consensus 的 slot 时间为 4 秒，在该窗口内，我们需要验证签名、转换状态并生成 attestations。actor 边界使状态转换保持顺序和可预测，而 I/O 密集的部分（网络、签名验证）在其周围并发运行。

密码学

crypto crate 包装了生态系统的 leanSig 和 leanMultisig 库。

在 Lean Consensus 中，每个验证器在每个 slot 中都进行投票，因此每个 XMSS 密钥索引在每个 slot 中仅使用一次，从而防止了密钥重用，这是基于哈希的签名方案的基本限制。

XMSS 签名每个 3112 字节。如果没有聚合，一个包含 400 个验证器签名的 block 将仅携带超过 1.2 MB 的签名数据。leanMultisig 通过将各个签名聚合为紧凑的证明来解决此问题。

当前 Lean Consensus 设计中的聚合遵循两阶段方法：

1. Fresh signatures：XMSS 签名通过 gossip 到达，经过验证，并使用 leanMultisig 进行聚合。这是 happy path：所有验证器都在线，并且它们的签名在 slot 内到达。
2. Fallback for missing validators：当我们没有给定 attestation 的验证器的普通签名时，我们仍然可以通过重用先前 block 中的聚合 attestation 来包含该验证器，该聚合 attestation 涵盖相同的 attestation 并包含它们。

网络

p2p 层构建在 libp2p 之上，并以 UDP 上的 QUIC 作为传输层。QUIC 为我们提供了比 TCP 更低的延迟、原生加密和多路复用，所有这些在你有 4 秒的 slot 时都很重要。

Gossipsub 参数是从 Beacon Chain 继承的：mesh 大小为 8，心跳间隔为 700 毫秒。Block 和 attestation 消息通过诸如 /leanconsensus/{network}/block/ssz_snappy 之类的主题流动。

除了 gossip 之外，我们还实现了用于 Status 和 BlocksByRoot 的请求-响应协议，并具有指数退避重试（在 5 次尝试中，10 毫秒 → 2560 毫秒）。这些用于同步期间：当节点上线并需要赶上链头时，它会通过 root 从其对等方请求 blocks。

指标

我们通过 /metrics 端点公开 Prometheus 指标，遵循 leanMetrics 规范以实现跨客户端的可观察性。这意味着任何 Lean Consensus Grafana 仪表板都可以与 ethlambda 开箱即用。

我们跟踪的指标包括 slot 处理时间、attestation 计数、对等连接、fork 选择 head 和签名验证持续时间。

当 devnet 中出现问题时，指标是我们知道的方式。

总结和下一步

我们在最近的 sprint 中了解到了一些事情：

Local devnets shorten the feedback loop. 我们可以在单个命令中启动多客户端 devnet，因此我们连续运行本地 devnet。它们为我们提供了一个短的反馈循环以进行快速迭代，从而可以在几分钟内发现问题，而无需等待计划的部署。

Real networks reveal real problems. 即使本地 devnet 捕获到一些问题，其他问题也仅在长期运行的分布式 devnet 中浮出水面。来自状态转换不匹配的非最终性、与时间相关的网络错误、签名聚合中的 edge case：这些需要随着时间的推移运行的真实多客户端环境才能出现。

Shared tooling accelerates everyone. 我们在之前的文章中详细介绍了生态系统工具。

Lean Consensus 生态系统提供了共享规范、密码学库、指标标准和 devnet 基础设施，从而可以更轻松地启动新客户端。Beacon Chain 在早期阶段从未有过这种情况。

在那篇文章中，我们还介绍了 devnet 进展的未来发展方向，但为了概括，我们目前正在开发对 devnet-3 的支持，以及随着 devnet 复杂性的增加而继续进行的 checkpoint-sync 和弹性工作。

我们将继续积极参与 Lean Consensus devnet 的进展。我们在 PQ Interop Breakout Meetings 上每周进行更新，并在 Telegram 上每天进行更新。

ethlambda 在 github.com/lambdaclass/ethlambda 上是开源的。请关注或加入 Telegram 或 X 上的对话。

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