Pi Network a activé la mise à niveau du protocole 24,1 en mai, exigeant que tous les opérateurs de nœuds terminent la migration de v23.0 à v24.1 avant la date limite du 2 juin ; les nœuds ayant manqué cette échéance risquent d’être déconnectés du réseau principal Pi et de devoir être entièrement resynchronisés pour pouvoir réintégrer le réseau.
Guide opérationnel pour la mise à niveau v24.1 : trois méthodes confirmées
Méthode 1 (principale) : pour les utilisateurs de Docker, mettez à jour la version de l’image dans docker-compose.yml vers : pinetwork/pi-node-docker:organization_mainnet-v1.0-p24.1.0 puis exécutez docker-compose up -d
Méthode 2 : Pi Desktop (Windows / macOS) redémarrez l’application Pi Node ; la version la plus récente déclenchera automatiquement la mise à niveau.
Méthode 3 : Linux Node CLI exécutez pi-node update-protocol, utilisez watch pi-node status pour surveiller l’état, et terminez lorsque « synchronisé » s’affiche.
La seule méthode fiable pour confirmer que la migration est terminée : comparez la valeur ingest_latest_ledger des nœuds (la valeur sur curl). Lorsque les deux valeurs sont à peu près équivalentes, cela indique que la migration est terminée. Point important : pendant le processus de migration, cette valeur ne se met pas à jour progressivement, elle n’est mise à jour qu’une seule fois à la fin de la migration ; la valeur restant inchangée pendant la migration ne signifie pas que la migration a échoué.
Quatre règles clés d’opération confirmées
（來源：Pi Network）
Mise à niveau par lots : ne mettez pas tous les nœuds à niveau en même temps, procédez par étapes ; pendant la mise à niveau, transférez le trafic vers les nœuds qui ne sont pas en cours de mise à niveau ou vers des nœuds de secours
Ne pas démarrer arbitrairement v25.1 ou v26.0 : ces deux versions ont été marquées comme « ne pas démarrer » ; vous devez attendre le signal officiel de lancement de l’équipe principale de Pi
Le 2 juin est une date limite stricte (hard cutoff) : le temps de migration ne doit pas dépasser 5 minutes ; l’équipe principale de Pi recommande de terminer le plus tôt possible plutôt que d’attendre la toute fin
Doit être confirmé via le point de terminaison du carnet (ledger) : ne supposez pas que la migration est terminée uniquement parce que le nœud a redémarré ; comparez impérativement via ingest_latest_ledger
FAQ
Quelle est la logique de conception de la séquence de mise à niveau v19→v26 de Pi Network, et pourquoi chaque étape est-elle obligatoire ?
La séquence de mise à niveau de Pi Network est une conception à dépendances linéaires : chaque nouvelle version construit ses fonctionnalités sur la base de la version précédente, sans possibilité de sauter d’étapes. Cette conception garantit que tout le réseau conserve à tout moment la même version de protocole, empêchant les nœuds de ne pas pouvoir communiquer efficacement en raison d’écarts de versions. Plus il y a de nœuds exécutant encore l’ancienne version dans le réseau, plus le déploiement complet des nouvelles fonctionnalités sur l’ensemble du réseau est lent ; c’est pourquoi les dates limites impératives visent à assurer une transition rapide du réseau vers la version suivante. v23.0 est l’étape la plus complexe de cette séquence : elle met à niveau à la fois le système d’exploitation et la base de données ; v24.1 progresse sur cette base en intégrant les nouvelles versions de Stellar-Core et Horizon.
Après la mise à niveau du protocole du réseau principal Pi vers v24.1, les fonctionnalités de smart contracts et de dApp seront-elles activées ?
Non. L’équipe principale de Pi a confirmé explicitement que l’activation des smart contracts et des applications décentralisées (dApp) sur le réseau principal Pi n’a pas encore été annoncée officiellement. Le protocole 23.0 aligne Pi avec Stellar Core v23, qui fournit au niveau technique un cadre de base pour ces fonctionnalités ; v24.1 intègre davantage Stellar-Core v24.1.0 en poursuivant cette trajectoire technique, mais l’activation des smart contracts et des dApp est une décision officielle distincte que l’équipe principale de Pi doit prendre séparément ; elle est indépendante d’un événement de mise à niveau de version du protocole. La séquence de mise à niveau actuelle se concentre principalement sur la stabilité de l’infrastructure et l’optimisation des performances.
Si un opérateur de nœuds rencontre un problème pendant la mise à niveau v23.0, la difficulté de migration de v24.1 sera-t-elle également aussi élevée ?
D’après la confirmation de l’équipe principale de Pi, v24.1 est une migration standard des données internes, avec une différence fondamentale par rapport à v23.0 : v23.0 nécessite d’effectuer simultanément une mise à niveau du système d’exploitation (Ubuntu 20→24), une mise à niveau de la base de données (PostgreSQL 12→16) et une migration du protocole ; en plus, comme cela implique une réécriture des fichiers de base de données, il faut effectuer au préalable des mesures de sauvegarde, ce qui allonge le temps de démarrage ; v24.1 est une simple migration interne des données, ne impliquant pas de réécriture des fichiers de base de données, ne nécessitant pas d’étapes de sauvegarde particulières, et dans la plupart des cas, la migration ne dépasse pas 5 minutes, et la vitesse de redémarrage est bien plus rapide que celle de v23.0. La difficulté de la mise à niveau v23.0 provient principalement de la complexité d’une mise à niveau synchronisée à plusieurs niveaux, tandis que v24.1 ne présente pas la même complexité.
