在亚马逊EKS上运行以太坊质押服务 数据库博客

在 Amazon EKS 上运行以太坊质押服务

作者：Emile Baizel 和 Karan Thanvi日期：2024年7月24日分类： Amazon Elastic Block Store、Amazon Elastic Kubernetes Service、区块链、中级学习、技术操作指南永久链接：点此查看

主要收获

在 2022 年 9 月，以太坊转型为 Proof of Stake (PoS) 共识模型。这一变化使任何拥有至少 32 以太币的人都可以质押其资产，操作验证者节点，参与网络验证并获得质押奖励。PoS 系统旨在让个人和公司使用标准硬件运行一个验证者节点。虽然验证者节点的停机会受到罚款，但这些罚款相对较小，停机可以通过设计良好的系统来避免。然而，机构质押者通常操作多个验证者，这增加了他们的技术和运行时间需求。

在本文中，我们将探讨运行机构级以太坊质押服务的技术挑战和需求，并概述在 AWS 上部署以太坊质押服务的解决方案。欲了解有关在您 AWS 帐户中安装和部署的更详细信息，请访问附带的 GitHub 存储库。

质押软件的工作原理

Proof of Stake 网络亦称为 Beacon Chain，由全球数千个单独运作的节点组成。Beacon 节点，又称 共识客户端，通过点对点网络协定与其他 beacon 节点通信。这些节点主要交换关于提交到网络的新交易和新区块的提议及创建的资讯。可供选择的共识客户端有多个，且使用多种流行的编程语言编写，其中最受欢迎的是 RustLighthouse、TypeScriptLodestar、GoPrysm和 JavaTeku。这些客户端的完整列表可在 ethereumorg 查看。

与共识客户端并行运行的是执行客户端。执行客户端的主要责任包括接收和广播提交给它的新交易以及处理新区块，通过将区块中的交易和数据解析到其本地数据存储中。最常用的执行客户端是使用 GoGeth、Erigon、NETNethermind和 JavaBesu等语言开发的，其全网络分布和执行客户端的完整列表可在 ethernodesorg 查看。

通过运行共识客户端和执行客户端，您可以保持区块链状态的实时副本。此功能对于索引区块链数据和接收有关特定事件的通知如执行特定智能合约或指定钱包的活动非常重要。然而，仅仅运行这两个客户端不足以进行网络验证，而网络验证是获得奖励所必需的。

还需要第三种类型的软件，称为验证者客户端，用于网络验证。验证者客户端的两个主要职责是：1监控新创建的区块并验证其内部数据，2提议新区块。为了促进诚实行为，验证者必须首先将 32 以太质押到 beacon chain。这笔质押有被削减的风险，如果验证者因停机而未能验证网络，则会有轻微的罚款；如果验证者表现出恶意行为，例如批准被发现包含恶意交易的区块，则会受到重大罚款。因此，确保验证者私钥的安全至关重要，以防止恶意行为者的窃取。

许多共识客户端包含一个验证者客户端，因为它通常是一个相对轻量的组件。

运行质押服务的挑战和需求

运行质押服务的过程中需要应对各种风险和挑战。一个主要风险是由于停机或共识客户端中的错误导致的削减罚款。例如，如果错误导致客户端错过验证，质押服务必须立即切换到备用客户端，直至原客户端的问题解决。2023 年 5 月，Prysm 客户端中的一个错误暂时影响了其区块验证能力参见 事后报告。为了降低因客户端停机而导致的削减风险，确保客户高度可用且在故障时能够快速恢复至关重要。这在执行客户端中尤其具有挑战性，因为全新同步可能需要超过 24 小时。因此，战略性地架构存储以便于客户端重启时的重用是至关重要的。

另一个至关重要的方面是验证者密钥的安全性和访问控制，因为这些密钥可访问潜在的重大金融资产。必须实施严格的访问控制政策，同时保持密钥的韧性和可用性，以确保运营卓越。

最后，拥有一种流线型的方法来监控该服务，并接收有关重要操作和安全事件的警报是必不可少的。

解决方案概述

对于那些对解决方案感兴趣或希望在自己的 AWS 帐户中部署的人，请参考相关的 GitHub 存储库。

以下图表显示了解决方案中涉及的主要组件。

该解决方案使用了基于 Amazon Elastic Kubernetes ServiceEKS的 Kubernetes。EKS 在管理 Kubernetes 控制平面节点的可用性和可扩展性方面至关重要。这些节点对于容器的调度、确保应用程序的可用性、管理集群数据存储以及执行其他基本功能至关重要。为了增强服务的可靠性，EKS 集群在同一区域内的多个可用区AZ之间运行，以防止在不太可能出现的 AZ 故障情况下的服务中断。

