Pi Network v24.1 升级须在 6 月 2 日前完成，错过将与主网断连

Pi Network 于 5 月启用协议 24.1 升级，要求所有节点运营商在 6 月 2 日截止日期前完成从 v23.0 到 v24.1 的迁移；错过截止日期的节点可能与 Pi 主网断开连接，并需要完全重新同步才能重新加入网络。

v24.1 升级的操作指南：已确认的三种方法

方法一（主要方法）：Docker 用户 更新 docker-compose.yml 中的映像版本至： pinetwork/pi-node-docker:organization_mainnet-v1.0-p24.1.0 然后运行 docker-compose up -d

方法二：Pi Desktop（Windows / macOS） 重启 Pi Node 应用程序；最新版本将自动触发升级。

方法三：Linux Node CLI 执行 pi-node update-protocol，使用 watch pi-node status 监控状态，当显示「已同步」时完成。

确认迁移完成的唯一可靠方法：比较节点中的 ingest_latest_ledger 值（curl 上的值，当两者大致相等时表示迁移已完成。重要提示：迁移过程中此数值不会逐步更新，只会在迁移结束时一次性更新，数值在迁移期间保持不变不代表迁移失败。

四项已确认的关键操作规则

（来源：Pi Network）

分批升级：不要同时升级所有节点，分阶段进行；在升级进行中，将流量从正在升级的节点转移至其他节点或备用节点

不得擅自启动 v25.1 或 v26.0：这两个版本已被标记为「请勿启动」，必须等待 Pi 核心团队的官方启动信号

6 月 2 日为硬截止日期：迁移时间不超过 5 分钟，Pi 核心团队建议尽早完成而非等到最后

必须通过账本端点确认完成：不要仅凭节点重启就假设迁移完成，务必通过 ingest_latest_ledger 比较确认

常见问题

Pi Network 的 v19→v26 升级序列的设计逻辑是什么，为何每一步都是强制性的？

Pi Network 的升级序列是线性依赖型设计：每一个新版本的功能都构建在上一個版本的基础之上，无法跳过。这种设计确保了整个网络在任何时刻都保持一致的协议版本，防止节点因版本差异无法有效通信。网络中仍运行旧版本的节点数量越多，新版本功能的全网部署就越慢，因此强制截止日期旨在确保网络整体向下一个版本的快速过渡。v23.0 是这个序列中最复杂的一步，同时升级了操作系统和数据库；v24.1 在此基础上推进，整合了 Stellar-Core 和 Horizon 的新版本。

Pi 主网协议升级至 v24.1 后，智能合约和 dApp 功能是否会被激活？

不会。Pi 核心团队明确确认，智能合约和去中心化应用程序（dApp）在 Pi 主网上的激活尚未官方宣布。协议 23.0 将 Pi 与 Stellar Core v23 对齐，后者在技术层面为这些功能提供了基础框架；v24.1 进一步整合 Stellar-Core v24.1.0 延续了这条技术路线，但激活智能合约和 dApp 是 Pi 核心团队需要单独做出的官方决策，与协议版本升级是相互独立的事件。目前的升级序列主要聚焦于基础设施的稳定性和性能优化。

如果节点运营商在 v23.0 升级过程中遇到问题，v24.1 的迁移难度是否也会同样高？

根据 Pi 核心团队的确认，v24.1 是标准的内部数据迁移，与 v23.0 存在根本性差异：v23.0 需要同时进行操作系统升级（Ubuntu 20→24）、数据库升级（PostgreSQL 12→16）和协议迁移，并且由于涉及数据库文件重写，需要提前进行备份预防措施，启动时间较长；v24.1 是单纯的内部数据迁移，不涉及数据库文件重写，无需特殊备份步骤，大多数情况下迁移不超过 5 分钟，重启速度也比 v23.0 快得多。v23.0 升级的困难主要源于其多层同步升级的复杂性，v24.1 不存在相同的复杂性。