2026 年 Polygon PoS 节点要求：Heimdall-v2、Bor 与归档节点

Polygon PoS 全节点要运行两个客户端：Heimdall-v2 和 Bor。Polygon 文档要求 8 个核心和 32 GB 内存（建议 16 核和 64 GB）、4–6 TB 高速存储以及 1 Gbit/s 带宽；归档节点需要 16 核、64 GB 内存和 16 TB 存储。2026 年 10 月，包含完整历史的 Bor 快照解压后约为 7.3 TB。

以上要求数据来自 Polygon 开发者文档（该文档现已将这一网络称为 Polygon Chain），查询于 2026 年 10 月 15 日。有两项变化让大多数旧指南已经过时：2025 年 7 月 10 日，Heimdall-v2 取代了最初的 Heimdall；2026 年 8 月 1 日，Polygon Labs 终止了对 Erigon 的支持，因此归档节点现在改用 Bor 运行。

简要结论

“实际占用”数据为 PublicNode 的快照大小，PublicNode 是 Polygon 文档列出的社区快照提供方；两者之间的差距在磁盘一节中说明。

Polygon PoS 节点官方硬件要求

Polygon 的前置条件页面以“最低/建议”的形式给出各项数据。一个节点就是一台同时运行两个客户端的机器：Heimdall-v2 是基于 Cosmos SDK 和 CometBFT 构建的共识层，Bor 是基于 Go Ethereum 构建、负责出块的执行层。安装指南要求等 Heimdall 同步完成后再启动 Bor。

其他官方页面的说法并不一致。关于 Bor 同步缓慢的故障排查页面建议 6,000 IOPS，并建议将跟不上进度的节点配置翻倍；Bor README 仍然列出最低 4 核、8 GB 内存和 1 TB 磁盘，远低于上表和当前的链数据量。

Polygon 全节点需要多少磁盘空间？

Polygon 快照页面对主网节点的容量估算如下：

这些数字彼此矛盾：按每天 105 GB 计算，8 TB 磁盘在恢复 4.5 TB 数据后剩下的 3.5 TB 只能维持一个月左右。快照提供方的数据能反映目前的实际数据量。下表为 PublicNode 在 2026 年 10 月 15 日的列表，已将其字节数换算为十进制单位；其页面以二进制单位显示，因此页面上标为“6.0 TB”的完整快照在此为 6.63 TB。

这对容量规划意味着：

• 完整历史节点需要超过 8 TB。Bor 的完整数据目录已超出文档推荐的 6 TB，几乎占满文档建议的 8 TB。Bor 的 snapshot prune-block 命令“仅适用于基于哈希的存储方案”，而 Bor 现在默认使用基于 PebbleDB 的路径方案，因此区块历史会持续累积。
• 增长速度尚不确定。按我们的计算，完整快照中较新的那部分涵盖 2025 年 9 月 2 日以来产生的区块，共 4.13 TB：平均每天约 10 GB，仅为文档所给速度的十分之一。2026 年 6 月，出块时间和 gas 上限都发生了变化，因此请自行测量实际增长，并以每天 105 GB 作为保守上限进行规划。
• 修剪节点体积小，但缺乏文档说明。Bor 修剪快照达到同一高度只需 109 GB，差额主要是旧的区块数据。Polygon 文档只要求验证节点“定期修剪节点以减少磁盘占用”，因此在用修剪节点提供 RPC 服务之前，请先向快照提供方确认它保留了哪些历史数据。
• Heimdall 很轻量。自 2026 年 6 月起，其默认附带的配置会禁用 CometBFT 交易索引，并每 10 分钟修剪一次；据 Polygon 称，这能在主网 RPC 节点上释放约 23 GB 空间。自 2025 年迁移以来的完整历史占用 3.7 TB；仅主网创世文件就约有 3 GB。
• 使用本地 NVMe。文档指出，磁盘 IOPS 决定了解压、同步和压缩合并（compaction）的速度；文档认为直连存储最为理想，要求 AWS 用户配置 16,000 IOPS，归档节点则需要 20,000+ IOPS。机械硬盘阵列远远达不到要求。

