BSC网络节点类型详解
一、节点类型概述
- 验证者节点(Validator Node)
- 全节点(Full Node)
- 归档节点(Archive Node)
4. 引导节点(Boot Node)
归档节点特点
全节点特点
验证者节点特点
BSC 网络节点类型

引导节点是一种超轻量级的节点,主要运行发现协议(Discovery Protocol),官方建议在生产环境中使用普通全节点作为引导节点,引导节点是BSC网络中的一个特殊角色,它不参与具体的区块链操作,而是专注于帮助维护网络的连通性,使新节点能够快速地发现和加入网络。这种设计使得网络更具弹性和去中心化特性. 下文不在对引导节点做区别比较。
二、状态存储方案对比
状态存储方案

1. Path方案(path)
- BSC的默认存储方案
- 更高的性能和更低的存储需求
- 支持状态剪枝
- 适用于验证者节点和普通全节点
2. Hash方案(hash)
- 传统的状态存储方案
- 支持完整的历史状态访问
- 归档节点必须使用此方案
- 需要更大的存储空间
三、验证者节点(Validator Node)
1. 核心特点
- 固定数量:BSC网络只有21个验证者节点
- 质押要求:最少质押10000 BNB
- 选举机制:通过Staking投票选举产生
- 获得奖励:出块奖励和交易手续费
2. 配置要求
# 命令行参数配置
--mine # 启用挖矿功能
--miner.etherbase # 设置接收奖励的地址
--unlock # 解锁账户
--password # 账户密码文件路径
# config.toml 配置
[Node]
IPCPath = "geth.ipc"
HTTPHost = "0.0.0.0"
HTTPPort = 8545
HTTPVirtualHosts = ["*"]
HTTPModules = ["eth", "net", "web3", "txpool", "parlia"]
[Node.P2P]
MaxPeers = 50
NoDiscovery = false
[Eth]
SyncMode = "full"
NoPruning = false # 可以启用状态剪枝
StateScheme = "path" # 使用path方案存储状态
3. 重要说明
- 必须满足质押和选举要求
- 推荐使用默认的path存储方案
- 可以启用状态剪枝以节省存储空间
四、全节点(Full Node)
1. 主要特点
- 数量不限:任何人都可以运行
- 无质押要求
- 支持状态剪枝
- 使用path存储方案
2. 配置要求
# 命令行参数配置
--http # 启用HTTP-RPC服务
--http.addr # RPC监听地址
--http.port # RPC监听端口
--http.api # 开放的API(eth,net,web3)
--ws # 启用WebSocket服务
--ws.addr # WebSocket监听地址
--ws.port # WebSocket监听端口
--datadir # 数据目录
# config.toml 配置
[Node]
HTTPHost = "0.0.0.0"
HTTPPort = 8545
HTTPModules = ["eth", "net", "web3"]
WSHost = "0.0.0.0"
WSPort = 8546
WSModules = ["eth", "net", "web3"]
[Node.P2P]
MaxPeers = 50
NoDiscovery = false
[Eth]
SyncMode = "full"
NoPruning = false # 启用状态剪枝
StateScheme = "path" # 默认使用path方案存储状态
GcMode = "full" # 垃圾回收模式
3. 应用场景
- DApp后端服务
- 钱包服务
- 交易所接入
- 一般区块链应用
五、归档节点(Archive Node)
1. 核心特点
- 存储完整历史状态
- 不进行状态剪枝
- 存储空间:数TB级别
- 必须使用hash存储方案
2. 配置要求
# 命令行参数配置
--http # 启用HTTP-RPC服务
--http.addr # RPC监听地址
--http.port # RPC监听端口
--http.api # 开放的API(eth,net,web3)
--ws # 启用WebSocket服务
--ws.addr # WebSocket监听地址
--ws.port # WebSocket监听端口
--datadir # 数据目录
--gcmode archive # 归档模式
# config.toml 配置
[Node]
HTTPHost = "0.0.0.0"
HTTPPort = 8545
HTTPModules = ["eth", "net", "web3"]
WSHost = "0.0.0.0"
WSPort = 8546
WSModules = ["eth", "net", "web3"]
[Node.P2P]
MaxPeers = 50
NoDiscovery = false
[Eth]
SyncMode = "full"
NoPruning = true # 禁用状态剪枝,保留所有历史状态
StateScheme = "hash" # 必须使用hash方案存储状态
GcMode = "archive" # 归档模式
3. 硬件要求
- 大容量存储(数TB)
- 高性能I/O
- 建议使用NVMe SSD
六、节点配置对比表
| 配置项 | 验证者节点 | 全节点 | 归档节点 |
|---|---|---|---|
| StateScheme | path | path | hash |
| NoPruning | false | false | true |
| GcMode | full | full | archive |
| 存储方案特点 | 高性能 | 高性能 | 完整历史 |
| 状态存储 | 近期状态 | 近期状态 | 完整历史 |
| 存储空间 | ~1TB | ~1TB | 数TB |
| 查询能力 | 近期状态 | 近期状态 | 完整历史 |
七、存储方案选择建议
- 验证者节点:
- 推荐使用:path方案
- 原因:更高的性能和更低的存储需求
- 可以启用状态剪枝
- 全节点:
- 推荐使用:path方案
- 原因:BSC默认且优化的存储方案
- 适合大多数应用场景
- 归档节点:
- 必须使用:hash方案
- 原因:支持完整历史状态访问
- 不能启用状态剪枝
八、启动命令示例
- 验证者节点:
geth --mine --miner.etherbase 0xYOUR_ADDRESS \ --unlock 0xYOUR_ADDRESS \ --password /path/to/password.txt \ --config /path/to/validator.toml
- 全节点:
geth --config /path/to/fullnode.toml \ --datadir /path/to/data
- 归档节点:
geth --config /path/to/archive.toml \ --datadir /path/to/data \ --gcmode archive
九、总结
- 存储方案选择:
- path方案:适用于验证者和全节点,是BSC的默认优化方案
- hash方案:归档节点必需,支持完整历史状态访问
- 状态剪枝:
- 验证者和全节点:可以启用剪枝,只保留近期状态
- 归档节点:不能剪枝,保留所有历史状态
- 性能考虑:
- path方案:提供更好的性能和更低的存储需求
- hash方案:需要更多存储空间,但支持完整历史查询

浙公网安备 33010602011771号