在 AWS 上运行 Polygon 节点
重点摘要
本文深入探讨了在 AWS 上建立基础设施并部署 Polygon 区块链节点的相关信息。我们提供了针对各种用例选择最优计算和存储选项的建议。通过使用 Amazon Simple Storage ServiceAmazon S3和 s5cmd 工具,我们探讨了如何将 Polygon 全节点 的水平扩展速度从约 8 小时缩短至 2 小时。最后,我们回顾了基于 AWS 的 Polygon 全节点配置,适应不同的使用模式。
如果您正在寻找无服务器的托管环境,我们建议您探索 Amazon Managed Blockchain (AMB) 访问 Polygon。
Polygon 区块链的工作原理
Polygon 的权益证明PoS区块链与 以太坊区块链 并行运行,但依赖于以太坊来存储 检查点交易。这使用户能够加速 Polygon PoS 区块链上的操作并降低 交易成本。在 Polygon 上,开发者可以在以太坊之外执行计算任务和数据存储,而 Polygon 验证者依靠以太坊的 防篡改特性 来持续验证新区块。Polygon PoS 网络是 Polygon 的核心产品,以 委托证明权益DPoS侧链的形式与以太坊虚拟机EVM互通,具体如以下图所示。
Polygon PoS 侧链由以下三层组成:
以太坊层 一组在以太坊上管理权益和存储检查点的智能合约。Heimdall 层 一个与以太坊节点并行运行的 Heimdall 客户端,验证 Bor 层生产的区块,并将检查点提交到 以太坊主网。Bor 层 一组兼容 EVM 的 Bor 客户端,接受用户交易并将其组装成区块。与 Go Ethereum 客户端相对应的 Bor 客户端代码也可以使用 Erigon 客户端 作为更多存储优化的 归档节点。为了运行 Polygon 全节点,我们在同一台机器上启动 Heimdall 和 Bor 客户端,以提高成本效益。您也可以通过组合 Heimdall 和 Erigon 客户端实现同样的效果。
运行 Polygon 节点中的挑战
Polygon 提供高效的处理速度和低交易成本,使其成为去中心化应用程序dApps的热门选择。随着 Polygon 网络的增长,Bor 和 Heimdall 的磁盘使用量也在增加,目前数据量已超过数 TB。这意味着同步数据以提供新的全节点可能需要 2 到 3 天。
为了解决这个问题,以下 Polygon 文档 建议使用 aria2c 工具 下载节点快照数据。Polygon 数据的总大小约为 24 TB,其中 90 是 Bor 客户端的状态数据。
下表展示了在三种不同类型的 Amazon Elastic Compute CloudAmazon EC2实例上测量数据下载和解压时间的结果。实验表明,整个过程需要 16 到 17 小时,其中下载时间约为 12 小时,解压时间超过 4 小时。我们对表中列出的每种实例类型进行了额外的实例大小测试,发现这个过程所需的时间在不同实例资源之间相对一致。
实例类型 (vCPUs 内存 GiB)EBS GP3 (大小/IOPS/吞吐量)下载 (hhmmss)提取 (hhmmss)总计 (hhmmss)c6g8xlarge (32 64)8T / 10000 / 1000115039041303160342r6g4xlarge (16 128)8T / 10000 / 1000122400041908164308m6g8xlarge (32 128)8T / 10000 / 1000124551041424170015这意味着在需要提供新节点来服务您的 dApps 时,您需要等待 16 到 17 小时才能准备好快照以运行您的节点。尽管比最初的 3 到 4 天快,但时间仍然足够长,令节点的按需扩展存在问题。为了解决这个问题,我们进行了系列基准测试,以进一步减少新 Polygon 节点的资源配置时间,并确定运行它们所需的合适实例和 Amazon Elastic Block StoreAmazon EBS存储类型。
解决方案概述
我们的目标是实施以下部署架构,以在 AWS 上运行可扩展且高度可用的 Polygon 全节点。
工作流程包含以下步骤:
一个专用 EC2 实例我们称其为 同步节点从 Polygon 快照服务下载并解压快照数据到其本地存储中。同步节点将 Polygon 提取的快照数据上传到一个 Amazon Simple Storage ServiceAmazon S3存储桶中。一组 EC2 实例我们称之为 RPC 节点由 自动扩展组 提供,以服务来自 dApps 的 JSON RPC API 请求,并从 S3 存储桶下载快照数据以初始化节点数据存储。基于已初始化的数据,RPC 节点执行额外的同步任务以赶上 Polygon 网络的链头。新的 RPC 节点与其他节点同步,更新创建快照后添加的新数据。dApps 和开发者通过 应用负载均衡器 使用高度可用的 RPC 节点。分析更快复制节点数据快照的不同方法
我们希望 RPC 节点能够随使用情况变化而自动扩展。为此,我们测试了两种方法。

