Polkadot 验证人节点升级实战 | 备用节点切换、会话密钥交接零宕机完整教程
原文作者：PaperMoon团队
给验证人升级服务器，不是直接关掉旧节点、开新节点那么简单——会话密钥的更改需要等待三个 Session 才能生效，操作时序错了就可能因为节点意外下线触发 Slash。
整个流程的核心逻辑是：用两台节点交替接管出块任务，让旧节点在新节点确认接管之前始终保持运行。
一、会话密钥的生效延迟：N+3 规则
在开始操作之前，必须先理解会话密钥的延迟机制，这是整个升级流程的设计基础。
会话（Session）：Polkadot 网络的时间单位，比纪元（Era）更短。每个 Era 包含多个 Session，每个 Session 结束时验证人的签名密钥集合可能发生变化。
当你通过 `set_key` 外部调用更新会话密钥时，**新密钥不会立刻生效**。具体规则是：
> 提交 `set_key` 的那个 Session 结束后，还要再等两个完整的 Session，新密钥才真正接管。
也就是说，在 Session N 提交了 `set_key`，要到 Session N+3 开始时，新节点才正式成为活跃验证人。
在这段等待期内，旧节点必须一直跑着。提前关掉旧节点，等于主动让这个验证人席位出现空缺，触发 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 并等待同步完成**
```bash
polkadot --validator --name "Validator-B" --node-key-file /path/to/node-b.key
# 中文：以验证人模式启动备用节点，等待链数据完全同步
# 中文：同步完成前不要进行后续操作
```
**步骤 2：为验证人 B 生成新的会话密钥**
```bash
curl -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 填 `0x00`
5. 提交并签名
**步骤 4：记录提交时所在的 Session 编号**
在 Polkadot.js Apps 的 Developer → Chain State → `session.currentIndex()` 可以查到当前 Session 编号，记下来，这就是"Session N"。
**步骤 5：等待——验证人 A 继续运行**
等待 Session N 结束，再等两个完整的 Session（Session N+1、N+2）。这段时间里，验证人 A 继续正常出块，不要关闭。
阶段二：Session N+3 — 验证人 B 正式接管
Session N+3 开始时，验证人 B 的密钥正式生效，B 成为活跃验证人。
现在可以安全地对验证人 A 进行维护、升级或迁移。
阶段三：维护完成后，切换回验证人 A
**步骤 1：重新启动验证人 A，等待同步完成**
```bash
polkadot --validator --name "Validator-A" --node-key-file /path/to/node-a.key
# 中文：重新启动维护好的验证人 A，等待链数据同步到最新
```
**步骤 2：为验证人 A 生成新的会话密钥**
```bash
curl -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 M+3），验证人 A 重新成为活跃验证人后，才可以安全关闭验证人 B。
四、如何确认切换成功
节点切换成功后，日志中会出现类似以下内容，表明 GRANDPA 权威集合已经更新：
```
2019-10-28 21:44:13 Applying authority set change scheduled at block #450092
2019-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 N+1 / N+2 | 等待新密钥生效 | 验证人A 继续运行 |
Session N+3 | 验证人B 正式接管出块 | 可以开始维护验证人A |
Session M | 维护完成后，启动验证人A并提交新的 set_keys | 验证人B 必须保持运行 |
Session M+3 | 验证人A 重新接管 | 可以关闭验证人B |
小结
整个升级流程就是一个"交棒"过程，核心是：**新节点就绪前，旧节点绝对不能停**。
三个容易出错的地方：
- 提前关闭旧节点（等待期还没过就关了）
- 把 keystore 目录从旧节点复制到新节点（两台节点持有相同密钥 = 双重签名 = Slash）
- 忘记记录提交 `set_key` 时的 Session 编号，不知道从哪个 Session 开始数
操作之前把时间算好，这个流程不复杂，但需要几个小时等 Session 过渡，中途不能脱手。
阅读原文：https://docs.polkadot.com/node-infrastructure/run-a-validator/onboarding-and-offboarding/upgrade-your-node/