在此部署中，我们在 EKS 集群上使用两种类型的客户端：执行客户端Geth 和 Erigon和共识客户端Lighthouse 和 Prysm。这些客户端是通过 Stakewise 提供的Helm charts 进行部署的。我们选择这些特定的客户端是因为它们的普及性和示范价值，尽管此解决方案很容易适应其他客户端。

为了有效地监控部署，我们使用了 Prometheus Operator 和 kubeprometheusstack。此设置在集群中运行一个 Prometheus 实例，该实例收集来自执行和共识客户端的指标。Prometheus 服务器被配置了 remotewrite 目标，将数据发送到 Amazon Managed Service for Prometheus AMP。收集的数据然后通过托管在 Amazon Managed Service for Grafana 上的 Grafana 仪表板进行可视化。以下是这些仪表板的范例。

本文接下来将深入探讨解决方案的三个主要方面：

此外，我们还将简要讨论验证者密钥和验证者客户端的管理。

运行高可用的客户端

我们使用 Amazon Elastic Block StoreAmazon EBSgp3 存储，并创建一个 Kubernetes 存储类。值得注意的是，存储类 YAML 包含以下内容：

yamlparameters csistoragek8sio/fstype xfs type gp3 iops 5700 encrypted true throughput 250reclaimPolicy Retain

reclaimPolicy 的 Retain 确保 EBS 卷在其附加的 pod 的生命周期之外持续存在。这使得我们能够在一个执行客户端 pod 停止后迅速启动新的执行客户端 pod，方法是将停止的 pod 的完全同步的 EBS 卷附加到新的 pod。若没有此 reclaimPolicy，则新 pod 至少需要 1 天Geth或 1 周Erigon来完成同步。

为了最佳的价格性能比，集群节点运行在 r7g 实例上，这些实例由最新一代 AWS Graviton3 处理器提供支持，这非常适合内存密集型工作负载。

保护 EKS 集群的网络边界

鉴于与安全漏洞相关的重大财务风险，确保解决方案不会通过公共互联网访问至关重要。为此，EKS 集群设置在新创建的虚拟私有云VPC中，虽然也可以集成到现有的 VPC 中。集群内的节点位于私有子网中，使其无法从公共互联网访问。

对 EKS 集群的访问严格限于一个堡垒主机，以进行管理任务。这个主机位于 VPC 的公共子网内 为运行任务提供安全的进入点，以部署 Helm charts 和配置执行和共识客户端。为了增强 EKS VPC 和任何现有平台基础架构之间的连接性和安全性，应使用 AWS PrivateLink。这超出了本文的范畴。

监控 EKS 集群和客户端

该解决方案涉及从 EKS 集群和执行及共识客户端收集 Prometheus 指标。这些指标由运行在集群内的 Prometheus 实例爬行，并随后存储在 Amazon Managed Service for Prometheus 中以供持久保存。我们在 Amazon Managed Grafana 中创建了多个仪表板，以促进有效的可视化监控。这些仪表板可以全面跟踪集群和客户端的状态。设置包括针对 Geth 执行客户端的两个仪表板、针对 Lighthouse 共识客户端的一个仪表板，以及几个专门用于 EKS 集群的仪表板。

客户端仪表板

包含在 GitHub 存储库 中的客户端仪表板提供了广泛的见解。以下是从这些仪表板中可以获得的一些数据范例：

执行客户端仪表板：此仪表板的Chain head功能指示客户端处理的最新区块。

Lighthouse 共识客户端仪表板：此仪表板提供了当前在网络上激活的验证者数量的快速视觉表示。

Geth 仪表板：此仪表板提供了有关客户端的各种指标的概览，提供了全面的快照。

EKS 节点仪表板：此仪表板显示在一个节点上运行的所有 pods，包括每个 pod 的 CPU 和内存使用的详细信息，无论是单独还是综合。

EKS 集群仪表板：此仪表板专注于 EKS 集群各节点的系统资源消耗，提供集群性能的整体视图。

关于验证者客户端签名密钥的说明

当验证者提议新区块或对提议的区块进行见证时，他们需要签署特定的数据值来表示此行动。默认情况下，验证者客户端使用本地可用的私钥来签名交易。这一过程可以扩展到通过 Web3Signer 的 HTTPS 接口 来促进远程签名。例如，博客文章 AWS Nitro Enclaves 用于运行以太坊验证者 示范了如何使用 AWS Nitro Enclaves 实现此目的。还有一些第三方产品旨在无缝切换到替代的共识客户端，以防某些客户端临时不可用或因软件错误变得无法使用。

结论

在本文中，我们讨论了以太