快照页面列出了六家社区快照提供方以及 All4nodes 聚合平台。使用快照时，节点同步只需“几小时而不是几天”；全节点指南提醒，如果从网络同步，则需要好几天。

Polygon 归档节点：采用 PBSS 的 Bor，而非 Erigon

前置条件表格中归档节点一行仍标注为 Erigon，Polygon Chain 概览页面也仍称 Erigon“同样受支持”。两者都已过时：

• 2025 年 9 月 17 日：Erigon v3.1.0 将 Polygon PoS 客户端的支持工作从 Erigon 团队移交给了 Polygon Labs。
• 2026 年 5 月 12 日：Polygon Labs 宣布将于“8 月 1 日前”终止对 Erigon 的支持，并建议归档节点采用“Bor w/ PBSS”，即使用基于路径的状态方案的 Bor。
• 2026 年 8 月 3 日：0xPolygon/erigon 仓库被归档。其 README 明确表示不会再有新版本和安全更新，并提醒现有部署只能继续同步到下一次 Bor 硬分叉为止；随后，Austin 硬分叉于 8 月 13 日激活。

公告中附有一份主网 config.toml，其关键配置如下：

chain = "mainnet"
datadir = "/var/lib/bor/data"
"db.engine" = "pebble"
"state.scheme" = "path"
syncmode = "full"
gcmode = "archive"

[history]
  transactions = 0   # 0 = index the entire chain
  logs = 0
  state = 0          # 0 = keep state history back to genesis

[cache]
  cache = 24576
  gomemlimit = "55GB"

• 磁盘。PublicNode 基于路径的 Bor 归档占用 12.95 TB，在文档给出的 16 TB 以内。修剪模式的 Heimdall 另需 10 GB，归档模式的 Heimdall 另需 3.7 TB。
• 内存。24 GB 缓存加上 55 GB 的 Go 内存上限，意味着至少需要 64 GB 内存，与归档节点一行的要求一致。
• API。Bor 仅对最近 128 个区块提供 eth_getProof。其 Parity 风格的 trace_* 命名空间默认关闭，需要归档节点并启用 --rpc.enabletrace；trace_block 不包含区块 80,084,800 之前的状态同步交易。
• 安装程序。Bor 安装包中的主网归档模板仍设置为 state.scheme = "hash"。请在首次启动前将其改为上述设置。

Polygon 验证节点要求：哨兵节点加验证节点

一个验证节点由两个节点组成，每个都须满足全节点规格：一个公开的哨兵节点，以及一个“只能通过其哨兵节点访问”的验证节点。Polygon 文档还补充了以下几点：

• 额外组件。验证节点上需要运行 RabbitMQ；需要一个以太坊 RPC 端点，可以来自服务商，也可以是您自己的节点（参见我们的以太坊节点硬件指南）；此外，自 Heimdall-v2 起，签名密钥需要导入密钥环（keyring）。
• 质押与名额。新验证节点至少需要自质押 100,000 POL（PIP-70），且活跃验证节点最多 105 个，因此新加入者需要等待名额空出；提交申请并不能保证获得名额。
• 以太坊上的费用。大约每 15–20 分钟需要签署一个检查点，签名地址上还需保留 0.5 至 1 ETH，用于提交检查点。
• 性能下限。签名表现按最近 700 个检查点统计，并与验证者集合中位数的 98% 相比较；低于该水平时，先有两个宽限期，每个宽限期为 700 个检查点，之后将被强制解除质押。
• 专机专用。只运行 Bor、Heimdall 和 RabbitMQ，不提供公共 RPC，也不开放任何可从互联网访问的端口：30303 和 26656 仅对哨兵节点开放，SSH 须经 VPN 访问。

如果中位数验证节点签署了每一个检查点，那么 700 的 98% 意味着大约允许错过 14 个：按我们的计算，每个窗口期允许的停机时间约为三个半小时到将近五小时。因此，镜像磁盘和快速重启都很重要。2026 年 10 月 15 日发布的 Bor v2.10.3 重构了重启时运行的 trie 预加载，并可将其地址缓存持久化保存（默认关闭，主网上约 9 GB）；据 Polygon 称，主网哨兵节点上的预加载耗时从约 1 小时 25 分钟降至约 4 秒。

