Stellar Protocol 30 Bell Active Sur Testnet Avant Vote

Imaginez un réseau blockchain capable de gérer des millions de clients à travers un seul contrat intelligent, de se préparer dès aujourd’hui aux ordinateurs quantiques et de poser les bases d’une vitesse de traitement encore plus élevée. C’est exactement ce que Stellar vient de faire en activant son Protocol 30, surnommé Bell, sur le testnet. Le vote des validateurs pour le passage sur le mainnet est déjà programmé au 23 novembre à 17 heures UTC. Cette mise à jour n’est pas une simple évolution technique. Elle redéfinit la façon dont les entreprises, les exchanges et les développeurs vont interagir avec le réseau dans les mois à venir.

Protocol 30 Bell : une étape majeure pour Stellar

Le 4 novembre, la Stellar Development Foundation a confirmé que Bell tournait officiellement sur le testnet. Trois propositions techniques majeures composent cette version : CAP-84, CAP-87 et CAP-88. Chacune répond à un besoin concret du marché. Les adresses de contrats muxed facilitent la gestion des fonds clients. La vérification de signatures ML-DSA introduit une résistance quantique au niveau des smart contracts. Enfin, l’enregistrement des horodatages en millisecondes ouvre la porte à des ledgers plus rapides dans les prochaines mises à jour.

Cette activation sur testnet fait suite à un vote des validateurs organisé le 3 novembre. Le même mécanisme sera reproduit le 23 novembre pour le mainnet. Si les validateurs approuvent, Protocol 30 Bell deviendra la nouvelle norme du réseau Stellar. Les équipes techniques ont déjà publié les versions compatibles de Stellar Core, Horizon, RPC et Galexie. Les développeurs disposent également des SDK JavaScript 17.3.0, Go 0.8.0 et d’une version candidate du SDK Rust pour Soroban.

Les adresses muxed : simplifier la gestion des clients

Jusqu’à présent, les exchanges et les custodians pouvaient utiliser des comptes muxed classiques, ceux qui commencent par la lettre M. Ces comptes permettaient de recevoir des dépôts de nombreux utilisateurs tout en identifiant chacun grâce à un identifiant unique. Les smart accounts, eux, ne disposaient pas de cette fonctionnalité. Il fallait déployer un contrat distinct pour chaque client, ce qui devenait rapidement coûteux et complexe lorsque le nombre d’utilisateurs grimpait.

CAP-84 change la donne. Désormais, une adresse de contrat peut embarquer un identifiant de 64 bits. Les fonds arrivent toujours sur le contrat sous-jacent, mais l’identifiant client est enregistré dans l’événement de transfert. Les nouvelles adresses commencent par la lettre W, ce qui les distingue clairement des anciennes adresses muxed. Les providers de wallets, les exchanges et les applications qui traitent des adresses Stellar doivent donc mettre à jour leur code pour reconnaître ce nouveau format.

Concrètement, un exchange peut maintenant gérer des millions de clients à travers un seul smart contract. Les dépôts sont correctement attribués grâce à l’identifiant intégré. Cette approche réduit les coûts de déploiement, simplifie la maintenance et limite les risques liés à la multiplication des contrats. Les entreprises de paiement et les custodians y voient un avantage opérationnel immédiat.

Signatures post-quantiques dans les smart contracts

La deuxième grande nouveauté concerne la sécurité. CAP-87 introduit la vérification de signatures ML-DSA à l’intérieur de 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 comme Ed25519, secp256k1 ou secp256r1, ML-DSA est conçu pour résister aux attaques d’ordinateurs quantiques suffisamment puissants.

Stellar continue d’utiliser 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 une opération. Les wallets et les custodians ont ainsi la possibilité d’ajouter une couche de contrôle quantique-résistante sur les dépenses. La vérification s’effectue via Stellar Core, car le calcul est nettement plus gourmand en ressources que les signatures classiques.

Protocol 30 propose trois fonctions de vérification correspondant aux différents niveaux de sécurité de ML-DSA. Il s’agit du premier composant on-chain du plan de préparation quantique de Stellar. D’autres blockchains explorent des pistes similaires. En août, Sui avait déjà annoncé des travaux sur l’authentification quantique-sécurisée s’appuyant sur des schémas approuvés par le NIST.

