Le délai pour les nœuds Pi Network est écoulé. Qu'a apporté le Protocole 28 ?

Pi Network a demandé aux opérateurs de nœuds d'installer le logiciel Protocol 28 avant le 13 octobre, en prévision d'une mise à niveau planifiée du Mainnet le 16 octobre. La date limite est derrière le réseau ; l'activation est encore à venir. La question immédiate est de savoir si les nœuds participants sont prêts et ce que les utilisateurs et les développeurs pourront réellement faire après le changement, car ni une date limite ni un numéro de protocole ne mesurent l'utilisation des applications.

Les instructions du nœud Pi demandent à chaque nœud du Mainnet de passer à la version 28. L'annonce publique de Pi indique que le changement améliore la façon dont le réseau gère les retards dans les données de transaction et permet aux développeurs de mettre à niveau des groupes de contrats intelligents et de données stockées plus sûrement. Ce sont deux affirmations d'infrastructure. Aucune ne dit qu'une application spécifique a été lancée, qu'un paiement utilisateur a augmenté ou qu'un stablecoin sera mis en service vendredi.

Crypto.news a déjà examiné le prix de PI avant la mise à niveau et la relation OUSD proposée. La question plus utile aujourd'hui concerne la chaîne elle-même : quelles preuves montreraient que le logiciel installé s'est activé comme prévu, et qu'est-ce qui reste dépendant des développeurs et des utilisateurs après ce moment ?

Une date limite de nœud n'est pas la date d'activation

Une date limite pour les opérateurs de nœuds demande aux ordinateurs participant au réseau d'installer un logiciel compatible. L'activation du protocole change les règles que le Mainnet suit. Ce sont des événements distincts même si les deux se produisent dans une même séquence de mise à niveau. L'annonce de Pi a fixé le 13 octobre pour les mises à niveau des nœuds et le 16 octobre pour le changement de protocole du Mainnet. Une date limite manquée par un opérateur ne signifie pas en soi que tout le réseau a échoué ; le résultat dépend de la participation des validateurs et de la façon dont le réseau gère les serveurs incompatibles.

Le projet a rapporté une mise à niveau réussie du Protocole 27 sur le Mainnet avant de déplacer le Protocole 28 vers le Testnet. Une mise à niveau du Testnet montre que le logiciel proposé peut être exercé dans un environnement d'essai. L'activation sur le Mainnet implique le registre en direct, les transactions en direct et les opérateurs maintenant le consensus avec des versions compatibles. L'événement du 16 octobre nécessite une confirmation indépendante après sa survenue. Écrire aujourd'hui comme s'il s'était déjà produit confondrait le calendrier avec le déploiement.

La page publique des nœuds de Pi ne donne pas de chiffre daté et vérifiable pour la part des validateurs du Mainnet exécutant la v28 au moment où cette fonctionnalité a été préparée. Cela empêche toute affirmation défendable en pourcentage sur la conformité. Un opérateur peut télécharger un logiciel sans l'exécuter, et un décompte public des téléchargements de bureau ne prouverait pas la participation des validateurs. La preuve utile serait une distribution des versions parmi les nœuds de consensus actifs, l'état du vote de mise à niveau ou d'activation, et la production continue du registre après le changement.

Une mise à jour de nœud peut nécessiter l'action de personnes qui ne développent pas d'applications. Un validateur sur un protocole obsolète peut perdre la capacité de rester synchronisé avec le réseau après l'activation des nouvelles règles de transaction. L'étendue de toute perturbation devrait être observée, et non présumée. Les pages de statut, les versions actuelles du registre, les avis aux opérateurs de nœuds et les transactions de test des développeurs peuvent fournir différentes parties de la réponse.

Ce que le Protocole 28 prétend changer

Pi décrit trois améliorations dans son annonce publique : la gestion des retards dans les données de transaction, la mise à niveau groupée de contrats intelligents, et la modification plus sûre des données de contrat stockées à mesure que les applications évoluent. L'annonce ne publie pas de benchmark de débit, de pourcentage de réduction des frais ni de liste de contrats en production utilisant les nouvelles fonctions. Décrire la version comme un bond automatique du nombre de transactions par seconde reviendrait donc à inventer un résultat de performance.

