Solana 集群重启实战从 latest-optimistic-slots 到超级多数等待的完整操作规程【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana本文基于 Solana 官方运维文档 重启集群指南完整梳理“让全网验证者在同一插槽上同步重启”的标准操作程序SOP。读完本文你将掌握如何用solana-ledger-tool定位最新乐观确认插槽、创建带硬分叉hard fork的重启快照、通过--wait-for-supermajority等参数协调全节点在同一高度恢复出块以及当 80% 质押未能在线时如何用--destake-vote-account发起二次重启并理解每一步背后验证器与账本工具的源码级实现机制。一、适用场景与整体流程Solana 集群需要“协调式重启”的典型情形是发布了新的验证器版本或集群因故障停摆需要所有节点在同一个确定的插槽上安全地、原子性地恢复生产。直接让各节点按自己的本地进度重启可能导致节点之间从不同高度的账本继续出块造成共识分歧。官方规程见 docs/src/operations/guides/restart-cluster.md将重启拆分为一条严格的操作链定位全网最新的乐观确认插槽记为SLOT_X停止所有验证器可选升级到新版本用create-snapshot在SLOT_X处创建带--hard-fork SLOT_X的新快照得到新的 shred version 与 bank hash向验证者社区公告重启参数并协调上线等待并监听直到超级多数80% 激活质押可见后集群自动恢复出块若 80% 质押长时间未能参与则对未响应节点的投票账户执行 destake 后二次重启。下面按步骤展开并给出每一步对应的仓库源码实现。二、Step 1定位最新的乐观确认插槽 SLOT_X2.1 基本命令在 Solana 1.14 及以上版本直接运行solana-ledger-tool -l ledger latest-optimistic-slots该子命令会输出本地验证器观测到的最近乐观确认插槽默认 1 个。该子命令被刻意设计为始终可见的顶层命令——ledger-tool/src/blockstore.rs 中的注释明确写着“This command is important in cluster restart scenarios, so do not hide it ever”集群重启场景下该命令至关重要因此永不隐藏。它还支持两个可选参数定义于 ledger-tool/src/blockstore.rs参数默认值作用--num-slots NUM1输出最近 N 个乐观确认插槽便于核对不止一个候选高度--exclude-vote-only-slots关闭排除只包含投票交易的插槽重启锚点通常应选有实际交易的插槽2.2 输出格式与实现原理从 ledger-tool/src/blockstore.rs 的处理逻辑看输出为四列表格Slot、Hash、Timestamp、Vote Only?RFC3339 时间戳。值得注意的是其选取逻辑ledger-tool/src/blockstore.rs 的get_latest_optimistic_slots函数在X - Y - Z这样一条链上若 X 和 Z 被标记为乐观确认Y 作为 Z 的祖先可被隐式视为乐观确认但 blockstore 并不保证 Y 会被显式标记。因此源码没有只查 OptimisticSlots 列而是先取最新的乐观确认插槽再用AncestorIterator手动向上遍历其祖先对未显式标记的祖先打印 warning。这意味着latest-optimistic-slots给出的结果覆盖了“隐式确认”的祖先链比直接读列更保守、更适合做重启锚点。2.3 跨验证者核对与旧版本替代方案文档特别强调故障发生前不同验证者观测到的最新乐观确认插槽可能不一致。必须向集群上的其他验证者调研survey确认是否存在更大的乐观确认插槽若有改用更大的那个。这是选择SLOT_X时防止“锚点落后”的关键人工步骤。在 Solana 1.13 及更早版本没有该子命令需要查看乐观确认相关的 metrics datapoint 日志来定位最新乐观确认插槽该数据点的产出逻辑位于 core/src/optimistic_confirmation_verifier.rs文档指向该文件中乐观确认的 metrics 上报点。将最终选定的插槽记为SLOT_X。三、Step 2 / Step 3停止验证器并可选升级版本Step 2停止所有要参与重启的验证器进程。停止前建议确认账本目录完整可用solana-ledger-tool -l path/to/ledger bounds检查本地 ledger 覆盖的插槽范围后文公告模板中也会用到。Step 3可选步骤——安装新的 Solana 版本。公告模板中的示例正是以“发布了 v1.1.12 并准备让 testnet 重新上线”为场景说明升级版本 协调重启是标准组合操作。四、Step 4创建硬分叉快照并调整验证器参数4.1 创建快照$ solana-ledger-tool -l LEDGER_PATH \ --snapshot-archive-path SNAPSHOTS_PATH \ --incremental-snapshot-archive-path INCREMENTAL_SNAPSHOTS_PATH \ create-snapshot SLOT_X SNAPSHOTS_PATH --hard-fork SLOT_X执行后快照目录中会生成新的全量快照。solana-ledger-tool create-snapshot同时会输出两个关键值NEW_SHRED_VERSION新的 shred versionNEW_BANK_HASHSLOT_X处的 bank hash。create-snapshot子命令的参数定义在 ledger-tool/src/main.rs除--hard-fork、--destake-vote-account外还支持--remove-account、--deactivate-feature-gate、--remove-stake-accounts、--incremental等修改快照状态的选项其中--destake-vote-account支持多次传入见 ledger-tool/src/main.rshelp 文本为 “List of validator vote accounts to destake”将在排障章节使用。4.2 调整验证器启动参数在验证器启动参数中增加这两个参数在 validator/src/cli.rs 中有明确定义--wait-for-supermajority SLOT_X --expected-bank-hash NEW_BANK_HASH从源码定义看这三个重启相关参数有严格的依赖与语义参数定义位置语义--wait-for-supermajority SLOTvalidator/src/cli.rs“处理完 ledger 且下一个插槽为 SLOT 时等待超级多数质押在 gossip 上可见后再启动 PoH”要求同时提供--expected-bank-hash和--expected-shred-version.requires(...)链--expected-bank-hash HASHvalidator/src/cli.rs“当--wait-for-supermajority x时要求 x 处的 bank 必须是该 hash”用于防止节点从不同状态的分叉启动--expected-shred-version VERSIONvalidator/src/cli.rs要求 shred version 必须等于该值确保 gossip 上的节点属于同一个“重启纪元”因此实践中还应把create-snapshot输出的NEW_SHRED_VERSION配上--expected-shred-version一起下发给各节点shred version 不匹配的节点会被单独统计为 “wrong shred version” 质押见下文监控部分。4.3 重启验证器并确认进入等待状态重启验证器后确认日志显示验证器已启动并停在SLOT_X的“holding pattern”等待超级多数质押的状态。从 core/src/validator.rs 的等待循环看验证器在此阶段的行为是比较 ledger 加载出的 bank 插槽与--wait-for-supermajority的插槽若 ledger 数据不够bank 插槽小于目标插槽报错 “Ledger does not have enough data to wait for supermajority, please enable snapshot fetch.”——这解释了为什么公告模板中本地 ledger 未覆盖SLOT_X的节点不能带--no-snapshot-fetch校验 bank hash 与--expected-bank-hash一致不一致则以BadExpectedBankHash退出进入每秒一次的轮询计算 gossip 中可见的激活质押占比直到达到WAIT_FOR_SUPERMAJORITY_THRESHOLD_PERCENT即 80%才放行启动等待期间会rpc_override_health_check.store(true, ...)——伪报 RPC 健康防止负载均衡器在人工重启窗口内把节点摘除源码注释原话如此。一旦确定NEW_SHRED_VERSION还应通知基金会foundation入口点entrypoint运营者更新 entrypoint使后续节点能下载正确 shred version 的数据。五、Step 5向验证者社区公告重启文档给出的公告模板发布在 #announcements 频道按实际情况调整版本号和占位符Hi Validators,Weve released v1.1.12 and are ready to get testnet back up again.Steps:Install the v1.1.12 release: 安装官方 release 提供的对应版本a. 首选方式从你的本地 ledger 启动solana-validator --wait-for-supermajority SLOT_X # -- NEW! IMPORTANT! REMOVE AFTER THIS RESTART --expected-bank-hash NEW_BANK_HASH # -- NEW! IMPORTANT! REMOVE AFTER THIS RESTART --hard-fork SLOT_X # -- NEW! IMPORTANT! REMOVE AFTER THIS RESTART --no-snapshot-fetch # -- NEW! IMPORTANT! REMOVE AFTER THIS RESTART --entrypoint entrypoint.testnet.solana.com:8001 --known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on --expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY --only-known-rpc --limit-ledger-size ... # -- 你其他的 --identity/--vote-account 等参数b. 如果你的验证器 ledger 没有覆盖到SLOT_X或者 ledger 已被删除则改为下载快照启动solana-validator --wait-for-supermajority SLOT_X # -- NEW! IMPORTANT! REMOVE AFTER THIS RESTART --expected-bank-hash NEW_BANK_HASH # -- NEW! IMPORTANT! REMOVE AFTER THIS RESTART --entrypoint entrypoint.testnet.solana.com:8001 --known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on --expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY --only-known-rpc --limit-ledger-size ... # -- 你其他的 --identity/--vote-account 等参数可以用solana-ledger-tool -l path/to/ledger bounds查看你的 ledger 覆盖到哪些插槽。Wait until 80% of the stake comes online确认你的验证器是否正确等待 80% a. 查找N% of active stake visible in gossip的日志消息 b. 通过 RPC 询问它当前处于哪个插槽solana --url http://127.0.0.1:8899 slot在达到 80% 质押之前它应始终返回SLOT_XThanks!模板中每个参数标注 “REMOVE AFTER THIS RESTART” 的提示很重要--wait-for-supermajority、--expected-bank-hash、--hard-fork、--no-snapshot-fetch都是一次性重启参数集群恢复正常出块后必须移除否则下一次重启或升级时行为会不符合预期。两种启动方式的取舍方式 a本地 ledger --no-snapshot-fetchledger 完整覆盖SLOT_X时最快节点直接从本地数据加载到锚点插槽并原地等待方式 b下载快照本地 ledger 不足时从 entrypoint 获取覆盖SLOT_X的快照即 Step 4 中生成的、带 hard fork 的快照加载后同样停在SLOT_X等待。六、Step 7等待与监听重启进入“等待超级多数”阶段后协调者需要监控验证器上线进度每个节点的日志会周期性打印质押可见性统计。从 core/src/validator.rs 看节点每 10 轮约 10 秒打一次 “Waiting for 80.0% of activated stake at slot ... to be in gossip...”并持续输出三类占比core/src/validator.rs 的get_stake_percent_in_gossipN% of active stake visible in gossip—— 在线且 shred version 正确的激活质押占比只有它达到 80% 才会放行N% of active stake has the wrong shred version in gossip—— 在线但 shred version 不对的节点逐节点列出按质押降序指向“别人已按新 shred version 重启、你还没跟上”N% of active stake is not visible in gossip—— 未上线节点逐节点列出可据此联系缺席的验证者。回答验证者的问题、协助排查直到 80% 激活质押在 gossip 中可见所有等待中的节点会打印 “Supermajority reached, N% active stake detected, starting up now.” 并恢复出块。用solana --url http://127.0.0.1:8899 slot自检重启完成前该命令应始终返回SLOT_X。注意源码中的一个细节gossip 中“可见”的判定基于 contact info 的墙钟时间戳core/src/validator.rs过滤掉超过CRDS_GOSSIP_PULL_CRDS_TIMEOUT_MS的过期条目因此“在线”指的是近期在 gossip 中刷新过心跳的节点而不仅仅是进程存活。七、Troubleshooting80% 质押未能参与重启怎么办如果合理的等待时间过后参与重启的激活质押仍不足 80%则必须移除未响应验证者的质押后重试。流程如下社区识别未响应的验证者并就名单达成社会共识social consensus所有参与重启的验证者回到 Step 4在create-snapshot命令上为每个未响应验证者的投票账户地址追加一个--destake-vote-account PUBKEY参数重新生成快照并再次协调重启$ solana-ledger-tool -l ledger create-snapshot SLOT_X ledger --hard-fork SLOT_X \ --destake-vote-account VOTE_ACCOUNT_1 \ --destake-vote-account VOTE_ACCOUNT_2 \ . . . --destake-vote-account VOTE_ACCOUNT_N \效果新快照中所有与这些未响应验证者关联的质押会立即被去激活deactivated。集群重启成功后这些节点上的所有委托方staker需要重新委托re-delegate自己的质押。--destake-vote-account参数定义于 ledger-tool/src/main.rs标记为multiple(true)允许一次传入任意多个投票账户公钥参数值经is_pubkey校验。由于新快照改变了账户状态去激活质押会派生出新的NEW_BANK_HASHshred version 变化因此整个“生成快照 → 公告参数 → 等待 80%”的循环需要完整重走一遍——这也是文档强调“all participating validators return to Step 4”的原因。八、关键参数速查表环节命令 / 参数作用实现依据定位锚点solana-ledger-tool -l ledger latest-optimistic-slots输出最近乐观确认插槽、hash、时间戳ledger-tool/src/blockstore.rs定位锚点--num-slots NUM/--exclude-vote-only-slots输出多个插槽 / 排除纯投票插槽ledger-tool/src/blockstore.rs生成锚点快照create-snapshot SLOT_X PATH --hard-fork SLOT_X在指定插槽创建硬分叉快照输出 NEW_SHRED_VERSION 与 NEW_BANK_HASHledger-tool/src/main.rs二次重启--destake-vote-account PUBKEY可多次将未响应投票账户的质押在新快照中去激活ledger-tool/src/main.rs验证器等待--wait-for-supermajority SLOT_X在锚点插槽等待 gossip 中 80% 激活质押可见后再启动 PoH要求同时提供 bank hash 与 shred versionvalidator/src/cli.rs、core/src/validator.rs状态校验--expected-bank-hash NEW_BANK_HASH校验锚点插槽的 bank hash 与社区共识一致validator/src/cli.rs版本隔离--expected-shred-version NEW_SHRED_VERSION隔离不同“重启纪元”的节点validator/src/cli.rs快照获取策略--no-snapshot-fetch仅方式 aledger 完整时禁止拉取快照ledger 不足时该参数会导致 “NotEnoughLedgerData” 错误core/src/validator.rs自检solana --url http://127.0.0.1:8899 slot等待期间应始终返回SLOT_X文档公告模板进度观测N% of active stake visible in gossip日志80% 达到后打印 “Supermajority reached ... starting up now.”core/src/validator.rs九、小结这套规程的设计核心可以概括为三点单一锚点全网以同一个乐观确认插槽SLOT_X为重启基线且必须跨验证者交叉核对防止锚点选择偏旧状态一致性证明--expected-bank-hash--expected-shred-version让每个节点在启动时就能证明自己的状态与社区共识一致不一致的节点会被拒绝启动或被明确统计为 “wrong shred version”而非静默分叉原子化的恢复触发--wait-for-supermajority把“何时恢复出块”交给 80% 激活质押这一全网可观测条件避免任何单点决定恢复时机等待期间的 RPC 健康伪报core/src/validator.rs则保证了人工协调窗口内基础设施层不会干扰节点。当 80% 条件长期不满足时--destake-vote-account提供了确定性的兜底路径以牺牲少数未响应节点质押活性为代价让整个集群能够收敛并继续运转。【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Solana 集群重启实战：从 latest-optimistic-slots 到超级多数等待的完整操作规程
Solana 集群重启实战从 latest-optimistic-slots 到超级多数等待的完整操作规程【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana本文基于 Solana 官方运维文档 重启集群指南完整梳理“让全网验证者在同一插槽上同步重启”的标准操作程序SOP。读完本文你将掌握如何用solana-ledger-tool定位最新乐观确认插槽、创建带硬分叉hard fork的重启快照、通过--wait-for-supermajority等参数协调全节点在同一高度恢复出块以及当 80% 质押未能在线时如何用--destake-vote-account发起二次重启并理解每一步背后验证器与账本工具的源码级实现机制。一、适用场景与整体流程Solana 集群需要“协调式重启”的典型情形是发布了新的验证器版本或集群因故障停摆需要所有节点在同一个确定的插槽上安全地、原子性地恢复生产。直接让各节点按自己的本地进度重启可能导致节点之间从不同高度的账本继续出块造成共识分歧。官方规程见 docs/src/operations/guides/restart-cluster.md将重启拆分为一条严格的操作链定位全网最新的乐观确认插槽记为SLOT_X停止所有验证器可选升级到新版本用create-snapshot在SLOT_X处创建带--hard-fork SLOT_X的新快照得到新的 shred version 与 bank hash向验证者社区公告重启参数并协调上线等待并监听直到超级多数80% 激活质押可见后集群自动恢复出块若 80% 质押长时间未能参与则对未响应节点的投票账户执行 destake 后二次重启。下面按步骤展开并给出每一步对应的仓库源码实现。二、Step 1定位最新的乐观确认插槽 SLOT_X2.1 基本命令在 Solana 1.14 及以上版本直接运行solana-ledger-tool -l ledger latest-optimistic-slots该子命令会输出本地验证器观测到的最近乐观确认插槽默认 1 个。该子命令被刻意设计为始终可见的顶层命令——ledger-tool/src/blockstore.rs 中的注释明确写着“This command is important in cluster restart scenarios, so do not hide it ever”集群重启场景下该命令至关重要因此永不隐藏。它还支持两个可选参数定义于 ledger-tool/src/blockstore.rs参数默认值作用--num-slots NUM1输出最近 N 个乐观确认插槽便于核对不止一个候选高度--exclude-vote-only-slots关闭排除只包含投票交易的插槽重启锚点通常应选有实际交易的插槽2.2 输出格式与实现原理从 ledger-tool/src/blockstore.rs 的处理逻辑看输出为四列表格Slot、Hash、Timestamp、Vote Only?RFC3339 时间戳。值得注意的是其选取逻辑ledger-tool/src/blockstore.rs 的get_latest_optimistic_slots函数在X - Y - Z这样一条链上若 X 和 Z 被标记为乐观确认Y 作为 Z 的祖先可被隐式视为乐观确认但 blockstore 并不保证 Y 会被显式标记。因此源码没有只查 OptimisticSlots 列而是先取最新的乐观确认插槽再用AncestorIterator手动向上遍历其祖先对未显式标记的祖先打印 warning。这意味着latest-optimistic-slots给出的结果覆盖了“隐式确认”的祖先链比直接读列更保守、更适合做重启锚点。2.3 跨验证者核对与旧版本替代方案文档特别强调故障发生前不同验证者观测到的最新乐观确认插槽可能不一致。必须向集群上的其他验证者调研survey确认是否存在更大的乐观确认插槽若有改用更大的那个。这是选择SLOT_X时防止“锚点落后”的关键人工步骤。在 Solana 1.13 及更早版本没有该子命令需要查看乐观确认相关的 metrics datapoint 日志来定位最新乐观确认插槽该数据点的产出逻辑位于 core/src/optimistic_confirmation_verifier.rs文档指向该文件中乐观确认的 metrics 上报点。将最终选定的插槽记为SLOT_X。三、Step 2 / Step 3停止验证器并可选升级版本Step 2停止所有要参与重启的验证器进程。停止前建议确认账本目录完整可用solana-ledger-tool -l path/to/ledger bounds检查本地 ledger 覆盖的插槽范围后文公告模板中也会用到。Step 3可选步骤——安装新的 Solana 版本。公告模板中的示例正是以“发布了 v1.1.12 并准备让 testnet 重新上线”为场景说明升级版本 协调重启是标准组合操作。四、Step 4创建硬分叉快照并调整验证器参数4.1 创建快照$ solana-ledger-tool -l LEDGER_PATH \ --snapshot-archive-path SNAPSHOTS_PATH \ --incremental-snapshot-archive-path INCREMENTAL_SNAPSHOTS_PATH \ create-snapshot SLOT_X SNAPSHOTS_PATH --hard-fork SLOT_X执行后快照目录中会生成新的全量快照。solana-ledger-tool create-snapshot同时会输出两个关键值NEW_SHRED_VERSION新的 shred versionNEW_BANK_HASHSLOT_X处的 bank hash。create-snapshot子命令的参数定义在 ledger-tool/src/main.rs除--hard-fork、--destake-vote-account外还支持--remove-account、--deactivate-feature-gate、--remove-stake-accounts、--incremental等修改快照状态的选项其中--destake-vote-account支持多次传入见 ledger-tool/src/main.rshelp 文本为 “List of validator vote accounts to destake”将在排障章节使用。4.2 调整验证器启动参数在验证器启动参数中增加这两个参数在 validator/src/cli.rs 中有明确定义--wait-for-supermajority SLOT_X --expected-bank-hash NEW_BANK_HASH从源码定义看这三个重启相关参数有严格的依赖与语义参数定义位置语义--wait-for-supermajority SLOTvalidator/src/cli.rs“处理完 ledger 且下一个插槽为 SLOT 时等待超级多数质押在 gossip 上可见后再启动 PoH”要求同时提供--expected-bank-hash和--expected-shred-version.requires(...)链--expected-bank-hash HASHvalidator/src/cli.rs“当--wait-for-supermajority x时要求 x 处的 bank 必须是该 hash”用于防止节点从不同状态的分叉启动--expected-shred-version VERSIONvalidator/src/cli.rs要求 shred version 必须等于该值确保 gossip 上的节点属于同一个“重启纪元”因此实践中还应把create-snapshot输出的NEW_SHRED_VERSION配上--expected-shred-version一起下发给各节点shred version 不匹配的节点会被单独统计为 “wrong shred version” 质押见下文监控部分。4.3 重启验证器并确认进入等待状态重启验证器后确认日志显示验证器已启动并停在SLOT_X的“holding pattern”等待超级多数质押的状态。从 core/src/validator.rs 的等待循环看验证器在此阶段的行为是比较 ledger 加载出的 bank 插槽与--wait-for-supermajority的插槽若 ledger 数据不够bank 插槽小于目标插槽报错 “Ledger does not have enough data to wait for supermajority, please enable snapshot fetch.”——这解释了为什么公告模板中本地 ledger 未覆盖SLOT_X的节点不能带--no-snapshot-fetch校验 bank hash 与--expected-bank-hash一致不一致则以BadExpectedBankHash退出进入每秒一次的轮询计算 gossip 中可见的激活质押占比直到达到WAIT_FOR_SUPERMAJORITY_THRESHOLD_PERCENT即 80%才放行启动等待期间会rpc_override_health_check.store(true, ...)——伪报 RPC 健康防止负载均衡器在人工重启窗口内把节点摘除源码注释原话如此。一旦确定NEW_SHRED_VERSION还应通知基金会foundation入口点entrypoint运营者更新 entrypoint使后续节点能下载正确 shred version 的数据。五、Step 5向验证者社区公告重启文档给出的公告模板发布在 #announcements 频道按实际情况调整版本号和占位符Hi Validators,Weve released v1.1.12 and are ready to get testnet back up again.Steps:Install the v1.1.12 release: 安装官方 release 提供的对应版本a. 首选方式从你的本地 ledger 启动solana-validator --wait-for-supermajority SLOT_X # -- NEW! IMPORTANT! REMOVE AFTER THIS RESTART --expected-bank-hash NEW_BANK_HASH # -- NEW! IMPORTANT! REMOVE AFTER THIS RESTART --hard-fork SLOT_X # -- NEW! IMPORTANT! REMOVE AFTER THIS RESTART --no-snapshot-fetch # -- NEW! IMPORTANT! REMOVE AFTER THIS RESTART --entrypoint entrypoint.testnet.solana.com:8001 --known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on --expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY --only-known-rpc --limit-ledger-size ... # -- 你其他的 --identity/--vote-account 等参数b. 如果你的验证器 ledger 没有覆盖到SLOT_X或者 ledger 已被删除则改为下载快照启动solana-validator --wait-for-supermajority SLOT_X # -- NEW! IMPORTANT! REMOVE AFTER THIS RESTART --expected-bank-hash NEW_BANK_HASH # -- NEW! IMPORTANT! REMOVE AFTER THIS RESTART --entrypoint entrypoint.testnet.solana.com:8001 --known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on --expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY --only-known-rpc --limit-ledger-size ... # -- 你其他的 --identity/--vote-account 等参数可以用solana-ledger-tool -l path/to/ledger bounds查看你的 ledger 覆盖到哪些插槽。Wait until 80% of the stake comes online确认你的验证器是否正确等待 80% a. 查找N% of active stake visible in gossip的日志消息 b. 通过 RPC 询问它当前处于哪个插槽solana --url http://127.0.0.1:8899 slot在达到 80% 质押之前它应始终返回SLOT_XThanks!模板中每个参数标注 “REMOVE AFTER THIS RESTART” 的提示很重要--wait-for-supermajority、--expected-bank-hash、--hard-fork、--no-snapshot-fetch都是一次性重启参数集群恢复正常出块后必须移除否则下一次重启或升级时行为会不符合预期。两种启动方式的取舍方式 a本地 ledger --no-snapshot-fetchledger 完整覆盖SLOT_X时最快节点直接从本地数据加载到锚点插槽并原地等待方式 b下载快照本地 ledger 不足时从 entrypoint 获取覆盖SLOT_X的快照即 Step 4 中生成的、带 hard fork 的快照加载后同样停在SLOT_X等待。六、Step 7等待与监听重启进入“等待超级多数”阶段后协调者需要监控验证器上线进度每个节点的日志会周期性打印质押可见性统计。从 core/src/validator.rs 看节点每 10 轮约 10 秒打一次 “Waiting for 80.0% of activated stake at slot ... to be in gossip...”并持续输出三类占比core/src/validator.rs 的get_stake_percent_in_gossipN% of active stake visible in gossip—— 在线且 shred version 正确的激活质押占比只有它达到 80% 才会放行N% of active stake has the wrong shred version in gossip—— 在线但 shred version 不对的节点逐节点列出按质押降序指向“别人已按新 shred version 重启、你还没跟上”N% of active stake is not visible in gossip—— 未上线节点逐节点列出可据此联系缺席的验证者。回答验证者的问题、协助排查直到 80% 激活质押在 gossip 中可见所有等待中的节点会打印 “Supermajority reached, N% active stake detected, starting up now.” 并恢复出块。用solana --url http://127.0.0.1:8899 slot自检重启完成前该命令应始终返回SLOT_X。注意源码中的一个细节gossip 中“可见”的判定基于 contact info 的墙钟时间戳core/src/validator.rs过滤掉超过CRDS_GOSSIP_PULL_CRDS_TIMEOUT_MS的过期条目因此“在线”指的是近期在 gossip 中刷新过心跳的节点而不仅仅是进程存活。七、Troubleshooting80% 质押未能参与重启怎么办如果合理的等待时间过后参与重启的激活质押仍不足 80%则必须移除未响应验证者的质押后重试。流程如下社区识别未响应的验证者并就名单达成社会共识social consensus所有参与重启的验证者回到 Step 4在create-snapshot命令上为每个未响应验证者的投票账户地址追加一个--destake-vote-account PUBKEY参数重新生成快照并再次协调重启$ solana-ledger-tool -l ledger create-snapshot SLOT_X ledger --hard-fork SLOT_X \ --destake-vote-account VOTE_ACCOUNT_1 \ --destake-vote-account VOTE_ACCOUNT_2 \ . . . --destake-vote-account VOTE_ACCOUNT_N \效果新快照中所有与这些未响应验证者关联的质押会立即被去激活deactivated。集群重启成功后这些节点上的所有委托方staker需要重新委托re-delegate自己的质押。--destake-vote-account参数定义于 ledger-tool/src/main.rs标记为multiple(true)允许一次传入任意多个投票账户公钥参数值经is_pubkey校验。由于新快照改变了账户状态去激活质押会派生出新的NEW_BANK_HASHshred version 变化因此整个“生成快照 → 公告参数 → 等待 80%”的循环需要完整重走一遍——这也是文档强调“all participating validators return to Step 4”的原因。八、关键参数速查表环节命令 / 参数作用实现依据定位锚点solana-ledger-tool -l ledger latest-optimistic-slots输出最近乐观确认插槽、hash、时间戳ledger-tool/src/blockstore.rs定位锚点--num-slots NUM/--exclude-vote-only-slots输出多个插槽 / 排除纯投票插槽ledger-tool/src/blockstore.rs生成锚点快照create-snapshot SLOT_X PATH --hard-fork SLOT_X在指定插槽创建硬分叉快照输出 NEW_SHRED_VERSION 与 NEW_BANK_HASHledger-tool/src/main.rs二次重启--destake-vote-account PUBKEY可多次将未响应投票账户的质押在新快照中去激活ledger-tool/src/main.rs验证器等待--wait-for-supermajority SLOT_X在锚点插槽等待 gossip 中 80% 激活质押可见后再启动 PoH要求同时提供 bank hash 与 shred versionvalidator/src/cli.rs、core/src/validator.rs状态校验--expected-bank-hash NEW_BANK_HASH校验锚点插槽的 bank hash 与社区共识一致validator/src/cli.rs版本隔离--expected-shred-version NEW_SHRED_VERSION隔离不同“重启纪元”的节点validator/src/cli.rs快照获取策略--no-snapshot-fetch仅方式 aledger 完整时禁止拉取快照ledger 不足时该参数会导致 “NotEnoughLedgerData” 错误core/src/validator.rs自检solana --url http://127.0.0.1:8899 slot等待期间应始终返回SLOT_X文档公告模板进度观测N% of active stake visible in gossip日志80% 达到后打印 “Supermajority reached ... starting up now.”core/src/validator.rs九、小结这套规程的设计核心可以概括为三点单一锚点全网以同一个乐观确认插槽SLOT_X为重启基线且必须跨验证者交叉核对防止锚点选择偏旧状态一致性证明--expected-bank-hash--expected-shred-version让每个节点在启动时就能证明自己的状态与社区共识一致不一致的节点会被拒绝启动或被明确统计为 “wrong shred version”而非静默分叉原子化的恢复触发--wait-for-supermajority把“何时恢复出块”交给 80% 激活质押这一全网可观测条件避免任何单点决定恢复时机等待期间的 RPC 健康伪报core/src/validator.rs则保证了人工协调窗口内基础设施层不会干扰节点。当 80% 条件长期不满足时--destake-vote-account提供了确定性的兜底路径以牺牲少数未响应节点质押活性为代价让整个集群能够收敛并继续运转。【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考