如何搭建 Binance Smart Chain (BSC) 节点

BNB Smart Chain——至今仍常被称为 Binance Smart Chain,这是它在 2022 年 2 月之前的名称——是一条 EVM 链,自 2026 年 1 月的 Fermi 硬分叉以来,每 0.45 秒出一个块,而在此之前,Maxwell 已于 2025 年年中将出块间隔减半至 0.75 秒。这样的速度对用户来说很友好,但对节点运营者来说要求很高:BSC 全节点需要服务器级别的硬件和正确的同步策略,只要有一项出错,节点就永远追不上链头。本指南是官方文档止步之处的”复制粘贴”版本:基于快照的搭建方式、bnb-chain geth 分支、systemd 单元配置、RPC 节点的安全说明、同步时间与成本的计算,以及关于何时根本不该运行节点的坦诚分析。

什么是 BSC 节点?您需要哪种类型?

BSC 节点运行链客户端,验证区块,并为您提供一个本地 JSON-RPC 端点,其接口与 Ethereum 相同:eth_blockNumber、eth_call、eth_sendRawTransaction 等等。实践中有四种类型值得关注。

全节点保留近期状态并提供 RPC 服务——这是默认选项,也是本指南的主题。快速节点是以 --tries-verify-mode none 启动的全节点;官方文档建议在导入速度比严格的状态树验证更重要的 RPC 工作负载中使用它。归档节点存储所有历史状态,需要两位数 TB 级别的磁盘空间,只有在索引和分析场景下才有意义。验证者负责出块,这需要被选入以质押 BNB 支撑的小型验证者集合——这是超出本搭建指南范围的另一个话题。

那轻节点呢?geth 分支继承了轻客户端代码,但实际上 BSC 上几乎没有什么在为轻节点对等方提供服务,因此可以认为”BSC 轻节点”不可用。如果精简全节点对您来说依然是”杀鸡用牛刀”,那正是 API 的用武之地——参见最后一节。

同样的选择以表格形式呈现,附 2026 年年中的磁盘数据:

BSC 与 Geth:一套代码库,两条链

BSC 的客户端是 go-ethereum 的一个分支,维护于 github.com/bnb-chain/bsc,二进制文件的名字就直接叫 geth。它使用相同的 JSON-RPC,接受大部分相同的参数,并加入了 BSC 的特有内容:Parlia 权益证明委任共识机制(单一进程即为整个节点——不像 Ethereum 合并后那样需要独立的共识客户端),以及诸如 --tries-verify-mode 之类的参数。由此产生两个实际后果:您的 Ethereum 工具链无需改动即可对接 BSC 节点;而且您必须运行 bnb-chain 的构建版本——上游 Geth 无法同步 BSC,这是关于”bsc geth”最常见的新手错误。

BSC 节点硬件要求

基础数据来自 bnb-chain/bsc 的 README,并针对 2026 年之前的数据增长做了调整:

拖垮大多数搭建方案的往往是 IOPS,而非容量。由于出块间隔只有 0.45 秒,节点需要持续不断地写入数据,而使用默认 IOPS 的云端块存储会逐渐落后于链头,并且永远无法追上。README 中的参考配置是配备 8000 预配置 IOPS、亚毫秒级读延迟的 AWS gp3(AWS 上的 m5zn.3xlarge 实例,或 Google Cloud 上的 c2-standard-16);专用服务器上的本地 NVMe 硬盘可以轻松超过这个门槛。

分步指南:从官方快照搭建 BSC 全节点

从创世区块开始同步是可行的,但并不是个好主意。官方文档本身也不建议这样做——他们建议尝试这种方式时使用 40k+ IOPS 的硬件,而且即便如此也需要数周时间。官方支持的路径是:下载链数据快照,在此基础上启动节点,让它追赶进度。以下命令假设使用的是 Ubuntu 24.04。

1. 准备服务器

sudo apt update && sudo apt install -y aria2 lz4 unzip jq
sudo useradd --no-create-home --shell /usr/sbin/nologin bsc
sudo mkdir -p /var/lib/bsc
sudo chown bsc:bsc /var/lib/bsc
sudo ufw allow 30311 comment 'bsc p2p'

30311 端口是 BSC 的点对点端口,也是唯一应该对外开放的区块链相关端口。RPC 端口仅保留在本地。

2. 下载 bnb-chain 的 geth 二进制文件