CPU 与内存：为什么需要 16 核和 64 GB

Polygon 文档只给出核心数，没有给出主频，但链的运行节奏可以解释为什么需要 16 核这一档。根据 Polygon 的更新日志，自 2026 年 6 月 3 日起，主网每 1.5 秒产出一个区块；6 月 gas 上限又提高到 160 百万，使处理能力提升到约 106.66 Mgas/s。Bor 使用 BlockSTM v2 并行执行交易，该功能自 v2.9.1 起默认启用，其默认配置为并行 EVM 分配 8 个工作线程。

追赶最新区块时最能体现速度。故障排查页面要求区块导入速度高于每秒 2 个区块；按这一下限计算，从一天前的快照恢复的节点大约需要 12 小时才能追上链头，因为链仍在每 1.5 秒增加一个区块（按我们的计算）。

内存方面，最低 32 GB、建议 64 GB 的要求为 Bor 的缓存留出了空间：其主网哨兵节点模板分配 4 GB，上文的归档配置则是它的六倍。

端口与带宽

上表综合了前置条件页面和网络配置页面的内容。Polygon 提醒，如果 30303 端口没有同时开放 TCP 和 UDP，节点“将难以找到对等节点”。

每种节点类型都要求 1 Gbit/s，文档也没有给出每月流量数据。首次下载占了大头：以 1 Gbit/s 的持续速率计算，6.6 TB 的全节点快照约需 15 小时，11.9 TB 的归档快照约需 26 小时。如果镜像站的速度跟得上，10 Gbit/s 端口可将时间分别缩短到约 1.5 小时和 2.6 小时；在 10 Gbps 不限流量端口上，这些流量永远不会体现在账单上。

Polygon 节点选哪款 PowerDedi 服务器

RAID 在下单或重装系统时选择：双硬盘服务器可选 RAID 1（默认）、RAID 0 或不做 RAID；四硬盘 NVMe 服务器另外还可选 RAID 10（四硬盘服务器的默认选项）和 RAID 5。详情请参阅我们的软件 RAID 指南。

坦白说，有几点需要注意：

• 双硬盘服务器已经容纳不下完整历史的主网节点。即使做条带化，容量最大的双盘组合也只有 7.68 TB，仅比目前的数据量多约 0.4 TB。EPYC 9555P 是能容纳的最小配置：按近 13 个月的平均增长速度计算，它在 RAID 5 下 4.2 TB 的余量可以用一年以上；但按文档给出的每天 105 GB 计算，只够用约 40 天。
• 验证节点做镜像，归档节点做条带化。验证节点能承受的停机时间只有几个小时，因此两台机器都应保持 RAID 1。Polygon 的归档节点一行本身就指定了 RAID 0，而条带化的归档节点即使坏了一块硬盘，也能从快照恢复，以 1 Gbit/s 下载约需一天。RAID 5 介于两者之间：可承受一块硬盘故障，但写入时有校验开销。
• 预算较紧的归档方案。采用 RAID 0 的 EPYC 9555P 可容纳目前 12.95 TB 的 Bor 归档，并余下约 2.4 TB，但容量低于文档要求的 16 TB。EPYC 9965 满足这一要求且留有余量；它的基础频率为 2.25 GHz，是我们所有 EPYC 中最低的，因此选择它是为了硬盘，而不是为了核心。
• 不适合的情况。我们的存储服务器：其机械硬盘阵列无法提供 Polygon 要求的 IOPS；以及只需读取链上数据的用户：文档建议他们改用 RPC 端点。

Polygon 文档没有规定节点必须部署在哪个地区，因此请选择离您的用户最近的城市：9950X3D 位于阿姆斯特丹、法兰克福、纽约和洛杉矶，9555P 位于阿姆斯特丹、法兰克福、纽约和东京，9965 位于阿姆斯特丹、法兰克福和纽约。

如何运行 Polygon 全节点：部署概要

以下步骤采用 Polygon 全节点指南中的安装包和命令，版本为截至 2026 年 10 月 15 日的最新版本；快照文件名为占位符。