La vérification ML-DSA ouvre la voie à des smart accounts réellement préparés pour l’ère quantique, tout en laissant le réseau continuer à fonctionner avec Ed25519 pour le moment.

Timing en millisecondes : préparer la vitesse future

CAP-88 s’attaque à un détail technique qui semblait anodin mais qui bloquait les évolutions. Jusqu’à présent, Stellar enregistrait les horodatages de fermeture de ledger en secondes entières. Impossible donc de cibler des intervalles inférieurs à une seconde. Protocol 30 introduit des timestamps à la milliseconde près. Cette précision ne réduit pas immédiatement le temps de fermeture des ledgers, mais elle lève une restriction technique importante.

En septembre, Protocol 28 avait déjà fait passer le temps de fermeture typique de 5,7 secondes environ à cinq secondes sur le mainnet. Les développeurs de Stellar Core expérimentent désormais des traitements encore plus rapides. CAP-88 leur donne la marge de manœuvre nécessaire pour les prochaines optimisations. Le nouveau format d’en-tête de ledger oblige cependant les applications qui décodent les données brutes de la blockchain à mettre à jour leurs outils.

Les SDK plus anciens risquent de ne plus pouvoir décoder correctement les ledgers Protocol 30. Les indexeurs et les services d’analyse doivent actualiser leurs définitions XDR. En revanche, les contrats Soroban déjà déployés continuent de fonctionner sans modification. Seuls les développeurs qui souhaitent utiliser les nouvelles fonctionnalités doivent mettre à jour leurs environnements de développement.

Ce que doivent faire les acteurs de l’écosystème

Les validateurs ont reçu l’instruction d’installer Stellar Core version 30.0.0 avant le vote du 23 novembre. Les exchanges, les providers de wallets et les opérateurs d’infrastructure doivent préparer leurs intégrations au nouveau format de ledger et au format d’adresse commençant par W. Les équipes de la foundation ont publié un guide de mise à jour détaillé le 23 octobre pour accompagner cette transition.

Les développeurs disposent déjà des SDK nécessaires. La version JavaScript 17.3.0 et la version Go 0.8.0 sont disponibles. Une release candidate du SDK Rust pour Soroban a également été proposée. L’écosystème dispose donc de plusieurs semaines pour tester et adapter ses applications avant l’activation potentielle sur le mainnet.

Un contexte d’évolution continue pour Stellar

Protocol 30 Bell s’inscrit dans une série d’améliorations récentes. Fin octobre, VIA Labs a intégré la messagerie cross-chain entre Stellar et Ethereum. Les contrats Soroban peuvent désormais échanger des messages avec des contrats déployés sur Ethereum. Cette interopérabilité ouvre des cas d’usage autour des stablecoins, des actifs tokenisés et des transactions multi-chaînes.

Le réseau Stellar continue de se positionner comme une infrastructure adaptée aux paiements et aux services financiers. Les adresses muxed répondent directement aux besoins des exchanges et des custodians. La préparation quantique montre une vision à long terme. Le timing en millisecondes prépare le terrain pour des performances encore plus élevées. Ensemble, ces trois piliers forment une mise à jour cohérente et orientée vers l’usage professionnel.

Le prix de Stellar évolue dans un marché crypto toujours volatile. Au moment de l’annonce, l’actif évoluait autour de 0,16 dollar avec un volume de trading quotidien significatif et une capitalisation dépassant les 5,7 milliards de dollars. Ces chiffres rappellent que les avancées techniques se produisent dans un contexte de marché en mouvement permanent.

Les implications pour les développeurs

Les développeurs qui travaillent déjà sur Soroban n’ont pas besoin de réécrire leurs contrats existants. Ils doivent simplement mettre à jour leurs outils pour profiter des nouvelles possibilités. Les adresses muxed ouvrent des architectures plus simples pour les applications multi-utilisateurs. La possibilité d’exiger des signatures ML-DSA permet de concevoir des mécanismes de contrôle plus robustes face aux menaces futures.

