Tout savoir sur la mise à jour v1.17 de Solana

Quel est le sujet de cet article ?

Le réseau Solana a franchi une étape importante avec l’adoption à la supermajorité de la version 1.17, la dernière version du client de validation de Solana Labs. À la suite de la récente panne réseau, les validateurs ont redémarré avec la version 1.17.20. Au moment de la rédaction, ~68,6 % des validateurs utilisent la version 1.17.21 et ~31,3 % utilisent la version 1.17.20.  Cette nouvelle version apporte une série d’améliorations destinées à renforcer l’efficacité, l’évolutivité et les cas d’usage du réseau. Des avancées pionnières en matière de preuves à divulgation nulle de connaissance à l’amélioration du protocole Gossip, la v1.17 marque une étape charnière dans le développement continu de Solana.

Cet article présente tout ce que vous devez savoir sur la mise à jour 1.17 du client de validation de Solana Labs. Nous examinerons la rigueur des tests de la v1.17, la récente panne réseau et les nouvelles fonctionnalités mises en œuvre avec cette mise à jour.

Comment la v1.17 a-t-elle été testée ?

La v1.17 fonctionne sur testnet depuis le 3 octobre 2023. Elle a régulièrement fait l’objet de tests de charge avec d’importants volumes de transactions. Solana Labs a également déployé quelques nœuds canaris mainnet-beta exécutant la v1.17 afin de surveiller la stabilité de la version dans des conditions réelles. Ils sont restés stables au cours des derniers mois. Vous pouvez consulter l’activité passée et la progression de ces nœuds canaris dans le canal #canaries-monitoring du Discord Solana Tech. De plus, à partir du 4 décembre 2023, un petit sous-ensemble de nœuds mainnet-beta volontaires est passé à la v1.17. 

Plusieurs fuzzers d’exécution ont été développés pour exécuter des transactions partiellement aléatoires afin de détecter les cas limites ou les conditions de concurrence rares. Ces transactions ont été exécutées sur plusieurs versions afin de garantir des performances constantes. La v1.17 a été auditée à plusieurs reprises par des auditeurs externes. Les rapports seront publiés dans le dépôt GitHub des audits de sécurité de Solana dès qu’ils seront disponibles.

Panne de février

Le 6 février 2024 à 9 h 53 UTC, mainnet-beta a subi une panne qui a temporairement interrompu la finalisation des blocs. L’activité du réseau a été perturbée pendant environ cinq heures, jusqu’à la reprise du consensus à 14 h 55 UTC. Cette panne provenait d’un bug lié à la manière dont le réseau compilait et mettait en cache le code d’un programme pour l’exécuter, affectant plus particulièrement les anciennes versions des chargeurs de programmes.

La cause première résidait dans la manière dont les validateurs géraient la sortie compilée en juste-à-temps (JIT) des programmes fréquemment utilisés. Un nouveau système de mise en cache destiné à optimiser ce processus a introduit par inadvertance ce bug critique. Pour certains programmes hérités, ce nouveau système pouvait entrer dans une boucle de recompilation infinie. Le mécanisme de consensus de Solana s’est alors retrouvé bloqué, car la plupart des validateurs ont rencontré ce problème et n’ont pas pu continuer à traiter les transactions.

La cause première a été rapidement identifiée, car le bug présentait plusieurs similitudes avec la récente panne de devnet. La version 1.17.20 a été modifiée pour corriger directement le problème, puis les validateurs ont coordonné un redémarrage du réseau. Le correctif comportait deux volets : une solution à court terme qui empêchait le déclenchement de la boucle infinie en dépréciant les deux chargeurs hérités susceptibles de la provoquer, et une modification plus complète du nouveau système de mise en cache des programmes pour éviter que des problèmes similaires ne se reproduisent. 

Le rapport officiel, initialement publié par Anza, est disponible ici.

ZK Token Proof Program

Le ZK Token Proof Program devait être publié avec la mise à jour 1.16. Son activation a toutefois été retardée en raison d’audits approfondis. Dans le calendrier d’activation des fonctionnalités, le programme est indiqué comme En attente d’activation sur testnet avec une version minimale de 1.17.12. 

Transferts confidentiels

