原文作者PaperMoon团队给验证人升级服务器不是直接关掉旧节点、开新节点那么简单——会话密钥的更改需要等待三个 Session 才能生效操作时序错了就可能因为节点意外下线触发 Slash。整个流程的核心逻辑是用两台节点交替接管出块任务让旧节点在新节点确认接管之前始终保持运行。一、会话密钥的生效延迟N3 规则在开始操作之前必须先理解会话密钥的延迟机制这是整个升级流程的设计基础。会话SessionPolkadot 网络的时间单位比纪元Era更短。每个 Era 包含多个 Session每个 Session 结束时验证人的签名密钥集合可能发生变化。当你通过 set_key 外部调用更新会话密钥时**新密钥不会立刻生效**。具体规则是 提交 set_key 的那个 Session 结束后还要再等两个完整的 Session新密钥才真正接管。也就是说在 Session N 提交了 set_key要到 Session N3 开始时新节点才正式成为活跃验证人。在这段等待期内旧节点必须一直跑着。提前关掉旧节点等于主动让这个验证人席位出现空缺触发 Chill 甚至 Slash。二、Keystore 安全管理绝对不能复制验证人的 keystore 目录存放着用于签名网络操作的私钥默认路径是/home/polkadot/.local/share/polkadot/chains/chain/keystore# 中文chain 替换为实际网络名称如 polkadot 或 kusama**绝对不能把 keystore 文件夹从一台服务器复制到另一台**。如果两台节点同时持有相同的会话密钥它们都会对同一个区块高度进行签名产生矛盾投票Equivocation直接触发 Slash 惩罚——质押的 DOT 被没收。**每台新节点必须单独生成自己的会话密钥**通过 set_key 在链上注册等到密钥生效后旧节点才能下线。三、完整升级流程假设你有两台节点- **验证人 A**当前正在运行的活跃验证人- **验证人 B**用于维护期间临时接管的备用节点阶段一Session N — 启动备用节点提交密钥切换**步骤 1启动验证人 B 并等待同步完成**bashpolkadot --validator --name Validator-B --node-key-file /path/to/node-b.key# 中文以验证人模式启动备用节点等待链数据完全同步# 中文同步完成前不要进行后续操作**步骤 2为验证人 B 生成新的会话密钥**bashcurl -H Content-Type: application/json \-d {id:1, jsonrpc:2.0, method: author_rotateKeys, params:[]} \http://localhost:9944# 中文向验证人 B 的 RPC 接口发送请求生成并返回新的会话密钥十六进制字符串复制返回的 result 字段值会话密钥下一步用。**步骤 3提交 set_key 外部调用将验证人 B 的密钥注册到链上**在 Polkadot.js Apps 中1. 进入 **Developer** → **Extrinsics**2. 选择你的 Staking Proxy 账户3. 选择 session pallet → setKeys(keys, proof)4. 填入验证人 B 的会话密钥proof 填 0x005. 提交并签名**步骤 4记录提交时所在的 Session 编号**在 Polkadot.js Apps 的 Developer → Chain State → session.currentIndex() 可以查到当前 Session 编号记下来这就是Session N。**步骤 5等待——验证人 A 继续运行**等待 Session N 结束再等两个完整的 SessionSession N1、N2。这段时间里验证人 A 继续正常出块不要关闭。阶段二Session N3 — 验证人 B 正式接管Session N3 开始时验证人 B 的密钥正式生效B 成为活跃验证人。现在可以安全地对验证人 A 进行维护、升级或迁移。阶段三维护完成后切换回验证人 A**步骤 1重新启动验证人 A等待同步完成**bashpolkadot --validator --name Validator-A --node-key-file /path/to/node-a.key# 中文重新启动维护好的验证人 A等待链数据同步到最新**步骤 2为验证人 A 生成新的会话密钥**bashcurl -H Content-Type: application/json \-d {id:1, jsonrpc:2.0, method: author_rotateKeys, params:[]} \http://localhost:9944# 中文为验证人 A 生成全新的会话密钥不能复用之前的**步骤 3再次提交 set_key将验证人 A 的新密钥注册到链上**操作同上这次填入验证人 A 的新密钥。**步骤 4记录这次提交时所在的 Session 编号设为 Session M****步骤 5继续保持验证人 B 运行**同样等待 Session M 结束加两个完整 Session即到 Session M3验证人 A 重新成为活跃验证人后才可以安全关闭验证人 B。四、如何确认切换成功节点切换成功后日志中会出现类似以下内容表明 GRANDPA 权威集合已经更新2019-10-28 21:44:13 Applying authority set change scheduled at block #4500922019-10-28 21:44:13 Applying GRANDPA set change to new set with 20 authorities# 中文权威集合变更已在指定区块高度生效新的验证人集合包含 20 个节点也可以在 Polkadot.js Apps 的 Staking 页面查看你的验证人是否出现在活跃集合中。---五、流程时序总结阶段操作注意事项Session N启动验证人B生成密钥并提交 set_keys验证人A 必须保持运行Session N1 / N2等待新密钥生效验证人A 继续运行Session N3验证人B 正式接管出块可以开始维护验证人ASession M维护完成后启动验证人A并提交新的 set_keys验证人B 必须保持运行Session M3验证人A 重新接管可以关闭验证人B小结整个升级流程就是一个交棒过程核心是**新节点就绪前旧节点绝对不能停**。三个容易出错的地方- 提前关闭旧节点等待期还没过就关了- 把 keystore 目录从旧节点复制到新节点两台节点持有相同密钥 双重签名 Slash- 忘记记录提交 set_key 时的 Session 编号不知道从哪个 Session 开始数操作之前把时间算好这个流程不复杂但需要几个小时等 Session 过渡中途不能脱手。阅读原文https://docs.polkadot.com/node-infrastructure/run-a-validator/onboarding-and-offboarding/upgrade-your-node/