Des données de transaction retardées peuvent créer un problème de coordination pour un registre si les serveurs ont des vues différentes des informations nécessaires au traitement d'un ensemble d'opérations. Un logiciel qui gère ces retards de manière plus fiable peut réduire les échecs évitables ou améliorer la robustesse. Pour démontrer une amélioration réelle sur le Mainnet, un développeur aurait besoin de mesures datées avant et après : transactions échouées du type concerné, délai pour les inclure, ou un test reproductible qui exerce le nouveau comportement. Un journal des modifications ne décrit qu'une capacité prévue.

Les mises à niveau groupées sont utiles pour les applications composées de plusieurs contrats interdépendants. Prenons une application de paiement avec un contrat enregistrant les soldes et un autre appliquant les permissions. Mettre à jour un seul à la fois peut créer une période pendant laquelle les versions divergent. Une opération qui met à niveau un groupe ensemble pourrait réduire ce décalage. Elle ne rend pas à elle seule un contrat individuel sécurisé ; les développeurs doivent toujours spécifier une logique correcte, vérifier les chemins de migration et tester ce qui se passe en cas d'échec d'exécution.

Les données stockées soulèvent une question de migration distincte. Lorsqu'une application modifie sa structure, les soldes utilisateurs existants, les permissions et autres enregistrements doivent rester interprétables sous le nouveau code. Un mécanisme de mise à jour plus sûr peut aider à coordonner ce changement. Un bug dans le nouveau contrat du développeur ou une erreur dans la transformation des enregistrements peut toujours endommager l'application. Le support au niveau du protocole est un outil, pas un audit de chaque projet qui l'utilise.

L'histoire des contrats intelligents a commencé avant la version 28

La couverture du Protocole 27 de Pi décrivait les capacités de développement de la mise à niveau précédente et la distance entre une large base d'utilisateurs revendiquée et l'utilisation observable de la finance décentralisée. Le Protocole 28 est une continuation du parcours logiciel, pas le premier moment où les contrats intelligents deviennent concevables sur le réseau. Ses ajouts spécifiques doivent être mesurés par rapport au Protocole 27, et non par rapport à un réseau fictif sans outils de développement préalables.

La version RPC pour développeurs offrait un moyen pour les applications d'interagir avec l'infrastructure Testnet de Pi. La documentation, les points de terminaison et une mise à niveau du protocole abaissent les barrières pour les constructeurs, mais ils ne prouvent pas le déploiement ou l'utilisation sur le Mainnet. Une application peut être listée sans transactions significatives. Un contrat peut être déployé sans utilisateurs actifs. Un compteur de transactions peut augmenter à cause de tests automatisés. Chaque chiffre répond à une question différente.

Un registre d'adoption utile enregistrerait les contrats Mainnet actifs construits avec la nouvelle capacité, les transactions qui les ont invoqués, les portefeuilles participants uniques et la valeur économique ou le service fourni. Même ces mesures exigent de la prudence. Une seule personne peut contrôler de nombreux portefeuilles ; une application populaire peut représenter la majeure partie de l'activité ; un chiffre de valeur peut inclure des transferts entre comptes détenus par le même développeur. Des noms d'applications indépendants et des adresses onchain reproductibles rendraient les preuves plus solides.

La feuille de route 2026 contient d'autres étapes. Le KYC et la migration déterminent quels Pionniers peuvent utiliser les soldes du Mainnet. La découverte d'applications détermine si les utilisateurs trouvent quelque chose à faire. L'acceptation par les marchands ou une application grand public utile détermine si les utilisateurs ont une raison de dépenser. Le protocole 28 peut améliorer le substrat alors que ces trois éléments restent des goulots d'étranglement. La mise à niveau devrait d'abord être jugée sur ses affirmations techniques, puis séparément sur toute demande qui en découle.

Un partenariat de stablecoin ne fait pas partie du basculement du 16 octobre

