La Stellar Development Foundation a publié le 13 août la version stable 28.0.0 de Stellar Core. Le logiciel contient trois changements destinés au consensus et aux contrats Soroban : abandon explicite d’un lot de transactions indisponible, mise à jour simultanée d’une famille de contrats et migration plus souple de leurs données.

Ce n’est pourtant pas encore une activation sur le réseau principal. Les validateurs doivent d’abord voter sur le testnet le 27 août, puis sur le mainnet le 16 septembre. Entre un code disponible et un protocole adopté par le réseau, il reste donc deux étapes vérifiables — et plusieurs obligations techniques pour les opérateurs.

Ce qui a réellement été publié

La version 28.0.0 de Stellar Core est une publication logicielle stable, datée du 13 août à 20 h 05 UTC. Ses notes de version rattachent explicitement Protocol 28, surnommé « Adapter », aux propositions CAP-83, CAP-85 et CAP-86.

Le guide officiel de mise à niveau prévoit ensuite une fenêtre du 13 au 21 août pour les autres composants d’infrastructure et les kits de développement. Il demande aux intégrations testnet de se mettre à jour avant le 27 août, et aux intégrations mainnet avant le 16 septembre.

Cette distinction est importante. Le 27 août à 17 h UTC correspond au vote de mise à niveau du testnet. Le vote du réseau principal est prévu le 16 septembre à 17 h UTC. Une date de vote n’est pas une garantie d’adoption : les validateurs doivent être prêts et accepter la nouvelle version du protocole.

CAP-83 : avancer sans attendre indéfiniment un lot

Sur Stellar, les validateurs s’accordent sur le prochain registre et le lot de transactions qui doit y être appliqué. La CAP-83 permet de commencer certaines étapes du vote avant d’avoir reçu l’intégralité de ce lot. Si celui-ci arrive trop tard ou s’avère invalide, les validateurs peuvent voter pour le retirer et finaliser un registre vide plutôt que rester bloqués.

La proposition introduit pour cela une nouvelle valeur, `STELLAR_VALUE_EMPTY_TX_SET`. Les indexeurs, pipelines d’analyse et autres outils qui lisent directement les données brutes du registre doivent savoir la reconnaître et traiter le lot comme vide. Les intégrations ordinaires fondées sur les SDK ne sont pas concernées de la même manière.

Stellar présente ce mécanisme comme un moyen d’améliorer le débit et la régularité du consensus lorsque la diffusion des transactions prend du temps. La limite est essentielle : le téléchargement parallèle qui doit produire le gain complet sera désactivé par défaut au départ, puis activé progressivement. Le code et des simulations soutiennent donc la promesse technique, mais aucune mesure en production ne prouve encore le gain annoncé.

La CAP documente aussi un risque. Un validateur malveillant pourrait proposer un mauvais identifiant de lot et pousser le réseau à finaliser un registre vide après un délai. Le dispositif conserve la valeur d’origine et sa signature afin d’identifier le proposant ; il ne fait pas disparaître la nécessité de surveiller le comportement des validateurs.

CAP-85 : une seule référence pour mettre à jour une flotte

De nombreux protocoles déploient plusieurs exemplaires d’un même contrat. Jusqu’ici, une grande « flotte » Soroban devait être mise à jour instance par instance lorsque son code partagé changeait. Cette séquence crée une période où certaines instances exécutent l’ancienne version et d’autres la nouvelle.

La CAP-85 ajoute une référence de code administrée par un autre contrat. Toutes les instances qui la suivent peuvent basculer simultanément vers le nouveau binaire. Stellar compare ce modèle au « beacon proxy » utilisé dans l’écosystème Ethereum.

L’intérêt est concret pour un correctif de sécurité : une modification atomique réduit le risque d’oublier une instance ou de laisser coexister deux versions incompatibles. Mais le même levier concentre le pouvoir de mise à jour. GatherHub en déduit que la sécurité dépendra aussi du propriétaire de la référence, de ses règles d’autorisation, de ses délais éventuels et de la possibilité d’auditer le nouveau code avant le basculement.

