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

De quoi parle cet article ?

Le réseau de validateurs de Solana a atteint avec succès une supermajorité dans l’adoption de la version 1.16, la dernière mise à jour du client de validation de Solana Labs. Après une période d’audit approfondie, renforcée par les efforts soutenus de bénévoles et de nœuds canaris, cette étape marque l’aboutissement de près de dix mois de développement rigoureux.

Dans les sections suivantes, nous examinerons la façon dont la v1.16 a été testée, ainsi que le système de portes de fonctionnalités de Solana, un cadre qui régit le déploiement progressif des nouvelles fonctionnalités sur le réseau. Nous aborderons ensuite les nouvelles fonctionnalités implémentées dans la v1.16.

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

La v1.16 a fait l’objet de tests rigoureux au cours des derniers mois. Cette version fonctionne sur le testnet depuis le 7 juin 2023 et a subi de nombreux tests de résistance. En outre, un petit groupe de nœuds bénévoles a commencé à passer à la v1.16 le 23 août 2023. Ces bénévoles ont pu identifier et résoudre divers problèmes, notamment la lenteur du démarrage des nœuds RPC et des erreurs de protection générale. Solana Labs a également déployé plusieurs nœuds canaris sur mainnet-beta afin de surveiller la stabilité des nœuds v1.16 dans des conditions réelles. Pour consulter l’activité passée et les progrès réalisés par ces nœuds canaris, rendez-vous dans le canal #canaries-monitoring du Discord Solana Tech.

Pour détecter les cas limites ou les conditions de concurrence peu fréquentes, plusieurs fuzzers d’exécution ont servi à exécuter des transactions partiellement aléatoires. Ces transactions ont été exécutées sur différentes versions de l’environnement d’exécution afin de garantir des performances cohérentes. La v1.16 a également fait l’objet d’un audit approfondi par Halborn. Les rapports d’audit sont publiés dans ce dépôt à mesure qu’ils deviennent disponibles.

Portes de fonctionnalités

Il est important de noter que certaines des fonctionnalités abordées dans les sections suivantes ne sont pas encore actives. Elles sont déployées progressivement à l’aide d’un système de portes de fonctionnalités. Les fonctionnalités sont activées à certaines époques en fonction de leur priorité relative et de l’ordre dans lequel elles ont été activées sur d’autres réseaux. Jusqu’à présent, la planification de l’activation des portes de fonctionnalités s’effectue au cas par cas selon une liste de critères disponible ici. En principe, ces portes doivent d’abord être activées sur le testnet, puis sur le devnet et enfin sur mainnet-beta. Pour activer une fonctionnalité, un ingénieur disposant de la paire de clés d’activation requise envoie une transaction qui est traitée et rend la fonctionnalité active à l’époque suivante. Une seule porte de fonctionnalité doit être activée à la fois sur chaque réseau afin de garantir des performances adéquates. Certaines fonctionnalités peuvent nécessiter une période d’observation, ce qui pourrait retarder l’activation des portes moins prioritaires.

Ce système de portes de fonctionnalités garantit que les changements incompatibles avec le consensus n’entraînent pas la divergence d’un validateur exécutant une version plus récente par rapport à la chaîne canonique, tout en continuant à produire des blocs. Par exemple, un validateur v1.14 ne connaît pas les nouvelles fonctionnalités de la v1.16 et pourrait faire planter le réseau en cas de désaccord. Un commit fusionné cette semaine dans la base de code de Solana préconise que tous les changements incompatibles avec le consensus disposent d’un Solana Improvement Document (SIMD). Le modèle de ticket relatif aux portes de fonctionnalités inclura désormais une demande de SIMD pour le ticket concerné. Cela contribue à standardiser le processus de développement et à améliorer la transparence des nouveaux changements grâce à leur documentation.

Transferts confidentiels

Confidential Transfers, une fonctionnalité introduite par Token2022, utilise des preuves à divulgation nulle de connaissance pour chiffrer les soldes et les montants des transactions de tokens SPL. Cette fonctionnalité vise avant tout à améliorer la confidentialité des utilisateurs, en privilégiant la confidentialité plutôt que l’anonymat.

Confidential Transfers s’appuie sur le chiffrement Twisted ElGamal pour effectuer des opérations mathématiques sur les montants chiffrés. Ces transferts sont validés à l’aide de protocoles Sigma, une catégorie spécialisée de preuves à divulgation nulle de connaissance dans laquelle une partie (le prouveur) peut démontrer à une autre partie (le vérificateur) qu’elle connaît un secret donné sans le révéler. Pour approfondir les subtilités de Confidential Transfers, consultez notre article Qu’est-ce que Token2022 ?.

L’ajout de la prise en charge de l’interface en ligne de commande (CLI) accompagne utilement le déploiement de Confidential Transfers. La commande create-token a été étendue pour inclure une option --enable-confidential-transfers, qui permet aux utilisateurs de créer des tokens avec les transferts confidentiels activés. La commande update-confidential-transfer-settings a également été ajoutée pour permettre de modifier dynamiquement la configuration des transferts confidentiels d’un mint donné. Il est ainsi possible de mettre à jour la clé d’audit et les paramètres d’approbation.

