用 Elixir 构建一个共识节点

本文主要介绍了 LambdaClass 团队正在使用 Elixir 语言构建一个全新的以太坊共识客户端。该项目旨在通过技术和地域多样性来增强以太坊生态系统的健壮性，并创建一个高质量、易于理解的代码库作为学习和贡献以太坊协议的教育工具。文章详细阐述了项目目标、架构设计、技术细节、开发路线图以及面临的挑战。

在 Elixir 中构建共识节点

动机

以太坊生态系统的优势在于其通过多样性实现的可靠性，包括技术和人为因素两个方面。 然而，迄今为止，以太坊客户端的开发主要由欧洲和北美团队带头。 这在无意中集中了知识、贡献和维护，这与以太坊去中心化的基本精神背道而驰。 认识到客户端多样性的关键性——这不时面临挑战——我们深信我们的 LambdaClass Consensus 客户端可以产生重大影响。 我们的目标不仅仅是构建，而是以不同的方式构建，从而促进一个真正的全球以太坊社区。

在未来几个月内，我们的目标是开发一个完全开源的客户端，由来自拉丁美洲的一个充满激情的团队领导——在拉丁美洲，此类技术的相关性和需求因当地的不稳定性而更加突出。 增强多样性不仅邀请更广泛地参与以太坊，而且还增强了协议的弹性。 这是通过纳入协议核心贡献者所在地区的各种背景和法律框架来实现的，从而减轻了潜在的监管挑战。 我们强调培养社区参与。

从技术角度来看，我们已决定使用 Elixir 编程语言构建新的共识客户端。 Elixir 以其对并发性、可用性、容错性和稳定性的关注而闻名，它是一种由 Erlang VM 驱动的函数式语言。 这些属性使其成为实现以太坊共识客户端的理想选择。

我们对 Elixir 的深刻赞赏推动了我们培养一个充满活力的以太坊 Elixir 社区的雄心，让人想起我们近年来见证并积极贡献的蓬勃发展的 Rust 以太坊社区。 Elixir 强调代码可读性及其简单的实现策略，使我们能够设定一个明确的目标：使我们的客户端不仅成为一个堪称典范的技术作品，而且成为一个有价值的教育工具。 我们的目标是使其成为学习协议规范、了解以太坊内部机制、为核心协议做出贡献以及实施这些规范的综合资源。

与以太坊对开源协作的奉献精神相一致，我们设想我们的客户端可以作为广泛协议贡献的启动平台，真正体现“为了人民，为了人民”的精神。

项目描述

该项目背后的理念依赖于：

  • 团队专业知识： 我们致力于组建一支精通整个共识规范的强大团队。 我们的目标是让该团队成为整个社区的知识灯塔和可靠参考点。

  • 透明的开源方法： 我们的项目就像一本开放的书。 从我们的日常进展、路线图和问题日志的方方面面都将对公众开放，从而促进开放协作、贡献和反馈。 这种透明性为从一开始就进行外部参与铺平了道路，我们很自豪能够在早期阶段就实现这一目标。

  • 从第一天起就可用于生产： 我们设想我们的首次发布即可立即使用。 只需执行 make run 即可使一个功能正常的节点启动并运行，该节点可以接收和存储区块。 它将与执行层无缝集成，并且信标 API 将可用于基本的信标状态查询。 这种方法促使我们快速迭代，专注于切实的解决方案，并对潜在的错误和集成挑战保持警惕。

  • 代码清晰： 我们的目标是精简、易懂且功能强大的代码库。 我们优先考虑一种设计，其中主动处理预期的错误，而不仅仅是“捕获”。 Elixir 的固有能力有助于在进程和可能表现出不同负载的请求之间进行高效调度。 此外，它的架构确保各个组件可以独立崩溃和恢复，同时保持整体系统弹性 [1]。

规范

这是该解决方案的高级架构图。

graph TB

subgraph "Consensus Node"
  engine[Engine API Client]
  BAPI[Beacon API]
  TICK[Slot processor]
  STORE[Local Storage]
  CACHE[State Cache]
  PRT[State transition server]

  BAPI -->|Beacon state queries| CACHE
  PRT -->|beacon state transition, fork-choice queries| CACHE
  PRT --> |payload validation, execution, reorgs| engine
  TICK --> |on_tick| PRT
  CACHE <--> STORE
end

GOS[Gossip Protocols]
exec[Execution Client]
VALIDATOR[Validator]

engine <--> exec
GOS -->|blocks, attestations| PRT
VALIDATOR --> BAPI

技术细节

  1. API 框架：

    • Beacon API：使用 Phoenix 框架。
    • Engine API Client：使用 Tesla 实现。

  2. 存储：

    • 缓存和本地存储：技术有待确定 (TBD)。

  3. Gossip 消息处理：

    • 只要状态转换保持排序，就可以通过 snappy 解压缩和 SSZ 反序列化并行处理消息。

  4. 状态转换服务器：

    • 这是最关键的组件。
    • 主要职责：对传入的 gossip 消息进行排序并启动状态转换函数。
    • 这些函数集成到一个纯库中。
    • 我们正在评估多种策略，例如：
      • 使用 OTP GenServer 利用 ETS 键值存储作为 SQL 存储上的缓存

