GoQuorum私有QBFT网络节点异常后停止出块问题求助

核心问题定位：QBFT共识轮次无法推进 #

QBFT持续触发ROUND-CHANGE但无法出块，核心原因集中在验证节点集一致性或节点本地共识状态损坏，具体拆解如下：

1. 验证节点集配置不一致 #

你移除了崩溃节点后，需确认两个关键配置是否统一：

• 所有剩余4个验证节点的genesis.json中extraData字段的验证者列表必须完全一致。QBFT要求所有节点的验证集合严格匹配，否则共识消息无法获得多数节点认可，导致轮次无限循环。
• 检查每个节点的static-nodes.json是否包含全部4个验证节点的enode地址，且地址为K8s集群内可访问的IP或服务名；若开启权限网络，确认--permissioned启动参数在所有节点上一致。

2. 非正常关闭导致的共识状态损坏 #

多次强制删除Pod重启节点，可能破坏节点本地QBFT共识状态：

• GoQuorum的QBFT共识状态存储在geth/chaindata下的LevelDB数据库中，非正常关闭易引发状态不一致（如本地记录的共识轮次、投票状态与其他节点不匹配），触发持续的ROUND-CHANGE。
• 验证方式：对比4个节点geth/chaindata目录下共识数据库的文件大小，若差异明显，说明存在损坏。

3. "replacement transaction underpriced"报错的关联 #

该报错是表象：内存池中的交易gasPrice为0，新提交的交易gasPrice同样为0，GoQuorum默认不允许相同nonce的交易以相同或更低gasPrice替换。但这不是出块失败的直接原因，根源是共识无法推进导致交易无法打包。

关于UPnP日志的说明 #

日志中"no UPnP or NAT-PMP router discovered"是无关警告，K8s集群内部节点通信不需要UPnP，该信息不会影响节点连接与共识，可直接忽略。

链数据损坏的排查方法 #

• 所有节点块高已同步至359732，说明链上数据未损坏，问题出在共识状态而非链数据本身。
• 可导出某一节点的链数据（执行geth export命令），导入到全新验证节点中启动，观察是否能正常参与共识，以此验证链数据完整性。

修复步骤建议 #

1. 统一验证节点配置：确保所有4个节点的genesis.json验证者列表、启动参数、静态节点配置完全一致。
2. 重置共识状态：停止节点后，删除geth/chaindata下的QBFT共识数据库（或执行geth init --datadir ./data genesis.json重新初始化共识状态，需确保genesis文件正确）。
3. 重启节点：依次启动4个验证节点，观察日志是否停止ROUND-CHANGE循环，开始正常出块。
4. 处理交易报错：共识恢复后，执行geth txpool clear清理内存池旧交易，重新提交即可解决"replacement transaction underpriced"问题。

内容的提问来源于stack exchange，提问作者Dvinubius