Meilleure prise en charge des preuves à divulgation nulle de connaissance dans l’environnement d’exécution

La version v1.16 renforce les capacités de Solana en matière de divulgation nulle de connaissance grâce à une meilleure prise en charge des calculs correspondants dans l’environnement d’exécution, notamment des opérations sur les courbes elliptiques 128 bits. La v1.16 introduit les appels système alt_bn128, essentiels à la génération efficace des preuves.

alt_bn128 désigne une implémentation particulière d’une courbe elliptique utilisée pour les opérations cryptographiques, connue sous le nom de courbe Barreto-Naehrig (BN-128). BN-128 est un type particulier de courbe elliptique adaptée aux couplages, qui permet d’implémenter efficacement les zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge). Pour rappel, une courbe elliptique est considérée comme « adaptée aux couplages » si elle permet d’effectuer certains calculs plus efficacement. Dans notre cas, l’utilisation de la courbe BN-128 accélère donc considérablement les opérations mathématiques et les preuves à divulgation nulle de connaissance.

Un syscall, ou appel système, sert à demander des services au noyau du système d’exploitation. Dans le contexte de Solana, un syscall permet aux programmes exécutés dans la Solana Virtual Machine (SVM) d’interagir avec des ressources externes.

Un appel système alt_bn128 est donc un appel que les programmes Solana peuvent utiliser pour interagir avec la courbe BN-128, particulièrement efficace. Il simplifie la vérification des preuves à divulgation nulle de connaissance et offre ainsi de meilleures fonctionnalités de sécurité et de confidentialité sur Solana. Des appels système alt_bn128 g1 et g2 ont aussi été ajoutés récemment pour permettre la compression des preuves Groth16. C’est important, car ces preuves occupent 256 octets de données d’instruction chacune et les programmes Solana privés (PSP) doivent actuellement vérifier deux preuves Groth16. Grâce à la compression g1 et g2, le nombre d’octets requis par preuve peut être réduit de moitié, à 128 octets, ce qui est essentiel pour optimiser l’espace.

En outre, les contrats basés sur Solidity rencontrent des problèmes de compatibilité avec Solana s’ils contiennent des appels aux contrats précompilés suivants pour les opérations sur les courbes elliptiques :

• bn256Add - Effectue une addition dans les opérations sur les courbes elliptiques
• bn256ScalarMult - Effectue une multiplication scalaire dans les opérations sur les courbes elliptiques
• bn256Pairing - Effectue des opérations de couplage de courbes elliptiques pour vérifier les zkSNARKs dans la limite de gas du bloc

Ces opérations sont standardisées sur Ethereum par les normes EIP-196, EIP-197 et EIP-198. L’introduction des appels système alt_bn128 constitue une avancée majeure pour combler cet écart de compatibilité. Les contrats Solidity qui reposent sur ces opérations de courbes elliptiques peuvent désormais migrer vers Solana, voire interagir avec Solana, plus facilement.

L’intégration de l’appel système alt_bn128 dans la mise à jour v1.16 de Solana représente une avancée majeure pour le traitement efficace et sécurisé des preuves à divulgation nulle de connaissance par Solana. Consultez les pull requests suivantes pour en savoir plus sur les appels système alt_bn128 :

• Ajout des appels système alt_bn
• Ajout des tests des appels système alt_bn128 et correction des problèmes associés
• Fonctionnalité (syscall) : ajout de la compression altbn128 g1 et g2

Validateurs

La mise à jour v1.16 réduit considérablement l’utilisation de la RAM par les validateurs. Auparavant, Solana s’appuyait sur la RAM pour indexer les comptes. Le système a désormais été reconfiguré pour indexer les comptes sur disque par défaut, ce qui réduit fortement l’utilisation de la RAM. Yanshu de Luganodes indique que, depuis la sortie de la v1.16, son validateur fonctionne correctement avec seulement ~39 Go de RAM, contre ~120 Go avec les versions précédentes :

La version v1.16 introduit également un système remanié d’échantillonnage des pairs pour les requêtes pull du protocole gossip. Ce nouveau système réduit efficacement la bande passante nécessaire au démarrage des validateurs. Dans les versions précédentes, les validateurs pouvaient être confrontés à des contraintes de bande passante en raison d’un volume élevé de requêtes pull gossip. Cela pouvait ralentir, voire surcharger, le validateur. La v1.16 résout ce problème en introduisant une variable mesurant le temps écoulé depuis la dernière requête. Cette variable sert à évaluer le niveau du trafic entrant et à limiter le débit afin d’éviter que le validateur ne soit surchargé au démarrage.

Les validateurs stakés qui prennent du retard sur le réseau peuvent désormais rattraper encore plus rapidement l’état actuel grâce à une nouvelle fonctionnalité qui proportionne les requêtes de réparation au stake détenu. Lorsqu’un validateur possédant un stake important diverge du réseau, il envoie une requête de réparation. Ce validateur reçoit désormais les shreds plus rapidement grâce à son stake important. Cela lui permet de rejoindre le réseau et de continuer à y contribuer. Pour les requêtes de réparation, les validateurs stakés ont une priorité plus élevée que les nœuds RPC, puisque ces derniers ne produisent pas de blocs.