路线图

1. 区块订阅 - 9 月中旬

  • Libp2p 发现和区块检索
  • SSZ + snappy
  • on_block 回调：将最新区块保存在 分叉选择 存储中，进行基本检查。 GetHead 返回最新获得的区块。
  • Beacon API：返回区块根 (GET /beacon/states/{state_id}/root)

2. 检查点同步 - 10 月

  • 用于同步的 Libp2p 原语
  • 支持从已知提供商进行检查点同步
  • 从最新的最终确定区块同步
  • BeaconAPI：返回头区块的标头
  • EngineAPI：验证传入区块

3. 证明 - 10 月中旬

  • Libp2p 证明检索
  • 基本信标状态表示
  • 存储证明（每个验证者发送的最后一条消息）
  • 用于通过 Gossip 发送的证明的 on_attestation 回调
  • 处理来自区块的证明
  • Beacon API：返回头区块根 (GET /beacon/states/head/root)

4. 存款 - 11 月

  • BLS 签名检查
  • 更新存款合约的共识状态视图 (process_eth1_data)
  • 处理存款操作以更新验证者列表 (process_deposit)
  • 验证区块签名 (verify_block_signature)

5. 插槽和 分叉选择 - 11 月中旬

  • 状态转换中的 on_tick/process_slot； 定期调用此 GenServer
  • on_block：添加与插槽相关的检查和 epoch 计算（不包括最终确定）
  • Get-head 使用这些消息
  • 区块头验证
  • EngineAPI：处理执行负载
  • BeaconAPI：确保获取头值指向最重的

6. 最终性和削减 - 11 月中旬

  • Epoch 处理
  • on_block：修剪 分叉选择 存储； 拒绝最终确定之前的区块
  • 将 RANDAO 混合添加到信标状态
  • BeaconAPI：检索最终确定检查点、randao 混合
  • 处理证明者削减和提议者削减
  • EngineAPI：分叉选择 更新

7. 奖励、洗牌 - 12 月

  • 在 epoch 处理检查点的奖励 on_epoch
  • 处理存款和取款
  • 实施 RANDAO
  • 计算给定状态的委员会
  • 进行洗牌
  • 与 Grafana 集成
  • BeaconAPI：检索给定区块的 randao 混合

8. 验证者功能 - 12 月中旬/2024 年 1 月

  • 创建证明
  • 监控削减
  • 创建削减证明
  • BeaconAPI：发布区块、削减、自愿退出和提款

预期挑战

技术挑战：

  • 特定于语言的支持： 与其他语言相比，Elixir 在 BLS、密码原语、libp2p 和 SSZ 等关键组件中可能直接支持有限。 虽然我们打算为某些功能开发本机绑定，但其他功能将要求我们从头开始编写代码（这是最终目标，以进一步推动实现多样性）。

  • 负载测试限制： 彻底的负载测试，同时考虑标准计算机硬件的限制，可能会带来挑战。

  • 最佳存储解决方案： 信标状态和 分叉选择 存储的存储设计在规范中没有明确详细说明。 从无数选项中识别和验证最有效的存储解决方案至关重要。

  • 交叉测试兼容性： 必须通过使用所有现有执行客户端交叉测试我们的客户端来确保兼容性。

人为挑战：

  • 技能提升： 使团队适应以太坊规范的复杂细节绝非易事。 这需要持续的努力和耐心。 如果这种陡峭的学习曲线妨碍了一些外部协作者快速参与问题，则可能会阻止他们。

  • 区分功能： 为了确保更广泛的采用，我们需要确定独特的特性，这些特性将使我们的客户端更具吸引力。 这可能包括增强的可观察性或其他突出特性，以增强我们客户端的价值主张。

  • 培养有弹性的社区： 建立一个不仅持久，而且充分了解即将到来的协议变更并积极渴望进一步促进以太坊协议的增长和创新的社区至关重要。

项目目标

我们衡量成功的标准是明确而雄心勃勃的。 在研究金结束时，我们希望拥有一个与当前信标状态无缝同步并正确计算 分叉选择 的节点。 虽然对奖励计算和验证者的支持将在研究金结束后纳入，但我们在此过程中的目标是奠定坚实的基础。

合作者

成员

按 github 用户名首字母排序。

  • Tomás Arjovsky (@arkenan)
  • Godspower Eze (@Godspower-Eze)
  • Tomás Grüner (@megaredhand)
  • Martín Paulucci (@mpaulucci)
  • Paul-Henry Kajfasz (@phklive)

导师

  • Mikhail Kalinin @mkalinin

资源

Lambdaclass 以太坊共识客户端 Github 存储库

书籍：

视频：

博客：

论文：

规范：

参考书目：

[1] https://ferd.ca/the-hitchhiker-s-guide-to-the-unexpected.html

  • 原文链接： github.com/eth-protocol-...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
eth-protocol-fellows
eth-protocol-fellows
江湖只有他的大名，没有他的介绍。

eth-protocol-fellows

如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！