Protocole 30 Bell De Stellar Actif Sur Testnet

Imaginez un réseau qui, du jour au lendemain, donne aux entreprises la possibilité de gérer des millions de clients via un seul contrat intelligent, tout en se préparant déjà à l’ère quantique et en ouvrant la porte à des ledgers plus rapides que jamais. C’est exactement ce que Stellar vient de faire. Le 4 novembre 2026, la Fondation Stellar a confirmé l’activation réussie du Protocol 30, surnommé Bell, sur le testnet. Un pas décisif avant le vote des validateurs prévu le 23 novembre à 17 heures UTC pour le basculement sur le mainnet.

Protocol 30 Bell : une étape majeure pour Stellar

Cette mise à jour n’est pas une simple optimisation technique. Elle s’inscrit dans une vision claire : rendre Stellar plus adapté aux besoins des institutions, des exchanges et des fournisseurs de paiements, tout en anticipant les menaces futures liées à l’informatique quantique. Trois propositions techniques majeures, CAP-84, CAP-87 et CAP-88, structurent cette évolution.

L’annonce officielle de la Fondation Stellar souligne que le testnet est désormais opérationnel avec ces nouvelles capacités. Les validateurs ont déjà validé l’activation sur cet environnement de test le 3 novembre. Le prochain rendez-vous critique reste le vote mainnet du 23 novembre. Si la majorité l’approuve, le réseau public basculera vers Protocol 30.

Pour les développeurs, les opérateurs d’infrastructures et les entreprises qui s’appuient sur Stellar, les implications sont concrètes. Wallets, exchanges et indexeurs doivent se préparer. Les logiciels Core, Horizon, RPC et Galexie ont déjà des versions compatibles. Les SDK JavaScript et Go ont également été mis à jour.

Pourquoi cette mise à jour arrive maintenant

Stellar a toujours mis l’accent sur les paiements et les transferts de valeur à faible coût. Avec l’essor des comptes intelligents et des applications DeFi légères, le réseau avait besoin d’outils plus flexibles pour les acteurs institutionnels. Les adresses muxed classiques permettaient déjà de distinguer les clients dans un compte unique. Mais les smart accounts, basés sur des contrats programmables, n’avaient pas encore cette souplesse.

En parallèle, la question de la résistance quantique n’est plus théorique. Les algorithmes actuels comme Ed25519, secp256k1 ou secp256r1 pourraient un jour être vulnérables. Stellar choisit d’introduire dès maintenant la vérification de signatures ML-DSA dans l’environnement Soroban. C’est une première étape concrète de son plan de préparation quantique.

Enfin, le timing des ledgers en millisecondes prépare le terrain pour des clôtures plus rapides. Après la réduction à cinq secondes obtenue avec Protocol 28, l’objectif est de lever les limitations techniques pour aller encore plus loin dans le futur.

Les trois piliers techniques de Bell

Chaque CAP apporte une pièce du puzzle. Ensemble, elles forment une mise à jour cohérente qui touche à la gestion des fonds clients, à la sécurité cryptographique et à l’architecture des ledgers.

CAP-84 : les adresses muxed pour smart contracts

Jusqu’à présent, les exchanges et custodians utilisaient des adresses muxed commençant par la lettre M. Elles permettaient de recevoir des dépôts de différents clients sur un même compte tout en conservant un identifiant unique pour chacun. Les smart accounts, plus programmables, ne disposaient pas de cette fonctionnalité. Il fallait souvent déployer un contrat distinct par client, ce qui devenait rapidement coûteux et complexe à grande échelle.

CAP-84 change la donne. Une adresse de contrat peut désormais embarquer un identifiant de 64 bits. Cet identifiant désigne le client destinataire sans nécessiter de contrat supplémentaire. Les nouvelles adresses commencent par la lettre W, ce qui les distingue clairement des anciennes adresses muxed.