Avec l’activation du ZK Token Proof Program, les transferts confidentiels seront enfin disponibles. Les transferts confidentiels utilisent des preuves à divulgation nulle de connaissance pour chiffrer les soldes et les montants des transferts de tokens SPL. L’objectif principal est ici la confidentialité plutôt que l’anonymat. Le chiffrement homomorphe permet d’effectuer des calculs sur des données chiffrées sans les déchiffrer. Par exemple, il est possible d’additionner ou de soustraire des soldes sans déchiffrer puis rechiffrer les montants concernés. Ces calculs chiffrés produisent ainsi le même résultat que s’ils étaient effectués sur des données en clair.

Les transferts confidentiels utilisent le chiffrement Twisted ElGamal et les protocoles Sigma pour assurer des transactions sécurisées et privées sans révéler d’informations sensibles. 

À titre d’information :

• Le chiffrement Twisted ElGamal est une variante simple du schéma de chiffrement ElGamal standard, dans laquelle un texte chiffré est divisé en un engagement de Pedersen du message chiffré et une clé de déchiffrement permettant d’effectuer des opérations mathématiques masquées sur le texte chiffré
• Les protocoles Sigma servent à valider les transferts confidentiels. Il s’agit d’une catégorie particulière de preuves à divulgation nulle de connaissance dans laquelle une partie (le prouveur) peut prouver à une autre partie (le vérificateur) qu’elle connaît certaines informations sans les révéler

Les transferts confidentiels permettent uniquement au compte détenant la clé de déchiffrement de consulter son solde chiffré. Le système d’auditeur global est mis en œuvre dans les situations nécessitant un examen par un tiers, comme les contrôles de conformité ou les audits. Ce système permet aux titulaires de comptes d’accorder un accès sélectif en lecture à des comptes spécifiques au moyen de clés de déchiffrement distinctes. Il intègre également une « clé de chiffrement d’auditeur » pour les émissions de tokens afin de faciliter la réalisation d’audits sécurisés.

Les transactions utilisent des paramètres chiffrés pour les montants de l’expéditeur, du destinataire et de l’auditeur, ainsi que des preuves garantissant la confidentialité et l’intégrité. Les soldes des comptes sont divisés entre « En attente » et « Disponible » afin d’empêcher les attaques par front-running. Sans cela, un utilisateur malveillant pourrait envoyer des tokens à un compte pour invalider les preuves générées à partir du solde chiffré.

Il est important de noter que les transferts confidentiels nécessitent l’utilisation d’une nouvelle paire de clés. 

Prise en charge de la ligne de commande

La prise en charge des transferts confidentiels dans l’interface de ligne de commande (CLI) via le crate spl-token est également disponible. Une fois la fonctionnalité activée, la commande create-token a été étendue pour inclure l’option –enable-confidential-transfers auto. Les utilisateurs peuvent ainsi émettre des tokens pour lesquels l’extension de transferts confidentiels est activée. Plusieurs autres commandes utiles sont également disponibles, notamment :

• configure-confidential-transfer-account - configure un compte existant pour les transferts confidentiels. Seul le propriétaire du compte peut configurer les transferts confidentiels pour ce compte
• deposit-confidential-tokens - dépose des tokens depuis un compte non confidentiel vers un compte confidentiel. Notez que les tokens déposés n’existeront plus dans le solde non confidentiel du compte, car ils auront été entièrement transférés vers le solde confidentiel
• apply-pending-balance - déplace un solde de « En attente » vers « Disponible ». Cette opération est nécessaire chaque fois qu’un compte reçoit des tokens confidentiels à la suite d’un transfert ou d’un dépôt, car le montant apparaît dans le solde « En attente » du compte. Les utilisateurs n’ont donc pas immédiatement accès aux fonds et doivent appliquer le solde en attente
• transfer (avec l’option –confidential activée) - transfère des tokens vers un autre compte configuré pour les transferts confidentiels. Notez que cette opération peut prendre plus de temps qu’un transfert de tokens classique, car elle nécessite plusieurs transactions dépendantes
• withdraw-confidential-tokens - retire des tokens du solde confidentiel d’un compte vers son solde non confidentiel. Assurez-vous que tout solde en attente a été appliqué avant d’exécuter cette commande afin de retirer tous les tokens attendus
• update-confidential-transfer-settings - met à jour la configuration des transferts confidentiels pour une émission de tokens donnée. Cette commande permet de définir automatiquement des politiques d’approbation des transferts confidentiels, avec l’option –aprove-policy, et de définir la clé publique d’un auditeur, avec l’option –auditor-pubkey. Elle comprend également des options supplémentaires permettant de préciser un blockhash, l’autorité des transferts confidentiels, les fichiers de configuration, les informations sur le payeur des frais, l’URL JSON RPC, les informations sur le compte nonce, le format de sortie et l’ID du programme de tokens

