返回博客

2026年10月30日

Pi 节点奖励为什么比别人低?官方公式拆开看,只有三件事能改

官方奖励公式里你能控制的只有三样:昨天在不在线、端口通不通、给了多少 CPU。其余全是官方调控。这篇把公式拆成人话。

面向:节点在跑、区块也同步了,但奖励就是上不去的人。
结论先行:官方奖励公式里,你能控制的只有三样东西 —— 昨天在不在线、
端口通不通、给了多少 CPU。其余全是官方调控,改不了。

先把公式摊开

Pi 官方的节点奖励公式(白皮书 2021-12 版奖励章节):

N(I) = node_factor × tuning_factor × I

其中:

node_factor = Percent_uptime_last_1_days × (Uptime_factor + Port_open_factor + CPU_factor)

不用被这堆符号吓到,它其实就说了两件事:

第一层:昨天必须在线上。 Percent_uptime_last_1_days 是唯一的乘法项。它是百分比, 昨天掉线一半时间 → 直接砍半;昨天完全不在线 → 当天奖励直接是 0。

这是最容易忽略、也最致命的一点:没有"历史奖励"补偿。 你之前连续跑三个月,昨天掉了一天,那天的奖励就是零,不会后面补回来。

第二层:三个因子相加,决定"在线"能值多少。

| 因子 | 是什么 | 你能做什么 | |---|---|---| | Uptime_factor | 在线时长占比(按 90 天 / 1 年 / 2 年 / 10 年加权) | 别掉线 | | Port_open_factor | 31400-31409 公网可达占比 | 检查端口 | | CPU_factor | 平均可用 CPU 核数 ÷ 4 | 给够核数 |

公式里 tuning_factor(全网归一化到 0-10)和 I(当期基础挖矿率)都是官方调控, 单节点完全不可控。别在这上面浪费精力。

三个因子,逐个说人话

一、在线率:唯一的乘法项,也最容易翻车

关键词是乘法。别的因子再高,乘上一个接近 0 的在线率,结果就是 0。

所以第一个该问自己的问题不是"我的机器够不够强",而是:

昨天我的节点在线率是多少?

如果昨天有掉线,先解决掉线,再谈别的。掉线原因通常是:

  • 家里断网 / 停电(这个只能靠上托管或加 UPS)
  • 机器重启后容器没自动起来
  • 磁盘满了导致进程被杀
  • 系统自动更新后没恢复

判断方法:看容器有没有设自动重启,以及最近有没有异常退出记录。

docker inspect <容器名> --format '{{.HostConfig.RestartPolicy.Name}}'
# 应该返回 always 或 unless-stopped

返回 no 的话,机器一重启节点就没了,而你可能要过几天才发现。

二、端口开放:占比算的,不是"开了就行"

Port_open_factor 算的是占比,而且和在线率一样按时间加权。

这意味着:少开几个端口不是 0 分,是打折。开 8 个通 8 个, 比开 10 个通 8 个要好 —— 因为前者占比 100%,后者只有 80%。

而 31400-31409 一共 10 个端口。很多人只映射了其中一两个, 节点照样跑、区块照样同步、界面不报错,但端口占比低,奖励就一直上不去。

这是我认为最值得查的一条,因为它不报错、不影响运行、纯粹是"静默打折"。

自查方法(从另一台公网机器测,本机测 localhost 没意义):

IP=你的公网IP
for p in $(seq 31400 31409); do
  timeout 3 nc -zv "$IP" "$p" >/dev/null 2>&1 && echo "$p 通" || echo "$p 不通 ★"
done

不通就回去查三层:路由器端口转发 → 主机防火墙 → 云厂商安全组。

三、CPU:核数 ÷ 4,超过 4 核不再加分

CPU_factor = (... ) / 4,这个 /4 很关键 —— 它把核数归一化到"4 核为满分"。

意思是:4 核给满,8 核不会翻倍。

所以对单节点来说,"堆 CPU 核数换奖励"这条路走不通。 瓶颈在别处时加 CPU 是浪费钱。

真正该关注的是平均可用核数 —— 如果你机器上还跑了别的东西 (数据库、其他容器、你自己在用),节点能拿到的核数是不够的, 表现出来就是 CPU_factor 上不去。

一个必须知道的现实:奖励会归零几天,这不是你的错

官方对这套公式的标注是 "expected to iterate"(预期会迭代), 测试网阶段客户端里经常显示 "Tuning in progress"。

这个状态下奖励偶发归零几天是正常的调参行为,不是你配置错了。

判断方法:如果你什么都没改,之前一直有奖励,突然几天归零, 而容器状态、端口、在线率都没变化 —— 大概率是官方在调参。 这种时候不要乱动配置,动了反而可能引入新问题。

排查顺序(按投入产出排)

如果奖励不理想,按这个顺序查:

  1. 昨天的在线率 —— 有掉线先修掉线,因为它是乘法项,影响最大
  2. 十个端口从公网全通了吗 —— 静默打折最常见的原因
  3. 容器自动重启开没开 —— 决定你掉线后能不能自己恢复
  4. 磁盘还有多少空间 —— 满了会导致节点停摆且不易察觉
  5. CPU 平均可用核数 —— 确认没被别的进程抢走
  6. 是不是官方在调参 —— 什么都没改就归零,先别动

前三条能覆盖绝大多数情况。如果都排除了还是低, 那就要考虑是不是机器规格本身不够(比如在老机器、机械硬盘上跑)。

最后一句实在话

如果你查完上面这些,发现问题在"房子会断电""网络不稳""机器太旧"这类 你没法改的地方 —— 那就是环境问题,不是配置问题。

这时候继续折腾配置没有意义。要么换环境(比如上云、上托管), 要么接受这个环境的奖励上限。

区分清楚"我能改的"和"我改不了的",比盲目调参有用得多。

---