本页目录 11 个章节
根据 BNB Chain 文档，BNB Smart Chain 全节点需要 16 个核心、64 GB 内存、一块高速 SSD 和 5 MB/s 的带宽；验证节点则需要 128 GB 内存、7 TB NVMe 和 512 Mbps 带宽。磁盘需求一直在变化：2026 年 10 月的快照压缩后，已修剪版约 1.9 TB，含完整历史的版本约 7.4 TB。
这些数字大多早于 2026 年 1 月 14 日的 Fermi 硬分叉，该硬分叉将 BSC 的出块时间缩短至 0.45 秒。下文将这些数字与 2026 年 10 月的快照进行对比，指出取代 BSC-Erigon 的归档客户端，并为每种节点类型匹配相应的服务器。
简要结论
| 节点类型 | CPU | 内存 | 文档中的磁盘要求 | 快照（2026 年 10 月） | 带宽 |
|---|---|---|---|---|---|
| 快速节点（Geth，不校验状态根） | 16 核 | 32 GB | 2 TB SSD | 460.87 GB（48Club，10 月 15 日） | 5 MB/s |
| 全节点，近期历史 | 16 核 | 64 GB | 3 TB SSD，8k IOPS | 约 1.9 TB（BNB Chain，10 月 9 日） | 5 MB/s |
| 全节点，完整历史 | 16 核 | 64 GB | 3 TB（2023 年 12 月的数据） | 约 7.4 TB（BNB Chain，10 月 9 日） | 5 MB/s |
| 验证节点（Geth） | AWS i7i.8xlarge 级别，400 mgasps 或以上 | 128 GB | 7 TB NVMe，40k IOPS | 取决于保留的历史数据 | 512 Mbps 或以上 |
| 归档节点（现为 Reth-BSC） | 16 核 | 128 GB | 10 TB SSD，建议使用 NVMe | 7,461.58 GB（Reth-BSC，10 月 2 日） | 5 MB/s |
快照大小指压缩后的下载文件大小；BNB Chain 要求另外预留解压空间。文档中的归档节点数据是针对 Erigon 编写的，而该客户端现已停止维护。
BNB Chain 官方硬件要求
BNB Chain 的要求分散在多个页面上，而这些页面并非同时更新。节点最佳实践（Node Best Practices）页面最近更新于 2024 年 7 月 18 日，为所有节点类型规定了 16 个核心和至少 5 MBps 的带宽，此外还有：
- 快速节点，标注为“推荐配置”：32 GB 内存和一块 2 TB SSD。
- 全节点：64 GB 内存和一块 3 TB SSD。
- 归档节点：128 GB 内存和 10 TB SSD，并“建议使用 NVMe 以获得最佳性能”。
bsc 客户端的 README 补充了主网全节点的磁盘性能要求：“3 TB（2023 年 12 月）可用磁盘空间”、8k IOPS、500 MB/s、读取延迟低于 1 ms，snap 同步时需使用 NVMe；另需 16 个核心、64 GB 内存，以及上下行各 5 MB/s（约 40 Mbit/s）的带宽。2026 年 2 月更新的节点维护（Node Maintenance）页面重复了这些磁盘数据。
自 2025 年 4 月以来，三次硬分叉先后将出块间隔从 3 秒缩短至 1.5 秒、0.75 秒和 0.45 秒，数据量也随之增长：按照快照仓库自己提出的“可用空间为快照大小两倍”的规则，README 中的 3 TB 连已修剪快照都已容纳不下。
2026 年 10 月 BSC 节点需要多少磁盘空间
BNB Chain 不建议从创世区块开始同步，并在其 bsc-snapshots 仓库中每月发布 Geth 快照：一份是包含自创世以来所有区块的完整快照，另一份是只含状态和近期区块的已修剪快照。将其文件列表中的文件大小相加，可得到以下增长曲线（均为压缩后大小）：
| 快照 | 基准区块 | 完整快照 | 已修剪快照 |
|---|---|---|---|
| 2025年10月13日 | 64,198,666 | 4,270 GB | 1,286 GB |
| 2026年1月4日 | 73,745,891 | 4,936 GB | 1,388 GB |
| 2026年4月8日 | 90,778,787 | 5,620 GB | 1,509 GB |
| 2026年8月5日 | 113,615,622 | 6,619 GB | 1,742 GB |
| 2026年10月9日 | 126,063,687 | 7,376 GB | 1,899 GB |
十二个月间，链上新增了约 62 百万个区块；完整快照增长了 73%，约合每月 260 GB，已修剪快照增长了 48%，约合每月 50 GB，且自 8 月以来增速加快（分别约为每月 350 GB 和 75 GB）。这是我们根据 BNB Chain 文件列表计算得出的结果，并非官方预测。由此带来三点影响：
- 预留的空间要多于下载量。README 要求“为解压预留额外的磁盘空间”，一份较早的指南则要求“至少为快照大小的两倍”。已修剪快照是一个 1,899 GB 的压缩包；除非您以流式方式将下载内容直接交给
tar并跳过 MD5 校验，否则该压缩包会与解压出的数据同时占用磁盘。 - 社区还提供更小的快照。BNB Chain 仓库中致谢的 48Club 于 2026 年 10 月 15 日在区块 127,680,000 处发布了 zstd 格式的快照：全节点版 1,371.98 GB，快速节点版 460.87 GB，两者均设置为保留最近 600,000 个区块。
- 带宽决定恢复时间。以 1 Gbps 持续速率计算，已修剪快照约需 4 小时，完整快照约需 16.5 小时；按文档给出的 5 MB/s 计算，则分别需要 4.5 天和 17 天。
快速节点、修剪节点还是完整历史：该选哪一种
这三种节点都运行基于 Geth 的 bnb-chain/bsc 客户端，区别在于保留的历史数据和状态验证方式：
- 完整历史是默认模式（
--history.blocks0，即“整条链”）。它可以提供任意旧区块、交易或收据，满足区块浏览器和索引器的需要，代价是上文所述的 7.4 TB。 - 近期历史：使用已修剪快照，配合
--history.blocks=600000和相应的索引限制，可保留约 75 小时的区块，同时仍会验证每一个状态根（--tries-verify-mode=local，默认设置）。 - 快速节点：
--tries-verify-mode none会跳过状态根验证；客户端的帮助文本称，这样做“有极小的概率导致状态与其他对等节点不一致”。一旦运行过geth db delete-trie-state，除非使用新的快照，否则“无法再切换回全节点”。
以上都不是归档节点。BNB Chain 的快照 FAQ 指出，“只有最近 129（128+1）个区块的状态可以通过 RPC 查询”，按每个区块 0.45 秒计算还不到一分钟；FAQ 还指出，在状态缺失时，快速节点可能返回 0 而不是报错。要查询较早区块时的余额或合约状态，需要归档节点。
文档中有一个陷阱：节点维护页面仍在推荐 --pruneancient 和离线工具 prune-block。而 v1.5.18 版本已弃用前者、移除后者，两者均由 --history.blocks 取代。
BSC 归档节点：Reth-BSC 已取代 Erigon
BNB Chain 的归档节点页面最近更新于 2025 年 1 月，仍在推荐 NodeReal 的 BSC-Erigon，称其“仅需 3 天、占用 4.3 TB 磁盘空间即可从零同步一个归档节点”，要求 64 GB 内存，磁盘最低 5 TB。这一建议已经过时。BSC-Erigon 的停止维护公告宣布在 2025 年 12 月 31 日之后停止开发和维护，并引导用户转向 Reth-BSC；该仓库已于 2026 年 4 月 23 日归档。其最后一个版本 v1.4.3 早于 Mendel（2026 年 4 月）和 Pasteur（2026 年 8 月）这两次硬分叉，而两者都是强制升级。
其继任者 Reth-BSC 位于 GitHub 上的 bnb-chain 组织中：
- 成熟度。其 README 称该项目“处于实验阶段，仍在积极开发中”。2026 年 7 月发布的 v0.1.1 版本为主网排定了 Pasteur 硬分叉；v0.1.2 版本则修复了该分叉过渡时的一个状态根问题。
- 数据量。2026 年 10 月 2 日的主网归档快照由八个压缩文件组成，共 7,461.58 GB，并要求设置
--db.max-size=12TB。实际占用的磁盘空间更大：README 在 2025 年 9 月给出的数字是 10.6 TB；2026 年 9 月，一位运营者报告其 MDBX 占用 793 GB，另有 12 TB 的静态文件。 - 磁盘速度。在 2026 年 9 月和 10 月的两个 issue 中，用户反映归档节点在虚拟磁盘或云盘上同步落后，项目的一位贡献者指出磁盘性能可能是瓶颈，并建议使用本地 NVMe。其中一位运营者的节点在每秒约 180 个 RPC 请求以上时就会落后。
规划归档节点时，请按 16 TB 或以上的本地 NVMe 准备，而不是 2024 年列出的 10 TB，并配备至少 16 个核心和 128 GB 内存。Reth-BSC 的 README 将其 --full 模式标为“推荐”；该模式的主网快照在 10 月 2 日为 3,473.25 GB。
BSC 验证节点要求：硬件与质押
运行 BSC 验证节点（Run BSC Validator）页面更新于 2026 年 2 月 6 日，它设定的门槛高于其他任何节点类型：
- 计算：AWS i7i.8xlarge 或 i7ie.6xlarge，“最好关闭超线程（HyperThread），可带来 10% 以上的性能提升”，“或选择其他能达到 >=400 mgasps 的实例规格”。AWS 标注这两款实例分别为 32 个 vCPU 配 256 GiB 内存、24 个 vCPU 配 192 GiB 内存，采用第五代 Xeon Scalable 处理器，全核睿频 3.2 GHz：不计超线程时分别为 16 个和 12 个核心。
- 内存：128 GB。
- 磁盘：“重要：7TB，NVMe SSD，40k IOPS，500 MB/S 吞吐量，读取延迟 <1ms。”
- 网络：512 Mbps 或以上。
客户端会在每一行“Imported new chain segment”日志中记录 mgasps（每秒百万 gas）；请在从快照追赶进度时查看该数值，然后再注册验证节点。
此外还需要质押：至少 2,000 BNB 的自委托。每日选举按质押量选出排名前 45 的验证者，其中 21 名为“内阁”（Cabinet）成员，24 名为“候选”（Candidate）成员，每个纪元（epoch）由其中 21 名负责出块。24 小时内错过的区块超过 50 个将失去奖励；超过 150 个则罚没 10 BNB 并监禁两天；同一套密钥同时在两台机器上签名属于双签，将被罚没 200 BNB 并监禁 30 天。
因此，BNB Chain 推荐的备用节点是通过在一台机器上执行 miner.stop()、在另一台机器上执行 miner.start() 来接管的，绝不能作为第二个同时在线的签名者；请按两台服务器做预算。验证节点可以公开自己的 IP，也可以隐藏在哨兵节点之后，具体见增强型验证者网络（Enhanced Validator Network，EVN）指南。该指南没有指定地区，但引用了 AWS 测得的延迟：亚太到欧洲约 100 ms，亚太到美国约 80 ms，美国到欧洲约 35 ms，而出块间隔为 450 ms。
端口与带宽
| 服务 | 默认 | 开放对象 |
|---|---|---|
| Geth P2P，TCP 和 UDP | 随附的主网 config.toml 中为 30311；文档中为 30303 | 公网 |
| Geth HTTP JSON-RPC | 8545，在 config.toml 中绑定到 localhost | 仅限可信客户端 |
| Geth WebSocket | 8546 | 仅限可信客户端 |
| Reth-BSC HTTP、WebSocket、auth RPC、监控指标 | 项目示例中为 8545、8546、8551、6060 | 仅限可信客户端 |
BNB Chain 文档的防火墙部分给出的 Geth TCP 和 UDP 端口为 30303，并要求 JSON-RPC 不对外开放，“因为通过它可以执行管理操作”。然而，v1.7.8 版本随附的 config.toml 设置的是 ListenAddr = ":30311"，也就是 EVN 和 Reth-BSC 对等节点列表中使用的端口；请开放您的配置实际使用的端口。Reth-BSC 的快照示例将 RPC 绑定到 0.0.0.0，因此请用防火墙加以限制。
没有任何页面估算每月流量；随附的配置允许 200 个对等节点（MaxPeers = 200）。在 10 Gbps 不限流量端口上，快照下载和对等节点流量都不会体现在账单上。
BSC 节点选哪款 PowerDedi 服务器
以下每种配置都配备独享的 10 Gbps 不限流量端口，按月计费。磁盘布局在下单或重装系统时选择：双硬盘服务器默认采用 RAID 1，也可选择 RAID 0 或无 RAID；四硬盘的 EPYC 9555P 和 9965 默认采用 RAID 10，也可选择 RAID 5 或 RAID 0，详见我们的软件 RAID 指南。
| 角色 | 配置 | 布局与可用 NVMe 容量 | 适用人群 | 价格 |
|---|---|---|---|---|
| 快速节点、轻量 RPC 后端 | Ryzen 9 9950X：16 核、128 GB DDR5、2 × 1.92 TB NVMe | RAID 1：1.92 TB | 高于 16 核、32 GB 的配置要求；容量比标称的 2 TB 低 4%，约为当前快速节点快照的四倍 | $159/月 |
| 全节点，近期历史 | Ryzen 9 9950X3D：16 核、192 GB DDR5、2 × 3.84 TB NVMe | RAID 1：3.84 TB | 高于 64 GB、3 TB 的全节点配置要求，且为镜像 | $219/月 |
| 预算型验证节点 | Ryzen 9 9950X3D | RAID 0：7.68 TB | 16 核（相当于关闭超线程的 i7i.8xlarge）、192 GB；仅保留近期历史；无冗余 | $219/月 |
| 带镜像的验证节点，或完整历史节点 | EPYC 9555P：64 核、768 GB ECC、4 × 3.84 TB NVMe Gen5 | RAID 10：7.68 TB；RAID 5：11.52 TB | RAID 10 满足验证节点保留近期历史时的 7 TB 要求；完整历史需要 RAID 5 或 RAID 0；24 小时内组装完成 | $949/月 |
| 归档节点（Reth-BSC） | EPYC 9965：192 核，1.5 TB ECC，4 × 7.68 TB NVMe Gen5 | RAID 10：15.36 TB；RAID 5：23.04 TB；RAID 0：30.72 TB | 唯一能以镜像方式容纳一位运营者报告的约 13 TB 数据的配置；72 小时内组装完成 | $1,790/月 |
坦白说，各方案的取舍如下：
- RAID 0 等于押注快照。条带化可使双硬盘服务器的容量翻倍，但一旦有硬盘故障，就要重装系统并恢复数据：以 1 Gbps 计算，修剪节点需要数小时，完整历史节点则要大半天。镜像可以扛过单块硬盘故障；而对验证节点来说，真正的冗余是备用节点。
- 完整历史正在超出两块硬盘的容量。压缩后已达 7.4 TB，且每月还要增加 260 至 350 GB，即使将两块 3.84 TB 硬盘做条带化也没有余量。在 EPYC 9555P 上，RAID 5 在压缩后大小之外还剩约 4 TB，按这一速度约可支撑一年；RAID 0 可提供 15.36 TB，但没有冗余保护。
- 恢复到 3.84 TB 的卷上会很紧张。在做镜像的 9950X3D 或做条带化的 9950X 上，按照 BNB Chain“预留快照两倍空间”的规则，1,899 GB 的已修剪快照压缩包几乎要占满整个卷；请以流式方式下载，或使用 48Club 更小的快照。EPYC 4585PX（$179/月）的硬盘与 9950X 相同，另配 ECC 内存。
- 归档节点的替代方案。采用 RAID 0 的 EPYC 9555P 同样能提供 15.36 TB，价格更低，但没有冗余，余量也很小。我们的存储服务器并不适合：其容量来自机械硬盘，而 BNB Chain 对所有节点都要求使用 SSD 或 NVMe。
- PowerDedi 不适合的情况。如果每秒请求数低于约 33 个，且不需要
eth_getLogs，BNB Chain 的公共端点可能就已足够（见下文）。
机房位置：9950X 位于阿姆斯特丹、法兰克福、伦敦、纽约、迈阿密、洛杉矶、新加坡和东京；9950X3D 位于阿姆斯特丹、法兰克福、纽约和洛杉矶；9555P 位于阿姆斯特丹、法兰克福、纽约和东京；9965 位于阿姆斯特丹、法兰克福和纽约。RPC 节点应部署在靠近您应用的位置；对于验证节点，BNB Chain 没有给出地区方面的建议，因此请在同步完成后测量到对等节点的延迟。
如何运行 BSC 全节点：部署概要
以下步骤遵循 BNB Chain 的全节点指南和快照 README，只有一处改动：锁定版本。该指南获取的是 GitHub 上标记为“latest”的版本，而在 2026 年 10 月，该版本是 v1.8.0-alpha，一个“不适用于生产环境”的预览版；最新的稳定版是 2026 年 8 月 11 日发布的 v1.7.8。
# 1. Pinned binary and mainnet config (config.toml, genesis.json)
wget https://github.com/bnb-chain/bsc/releases/download/v1.7.8/geth_linux
mv geth_linux geth
chmod -v u+x geth
wget https://github.com/bnb-chain/bsc/releases/download/v1.7.8/mainnet.zip
unzip mainnet.zip
# 2. Download, verify and extract the pruned snapshot into the datadir
wget https://raw.githubusercontent.com/bnb-chain/bsc-snapshots/main/dist/fetch-snapshot.sh
bash fetch-snapshot.sh -d -e -c -p --auto-delete -D /data/snapshot -E /data/bsc mainnet-geth-pbss-20261009
# 3. Start with recent history only (docs: --cache of about a third of RAM)
./geth --config ./mainnet/config.toml --datadir /data/bsc --cache 20000 --rpc.allow-unprotected-txs --syncmode=full --tries-verify-mode=local --history.transactions=600000 --history.blocks=600000 --history.logs=600000
# 4. Follow the import speed (mgasps)
tail -f /data/bsc/bsc.log | grep "Imported new chain segment"请按文档的做法用 kill -HUP 停止节点，而不要用 kill -9，后者会导致重放近期区块。请将节点作为 systemd 服务运行，并且只开放 SSH 和 P2P 端口。验证节点还需添加 --mine --vote，以及用 geth account new 和 geth bls account new 创建的共识密钥和 BLS 投票密钥。
常见问题
使用 BNB Smart Chain 需要自建节点吗？偶尔使用的话不需要。BNB Chain 的公共主网端点每五分钟允许 10,000 个请求，约合每秒 33 个，且禁用了 eth_getLogs。需要读取事件日志或更高吞吐量的索引器、交易所和交易系统，会运行自己的节点或付费使用 RPC 服务商。
可以在 VPS 或云实例上运行吗？README 提到了“VPS”，验证节点页面也列出了配备本地 NVMe 的 AWS 实例。薄弱环节在于网络块存储：上文提到的两个同步落后的 Reth-BSC 节点都运行在虚拟磁盘或云盘上。
运行验证节点算“挖矿”吗？不算。--mine 参数的作用是在权益权威证明（Proof of Staked Authority）机制下出块。PowerDedi 允许运行节点和验证节点，但不允许加密货币挖矿。
其他 EVM 链请参阅我们的以太坊节点硬件指南。当前库存请见区块链节点托管页面，可用 BTC、ETH、XMR、TRON 链上的 USDT 或 SOL 支付。
参考资料
- BNB Smart Chain（BSC）节点配置：最佳实践 — BNB Chain 文档（更新于 2024 年 7 月 18 日）
- 运行 BSC 验证节点 — BNB Chain 文档（更新于 2026 年 2 月 6 日）
- 全节点、BNB Smart Chain 快速节点和节点维护 — BNB Chain 文档（更新于 2026 年 2 月 6 日）
- 如何在 BNB Smart Chain 上运行归档节点 — BNB Chain 文档（更新于 2025 年 1 月 23 日）
- BSC 验证节点概览（更新于 2025 年 7 月 17 日）和 EVN 最佳实践 — BNB Chain 文档
- JSON-RPC-Endpoint — BNB Chain 文档（更新于 2026 年 8 月 19 日）
- bnb-chain/bsc README 及其发行版本（包括 v1.5.10、v1.5.18 和 v1.6.4），以及 v1.7.8 中的主网
config.toml— BNB Chain，GitHub - 关于 BSC 快照（2026 年 10 月 9 日的快照及历史文件列表）和常见问题 — bnb-chain/bsc-snapshots，GitHub
- bsc-snapshots — 48Club，GitHub（区块 127,680,000，2026 年 10 月 15 日）
- Reth @ BSC 及其发行版本和 issue #500、#517 与 #544 — bnb-chain/reth-bsc，GitHub（2026 年 9 月和 10 月）
- BSC-Erigon 客户端：停止维护公告 — node-real/bsc-erigon，GitHub（2026 年 4 月 23 日归档）
- Amazon EC2 I7i 实例 — Amazon Web Services（涵盖 I7i 和 I7ie）