Compatibilité 

Notez que les combinaisons d’extensions suivantes ne fonctionnent pas ou n’ont pas de sens avec les transferts confidentiels :

• Transfert confidentiel + non transférable
• Transfert confidentiel + frais (ne fonctionnera pas avant la version 1.18)
• Transfert confidentiel + hooks de transfert (car ces transferts ne peuvent voir que les comptes source ou de destination et ne peuvent donc pas agir sur le montant transféré)

Audits

Les transferts confidentiels, et plus généralement le programme Token-2022, ont fait l’objet d’audits approfondis réalisés par des sociétés telles que Halborn, Zellic, Trail of Bits, NCC Group et OtterSec, à deux reprises : le premier audit portait sur Token-2022, tandis que le second audit était consacré aux transferts confidentiels.

Appels système Poseidon

Poseidon est une famille de fonctions de hachage adaptée aux preuves à divulgation nulle de connaissance. Les fonctions de hachage Poseidon sont utilisées par la plupart des projets blockchain reposant sur les ZK, notamment Zcash, Mina et le Light Protocol de Solana. Actuellement, le calcul des hachages Poseidon sur Solana est trop coûteux pour être réalisé en une seule transaction. Les appels système Poseidon devraient changer la donne. Leur publication est actuellement prévue avec la v1.17.5, sous réserve de leur activation sur testnet.

Explication simplifiée

Imaginez une calculatrice avancée qui résout efficacement certains types d’énigmes utilisés pour sécuriser les communications. Cette calculatrice prend des éléments d’information, les découpe et les mélange d’une manière unique. Les informations sont ainsi mélangées de façon à masquer entièrement le contenu d’origine tout en permettant de le vérifier.

Ce processus de mélange utilise une méthode spéciale qui additionne des nombres et les élève à certains exposants appartenant à un ensemble défini à l’avance. Cette méthode garantit que le mélange est réalisé de manière complète et cohérente à chaque fois.

Poseidon fait exactement la même chose que cette calculatrice avancée. Ces types de fonctions de hachage sont particulièrement adaptés à la création de circuits à divulgation nulle de connaissance. Les circuits sont essentiellement un ensemble d’opérations mathématiques. Ils représentent mathématiquement la manière dont une partie, le prouveur, démontre à une autre partie, le vérificateur, qu’elle connaît certaines informations sans les révéler. Imaginez que vous deviez prouver que vous savez ce que contient une boîte scellée sans l’ouvrir. Vous pouvez le prouver à la personne qui a scellé la boîte au moyen d’une série de coups ou d’étapes. Ces coups ou étapes sont conçus pour ne révéler aucun détail sur le contenu de la boîte ni sur la façon de l’ouvrir, et ne peuvent être compris que si vous avez ouvert la boîte.

C’est particulièrement utile pour les blockchains, car il est essentiel de préserver la confidentialité des transactions tout en pouvant vérifier leur authenticité. 

Caractéristiques adaptées aux ZK

Les fonctions de hachage Poseidon sont considérées comme adaptées aux preuves à divulgation nulle de connaissance pour plusieurs raisons. Notamment :

• Poseidon est conçu pour effectuer efficacement les opérations arithmétiques courantes dans les calculs de preuves à divulgation nulle de connaissance, à savoir l’addition, la multiplication et l’exponentiation
• Les systèmes de preuves à divulgation nulle de connaissance doivent transformer une logique de calcul en preuve cryptographique. Grâce à sa conception adaptée à l’arithmétique, à sa S-box optimisée, à ses paramètres personnalisables et à son faible nombre de tours, la conception de Poseidon produit des circuits moins complexes que les autres fonctions de hachage. Un tour est une séquence d’opérations appliquée de manière itérative aux données d’entrée ou à l’état interne de la fonction de hachage. Il faut donc moins d’étapes pour générer une preuve pour une donnée donnée
• Les fonctions de hachage Poseidon reposent sur une construction en éponge. Autrement dit, Poseidon utilise une catégorie d’algorithmes qui acceptent une séquence de bits de n’importe quelle longueur et produisent une sortie de n’importe quelle longueur. Cela facilite grandement l’intégration des fonctions de hachage Poseidon dans différentes applications à divulgation nulle de connaissance.

