La mise à niveau Protocol 30 de Stellar, Bell, est « live sur Testnet », a annoncé la Stellar Development Foundation le 3 novembre, ouvrant des tests aux développeurs avant un vote des validateurs sur l'activation sur le mainnet prévu le 23 novembre.
La version donne aux smart contracts de nouveaux moyens d'identifier les dépôts des clients et de vérifier les signatures post-quantiques. Selon le guide de mise à niveau de la SDF, les portefeuilles, les plateformes d'échange et les fournisseurs d'infrastructure doivent mettre à jour leurs bibliothèques logicielles Stellar avant le vote sur le mainnet. Les smart contracts existants peuvent continuer à fonctionner sans modification.
Chargement du post sur X…
Voir le post sur XNouveaux outils pour les comptes intelligents
$CAP-84 introduit les adresses de contrat multiplexées : une adresse de contrat associée à un identifiant client, écrite dans un nouveau format commençant par W. Cela permet à une entreprise d'acheminer les dépôts de plusieurs clients vers un seul smart contract et de suivre leurs soldes hors chaîne. Stellar prenait déjà en charge ce modèle pour les comptes classiques, mais pas pour les adresses de contrat.
Les fonds atteignent toujours le contrat sous-jacent, l'identifiant étant enregistré dans l'événement de transfert ; cela ne crée pas de solde distinct sur la chaîne. Les portefeuilles et les plateformes d'échange doivent accepter les adresses W dans leur logique de validation, d'affichage et de stockage. Les développeurs de contrats qui souhaitent les accepter doivent utiliser un paramètre d'adresse prenant en charge la variante multiplexée : un paramètre d'adresse classique la rejette.
$CAP-87 ajoute à l'environnement de smart contracts Soroban de Stellar trois fonctions de vérification intégrées pour ML-DSA, un algorithme de signature post-quantique standardisé. Les contrats de compte personnalisés peuvent les utiliser pour exiger une autorisation post-quantique avant de dépenser des fonds, sans avoir à implémenter eux-mêmes la vérification. Les signatures de transactions au niveau du réseau restent en Ed25519.
Les nouvelles fonctionnalités des contrats sont optionnelles. Les développeurs qui les adoptent doivent recompiler avec le SDK Soroban mis à jour et utiliser un outil en ligne de commande Stellar correspondant ou plus récent, indique la SDF.
Un nouveau format de registre
$CAP-88 ajoute des horodatages de clôture des registres d'une résolution de la milliseconde. Auparavant, les horodatages en secondes entières imposaient un écart minimal d'une seconde entre les registres et empêchaient des cibles telles que 4,5 secondes. Ce changement supprime cette contrainte de temporisation ; la présentation du protocole par la SDF indique que Bell ne rend pas, à lui seul, les clôtures de registres plus rapides.
Les indexeurs, explorateurs et autres systèmes qui décodent les données brutes des registres doivent mettre à jour leurs règles de mise à niveau, et les validateurs doivent configurer leurs nœuds pour voter à partir d'un moment précis. L'adoption requiert le même consensus que celui utilisé pour approuver les ensembles de transactions. L'accord suit l'ensemble de validateurs de confiance de chaque nœud et le seuil correspondant, plutôt qu'un vote des détenteurs de jetons.
L'activation sur le mainnet dépend de cet accord. La SDF demande aux validateurs d'installer Stellar Core v30.0.0 et indique que la commande pour armer leurs nœuds en vue du vote sera communiquée à l'avance via les canaux réservés aux validateurs.