Les équipes qui construisent des indexeurs ou des explorateurs de blocs devront être particulièrement attentives. Le nouveau format d’en-tête de ledger et les nouveaux types d’adresses nécessitent des mises à jour côté parsing. Les services d’analytics qui s’appuient sur les données brutes de la blockchain doivent également adapter leurs pipelines.

Pour les créateurs de wallets, le support du format d’adresse W devient indispensable. Les utilisateurs s’attendront à pouvoir envoyer et recevoir des fonds vers ces nouvelles adresses sans friction. Les interfaces devront clairement indiquer la nature de l’adresse et éventuellement afficher l’identifiant client associé lorsque cela a du sens.

Pourquoi le timing en millisecondes compte vraiment

À première vue, passer d’une précision à la seconde à une précision à la milliseconde peut sembler purement cosmétique. En réalité, cette modification lève un verrou technique. Tant que les horodatages étaient limités à la seconde, il était impossible de cibler des intervalles de fermeture de ledger inférieurs à une seconde de manière fiable. Avec des timestamps plus fins, les équipes de Stellar Core peuvent expérimenter des configurations plus agressives.

Les expériences en cours visent à réduire encore le temps de fermeture des ledgers. Protocol 28 avait déjà apporté une amélioration tangible. Protocol 30 prépare le terrain pour la suite. Dans un écosystème où la vitesse de finalité reste un critère de compétitivité, cette flexibilité technique n’est pas anodine.

Les applications qui affichent des données en temps réel devront aussi s’adapter. Les horodatages plus précis peuvent améliorer la qualité des graphiques et des analyses de performance. Les services de monitoring gagneront en granularité.

La préparation quantique : une vision long terme

L’introduction de ML-DSA dans les smart contracts marque une étape concrète dans le plan de préparation quantique de Stellar. Les ordinateurs quantiques capables de casser les signatures elliptiques actuelles n’existent pas encore à grande échelle, mais la communauté cryptographique anticipe déjà ce risque. Intégrer dès maintenant la possibilité de vérifier des signatures post-quantiques permet aux applications de se préparer progressivement.

Les smart accounts peuvent désormais combiner plusieurs schémas de signature. Un wallet peut par exemple exiger une signature Ed25519 classique et une signature ML-DSA pour les opérations sensibles. Cette approche hybride offre une transition en douceur. Le réseau lui-même continuera d’utiliser Ed25519 pour les transactions tant qu’une future mise à jour protocolaire ne décidera pas autrement.

D’autres projets blockchain travaillent sur des pistes comparables. L’annonce de Sui en août a montré que la question quantique progresse dans plusieurs écosystèmes. Stellar se positionne parmi les premiers à proposer un composant on-chain utilisable dès aujourd’hui.

Les défis de la transition

Toute mise à jour protocolaire majeure comporte des risques de friction. Les applications qui n’auront pas mis à jour leurs SDK risquent de rencontrer des erreurs de décodage. Les services qui traitent des adresses devront reconnaître le préfixe W. Les indexeurs qui s’appuient sur d’anciennes définitions XDR devront être actualisés sous peine de perdre des données ou d’afficher des informations incorrectes.

La foundation a anticipé ces points en publiant un guide de mise à jour et en rendant disponibles les versions compatibles des principaux composants. Les validateurs ont plusieurs semaines pour installer Stellar Core 30.0.0 et tester le comportement sur testnet. Les exchanges et les custodians disposent du même délai pour adapter leurs backends.

Le vote du 23 novembre à 17 heures UTC reste le point de bascule. Si les validateurs approuvent, Protocol 30 Bell s’activera sur le mainnet. L’écosystème devra alors fonctionner avec les nouvelles règles. Les équipes qui auront anticipé la transition seront prêtes. Celles qui auront attendu le dernier moment risquent de rencontrer des interruptions de service temporaires.

Ce que Protocol 30 change concrètement pour les utilisateurs finaux

Pour un utilisateur lambda qui envoie simplement des XLM ou des tokens, le changement sera quasi invisible. Les adresses classiques continueront de fonctionner. Les contrats existants resteront opérationnels. En revanche, les utilisateurs qui interagissent avec des exchanges ou des services de paiement qui adoptent les adresses muxed verront potentiellement de nouveaux formats d’adresses apparaître dans leurs interfaces.