Lors d’un transfert vers une telle adresse, les fonds arrivent bien sur le contrat sous-jacent. L’identifiant client est simplement enregistré dans l’événement de transfert. Pour un exchange ou un prestataire de paiement, cela signifie pouvoir gérer potentiellement des millions d’utilisateurs via un nombre limité de contrats intelligents.

Cette approche réduit la complexité opérationnelle et les coûts de déploiement. Elle s’aligne parfaitement avec les besoins des plateformes qui veulent offrir des comptes intelligents à leurs utilisateurs tout en gardant une architecture simple côté backend.

Les exchanges, les prestataires de paiement et les custodians peuvent désormais gérer les dépôts clients via des smart accounts sans déployer un contrat individuel pour chaque utilisateur.

Fondation Stellar

Les wallets et applications qui traitent des adresses Stellar doivent impérativement prendre en charge ce nouveau format. Sans mise à jour, certaines opérations pourraient échouer ou être mal interprétées. C’est l’un des points de vigilance majeurs soulignés dans le guide de migration de la Fondation.

CAP-87 : la vérification de signatures post-quantiques

La deuxième innovation majeure concerne la sécurité. CAP-87 introduit la possibilité de vérifier des signatures ML-DSA directement dans l’environnement Soroban. ML-DSA est un algorithme de signature numérique post-quantique standardisé par le NIST en 2024. Contrairement aux schémas basés sur les courbes elliptiques, il a été conçu pour résister aux attaques d’ordinateurs quantiques suffisamment puissants.

Stellar conserve pour le moment Ed25519 pour les signatures de transactions au niveau du réseau. En revanche, les développeurs peuvent désormais créer des smart accounts qui exigent une signature ML-DSA avant d’autoriser certaines opérations. C’est particulièrement utile pour les wallets et custodians qui souhaitent anticiper les risques quantiques sur les contrôles de dépenses.

La vérification elle-même s’exécute via Stellar Core. La raison est purement technique : vérifier une signature ML-DSA demande nettement plus de ressources de calcul que les algorithmes classiques. Trois niveaux de sécurité sont supportés, correspondant aux différentes variantes de l’algorithme.

Cette fonctionnalité constitue le premier composant on-chain du plan de préparation quantique de Stellar. D’autres réseaux, comme Sui, ont également annoncé des travaux similaires autour d’authentifications quantiques-sûres. Stellar prend une longueur d’avance en rendant la vérification disponible dès Protocol 30.

Pour les développeurs, cela ouvre de nouvelles possibilités de conception de comptes intelligents. On peut imaginer des multi-signatures hybrides ou des règles de dépense qui imposent une signature post-quantique pour les montants élevés. La flexibilité est réelle, même si le coût computationnel reste plus élevé.

CAP-88 : le timing des ledgers en millisecondes

Le troisième pilier de Bell touche à l’architecture profonde du réseau. Jusqu’à présent, Stellar enregistrait les horodatages de clôture des ledgers en secondes entières. Cette granularité empêchait de viser des intervalles strictement inférieurs à une seconde.

CAP-88 introduit des timestamps à la milliseconde. Cette précision supplémentaire ne réduit pas immédiatement le temps de clôture des ledgers. Après Protocol 28, le réseau tournait déjà autour de cinq secondes. L’objectif est plutôt de lever une contrainte technique pour permettre, dans de futures mises à jour, des intervalles encore plus fins.

Les équipes de développement de Stellar Core expérimentent déjà des traitements de ledger plus rapides. La nouvelle résolution d’horloge leur donne la latitude nécessaire pour tester ces approches sans être bloqués par le format de données actuel.

Le changement implique un nouveau format d’en-tête de ledger. Les applications qui décodent les données brutes de la blockchain doivent mettre à jour leurs définitions XDR. Les SDK plus anciens peuvent échouer à lire les ledgers Protocol 30. Les indexeurs et services d’analyse doivent donc se préparer en amont.