Comparaison avec les fonctions de hachage traditionnelles

L’efficacité de calcul de Poseidon, spécialement adaptée aux preuves à divulgation nulle de connaissance, offre un avantage évident par rapport aux opérations plus générales et plus gourmandes en calcul des fonctions de hachage traditionnelles, comme SHA-256. 

Bien qu’elles soient sûres et fiables, les fonctions de hachage traditionnelles produisent souvent des circuits plus grands et plus complexes dans les preuves à divulgation nulle de connaissance. En effet, ces fonctions n’ont pas été conçues à l’origine en tenant compte des contraintes propres aux systèmes de preuves à divulgation nulle de connaissance. Sur les blockchains, ces preuves effectuent leurs calculs dans des corps finis. Un corps fini est un ensemble de nombres dans lequel toutes les opérations arithmétiques — addition, soustraction, multiplication et division — sont effectuées modulo un nombre premier. Les valeurs « rebouclent » ainsi dans l’ensemble, ce qui garantit que chaque opération reste dans cet ensemble de nombres. 

Les fonctions de hachage traditionnelles, comme SHA-256, s’appuient fortement sur des opérations bit à bit et des séquences d’opérations prédéfinies. Ces fonctionnalités ne sont pas directement compatibles avec les opérations arithmétiques utilisées dans les corps finis. Leur mise en œuvre dans le contexte d’un corps fini nécessiterait des étapes supplémentaires, ce qui augmenterait la complexité du circuit.

De plus, les fonctions de hachage traditionnelles utilisent généralement une arithmétique modulaire basée sur les puissances de 2. Celle-ci diffère de l’arithmétique modulaire des corps finis utilisés dans les preuves à divulgation nulle de connaissance, qui reposent souvent sur des nombres premiers. Cette incompatibilité nécessiterait encore plus d’étapes et augmenterait la taille et la complexité du circuit.

La construction d’une preuve à divulgation nulle de connaissance vise à créer une représentation mathématique d’une logique de calcul qui démontre la connaissance de certaines informations sans les révéler. Une représentation efficace et simple de ces connaissances est essentielle à l’évolutivité de ces preuves. Les fonctions de hachage de la famille Poseidon répondent directement à ces besoins grâce à des opérations efficaces dans les corps finis, réduisant considérablement le nombre d’étapes nécessaires à la création du circuit. Le circuit obtenu est donc plus petit et moins complexe. Les fonctions de hachage traditionnelles ne sont pas adaptées aux besoins spécifiques de la création de circuits : elles sont conçues pour un usage général. 

L’intégration des appels système Poseidon dans la v1.17 marque une transition vers l’utilisation d’outils cryptographiques spécialisés pour simplifier la génération et la validation des preuves à divulgation nulle de connaissance sur Solana. Elle accélère le traitement des transactions, réduit les coûts et améliore l’évolutivité des calculs à divulgation nulle de connaissance. Grâce également à la flexibilité et aux possibilités de personnalisation de Poseidon, la génération et la validation de ces preuves sur Solana sont devenues beaucoup plus simples.

Implémentation spécifique

La v1.17 introduit l’appel système sol_poseidon, un appel système qui accepte en entrée une tranche bidimensionnelle d’octets et calcule le hachage Poseidon correspondant en sortie. Il utilise la courbe BN254 et accepte les paramètres Poseidon suivants :