cd /tmp
curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest \
  | jq -r '.assets[] | select(.name=="geth_linux") | .browser_download_url' \
  | xargs wget -O geth_linux
chmod +x geth_linux
sudo mv geth_linux /usr/local/bin/geth-bsc
geth-bsc version

将二进制文件重命名为 geth-bsc,可以避免误将系统自带的上游 geth 用于运行 BSC 数据这一常见事故。

3. 获取 config.toml 和 genesis.json

cd /tmp
curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest \
  | jq -r '.assets[] | select(.name=="mainnet.zip") | .browser_download_url' \
  | xargs wget -O mainnet.zip
unzip -o mainnet.zip
sudo mv config.toml genesis.json /var/lib/bsc/
sudo chown bsc:bsc /var/lib/bsc/config.toml /var/lib/bsc/genesis.json

注意:geth-bsc init genesis.json 只有在从创世区块开始同步时才需要。走快照路线时您可以跳过 init——快照会自带自己的数据库。

4. 下载并解压快照

快照存放在官方仓库 github.com/bnb-chain/bsc-snapshots。截至 2026 年年中,该仓库发布了三种数据集:精简快照,压缩后约 1.6 TB(仅包含近期区块——正是本指南所需要的);完整快照,约 6 TB;以及增量快照,只获取相对于此前某个快照的变化部分,这是 Fermi 时代新增的功能(BEP-593)。当前这一代快照要求客户端版本不低于 v1.7.2,第 2 步中下载的版本已经满足这一要求。该仓库还提供了 fetch-snapshot.sh 脚本,可以一条命令完成下载、校验 MD5 校验和(-c 参数)以及解压;下面的手动方式展示了其背后的具体过程。有两种方式可以把归档文件放到磁盘上:

cd /var/lib/bsc
# Option A: resumable download, needs space for archive + extracted data
sudo -u bsc aria2c -x8 -s8 -c '<PASTE_SNAPSHOT_URL>'
sudo -u bsc bash -c "lz4 -cd geth.tar.lz4 | tar -x"

# Option B: stream-extract, needs space only once, but no resume
sudo -u bsc bash -c "wget -qO- '<PASTE_SNAPSHOT_URL>' | lz4 -d | tar -x"

aria2c 通过八个连接下载,并支持在中断后续传(-c)——如果只用普通的 wget,一次中断的多 TB 下载就得从头再来。解压完成后,链数据库必须位于 /var/lib/bsc/geth/chaindata;不同代快照的归档目录结构有所变化,如有需要请将内部的 geth 文件夹移动到该位置。解压前请先校验:将快照页面上的 MD5 值进行比对,或者让 fetch-snapshot.sh -c 自动完成校验——一个比特错误的 TB 级归档文件可能会让您损失一整天。方案 A 需要同时容纳归档文件和解压后数据的空间,对于精简数据集大约需要 2 TB 的额外余量,这也是推荐使用 4 TB 硬盘的真正原因。

5. systemd 单元

创建 /etc/systemd/system/bsc.service:

[Unit]
Description=BSC full node (bnb-chain geth fork)
After=network-online.target
Wants=network-online.target

[Service]
User=bsc
Group=bsc
Type=simple
Restart=always
RestartSec=5
TimeoutStopSec=600
LimitNOFILE=65536
ExecStart=/usr/local/bin/geth-bsc \
  --config /var/lib/bsc/config.toml \
  --datadir /var/lib/bsc \
  --cache 8000 \
  --tries-verify-mode none \
  --history.transactions 0 \
  --rpc.allow-unprotected-txs \
  --http --http.addr 127.0.0.1 --http.port 8545 \
  --http.api eth,net,web3

[Install]
WantedBy=multi-user.target

--tries-verify-mode none 是官方文档中的”快速节点”开关,推荐在您能接受状态一致性权衡的情况下用于 RPC 服务。--history.transactions 0 保持交易索引完整;较旧的指南出于同样目的使用已弃用的 --txlookuplimit 0。TimeoutStopSec=600 给节点十分钟时间在关闭时刷新数据——强制终止迟早会导致数据库损坏。

6. 启动并验证

sudo systemctl daemon-reload
sudo systemctl enable --now bsc
journalctl -fu bsc

健康的输出应该是持续不断的 “Imported new chain segment” 日志行。将您的高度与公共浏览器进行比对:

curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
  http://127.0.0.1:8545