Les wallets qui supporteront ML-DSA pourront proposer des options de sécurité renforcée. Un utilisateur soucieux de long terme pourra choisir d’activer des contrôles de signature post-quantiques pour certaines opérations. Ces fonctionnalités resteront optionnelles et progressives.

La vitesse de confirmation des transactions ne changera pas immédiatement. CAP-88 prépare le terrain mais ne réduit pas encore le temps de fermeture des ledgers. Les améliorations de performance arriveront dans de futures mises à jour une fois que les expérimentations en cours auront abouti.

Le rôle des validateurs dans le processus

Sur Stellar, les évolutions protocolaires passent par un vote des validateurs. Le mécanisme a déjà été utilisé pour Protocol 28 et pour l’activation de Bell sur le testnet. Le 23 novembre, les validateurs voteront à nouveau. L’activation sur le mainnet dépendra de leur approbation. Ce modèle de gouvernance technique donne au réseau une capacité d’évolution maîtrisée tout en impliquant les opérateurs d’infrastructure.

Les validateurs doivent installer la version 30.0.0 de Stellar Core avant le vote. Ils sont encouragés à tester le comportement sur le testnet, déjà actif depuis le 3 novembre. La coordination se fait via les canaux développeurs et les canaux validateurs de la foundation. L’objectif est d’assurer une transition fluide et une adoption large des nouvelles versions logicielles.

Perspectives après le 23 novembre

Si le vote est positif, Protocol 30 Bell deviendra la version active du mainnet. Les adresses muxed, la vérification ML-DSA et les timestamps en millisecondes seront alors disponibles en production. Les développeurs pourront commencer à déployer des applications qui tirent parti de ces nouveautés. Les exchanges et les custodians pourront migrer progressivement leurs flux de dépôts vers les nouvelles adresses W.

Les prochaines étapes concerneront probablement l’optimisation des temps de ledger grâce à la précision millisecondes. Des expérimentations sont déjà en cours côté Stellar Core. Une future mise à jour protocolaire pourrait alors réduire encore le temps de finalité. La préparation quantique se poursuivra également, avec potentiellement l’introduction de signatures post-quantiques au niveau du réseau lui-même dans des versions ultérieures.

L’intégration cross-chain avec Ethereum via VIA Labs montre que Stellar ne se limite plus à son propre écosystème. Les stablecoins, les actifs tokenisés et les applications multi-chaînes peuvent désormais s’appuyer sur une interopérabilité concrète. Protocol 30 renforce cette dynamique en offrant des outils plus adaptés aux besoins des entreprises.

Un réseau qui se prépare aux usages institutionnels

Les adresses muxed répondent directement aux contraintes des acteurs qui gèrent de grands volumes de clients. Un exchange qui doit attribuer des dépôts à des centaines de milliers d’utilisateurs gagne en simplicité et en coût opérationnel. Un custodian qui utilise des smart accounts pour contrôler les permissions de dépense peut maintenant le faire sans multiplier les contrats.

La possibilité d’intégrer des signatures ML-DSA s’inscrit dans une logique de conformité et de robustesse à long terme. Les institutions qui évaluent les risques cryptographiques sur plusieurs décennies apprécieront de pouvoir activer dès maintenant des mécanismes résistants aux menaces quantiques. Même si ces menaces restent futures, la capacité technique existe déjà.

Le timing en millisecondes, quant à lui, montre que Stellar continue d’investir dans la performance. Après le passage à cinq secondes de temps de fermeture, la porte est ouverte à des améliorations supplémentaires. Dans un marché où la concurrence sur la vitesse et le coût des transactions reste forte, chaque gain technique compte.

Comment suivre l’évolution du vote

Les annonces officielles de la Stellar Development Foundation restent la source principale d’information. Le compte X de l’organisation a déjà confirmé l’activation sur testnet et rappelé la date du vote mainnet. Les canaux développeurs et les forums validateurs permettent de suivre les discussions techniques et les retours d’expérience sur le testnet.

Les équipes qui construisent sur Stellar ont intérêt à tester dès maintenant leurs applications contre Protocol 30. Le testnet est disponible et les SDK sont publiés. Plus les tests sont réalisés tôt, plus les éventuels problèmes de compatibilité peuvent être identifiés et corrigés avant le 23 novembre.