Bonne nouvelle : les contrats Soroban existants continuent de fonctionner sans modification. Seuls les outils et les couches d’infrastructure qui interagissent directement avec le format des ledgers nécessitent une mise à jour.

Le calendrier et les préparatifs pour le mainnet

Le vote des validateurs pour l’activation sur le mainnet est fixé au 23 novembre 2026 à 17 heures UTC. La Fondation a publié un guide de migration complet. Les versions compatibles de Stellar Core (v30.0.0), Horizon, RPC et Galexie sont déjà disponibles. Les SDK JavaScript 17.3.0 et Go 0.8.0 ont également été publiés, ainsi qu’une version candidate du SDK Rust pour Soroban.

Les validateurs ont reçu l’instruction claire d’installer Stellar Core v30.0.0 avant le vote. Les exchanges, wallets et opérateurs d’infrastructure doivent adapter leurs intégrations au nouveau format d’adresses et au nouveau format de ledger.

Cette coordination n’est pas anodine. Une activation réussie dépend de la préparation de l’ensemble de l’écosystème. Un décalage entre les nœuds ou les services critiques pourrait créer des frictions temporaires. C’est pourquoi la Fondation multiplie les communications via ses canaux développeurs et validateurs.

Impact concret pour les différents acteurs

Pour les exchanges et custodians, CAP-84 représente un gain opérationnel majeur. La gestion de millions de clients via des smart accounts devient bien plus réaliste. Les coûts de déploiement et de maintenance diminuent, tandis que la clarté des flux de fonds s’améliore grâce aux identifiants embarqués.

Les wallets doivent absolument supporter le nouveau format d’adresses commençant par W. Sans cela, les utilisateurs risquent de rencontrer des erreurs lors de transferts vers des adresses muxed de contrats. La mise à jour des applications est donc prioritaire.

Les développeurs de smart contracts gagnent de nouveaux outils. Ils peuvent désormais concevoir des comptes qui exigent des signatures ML-DSA. Cela ouvre la voie à des mécanismes de sécurité plus avancés, particulièrement intéressants pour les applications institutionnelles ou les wallets multi-signatures.

Les indexeurs et services d’analyse doivent mettre à jour leurs parsers XDR. Les anciens SDK risquent de ne plus décoder correctement les ledgers Protocol 30. Une préparation anticipée évite les interruptions de service le jour de l’activation.

Le contexte plus large de l’écosystème Stellar

Protocol 30 s’inscrit dans une dynamique plus large. Fin octobre 2026, VIA Labs a activé la messagerie inter-chaînes entre Stellar et Ethereum. Les contrats Soroban peuvent désormais échanger des messages avec des contrats déployés sur Ethereum. Cette intégration facilite les cas d’usage autour des stablecoins, des actifs tokenisés et des transactions cross-chain.

La combinaison de ces avancées positionne Stellar comme un réseau de plus en plus attractif pour les institutions qui cherchent à la fois performance, coûts réduits et capacités de programmation avancées. Les smart accounts deviennent plus pratiques grâce aux adresses muxed, tandis que la préparation quantique rassure sur le long terme.

Le marché des cryptomonnaies observe avec attention ces évolutions. Les réseaux qui parviennent à combiner simplicité d’usage pour les paiements et robustesse technique pour les applications plus complexes gagnent en pertinence. Stellar semble déterminer à rester dans cette catégorie.

Les défis restants et les points de vigilance

Malgré l’enthousiasme, plusieurs défis demeurent. La vérification ML-DSA est plus coûteuse en ressources. Les développeurs devront trouver le bon équilibre entre sécurité renforcée et efficacité. Tous les cas d’usage n’ont pas forcément besoin d’une signature post-quantique dès aujourd’hui.

Le nouveau format d’adresses impose une coordination large. Si une partie significative des wallets ou des exchanges n’est pas prête le jour de l’activation, des frictions utilisateurs peuvent apparaître. La communication de la Fondation et la participation active de la communauté seront déterminantes.