第一种方法使用同步节点存储整个数据集,并为该数据创建 EBS 卷快照。如下图所示,当需要新的 RPC 节点时,将从同步节点的快照加载 EBS 卷到新的 RPC 节点,仅需几分钟。
闪连加速器第二种方法,如下图所示,使用 s5cmd 工具 从同步节点将数据复制到 S3 存储桶,然后再从 S3 存储桶复制到 RPC 节点。此方法利用 Amazon S3 的并行文件传输功能,可以根据 CPU 核心数量加速文件传输。
下表展示了使用 aria2c 的当前 Polygon 方法、EBS 卷快照方法和使用 s5cmd 工具所需的时间。
实例类型 (vCPUs 内存 GiB)aria2c (hhmmss)EBS 卷快照 (hhmmss)s5cmd (hhmmss)取恢复总计上传r6g8xlarge (32 256)17365004391200328m6g8xlarge (32 128)17001504405200343c6g8xlarge (32 64)16034205300000335结果显示,在使用 EBS 卷快照的方法时,创建卷快照大约需要 45 到 55 小时。由同步节点创建的卷快照使得新 RPC 节点可以在几分钟内添加,但在 EBS 快照从 S3 存储加载的过程中可能经历较高的延迟。然而,与从 Polygon 快照服务下载相比,这种方法仍然快四倍。
另一方面,使用 s5cmd 工具,我们可以直接从 Amazon S3 将文件复制到每个 RPC 节点的本地数据卷。此方法避免了 EBS 懒加载,尽管新 RPC 节点在初始阶段花费时间复制数据,但最终不会遭遇数据卷低延迟问题。在我们的测试中,完整过程大约需要 2 小时,不论 EC2 实例类型如何。然而,不同实例的上传和下载速度会有显著差异。使用 s5cmd 上传和下载快照对于 4xlarge 实例约需 4 小时,对于 8xlarge 实例则约需 2 小时。使用较大实例时,该方法比使用 EBS 卷快照快约两倍,且比从 Polygon 快照服务下载快约八倍。
使用以上提到的任何方法下载快照后,新 RPC 节点仍需与 Polygon PoS 网络的其他节点同步数据。根据快照创建的时间,这可能需要 30 分钟到约 1 小时的时间,此外还需计算快照处理时间。
根据使用模式选择合适的 RPC 节点配置
除了改善初始同步时间外,我们还进行了系列基准测试,以寻求适合 Polygon 全节点在 AWS 上的配置。我们启动了多种 Bor 和 Heimdall 客户端的计算和存储组合,并通过随机 API 调用对 JSON RPC API 进行了负载测试,以测量哪个配置能为 dApps 提供更好的用户体验。同时,我们还测量了每个配置在负载下与链头保持同步的时间。下表中的配置在这些基准测试中表现最佳,依据三个常见使用模式进行选择。
使用模式AWS 上的配置可以轻松跟随链头并能处理单到双位数字请求的节点,适用于磁盘密集型 RPC 方法,如 Erigon 的 traceblock。计算:m7g4xlarge16 vCPU,64GB RAM 存储:7000 GB EBS GP3,16000 IOPS 和 1000 MBps 吞吐量每秒处理数百个 JSON RPC 请求的节点,仍能跟随链头。操作上需要容忍短暂的实例存储,但需要在实例停止、休眠或删除后重新初始化数据。计算:im4gn4xlarge16 vCPU,64GB RAM 存储:7500 GB 实例存储im4gn 实例类型自带和额外的 50 GB EBS gp3 根卷每秒处理高达千个 RPC 请求取决于 RPC 方法的节点,并能跟随链头,具备 EBS 卷的全面操作便利性。计算:m7g4xlarge16 vCPU,64GB RAM 存储:7000 GB EBS IO2,16000 IOPS测试结果表明,使用 AWS Graviton3 处理器的 通用 m7g4xlarge EC2 实例 的性能和成本比相对较好,但在存储方面,更具成本效益的 EBS gp3 卷类型 在同步和服务较高并发 RPC 请求时的表现不佳。从成本角度来看,使用基于 AWS Graviton2 的 存储优化 im4gn4xlarge 实例 及短期 实例存储卷 可能更具成本效益,尽管与 EBS io2 或 io1 卷类型相比,使用短期实例存储卷的节点在操作上不如与永久 EBS 卷的节点便利,但考虑到使用前面提到的 s5cmd 工具时快速配置新 RPC 节点的改善,这种做法或许是可以接受的。
结论
在本文中,我们讨论了如何更快速地在新创建的 Polygon 节点上获取数据快照。我们讨论了同步节点如何下载、解压和共享快照数据,并展示了如何在约 17 小时内完成此过程,从而避免耗时数天。随后,我们讨论了两种使用快照来配置新 RPC 节点的方法。您可以在启动时创建 EBS 卷快照并将其映射到新 RPC 节点,但会遇到较高的延迟,因为 EBS 会懒加载,或者利用 s5cmd 工具在 EC2 实例和 S3 存储之间进行高效的数据复制,降低初始化与配置的时间至约 2 小时。
最后,我们呈现了针对不同使用模式的 RPC 节点配置。基于 AWS Graviton3 的 EC2 实例非常适合此目的,并且利用 s