• S-boxes x^5, c’est-à-dire des boîtes de substitution
• Entrées où 1 ≤ n ≤ 12
• Largeur où 2 ≤ t ≤ 13
• 8 tours complets et des tours partiels en fonction de t : [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

Le calcul de ces hachages Poseidon sera effectué avec le crate light-posiedon, qui est audité et compatible avec Circom. 

Notez que, dans la section suivante, nous abordons l’ajout des appels système alt_bn128. BN254 est couramment appelée BN128, en référence au nombre de bits de sécurité, ainsi que alt_bn128 ou alt_bn_128. Il s’agit ici de la même courbe.

Appels système alt_bn128

La v1.16 proposait une meilleure prise en charge à l’exécution des calculs à divulgation nulle de connaissance, en particulier les opérations sur les courbes elliptiques 128 bits. Les appels système alt_bn128, essentiels pour générer efficacement des preuves, devaient être publiés avec la v1.16. Leur sortie a toutefois été retardée. Dans le calendrier d’activation des fonctionnalités, les appels système alt_bn128 sont actuellement prévus pour la v1.17.15, sous réserve de leur activation sur mainnet-beta, et la compression alt_bn128 est prévue pour la v1.17.15, sous réserve de son activation sur testnet.

Pour les personnes souhaitant approfondir le sujet, alt_bn128 désigne l’implémentation de la courbe elliptique Barreto-Naehrig (BN-128). Cette courbe elliptique particulière est adaptée aux couplages et permet d’utiliser efficacement les zk-SNARKs, ou arguments de connaissance succincts, non interactifs et à divulgation nulle de connaissance. Elle est considérée comme « adaptée aux couplages », car elle permet d’effectuer plus efficacement certains calculs et certaines preuves à divulgation nulle de connaissance. Sur Solana, les appels système alt_bn128 permettent aux programmes d’exploiter cette courbe pour simplifier la vérification des preuves à divulgation nulle de connaissance, ce qui renforce la sécurité et la confidentialité. L’ajout des appels système g1 et g2 d’alt_bn128 facilite la compression des preuves Groth16. Cela réduit considérablement l’espace requis pour chaque preuve et optimise ainsi l’espace disponible pour les programmes Solana.

L’introduction des appels système alt_bn128 contribue à réduire l’écart de compatibilité entre Solana et les contrats reposant sur Solidity qui utilisent des contrats précompilés pour les opérations sur les courbes elliptiques définies dans EIP-196, EIP-197 et EIP-198. Ces opérations (bn256Add, bn256ScalarMult, bn256Pairing) facilitent la vérification des zk-SNARKs dans les limites de gas d’Ethereum. Les contrats Solidity qui s’appuient sur ces opérations de courbes elliptiques peuvent désormais migrer vers Solana ou interagir avec celui-ci plus facilement.

Améliorations de Gossip

La v1.17 améliore l’efficacité de la propagation des messages Gossip en renforçant la propagation des messages push et en réduisant la dépendance aux requêtes pull. La simplification du fonctionnement du protocole Gossip contribue à réduire l’utilisation des ressources par les validateurs participant au consensus.

Pour rappel, le service Gossip de Solana est essentiel à l’échange d’informations entre les validateurs. Il transmet notamment la hauteur du registre, les coordonnées des nœuds et les votes de consensus. Il utilise des messages « push » et « pull » pour partager et vérifier les informations sur le réseau. Ce système de messagerie garantit la synchronisation de tous les nœuds. 

Traditionnellement, AccountsHashVerifier envoie les hachages de ses comptes à Gossip. Cependant, aucun composant du réseau ne récupère ces données, ce qui rend ce processus redondant. Des opérations historiques, comme la comparaison des hachages de comptes provenant de Gossip avec les valeurs de validateurs connus, ont été supprimées avec l’introduction d’EpochAccountsHash.  La méthode RPC getHealth a également été réécrite pour ne plus dépendre des hachages de comptes provenant de Gossip. Nous y reviendrons dans la section suivante. Ainsi, depuis la v1.17, aucun élément ne récupère les hachages de comptes depuis Gossip. AccountsHashVerifier a été modifié pour ne plus envoyer les comptes à Gossip, et les fonctions chargées d’envoyer et de récupérer les hachages de comptes depuis Gossip ont également été supprimées.

getHealth 

Auparavant, l’appel RPC getHealth pouvait indiquer un état incorrect pour un nœud donné. Cela provenait d’une divergence entre la commande CLI solana catchup et l’appel RPC getHealth, un nœud pouvant sembler à la fois synchronisé et en retard. Des nœuds sains pouvaient ainsi être incorrectement signalés comme défaillants et potentiellement retirés des pools RPC.

À l’origine, l’état de santé était déterminé en comparant le slot local du hachage des comptes publié dans Gossip avec ceux des autres nœuds, en utilisant une valeur de comparaison par défaut de 100 slots. Cette méthode pouvait être imprécise, en particulier pour les nœuds configurés avec des valeurs supérieures à 100 slots. getHealth a été réécrit pour utiliser le dernier slot confirmé de manière optimiste par le cluster, c’est-à-dire le dernier slot traité par tous les validateurs et confirmé par une supermajorité, mais pas encore finalisé. Cette méthode permet une comparaison plus précise, car le slot confirmé par le cluster peut être comparé à la dernière banque confirmée de manière optimiste afin de déterminer le retard du nœud. Cette modification offre un contrôle plus précis, réduit le risque de faux négatifs, c’est-à-dire de nœuds sains signalés comme défaillants, et protège contre les effets domino liés à des problèmes affectant les validateurs connus. 

L’option –skip-health-check a également été ajoutée aux commandes wait-for-restart-window et exit pour résoudre les problèmes liés à getHealth. Elle permet aux validateurs d’ignorer la vérification de l’état de santé d’un nœud.

QUIC

La v1.17 permet de diffuser des shreds et d’effectuer des réparations avec QUIC. Les endpoints QUIC de Turbine et de réparation sont actuellement désactivés, car ils ne sont pas nécessaires tant que testnet n’a pas entièrement migré vers QUIC. Cette évolution pose toutefois les bases de la migration de ces protocoles vers QUIC. Plusieurs PR ont été fusionnées pour introduire les fonctionnalités sous-jacentes, notamment :

• Ajout d’une éviction différée pour la réparation des connexions QUIC afin d’empêcher le nombre de connexions en attente d’augmenter indéfiniment
• Ajout de métriques pour surveiller l’endpoint QUIC de Turbine
• Ajout de métriques pour surveiller la réparation de l’endpoint QUIC
• Prévention de l’expiration des connexions QUIC due à des demandes de réparation peu fréquentes

Connexions TPU asynchrones

La v1.17 introduit des connexions asynchrones pour le client TPU, ce qui améliore considérablement le mécanisme de cache des connexions. Cette mise à jour vise à réduire la latence des transactions en permettant l’établissement de connexions en arrière-plan, avec une taille de pool de connexions par défaut de quatre. Les connexions asynchrones du client TPU fluidifient le traitement des transactions en évitant les temps d’attente inhérents aux connexions synchrones. 

Démarrage simplifié des validateurs et mise à jour du format des snapshots

La v1.17 simplifie le démarrage des validateurs en introduisant une nouvelle option et en mettant à jour les formats de fichiers de snapshots pris en charge. Les validateurs démarrent ainsi plus rapidement, ce qui renforce la résilience du réseau en réduisant les temps d’arrêt.

La v1.17 introduit une nouvelle option –use-snapshot-archives-at-startup. Elle permet aux validateurs d’accélérer le démarrage en choisissant entre les snapshots locaux, l’état local sur disque ou automatiquement le plus récent des deux. Cette option évite de traiter les snapshots lorsque l’état sur disque est plus récent, ce qui réduit la durée des redémarrages.

Auparavant, Solana prenait en charge plusieurs formats de compression pour les snapshots. Les formats d’archive comprenaient bz2, gzip, zstd, lz4, tar et aucun format. La dernière mise à jour limite toutefois les choix à zstd et lz4 afin d’optimiser l’efficacité et de réduire la complexité de la prise en charge. Les autres formats ont été dépréciés pour l’argument –snapshot-archive-format, même si les validateurs peuvent toujours lire les snapshots existants dans ces formats afin de préserver la rétrocompatibilité. Cela simplifie l’interface de ligne de commande de solana-validator et solana-ledger-tool. 

Conclusion

Grâce aux nombreuses fonctionnalités mises en œuvre et à la résolution rapide de la récente panne réseau, la mise à jour v1.17 de Solana représente une avancée majeure. Elle inaugure une prise en charge et des capacités inédites en matière de divulgation nulle de connaissance avec la publication du ZK Token Program, des appels système Poseidon et des appels système alt_bn128. Associée aux améliorations apportées aux validateurs et à l’efficacité du réseau, cette mise à jour établit une base solide pour la prochaine version. Elle est moins importante que la v1.16 et s’inscrit dans l’objectif de publier une nouvelle version tous les trois mois. Le calendrier de publication de la version 1.18 est disponible ici.

Si vous avez lu jusqu’ici, merci, anon ! N’oubliez pas de saisir votre adresse e-mail ci-dessous pour ne manquer aucune actualité sur Solana. Vous souhaitez aller plus loin ? Découvrez les derniers articles du blog Helius et poursuivez dès aujourd’hui votre parcours sur Solana.

Ressources supplémentaires

• Rapport sur la panne de Solana Mainnet Beta du 06/02/2024
• Calendrier de publication de la v1.17
• Poseidon : hachage adapté aux ZK
• Compte Twitter Solana Status
• Les validateurs Solana adoptent la mise à jour v1.17