转换十六进制结果并对照 bscscan.com 进行核实。当 eth_syncing 返回 false 且高度一致时,该节点即已上线。

保护 BSC RPC 节点的安全

上面的单元配置将 RPC 绑定到 127.0.0.1,这对只由本地软件使用的节点来说是正确的做法。如果其他机器需要访问,不要将 8545 端口直接裸露暴露到互联网上。请在前面部署 nginx 或 Caddy,配置 TLS、认证令牌或 IP 白名单以及速率限制。将 --http.api 保持为 eth,net,web3——切勿在可被外部访问的节点上暴露 admin、debug 或 txpool。未经身份验证的公开 BSC 端点会在几天内被发现并遭到大量请求轰炸,而不受限制的 eth_getLogs 调用甚至能拖垮强劲的硬件。P2P 端口 30311 仍是唯一应保持开放的区块链端口。有一点与 Ethereum 的不同值得一提:这里没有 engine API,也没有 JWT 密钥,因为 Parlia 不需要独立的共识客户端——防火墙和 localhost 绑定构成了全部的安全边界,因此必须确保它们配置正确。

监控与健康检查

BSC 节点通常以一种典型方式出问题:进程本身仍在运行,但节点却在不断落后于链头。进程级别的正常运行时间检查完全无法察觉这一点,因此应改为检查同步状态和区块高度。

# false = at the head; a sync object = still catching up
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' \
  http://127.0.0.1:8545

# peer count as hex
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}' \
  http://127.0.0.1:8545

更严格的检测方式是每隔几分钟将您的 eth_blockNumber 与第二个来源(公共端点或浏览器)进行比对,并在差距扩大时发出警报。请根据 BSC 的节奏校准阈值:400 个区块听起来很多,但在 0.45 秒出块间隔下只相当于三分钟的链上时间。照搬 Ethereum 工具的阈值在这里会宽松得多,起不到作用。

该分支继承了 Geth 的指标体系。启动时加上 --metrics(Prometheus 端点在 6060 端口,请保持仅限 localhost 访问),标准的 Geth Grafana 仪表盘大多可以直接使用而无需修改。在配置任何仪表盘之前,先设置两条告警规则:磁盘使用率超过 85% ,以及本地区块高度五分钟内没有增长。每天在 cron 邮件中运行一次 journalctl -u bsc --since -24h | grep -ci error 可以进一步完善监控——错误数量呈上升趋势往往会提前数天预示大多数故障。

同步时间,以及快照为何依然有用

不谈承诺,只算数字:在持续 100 MB/s 的下载速度下,1.6 TB 的精简快照大约需要 4.5 小时下载完成;若为 50 MB/s,则约需 9 小时。解压过程受限于磁盘性能,在 NVMe 上会额外增加几个小时。快照通常落后链头一到两天;健康的节点导入速度是实时速度的数倍,因此追赶进度只需数小时,而非数天。总体而言,请预留一个工作日。相比之下,从创世区块同步即使在极端硬件上也要运行数周——这正是官方推荐使用快照的原因,没有例外。

状态增长与 pruning(裁剪)

数据库在第一天之后会持续增长——每个新合约和账户都会带来新的状态数据,区块数据则按照 0.45 秒出块间隔的节奏累积。具体的增长速度取决于网络活跃度;与其依赖一个固定数字,不如每周运行一次 du -sh /var/lib/bsc/geth/chaindata,自己构建增长趋势曲线。可以预期的规律是:每个季度增长数百 GB,而不是按年计算。

有三种工具可以控制数据库大小。geth-bsc snapshot prune-state 是内置的离线裁剪工具:它会丢弃不再被任何内容引用的状态节点,在多 TB 级别的数据库上运行需要耗费许多小时,而且节点在此期间无法提供任何服务。许多运营者更倾向于选择”清空并重建”这一替代方案:每隔几个月删除数据目录,重新恢复最新的精简快照。总停机时间通常比裁剪更短,而且还能额外获得一个刚刚整理压实过的数据库。

第三种工具随 Fermi 一起出现:增量快照(BEP-593)。您无需每次刷新都重新下载 1.6 TB 数据,而只需获取相对于您已有的快照版本发生变化的部分,这使得定期刷新从一项通宵作业变成了只需数小时的任务。bsc-snapshots 的 README 在经典归档方式旁边记录了这一工作流程。

BSC 上的 Erigon——及其继任者