Le guide de mise à jour publié le 23 octobre reste le document de référence pour les aspects techniques. Il détaille les versions logicielles nécessaires, les changements de format et les points de vigilance pour les différents types d’acteurs de l’écosystème.

Synthèse des trois piliers de Bell

CAP-84 apporte les adresses de contrats muxed. Un identifiant 64 bits intégré à l’adresse permet de distinguer les clients sans déployer un contrat par utilisateur. Le format commence par W. Les providers doivent mettre à jour leurs logiciels pour le reconnaître.

CAP-87 introduit la vérification ML-DSA dans les smart contracts. Trois niveaux de sécurité sont supportés. La vérification s’exécute via Stellar Core. Les signatures de transactions réseau restent en Ed25519. Il s’agit du premier élément on-chain du plan quantique de Stellar.

CAP-88 remplace les horodatages en secondes par des timestamps en millisecondes. Cette précision n’accélère pas encore les ledgers mais permet des expérimentations futures. Le nouveau format d’en-tête de ledger impose des mises à jour côté applications qui décodent les données brutes.

L’importance d’une adoption progressive

Les mises à jour protocolaires réussies reposent sur une adoption large et anticipée. Stellar a multiplié les communications depuis octobre. Les SDK ont été publiés, le guide de mise à jour est disponible, le testnet est actif. Les acteurs qui suivent ces recommandations réduisent fortement le risque de friction le jour de l’activation.

Les exchanges et les custodians ont un rôle particulier. Leurs utilisateurs s’attendent à une continuité de service. Une mise à jour tardive des backends pourrait entraîner des retards dans le traitement des dépôts ou des retraits. Anticiper le support des adresses W et du nouveau format de ledger est donc une priorité opérationnelle.

Les développeurs indépendants et les équipes de projets DeFi ont également intérêt à tester leurs contrats et leurs interfaces. Même si les contrats existants restent compatibles, l’utilisation des nouvelles fonctionnalités nécessite des outils à jour. Les wallets qui souhaitent proposer ML-DSA devront intégrer les fonctions de vérification correspondantes.

Un regard sur l’écosystème plus large

Stellar n’évolue pas isolément. L’intégration cross-chain avec Ethereum via VIA Labs illustre une volonté d’ouverture. Les stablecoins et les actifs tokenisés circulent de plus en plus entre différentes blockchains. Offrir des outils adaptés aux entreprises tout en préparant le réseau aux défis futurs positionne Stellar comme une infrastructure crédible pour les usages institutionnels et de masse.

La concurrence entre blockchains se joue aussi sur la capacité à évoluer sans casser l’existant. Protocol 30 respecte les contrats déjà déployés tout en ajoutant de nouvelles possibilités. Cette approche progressive limite les frictions et facilite l’adoption. Les validateurs restent les gardiens de la cohérence technique du réseau.

Dans les mois qui suivront l’éventuelle activation, on peut s’attendre à voir apparaître les premières applications qui exploitent pleinement les adresses muxed et les signatures ML-DSA. Les gains de performance liés au timing en millisecondes arriveront probablement dans une phase ultérieure, une fois les expérimentations consolidées.

Conclusion ouverte sur les prochaines semaines

Protocol 30 Bell représente bien plus qu’une mise à jour technique. Il apporte des réponses concrètes à des besoins métier (gestion multi-clients), à des enjeux de sécurité à long terme (résistance quantique) et à des ambitions de performance (précision des timestamps). Le testnet est déjà en production. Le vote mainnet approche à grands pas.

Les acteurs de l’écosystème ont encore le temps de se préparer. Les outils sont disponibles, la documentation est publiée, le testnet fonctionne. Ceux qui anticipent la transition seront prêts le 23 novembre. Ceux qui attendent risquent de devoir rattraper le retard dans l’urgence. L’histoire récente des mises à jour blockchain montre que la préparation fait toute la différence.

Stellar continue de construire une infrastructure orientée vers les paiements et les services financiers tout en intégrant les préoccupations de demain. Protocol 30 Bell en est la dernière illustration. Rendez-vous le 23 novembre pour savoir si les validateurs valident cette nouvelle étape.