Le seuil d’attente avant l’envoi de réparations de shreds est également passé de 100 ms à 200 ms. Cette modification vise à réduire le nombre de requêtes de réparation concernant des shreds qui seraient finalement transmis par Turbine. Pour rappel, Turbine désigne le mécanisme multicouche de propagation des blocs utilisé par Solana pour diffuser les entrées du registre à tous les nœuds. Le cluster Solana se divise alors en couches de nœuds, et chaque nœud d’une couche donnée est chargé de transmettre les données à la couche suivante. Cet ajustement est essentiel, car il réduit les requêtes de réparation inutiles et améliore ainsi l’efficacité de la propagation des données par Turbine.

Il n’a jamais été aussi facile d’exécuter votre propre validateur. Pour les personnes souhaitant exploiter leur propre validateur, Solana propose Solana Validator Education, une série d’ateliers consacrés aux validateurs et disponibles sur sa chaîne YouTube.

Prise en charge des comptes redimensionnables

Lors du déploiement d’un programme sur Solana, l’espace alloué au programme correspond toujours au double de sa taille. La v1.16 vous permet de déployer des programmes avec des comptes de données redimensionnables. Vous pouvez ainsi déployer votre programme avec un compte plus petit, puis augmenter sa taille ultérieurement en ne payant que la différence de mémoire. La prise en charge des comptes redimensionnables offre davantage de flexibilité et une meilleure allocation des ressources aux développeurs qui déploient des applications sur Solana.

Hachage des comptes d’une époque

Dans les versions précédentes, des problèmes pouvaient survenir concernant les blocs et la vérification de tous les comptes de l’état. Lorsqu’un validateur restait longtemps sans interagir avec un compte donné, il pouvait détenir une version corrompue de ce compte sans même s’en rendre compte. En effet, l’état du compte n’était pas comparé à celui détenu par les autres nœuds validateurs, puisqu’aucune transaction n’avait été effectuée pour le modifier.

La v1.16 résout ce problème en introduisant l’Epoch Accounts Hash. Il s’agit d’un hachage de tous les comptes généré à la fin de chaque époque, même lorsqu’aucune interaction n’a eu lieu avec ces comptes. L’Epoch Accounts Hash permet au réseau d’identifier et d’exclure les nœuds dont les données sont corrompues, ce qui renforce l’intégrité et la sécurité de Solana.

Réglage du système

Le réglage du système consiste à optimiser le système d’exploitation et les configurations matérielles d’un validateur afin d’obtenir des performances optimales. Avec la version v1.16, solana-sys-tuner a été supprimé et des tests manuels sont désormais recommandés. Cette option a été supprimée, car dans les versions précédentes, les colonnes TransactionStatus et AddressSignature de RocksDB n’étaient pas correctement nettoyées. De plus, la compaction périodique, un processus qui libère de l’espace de stockage, était désactivée par défaut. Cela entraînait une croissance illimitée de ces colonnes pour les nœuds utilisant l’option --enable-rpc-transaction-history. Grâce au commit suivant, l’espace de stockage des validateurs utilisant cette option sera désormais géré plus efficacement. Il s’agit d’une amélioration majeure qui rationalise les besoins de stockage des validateurs en supprimant la nécessité de conserver les statuts de transaction et les signatures d’adresse inutiles.

Conclusion

La version v1.16 de Solana marque une étape importante et concrétise dix mois de développement. La lenteur de sa publication s’explique par la priorité accordée à QUIC. Ces avancées concernant les transferts confidentiels, la prise en charge de la divulgation nulle de connaissance et l’optimisation des validateurs étaient donc attendues depuis longtemps. Elles n’en restent pas moins révolutionnaires. Cette version apporte à Solana de nouveaux niveaux d’efficacité et de confidentialité.

Pour la suite, Solana Labs adopte un cycle de publication plus agile, avec pour objectif une nouvelle version environ tous les trois mois. Ces futures versions seront beaucoup plus réduites que la v1.16. Cela permettra d’itérer plus rapidement et de réduire les risques lors du déploiement. Le calendrier de publication de la v1.17 est disponible ici. Cette version est elle aussi très attendue, avec une prise en charge encore meilleure de la divulgation nulle de connaissance et l’introduction potentielle d’appels système Posidon.

Si vous avez lu jusqu’ici, anon, merci ! Grâce à un cycle de publication plus agile et à de nombreuses nouvelles fonctionnalités et améliorations, l’avenir de Solana semble plus prometteur que jamais. Que vous soyez développeur, investisseur, validateur ou passionné de Solana, gardez un œil sur les prochaines versions ! Votre aventure avec Solana ne fait que commencer.

Ressources supplémentaires / Pour aller plus loin

• Calendrier d’activation des portes de fonctionnalités
• Processus d’activation des portes de fonctionnalités
• Audits de sécurité de Solana
• Solana Beach - Page des validateurs

‍