多年来,BSC 归档节点需求的答案一直是 bsc-erigon,即 NodeReal 对 Erigon 的移植版本:从零开始完整归档同步大约需要三天,存储空间约为 4.3 TB,而 geth 分支则需要数十 TB。这一篇章已经结束。维护工作已于 2025 年停止,node-real/bsc-erigon 仓库于 2026 年 4 月被归档——仅可读取,不再修复问题,也不再支持未来的分叉。NodeReal 将运营者引导至基于 Rust 的继任者 Reth-BSC,将其作为未来推荐的归档客户端。

这在 2026 年年中的实际意义是:对于本指南中的精简 RPC 节点而言,官方 geth 分支仍是参考标准和最安全的选择。对于归档类工作负载,请优先评估 Reth-BSC,并将现有的 bsc-erigon 机器视为等待进行的迁移工作——一个不再维护的客户端将无法按时跟上下一次硬分叉。

BSC 节点的成本

请将其视为一种计算方法,而非报价单。16 核 / 64 GB / 4 TB NVMe 这一档次属于专用服务器的范畴——没有哪个诚实的 VPS 套餐能够覆盖这样的配置。在欧洲的主机服务商那里,具备这些规格的机器大致处于每月几百欧元的中低区间,仅作为数量级参考。用具备 8k 预配置 IOPS(README 中的 AWS 参考配置)的云实例搭建相同规格,通常价格会更高,往往高出两倍甚至更多,因为预配置 IOPS 是单独计费的。

接下来再加上您的时间成本:按照本指南进行初始搭建大约需要一个工作日,再加上硬分叉升级和快照刷新每月需要几个小时。将其乘以您的时薪。对大多数团队而言,人力成本这一项最终会超过主机托管费用——在做出承诺之前了解这一点很有必要。

维护:硬分叉与升级

BSC 硬分叉的节奏之快,常常让 Ethereum 的运营者感到意外。仅 2025 年就带来了 Lorentz 和 Maxwell,二者各自将出块间隔减半;随后 Fermi 于 2026 年 1 月 14 日到来,将出块时间从 0.75 秒缩短到 0.45 秒,同时引入了增量快照并加强了快速终结性。每次分叉都有一个最低客户端版本要求——Fermi 对应的是 v1.6.4——低于该版本的节点会在分叉区块处停滞并出现共识错误。截至 2026 年年中,发布版本线已经到达 v1.7.x,当前的快照要求客户端版本至少为 v1.7.2。

因此,请订阅 GitHub 上 bnb-chain/bsc 的发布动态,把升级当作日常工作,而不是突发事件来对待。整个流程很简短:下载新的 geth_linux,验证它,停止服务,替换 /usr/local/bin/geth-bsc,然后重新启动——数据库会被保留下来。发布说明会指出配置变更,而 BSC 重命名参数的频率比上游 Geth 更高,因此请在重启前而不是重启后浏览一遍这些说明。每次发布预留大约一刻钟时间,并预计每隔几个月就会遇到一次分叉。

对于开发环境,可以通过 BSC-Deploy 工具包获取本地私有网络,而不必运行主网节点。

故障排查

节点在导入区块,但持续落后于链头

几乎总是磁盘 IOPS 的问题。使用 fio 进行基准测试,并与 8k IOPS 的参考值进行比较;使用默认 IOPS 的网络附加存储通常是罪魁祸首。确认 --tries-verify-mode none 已设置。如果硬件配置低于要求表中的标准,任何参数都无法弥补这一差距。

“missing trie node” 错误,或节点在快照恢复后从区块 0 重新开始同步

数据目录结构不正确。链数据库必须位于 <datadir>/geth/chaindata——如果日志中显示 “Writing custom genesis block”,说明 geth 发现的是一个空的数据目录,于是重新开始。停止服务,将解压出的 geth 文件夹移动到正确位置,再重新启动。

对等节点数量始终接近零

检查 30311 端口是否已开放并做了端口转发。过时的 config.toml 是第二个可疑因素:引导节点和静态节点列表会随时间变化,因此请从最新版本重新下载 mainnet.zip。在家庭网络连接下,还应额外检查 NAT 设置。

解压时 lz4 报告 “Decoding error”

说明归档文件不完整。使用 aria2c -c 恢复下载,并在再次解压前将文件大小与快照页面上标注的大小进行比对。请记住,方案 A 需要同时为归档文件和解压后的数据预留空间。

OOM killer 终止了节点