Enfin, le passage au timing milliseconde n’apporte pas de gain immédiat de performance. Les utilisateurs ne verront pas de réduction du temps de clôture des ledgers avec Protocol 30. L’avantage se situera dans les upgrades futurs. Il faut donc gérer les attentes.

Ces points de vigilance n’enlèvent rien à l’intérêt de la mise à jour. Ils rappellent simplement qu’une activation réussie dépend autant de la technique que de la préparation collective de l’écosystème.

Ce que Protocol 30 change pour l’utilisateur final

Pour la plupart des utilisateurs individuels, les changements resteront invisibles dans un premier temps. Les transferts classiques continueront de fonctionner de la même manière. Les gains se situent davantage du côté des plateformes qui proposent des services avancés.

Un exchange qui adopte les adresses muxed de contrats pourra offrir des comptes intelligents à ses clients de façon plus fluide. Un wallet qui intègre la vérification ML-DSA pourra proposer des options de sécurité renforcée. Ces améliorations finiront par redescendre vers l’expérience utilisateur, mais de manière progressive.

La préparation quantique, quant à elle, est une assurance sur le long terme. Peu d’utilisateurs y pensent aujourd’hui, mais les réseaux qui anticipent ces risques se placent dans une position favorable pour les décennies à venir.

Perspectives après le vote du 23 novembre

Si les validateurs approuvent l’activation, Protocol 30 Bell deviendra la nouvelle norme du réseau Stellar. Les équipes de développement pourront alors se concentrer sur les prochaines étapes : optimisation des performances de ledger, extension progressive des mécanismes quantiques-sûrs, et intégration plus profonde avec d’autres blockchains.

La Fondation a déjà montré sa capacité à livrer des upgrades régulières et bien coordonnées. Protocol 28 avait réduit le temps de clôture des ledgers. Protocol 30 pose les bases techniques pour aller encore plus loin tout en renforçant la sécurité et la flexibilité des smart accounts.

Dans un secteur où les annonces se multiplient, la capacité d’exécution reste un critère déterminant. Stellar démontre une fois de plus qu’il sait avancer méthodiquement, avec un calendrier clair et une documentation précise pour l’ensemble des acteurs.

Un réseau qui se prépare à l’avenir

Protocol 30 Bell n’est pas une révolution spectaculaire qui change tout du jour au lendemain. C’est une mise à jour structurante qui répond à des besoins concrets des entreprises tout en anticipant des enjeux de long terme. Les adresses muxed pour smart contracts simplifient la gestion des clients à grande échelle. La vérification ML-DSA pose les premières pierres de la résistance quantique. Le timing milliseconde ouvre la voie à des ledgers plus rapides.

Le testnet est déjà en production avec ces nouveautés. Le 23 novembre, les validateurs décideront du passage sur le mainnet. Entre-temps, l’écosystème a quelques semaines pour finaliser ses préparatifs. Wallets, exchanges, indexeurs et développeurs ont tous un rôle à jouer pour que la transition se fasse en douceur.

Stellar continue de construire, pierre après pierre, un réseau capable de servir à la fois les paiements de tous les jours et les applications plus sophistiquées de demain. Protocol 30 Bell s’inscrit pleinement dans cette trajectoire. L’activation sur le testnet marque le début de la dernière ligne droite avant le basculement définitif.

Les prochaines semaines diront si la communauté des validateurs suit le rythme proposé par la Fondation. Tout indique que les conditions techniques sont réunies. Reste maintenant à confirmer l’adhésion collective pour que Bell devienne officiellement la nouvelle version du protocole Stellar.

Dans un univers blockchain en constante évolution, les réseaux qui savent anticiper les besoins des institutions tout en protégeant leur architecture face aux menaces futures se démarquent. Avec Protocol 30, Stellar montre qu’il appartient clairement à cette catégorie. L’activation sur le testnet n’est que le premier acte. Le vote du 23 novembre en sera le second. Et l’histoire, elle, ne fait que commencer.