La déclaration du 8 octobre sur les stablecoins de Pi décrit un travail avec Open Standard, le groupe derrière OUSD, et indique que le projet explorera les récompenses et d'autres utilisations dans l'écosystème. L'entreprise n'a pas donné de date de lancement confirmée pour OUSD sur Pi ni déclaré que l'activation du protocole 28 rendra un produit OUSD disponible. Réunir ces annonces en un seul lancement le 16 octobre serait non étayé.

Les stablecoins peuvent faciliter la tarification d'un paiement lorsque les marchands et les consommateurs ne veulent pas que le montant de la facture change avec la valeur marchande de PI. Pi affirme que PI reste la cryptomonnaie native de l'écosystème. Savoir si les dépenses libellées en dollars génèrent une demande pour PI dépend de la mise en œuvre finale : frais de transaction, incitations des applications, voies de liquidité, financement des récompenses et toute exigence de détenir du PI. Aucune spécification de produit publiée ne tranche ces flux.

Un développeur pourrait construire une application après le protocole 28 qui utilise directement PI, un stablecoin, ou les deux. La mise à niveau du réseau elle-même ne choisit pas le modèle économique. Une application avec une tarification en dollars et un règlement en stablecoin pourrait utiliser PI pour des frais de réseau réduits, tandis qu'une application récompensant les utilisateurs en PI pourrait créer une activité directe plus importante. Ce sont des exemples conditionnels, et non des descriptions de services déployés.

La distinction est importante pour la communication des prix. Un basculement de protocole réussi est une preuve positive de la coordination des opérateurs et du déploiement du code. Ce n'est pas la même chose qu'une augmentation mesurée des achats de jetons, des utilisateurs durables ou des marchands acceptant PI. La communication récente sur les prix a déjà lié la discussion sur OUSD et le calendrier de mise à niveau à un marché faible. Répéter cette juxtaposition sans nouvelles données sur la demande apporterait peu.

Ce qu'un vendredi réussi prouverait

Si Pi confirme l'activation du 16 octobre et que les explorateurs montrent des registres Mainnet ultérieurs utilisant le nouveau protocole, cela établirait la transition logicielle planifiée. La poursuite du fonctionnement du réseau et la compatibilité des nœuds soutiendraient la conclusion que la mise à niveau n'a pas visiblement perturbé le consensus. Un test publié du délai de transaction spécifique ou des fonctionnalités de mise à niveau groupées montrerait plus qu'une simple étiquette de version.

Aucune capture d'écran unique ne prouve tout cela. Un explorateur de blocs peut afficher les versions du registre mais pas nécessairement si les migrations de contrats complexes sont sûres. Une démonstration de développeur peut montrer une application fonctionnant correctement sans prouver une adoption généralisée. Une annonce d'équipe peut signaler l'achèvement sans donner de comptages indépendants des nœuds ou des transactions échouées. Le meilleur compte combine ces sources et identifie où une affirmation reste auto-déclarée.

L'argument opposé est simple. Les améliorations d'infrastructure peuvent être précieuses même avant que les utilisateurs ne les remarquent. Les équipes construisant des paiements ou des jeux ont souvent besoin d'outils de mise à niveau prévisibles avant d'engager de vrais soldes, et l'utilisation publique pourrait arriver des semaines ou des mois plus tard. Juger une version technique uniquement par le prix du jeton le jour même ou la valeur DeFi manquerait son rôle prévu. Cet argument justifie la patience, mais il exige aussi un jalon futur vérifiable.

La fonctionnalité deretard KYC documentait des portes d'accès et d'utilisation distinctes. Pi a promu une grande communauté pendant des années. Ses mises à jour KYC et de migration montrent que l'accès au Mainnet reste un processus pour certains utilisateurs. Un public revendiqué n'est pas une liste d'utilisateurs actifs de contrats intelligents. Le test pratique après l'activation consiste à déterminer si les applications peuvent fonctionner de manière fiable pour les utilisateurs dont les soldes ont été migrés et si ces utilisateurs reviennent après une promotion initiale.

Ce qui reste inconnu aujourd'hui

La date limite de l'opérateur ne s'accompagne pas d'un tableau de conformité public, l'activation reste planifiée, et aucune application Mainnet identifiée n'a encore montré une amélioration avant/après attribuable à la version 28 dans les documents examinés. Ce sont là des limites à ce qui peut être rapporté le 14 octobre. Elles n'impliquent pas que la mise à niveau a échoué ; elles signifient qu'un résultat mesuré est encore en attente.