journalctl -k | grep -i oom 可以确认这一点。该单元设置了 --cache 8000,而在追赶进度期间实际内存占用会明显超过缓存设定值——在推荐的 64 GB 配置下没有问题,但在精简过的硬件上会成为问题。请优先降低 --cache,而不是先降低其他配置,同时保持 swap 启用作为崩溃缓冲区,并记住被 OOM 终止的节点不会刷新任何数据:下一次启动可能会遇到上文提到的 “missing trie node” 情况。

磁盘空间用尽

先运行 df -h,再运行 du -h --max-depth=2 /var/lib/bsc 来定位增长来源。被遗忘的快照归档文件是最常见的原因——仅精简版的 .tar.lz4 就约有 1.6 TB,如果跳过清理步骤,方案 A 会把它遗留在磁盘上。如果问题出在 chaindata 本身,请从最新的精简快照刷新数据,或执行离线裁剪(参见状态增长一节)。在 BSC 的增长曲线下,磁盘写满是一个规划失误,而不是运气不好;监控一节中提到的 85% 告警,正是为了给您争取所需的那一周时间。

常见问题

Binance Smart Chain 节点和 BNB Smart Chain 节点是一回事吗?

是的。该链在 2022 年 2 月从 Binance Smart Chain 更名为 BNB Smart Chain。文档、二进制文件和本指南描述的都是同一个网络;变化的只是名称。

2026 年 BSC 全节点有多大?

截至 2026 年年中,官方精简(pruned)快照压缩后约为 1.6 TB,完整快照约为 6 TB,工作数据库加上追赶数据大约在 2-3 TB 之间。考虑到快照解压过程中所需的临时空间,现实可行的规格是 4 TB NVMe 硬盘。

我能用普通的 Ethereum Geth 运行 BSC 节点吗?

不能。BSC 使用 Parlia 共识机制和自己的协议规则;只有 github.com/bnb-chain/bsc 上的分支才能同步它。二进制文件名称相同正是造成这种混淆的原因——这也是第 2 步中要将其重命名为 geth-bsc 的理由。

BSC 有轻节点(light node)吗?

实际上没有。分支中确实存在轻客户端代码,但网络几乎不为轻节点对等方提供服务。现实可行的选项是精简全节点、快速节点或使用 API。

运行全节点能赚 BNB 吗?

不能。出块奖励归属于被选中的验证者集合,这需要大量质押的 BNB 和社区投票。全节点为您提供独立的链上访问权限,而不是收入。

自建节点,还是使用 API?

一次坦诚的比较,毕竟 Chaingateway 正是这一替代方案的提供者。

如果您需要以大量、持续的方式消耗原始 JSON-RPC——索引、回测、在数百万区块中扫描日志——或者不允许任何第三方介入您与链之间,那就运行自己的节点。专用服务器是固定成本、请求次数不受限制,一旦调用量超过某个临界点,它就会胜过任何按量计费的套餐。由于 BSC 的硬件门槛虽高但相对稳定,其盈亏平衡点往往比大多数链来得更快。

如果节点只是充当支付业务的”管道”,那就该使用 API。一个已同步的 BSC 全节点能给您 eth_sendRawTransaction 和日志;而一个支付系统真正需要的一切——每位客户的存款地址、检测传入的 BEP-20 转账、已签名的 webhook、密钥存储、失败重试——都是您需要自行在此基础上构建并持续维护的软件。按照成本一节中的费率计算,这些工程时间成本会远远超过服务器账单。

Chaingateway 的 BNB Smart Chain API 以 REST 形式覆盖了这一层:导入地址(POST /api/v2/bsc/addresses/import)、发送 BEP-20 代币(POST /api/v2/bsc/transactions/bep20),以及接收 HMAC 签名的存款 webhook——GET /api/v2/bsc/webhooks/notifications/failed 列出失败的投递记录,每一条都可以通过重试端点重新发送。盈亏平衡点用一句话概括:专用服务器加上您的搭建与运维时间,对比 /zh/pricing/ 页面上的套餐。对于支付流程而言,API 在远超小企业规模之前都会更具成本优势;而对于原始 RPC 算力需求,自建节点会更早胜出。快速入门 和 Webhook 指南 能让您在几分钟内完成首次测试,而 7 天试用期无需 KYC 验证(注册)。

同时还在运行其他链?请参阅 Ethereum 和 TRON 的搭建指南。