# 1. Install Heimdall-v2 and Bor ("sentry" is the full-node profile)
curl -L https://raw.githubusercontent.com/0xPolygon/install/heimdall-v2/heimdall-v2.sh | bash -s -- v0.12.2 mainnet sentry
curl -L https://raw.githubusercontent.com/0xPolygon/install/main/bor.sh | bash -s -- v2.10.3 mainnet sentry

# 2. Initialize Heimdall for mainnet and fetch the migrated genesis (about 3 GB)
sudo -u heimdall heimdalld init my-node --chain-id=heimdallv2-137 --home /var/lib/heimdall
cd /var/lib/heimdall/config
curl -fsSL https://storage.googleapis.com/mainnet-heimdallv2-genesis/migrated_dump-genesis.json -o genesis.json

# 3. Restore community snapshots into the data directories (follow the provider's steps)
lz4 -dc HEIMDALL_SNAPSHOT.tar.lz4 | tar -x

# 4. Start Heimdall; start Bor only once "catching_up" is false
sudo service heimdalld start
curl localhost:26657/status
sudo service bor start
journalctl -u bor.service -f

如果您的配置模板中缺少 Heimdall 的种子节点和 Bor 的引导节点，请按文档中的种子节点列表进行设置。有三点需要注意：

• 升级频繁。主网在 2026 年先后于 6 月 2 日、6 月 25 日（Zurich）、7 月 29 日（Ithaca）、8 月 13 日（Austin，要求 Bor v2.10.0 或更高版本）和 10 月 1 日（Lugano，Heimdall v0.12.1）进行了硬分叉。仍在运行 v0.11.0 或更早版本的 Heimdall 节点已停在 Lugano 分叉高度。
• 暂时不要使用 Docker 指南。该指南固定使用 Docker Hub 上的 Bor 1.1.0 和 Heimdall-v2 0.2.16 镜像，这些版本无法跟随主网越过上述硬分叉；而且从 Bor v2.10.2 和 Heimdall v0.12.2 起，已不再在 Docker Hub 上发布镜像。
• 恢复后检查文件所有权。快照页面关于权限的提示把两个目录弄反了：Bor 的数据目录应归 bor 用户所有，Heimdall 的数据目录应归 heimdall 用户所有。

在开放 26656 和 30303 以外的任何端口之前，请先按照我们的上线首小时安全加固清单逐项完成。

常见问题

我需要自己的 Polygon 节点吗？如果只是偶尔发送交易或读取链上数据，则不需要：前置条件页面会将只需连接网络的用户引导至 Polygon 的 RPC 端点列表。对于验证节点、索引器，以及请求量超出共享端点承载能力的应用，自建节点才有意义。

可以在 PowerDedi 上运行 Polygon 验证节点吗？可以：我们的可接受使用政策允许运行节点和验证节点，但不允许挖矿。库存、机房位置和加密货币支付方式请见区块链节点托管页面。

参考资料

• 前置条件和已知问题与错误 — Polygon 开发者文档（查询于 2026 年 10 月 15 日）
• 使用快照同步节点 — Polygon 开发者文档
• 使用二进制文件、使用软件包和使用 Docker — Polygon 开发者文档
• 网络配置、Polygon Chain 概览和相对 v1 的变化 — Polygon 开发者文档
• 成为验证节点、验证节点最佳实践和验证节点性能要求 — Polygon 开发者文档
• 更新日志 — Polygon 开发者文档（2026 年 6 月 1 日至 10 月 12 日的条目）
• 逐步停止 Erigon 支持（2026 年 5 月 12 日）和Erigon 更新与未来计划（2025 年 9 月 30 日） — Polygon Labs，Polygon 论坛
• 0xPolygon/erigon — GitHub（于 2026 年 8 月 3 日归档）
• Bor README、default_config.toml、snapshot prune-block、主网归档模板，以及 v2.10.2 和 v2.10.3 的发行说明 — 0xPolygon/bor，GitHub
• v0.12.1（Lugano）和 v0.12.2 的发行说明 — 0xPolygon/heimdall-v2，GitHub
• 计划迁移 – Heimdall V1 → V2 — Polygon Status
• 100+ 条区块链的快速节点快照 — PublicNode by Allnodes（查询于 2026 年 10 月 15 日）