Une application prospective peut utiliser des mises à jour de contrats groupées sans rendre ce fait facilement visible depuis un flux de transactions ordinaire. Les développeurs pourraient publier les adresses des contrats, le code et les enregistrements de migration. Le projet peut publier l'adoption des versions et les journaux d'incidents. Sans de telles divulgations, les observateurs externes peuvent vérifier certains comportements du registre tout en laissant les détails d'implémentation incertains.

Le prix et l'utilité restent distincts. Les desks de trading peuvent anticiper une mise à niveau planifiée et se positionner avant l'activation, tandis que les utilisateurs peuvent mettre beaucoup plus de temps à adopter une application. Ni la réaction du marché ni une annonce de mise à niveau ne répondent à la question de savoir si les nouveaux outils ont produit un service économiquement utile. Un article sur le Protocole 28 devrait laisser cette question ouverte jusqu'à ce que les données existent.

Un plan de repli révélerait les enjeux opérationnels

Un changement de protocole planifié devrait comporter une procédure pour les opérateurs qui restent sur l'ancien logiciel et pour les développeurs dont les transactions se comportent différemment après l'activation. Pi a donné une date limite de mise à jour, mais l'annonce publique ne précise pas le seuil du réseau en production pour procéder, une règle de report ou une procédure de rollback. Rapporter ces détails nécessiterait un avis technique actuel ou des réponses de l'équipe. Une affirmation spéculative selon laquelle un opérateur en retard pourrait arrêter le Mainnet ne serait pas justifiée.

Les opérateurs peuvent être divisés en plusieurs groupes. Une machine peut exécuter le bon binaire sans être un participant actif au consensus. Une autre peut être active mais ne pas avoir d'historique de registre récent parce qu'elle a perdu la connectivité. Une troisième peut traiter des registres tout en servant des informations obsolètes via un point de terminaison d'application. Un simple pourcentage étiqueté « nœuds mis à niveau » pourrait masquer ces différences. Les décomptes de versions nécessitent une définition des machines et des fonctions qu'ils couvrent.

Après l'activation, les développeurs devraient tester un chemin de transaction complet : soumettre un appel, recevoir un résultat, vérifier la finalité du registre et lire l'état mis à jour du contrat via leur application. Si une mise à niveau groupée modifie plusieurs contrats, le test devrait vérifier à la fois l'exécution réussie et la gestion des échecs. Une application affichant le bon numéro de version tout en montrant un solde obsolète aurait encore un problème visible pour l'utilisateur.

Une pause temporaire pour corriger un problème serait la preuve d'une décision opérationnelle, et non automatiquement la preuve que la conception originale a échoué. Inversement, une annonce selon laquelle le réseau est resté en ligne n'établirait pas que chaque migration a préservé des données d'application correctes. Un journal d'incidents public avec les versions concernées, les registres et les remèdes permettrait aux utilisateurs de distinguer un problème courant de mise à niveau de nœud d'un défaut dans la nouvelle fonctionnalité.

La date limite et l'activation planifiée offrent une fenêtre de reporting étroite pour ces vérifications. Le résultat du 16 octobre devrait être décrit avec le statut au moment des faits, et toute affirmation d'application devrait identifier les transactions Mainnet spécifiques qui la soutiennent.

Ce qu'il faut surveiller

• Activation du 16 octobre : Confirmez la version du protocole du Mainnet au moyen d'un avis de projet daté et d'observations indépendantes du registre.
• Versions des nœuds actifs : Recherchez une répartition vérifiable des nœuds de consensus sur le Protocole 28 après la mise à niveau.
• Démonstrations de fonctionnalités : Vérifiez les adresses de contrats et les transactions reproductibles utilisant des mises à niveau groupées ou des modifications de données stockées.
• Continuité du réseau : Suivez les registres interrompus, les transactions échouées ou les correctifs d'urgence autour de l'activation.
• Utilisation des applications : Comparez les applications nommées, les portefeuilles actifs et les transactions économiquement significatives après le déploiement.

FAQ