Une mise à jour atomique ne garantit pas qu’un changement est bon. Elle amplifie aussi rapidement une erreur si le nouveau binaire est défectueux. Les équipes devront donc conserver audits, tests, contrôles d’accès et procédures de retour arrière adaptés à leur propre architecture.

CAP-86 : faire évoluer les données sans figer le contrat

Les structures de données d’un contrat changent avec le temps : ajout d’un champ, suppression d’un autre, évolution d’une interface. Les fonctions actuelles de Soroban exigent une correspondance exacte entre les clés attendues et les données reçues. La CAP-86 explique que cette rigidité a déjà laissé certains contrats bloqués après une mise à jour.

Deux nouvelles fonctions dites « sparse » accepteront des champs manquants ou supplémentaires de façon contrôlée. Un développeur pourra ainsi migrer progressivement une structure, par exemple en ajoutant d’abord un champ optionnel avant de retirer l’ancien. Les fonctions existantes ne changent pas : l’adoption est volontaire et passe par une reconstruction avec un SDK compatible.

Cette souplesse retire un obstacle opérationnel, pas le risque de migration. Une donnée absente peut désormais être représentée sans faire échouer automatiquement l’appel ; le contrat doit encore définir ce que cette absence signifie. Le guide officiel recommande donc de vérifier les changements incompatibles et de tester les dépendances avant les votes.

Le cours GatherHub Les smart contracts explique pourquoi le code d’un contrat et son état sont deux couches distinctes. Protocol 28 agit précisément sur ces deux plans : la référence du code avec CAP-85, et l’évolution des données avec CAP-86.

Qui doit agir avant les votes

Les opérateurs de Stellar Core, Horizon, RPC et Galexie doivent installer les versions compatibles au fur et à mesure de leur publication. Les validateurs doivent en plus armer leur nœud avant le vote mainnet prévu le 16 septembre. Le guide fixe au 9 septembre à 17 h UTC la date de préparation correspondante.

Protocol 28 exige aussi que les horloges des validateurs soient synchronisées par NTP. Sans cette synchronisation, la nouvelle logique destinée à réduire le temps et la variance de fermeture des registres peut au contraire dégrader les performances du réseau.

Portefeuilles, plateformes d’échange, émetteurs et services d’entrée ou de sortie devront surtout mettre à jour leurs SDK et infrastructures. Les consommateurs de données brutes doivent examiner la nouvelle valeur de registre. Les contrats qui utilisent les références externes ou les nouvelles fonctions de migration devront, eux, choisir explicitement ces mécanismes.

Pourquoi cela compte maintenant

Adapter ne promet pas une nouvelle application visible par le grand public. Il traite un problème moins spectaculaire et plus structurant : comment faire évoluer une infrastructure financière sans interrompre le consensus, laisser une flotte de contrats dans un état incohérent ou figer leurs données pour toujours.

La disponibilité du code rend l’échéance concrète pour les opérateurs. Elle ne prouve ni l’adoption par les validateurs, ni les gains de débit, ni la sécurité des contrats qui utiliseront les nouvelles fonctions. Deux articles secondaires consultés corroborent correctement le calendrier — Crypto Economy et CoinGabbar — mais les détails techniques restent fondés sur les documents de Stellar et les CAP.

À suivre

Le premier contrôle sera la publication des composants et SDK promis avant le 21 août. Le vote testnet du 27 août devra ensuite confirmer que les validateurs adoptent Protocol 28 et que les applications fonctionnent dans cet environnement.

Avant le 16 septembre, il faudra surveiller la préparation des validateurs, la synchronisation de leurs horloges et les éventuels correctifs de version. Après un vote mainnet réussi, les données les plus utiles seront le rythme réel d’activation du téléchargement parallèle, les temps de fermeture des registres et les incidents liés aux nouvelles références de contrats. Jusqu’à ce vote, Protocol 28 reste un logiciel publié et une mise à niveau planifiée — pas encore la règle du réseau principal.

Sources consultées