Beep, beep, beep. Beep, beep, beep.

Le sommeil de Steven est brisé par les carillons rauques de son téléphone, l’arrachant brusquement à ses rêves. Dans l’obscurité, l’écran brille de mille feux, vibrant furieusement sur sa table de chevet. Bip, bip, bip. Il gémit, se frotte les yeux d’un air groggy, et tend la main vers l’appareil. En plissant les yeux à l’évocation du message, son cœur se serre : le nœud est en panne. Sans hésiter, il bondit hors du lit, à moitié habillé, tâtonnant pour déverrouiller son téléphone alors que d’autres messages affluent. C’est alors qu’il le frappe : toute la grappe est en panne.

À cet instant précis, à travers le monde, dans des villes et des fuseaux horaires dispersés, des centaines d'opérateurs de nœuds fixent leur téléphone avec la même prise de conscience : le moment qu'ils redoutent est arrivé, une panne.

Introduction

Comme tous les systèmes distribués, Solana fonctionne en tenant compte de la réalité qu'une seule faille d'implémentation ou un cas limite obscur peut entraîner une défaillance à l'échelle du réseau. Les pannes, bien que perturbatrices, font partie inévitable de la maintenance d'infrastructures distribuées complexes, que ce soit dans des blockchains décentralisées, des échanges centralisés, ou même chez des grands fournisseurs de services cloud comme Amazon ou Microsoft.

La question n'est pas de savoir si des échecs se produiront, mais quand - et comment le réseau évoluera pour s'adapter et se renforcer contre les incidents futurs. Malgré des tests simulés rigoureux, un testnet incitatif et un programme de prime de bugs actif, aucun système - aussi bien conçu soit-il - ne peut anticiper chaque mode de défaillance possible. Les leçons les plus précieuses proviennent des opérations réelles.

Au cours des cinq dernières années, Solana a connu sept incidents de panne distincts, dont cinq ont été causés par des bogues clients et deux par l’incapacité du réseau à gérer les flots de spam de transaction. Les premières versions de Solana ne disposaient pas de mécanismes clés de gestion de la congestion, tels que les frais prioritaires et les marchés locaux des frais, qui se sont avérés essentiels par la suite pour atténuer les tensions sur le réseau. L’absence de tels mécanismes a conduit à des périodes prolongées de dégradation des performances et de congestion tout au long de l’année 2022, le réseau ayant essentiellement encouragé le spam.

Instances historiques de pannes et de performances degradées de Solana

Cet article analysera en détail chaque panne de Solana, examinant les causes profondes, les événements déclencheurs et les mesures prises pour les résoudre. De plus, nous discuterons des aspects clés des redémarrages du réseau, des rapports de bogues, et des concepts fondamentaux de défaillance de vivacité et de sécurité. Bien que ces sections soient mieux lues dans l'ordre, chacune est conçue pour être autonome, permettant aux lecteurs de passer aux sujets ou aux incidents de panne qui les intéressent le plus.

Vie et Sécurité

Selon le théorème CAP, également connu sous le nom de théorème de Brewer, un système distribué ne peut atteindre que deux propriétés sur trois :

• Cohérence : chaque lecture voit toutes les écritures précédentes.
• Disponibilité - Chaque demande reçoit une réponse.
• Tolérance à la partition - Le système continue de fonctionner malgré les partitions réseau.

Pour les blockchains, la tolérance aux partitions est essentielle : les perturbations du réseau sont inévitables. Cela oblige à choisir entre AP (Disponibilité + Tolérance de Partition) et CP (Cohérence + Tolérance de Partition). Comme la plupart des chaînes de point de vente à finalité rapide, Solana donne la priorité à la cohérence plutôt qu’à la disponibilité, ce qui en fait un système CP. Il s’arrête en cas de défaillance critique plutôt que de servir des données obsolètes ou d’autoriser des écritures non sécurisées. Bien que cela signifie que le logiciel de nœud peut entrer dans un état irrécupérable nécessitant une intervention manuelle, cela garantit que les fonds des utilisateurs restent en sécurité.

La position de Solana parmi les compromis du théorème CAP

Échec de la vivacité : se produit lorsque la blockchain cesse de progresser, empêchant les transactions d’être confirmées et les blocs d’être produits en raison d’un temps d’arrêt du validateur, de partitions réseau ou de blocages de consensus. Dans le cadre du théorème CAP, cela correspond à une perte de disponibilité.

Échec de sécurité : se produit lorsque l'état finalisé de la blockchain est modifié ou bifurqué de manière incorrecte. Cela peut entraîner des histoires conflictuelles ou des doubles dépenses, souvent causées par des bugs de consensus ou des attaques malveillantes. Dans le contexte du théorème CAP, cela correspond à une perte de cohérence.

Solana donne la priorité à la sécurité plutôt qu’à la vivacité. Ainsi, le réseau s’arrêtera en cas de stress extrême du réseau ou d’échec du consensus plutôt que de risquer la corruption de l’État. Bien que les pannes soient perturbatrices et puissent avoir un impact sur les applications, les utilisateurs et les validateurs, elles sont préférables aux conséquences catastrophiques d’un registre incohérent ou corrompu.

Redémarrage du réseau

Le redémarrage du réseau Solana implique l’identification du dernier emplacement de bloc confirmé de manière optimiste et le redémarrage des nœuds à partir d’un instantané d’état local de confiance de cet emplacement. Étant donné que l’emplacement de redémarrage n’est pas déterminé sur la chaîne, les opérateurs de validation doivent parvenir à un consensus hors chaîne pour convenir d’un point de restauration sûr. Cette coordination a lieu publiquement dans le canal des #mb-validateurs sur le Discord de Solana Tech, où les opérateurs de validateurs professionnels communiquent en temps réel. La plupart des opérateurs disposent de systèmes d’alerte automatisés qui les avertissent dès que la production de blocs s’arrête, garantissant ainsi une réponse rapide.

Une fois qu'un consensus est atteint sur le créneau de redémarrage correct, les opérateurs utilisent l'outil de registre pour générer un nouveau cliché local, redémarrer leurs validateurs et attendre qu'au moins 80% de l'enjeu total revienne en ligne. Ce n'est qu'alors que le réseau reprend la production de blocs et la validation. Vérifier qu'il y a au plus 20% de l'enjeu hors ligne lorsque le cluster redémarre garantit une marge de sécurité suffisante pour rester en ligne au cas où les nœuds bifurquent ou redeviennent immédiatement hors ligne après le redémarrage.

Rapport de bug

Les programmes de bug bounty récompensent les chercheurs en sécurité qui identifient et signalent les vulnérabilités logicielles. Il s’agit d’une ligne de défense essentielle, car elle incite de manière proactive attraper les bugs avant qu'ils ne puissent être exploitésLes chercheurs en sécurité et les développeurs qui identifient des vulnérabilités potentielles dans le client Agave sont encouragés à les signaler via les canaux de sécurité appropriés.Les directives de divulgation détaillées se trouvent dans le dépôt Agave GitHub.

Des récompenses sont offertes pour des rapports valides de vulnérabilités critiques, avec des paiements basés sur la gravité :

• Perte de fonds : jusqu'à 25 000 SOL
• Violations du consensus ou de la sécurité : jusqu’à 12 500 SOL
• Disponibilité ou perte de disponibilité: Jusqu'à 5 000 SOL

De plus le client FireDancer dispose d’un programme de bug bounty séparéhébergé par Immunefi, offrant une récompense maximale de 500 000 $ USDC pour des découvertes critiques.

Instances de panne

Les sections suivantes fournissent une analyse détaillée et chronologique des pannes et des périodes de dégradation des performances de Solana, à partir du lancement de la version bêta du réseau principal le 16 mars 2020. Cet examen mettra en évidence les principaux incidents, leurs causes profondes et les améliorations ultérieures du réseau, offrant un aperçu de la façon dont Solana a évolué pour améliorer la stabilité et la résilience au fil du temps.

Turbine Bug: Décembre 2020

Temps d'arrêt : Environ six heures

Problème principal : Bug de propagation de bloc

Correctifs:

• Suivre les blocs par hachage au lieu du numéro de slot
• Corrigez les endroits dans la turbine où la détection de défaut peut être effectuée plus tôt
• Propagez la première erreur détectée à tous les validateurs par le biais de commérages

Cette panne a été causée par un problème de réparation de blocs précédemment connu et de traitement de codedéclenché par un bug non identifié dansTurbine, le mécanisme de propagation de bloc de Solana. L’échec s’est produit lorsqu’un validateur a transmis deux blocs différents pour le même emplacement et les a propagés à deux partitions distinctes (A et B) tandis qu’une troisième partition détectait indépendamment l’incohérence.

Étant donné que chaque partition ne détenait qu'une participation minoritaire, aucune ne pouvait obtenir un consensus supermajoritaire pour faire progresser la chaîne. Le problème sous-jacent découlait de la manière dont les structures de données internes de Solana suivaient les blocs et leur état calculé. Le système utilisait le numéro de slot de Preuve d'Histoire (PoH) (un identifiant u64) pour faire référence à l'état et au bloc à ce slot. Une fois le réseau divisé en partitions, les nœuds ont interprété de manière incorrecte les blocs A et B comme étant identiques, empêchant une réparation adéquate et une synchronisation des blocs.

Chaque partition a supposé que l'autre avait le même bloc, conduisant à un conflit fondamental :

• Les nœuds détenant le bloc A ont rejeté les forks dérivés du bloc B
• Les nœuds détenant le bloc B ont rejeté les forks dérivés du bloc A

Étant donné que les transitions d'état différaient entre les partitions, les validateurs ne pouvaient pas réparer ou concilier les fourches, empêchant ainsi la finalité.

La solution à ce problème a consisté à permettre aux services de suivre les blocs par hachage au lieu du numéro de slot. Si un nombre quelconque de blocs pour le même créneau crée des partitions, ils ne sont traités d'aucune manière différemment des partitions avec des blocs occupant des créneaux différents. Les nœuds pourront réparer toutes les fourches possibles, et le consensus pourra résoudre les partitions.

Bien que le bogue ait été la cause initiale de la panne, la plupart du temps d'arrêt a résulté de l'attente que suffisamment de poids des enjeux revienne en ligne, car Solana exige une participation d'au moins 80% des enjeux pour reprendre la production de blocs.

L’IDO du Protocole du raisin : septembre 2021

Temps d'arrêt : Dix-sept heures

Problème principal : Débordement de mémoire causé par les transactions des bots

Corrections :

• Ignorer les verrous d’écriture sur les programmes
• Limites de taux sur la transmission des transactions
• Comportement de nouvelle tentative RPC configurable
• Hiérarchisation des transactions de vote TPU

Le 14 septembre 2021, Solana a connu un blocage majeur du réseau à la suite du lancement par Grape Protocol de son offre initiale DEX (IDO) on-chain sur la plateforme de financement participatif Raydium AcceleRaytor. Dans les 12 minutes qui ont suivi l’IDO, le réseau a été submergé par un flot sans précédent de transactions menées par des bots et a cessé de produire des machines à sous rootées. Ces bots ont effectivement exécuté une attaque par déni de service distribué (DDoS), poussant les charges de transaction au-delà de la capacité du réseau.

À pic de congestion:

• Certains validateurs recevaient plus de 300 000 transactions par seconde.
• Les données brutes de transaction ont dépassé 1 Gbps, avec 120 000 paquets par seconde.
• Le trafic dépassait parfois les limites physiques des interfaces réseau, entraînant des pertes de paquets au niveau du port du commutateur avant même d'atteindre les validateurs.

Solana slots par seconde pendant la panne de l'IDO Grape du 14 septembre 2021(Source de données : Jump Crypto)

L'un des bots a structuré ses transactions pour verrouiller en écriture 18 comptes clés, y compris le programme mondial de jetons SPL et le programme Serum DEX aujourd'hui défunt. Cela a bloqué toutes les transactions interagissant avec ces comptes, réduisant considérablement la capacité de traitement parallèle de Solana. Au lieu d'exécuter les transactions indépendamment, le réseau est devenu bloqué, traitant les transactions séquentiellement, exacerbant la congestion.

Une correction qui ignore les verrous d'écriture sur les programmes a déjà été développée et planifiée pour être publiée. Plus tard, le redémarrage du réseau a permis cette mise à niveau, supprimant définitivement ce vecteur d'attaque.

Pendant l'événement IDO, les validateurs ont reçu un flot de transactions pilotées par des robots et, à leur tour, ont transféré les transactions excédentaires au prochain leader, amplifiant la congestion. Le redémarrage du réseau a introduit des limites de taux sur le transfert de transactions pour éviter que les futures tempêtes de transactions ne submergent les leaders.

Les nœuds RPC de Solana réessaient automatiquement les transactions échouées, une fonctionnalité conçue pour améliorer la fiabilité. Cependant, ce mécanisme de réessai a exacerbé l'afflux de transactions en cas de congestion extrême, maintenant les anciennes transactions en circulation au lieu de permettre au réseau de récupérer. Solana 1.8 a introduit un comportement de réessai RPC configurable, permettant aux applications d'optimiser les réessais avec des délais d'expiration plus courts et des stratégies de backoff exponentielles.

Sous une forte congestion, les dirigeants de Solana ont omis d'inclure des transactions de vote, qui sont essentielles pour maintenir le consensus. En conséquence, le manque de votes confirmés a entraîné un blocage du consensus, interrompant la production de nouveaux blocs racine. Les versions ultérieures du client Solana ont introduit un mécanisme pour prioriser les transactions de vote, les empêchant d'être noyées par des transactions régulières lors d'événements futurs.

Un deuxième bug : débordement d'entier

Pendant le redémarrage du réseau, un deuxième problème est apparu. Les validateurs ont signalé des montants de mise en jeu actifs fluctuants de manière incontrôlable. Ce problème provenait d'un bogue selon lequel le pourcentage de mise en jeu était incorrectement multiplié par 100, dépassant ainsi la valeur maximale possible. Le mécanisme d'inflation avait créé tellement de nouveaux jetons SOL qu'il avait débordé un entier non signé sur 64 bits. Ce bogue a rapidement été identifié et corrigé avant un deuxième redémarrage.

Grande congestion : janvier 2022

Temps d’arrêt : Aucun

Cause principale: Transactions en double excessives

Correction partielle :

• Les versions 1.8.12 et 1.8.14 de Solana ont été publiées
• Optimisation de la déduplication SigVerify
• Améliorations des performances du cache de l'exécuteur

Entre le 6 janvier et le 12 janvier 2022, Solana mainnet a connu une congestion réseau sévère, entraînant une dégradation des performances et des pannes partielles. La perturbation a été causée par des robots envoyant un excès de transactions en double, réduisant considérablement la capacité du réseau. Les blocs ont mis plus de temps que prévu à être traités, entraînant la division du prochain leader et une réduction supplémentaire du débit. À son apogée, les taux de réussite des transactions ont chuté jusqu'à 70%. Le client a eu du mal à gérer les transactions de haute complexité et haute puissance du réseau, mettant en évidence les limites de sa capacité à répondre à la demande.

Une instabilité supplémentaire s'est produite du 21 au 23 janvier, la congestion persistant. Le 22 janvier, le point de terminaison RPC public (https://api.mainnet-beta.solana.com) s'est déconnecté en raison d'abus, car des appels RPC groupés indésirables ont submergé le système.

Pour remédier à ces problèmes, le Version 1.8.12 de Solana spécifiquement ciblée sur l'épuisement du cache du programme, tandis que la version 1.8.14 a introduit des améliorations au cache Sysvar, au rejet de SigVerify et à la déduplication de SigVerify.

Spam de machines à bonbons : avril / mai 2022

Temps d'arrêt : Huit heures

Problème principal : Spam de transactions provenant de comptes de robots

Corrections :

• Taxe bot sur le programme de la machine à bonbons
• Améliorations de la mémoire dans Solana v1.10

Le 30 avril 2022, Solana a connu une augmentation sans précédent des demandes de transaction. Certains nœuds ont signalé avoir atteint six millions de demandes par seconde, générant plus de 100 Gbps de trafic par nœud. Cette augmentation a été provoquée par des robots essayant de sécuriser de nouveaux NFT fraîchement frappés grâce au programme Metaplex Candy Machine. Ce mécanisme de frappe fonctionnait sur la base du premier arrivé, premier servi, créant un fort incitatif économique à inonder le réseau de transactions et à remporter la frappe.

30 avril / 1er mai 2022 Panne de la machine à bonbons, paquets par seconde en entrée(Source de données : Jump Crypto)

Alors que le volume des transactions a explosé, les validateurs ont manqué de mémoire et ont planté, bloquant finalement le consensus. Le débit de vote insuffisant a empêché la finalisation des blocs précédents, empêchant les fourchettes abandonnées d'être nettoyées. En conséquence, les validateurs ont été submergés par le nombre impressionnant de fourchettes qu'ils devaient évaluer, dépassant leur capacité même après les redémarrages et nécessitant une intervention manuelle pour restaurer le réseau.

Bien que cette panne présentait des similitudes avec l'incident de septembre 2021, Solana a démontré une résilience améliorée. Malgré avoir subi 10 000 % de demandes de transactions en plus par rapport à la panne précédente, le réseau est resté opérationnel beaucoup plus longtemps, reflétant les améliorations apportées par la communauté des validateurs en réponse aux défis d'évolutivité antérieurs.

30 avril / 1er mai 2022 Panne de Candy Machine, validateurs actifs(Source de données: Jump Crypto)

Le redémarrage du réseau a pris moins de 1,5 heures après que le cliché canonique ait été convenu. Solana v1.10 incluait des améliorations de l'utilisation de la mémoire pour prolonger le temps pendant lequel les nœuds peuvent supporter un consensus lent ou bloqué.

Cependant, des problèmes fondamentaux sont restés irrésolus. Le leader traitait toujours les transactions en lice pour les mêmes données de compte sur la base du premier arrivé, premier servi sans prévention efficace du spam, laissant les utilisateurs incapables de donner la priorité à l'urgence de leurs transactions. Pour remédier à cela, trois mécanismes à long terme ont été proposés comme solutions pratiques.

L'adoption de QUICAuparavant, Solana s'appuyait sur le protocole de réseau UDP (User Datagram Protocol) pour envoyer des transactions via Gulf Stream des nœuds RPC au leader actuel. Bien que rapide et efficace, l'UDP est sans connexion, manquant de contrôle de flux et d'accusés de réception. Par conséquent, il n'y a aucun moyen significatif de décourager ou d'atténuer un comportement abusif. Pour contrôler le trafic réseau, le protocole d'ingestion des transactions du validateur (c'est-à-dire l'étape de récupération du TPU) a été réimplémenté avec QUIC.

QUIC tente d'offrir le meilleur de TCP et UDP. Il facilite la communication rapide et asynchrone similaire à UDP, mais avec les sessions sécurisées et les stratégies avancées de contrôle de flux de TCP. Cela permet de limiter les sources de trafic individuelles afin que le réseau puisse se concentrer sur le traitement des transactions authentiques. QUIC a également un concept de flux séparés, donc si une transaction est abandonnée, elle ne bloque pas les autres. QUIC a finalement été intégré dans le client Solana Labs avec la version 1.13.4.

Pondération des enjeux de qualité de service (PEQoS): Un nouveau système qui hiérarchise le trafic réseau en fonction de la mise détenue par les validateurs a été introduit, garantissant que ceux ayant une mise plus élevée peuvent envoyer des transactions de manière plus efficace. Sous ce mécanisme, un validateur possédant 3 % de la mise totale peut envoyer jusqu'à 3 % des paquets totaux au leader. SWQoS agit comme une mesure de résistance à Sybil, rendant plus difficile pour les acteurs malveillants de submerger le réseau avec des transactions de faible qualité. Cette approche remplace le modèle précédent du premier arrivé, premier servi, qui acceptait les transactions de manière indiscriminée sans tenir compte de leur source.

Introduction des frais prioritaires :Une fois que les transactions sont ingérées, elles continuent de rivaliser pour accéder aux données de compte partagées. Auparavant, cette contention était résolue sur la base du premier arrivé, premier servi, ne permettant pas aux utilisateurs de signaler l'urgence de leurs transactions. Comme n'importe qui peut soumettre des transactions, la pondération des parts n'est pas adaptée à la priorisation à ce stade. Pour remédier à cela, une nouvelle instruction a été ajoutée au programme de Budget de Calcul, permettant aux utilisateurs de spécifier des frais supplémentaires collectés lors de l'exécution et de l'inclusion dans le bloc. Le ratio frais-unité-de-calcul détermine la priorité d'exécution d'une transaction, garantissant une approche plus dynamique et orientée vers le marché pour l'ordonnancement des transactions.

Taxe du Bot de la Machine à Bonbons

Metaplex a rapidement introduit une taxe bot codée en dur de 0,01 SOL sur les transactions de mintinteragir avec le programme Candy Machine pour lutter contre le spam généré par des bots. Ce mécanisme anti-spam imposait des frais minimes pour dissuader les activités malveillantes sans pénaliser les utilisateurs légitimes qui ont commis des erreurs accidentelles. La taxe était appliquée dans des scénarios spécifiques, notamment :

• Tentative de frappe lorsque la Machine à bonbons n'était pas en direct
• Essayer de créer lorsque aucun article n'est resté
• Transactions où la création ou la définition de la collection n'était pas l'instruction finale
• Utilisation d'un identifiant de collection incorrect
• Instructions de collection d'ensemble incompatibles
• Un désaccord entre le signataire-payeur et les instructions de collecte et de création de monnaie
• Transactions suspectes impliquant des programmes interdits
• Tentative de création à partir d'une Machine à bonbons protégée par AllowList sans détenir le jeton d'allowlist requis

Ce dissuasif économique s'est avéré très efficace. Les snipers de la menthe ont été rapidement épuisés et l'activité de spam a cessé. Dans les premiers jours, les botters ont collectivement perdu plus de 426 SOL.

Bug de nonce durable : juin 2022

Temps d'arrêt : quatre heures et demie

Problème principal : Bug de nonce durable conduisant à un échec de consensus

Corrections :

• Désactivation temporaire des transactions de nonce durables
• Mise à jour Solana 1.10.23

Un bug d'exécution a permis à certaines transactions de nonce durables d'être traitées deux fois - une fois en tant que transaction régulière et une autre fois en tant que transaction de nonce - si elles utilisaient un blockhash récent au lieu d'un nonce durable dans le champ recent_blockhash. Cela a conduit à un comportement non déterministe parmi les validateurs, car certains nœuds ont rejeté la deuxième exécution tandis que d'autres l'ont acceptée. Critiquement, étant donné que plus d'un tiers des validateurs ont accepté le bloc, cela a empêché la majorité requise des deux tiers d'atteindre un consensus.

Contrairement aux transactions standard, les transactions de nonce durables n'expirent pas et nécessitent un mécanisme unique pour prévenir une exécution double. Elles sont traitées séquentiellement en utilisant une valeur de nonce on-chain liée à chaque compte, qui est tournée à chaque fois qu'une transaction de nonce durable est traitée. Une fois tournée, la même transaction de nonce ne devrait plus être valide à nouveau.

Pour atténuer le problème, les transactions de nonce durables ont été temporairement désactivées.Un correctif a ensuite été implémenté dans Solana 1.10.23, ce qui empêchait l’exécution dupliquée en séparant les domaines nonce et blockhash. La mise à jour a permis de s’assurer que lors de l’avancement des comptes nonce, le blockhash est haché avec une chaîne fixe, ce qui rend un blockhash invalide en tant que valeur nonce. Par conséquent, une transaction exécutée une fois en tant que transaction normale ne peut pas être réexécutée en tant que transaction durable, et vice versa. De plus, un nouveau type DurableNonce a remplacé les valeurs de hachage de bloc précédentes dans l’état du compte nonce, ajoutant la sécurité de type et évitant des problèmes similaires à l’avenir.

Lisez notre article de blog Helius précédent pour comprendre davantage sur les durables nonces et leurs utilisations.

Bug de bloc en double : septembre 2022

Temps d'arrêt : huit heures et demie

Problème de fond : un bogue dans les règles de choix de fork a conduit à l’échec du consensus

Fix :

• Client patch

Cet arrêt a été déclenché par un validateur produisant de manière erronée des blocs dupliqués à la même hauteur de bloc. Cela s'est produit car à la fois le nœud principal du validateur et son nœud de secours de secours sont devenus actifs simultanément, utilisant la même identité de nœud mais proposant des blocs différents. Cette condition a persisté pendant au moins 24 heures avant l'arrêt, pendant lesquelles le réseau a correctement géré les créneaux de leader dupliqués du validateur.

Le cluster s’est finalement arrêté lorsque le réseau a rencontré un fork irrécupérable en raison d’un bogue dans la logique de sélection du fork. Ce bogue empêchait les producteurs de blocs de s’appuyer sur le bloc précédent, ce qui entraînait un échec du consensus.

Les forks sont une occurrence courante sur Solana, et les validateurs les résolvent généralement en s'alignant sur le fork avec la majorité des votes (le fork le plus lourd). Lorsqu'un validateur sélectionne le mauvais fork, il doit passer au fork le plus lourd pour rester synchronisé avec le réseau. Cependant, dans ce cas, les validateurs ne pouvaient pas revenir à la banque la plus lourde si son slot correspondait à leur dernier slot voté. Cette faille a causé aux validateurs de rester bloqués, empêchant ainsi le consensus de progresser et conduisant finalement à l'arrêt du réseau.

Bug de bloc dupliqué, panne de choix de fourche, septembre 2022(Source: Laine, Michael Hubbard)

Dans l'exemple ci-dessus, le validateur défectueux C produit des blocs en double pour ses créneaux de leader 5 à 8. Lorsque le validateur G prend le relais en tant que prochain leader, il n'observe qu'un seul des doublons et prolonge sa fourchette en conséquence. Cependant, le leader suivant, le validateur D, détecte les deux blocs en double du validateur C et décide de les ignorer, construisant plutôt sa fourchette sur le dessus du créneau 4.

Au fur et à mesure que le réseau progresse, la fourchette construite par le validateur G gagne des votes de la majorité des participations, s'établissant comme la chaîne canonique. Reconnaissant que sa fourchette est en train de perdre, le validateur D tente de passer à la fourchette du validateur G. Cependant, la transition échoue en raison d'un bogue dans la logique de sélection de la fourchette. Ce problème survient car l'ancêtre commun des deux fourchettes - un bloc en double à l'emplacement 5 - n'a pas été traité correctement, empêchant le validateur D de reconnaître la fourchette majoritaire. En conséquence, le validateur D reste bloqué sur sa propre fourchette, incapable de rejoindre la chaîne principale.

Le problème a été résolu après un examen par l'équipe principale.Un correctif a été fusionné dans la branche principale et rétroporté dans toutes les branches de publication.

Gros bloc submerge la turbine : février 2023

Temps d'arrêt : près de 19 heures

Problème principal : Échec de la logique de déduplication dans les services de transfert de fragments.

Corrections :

• De nombreuses améliorations ont été apportées à la logique de déduplication et au filtrage de Turbine
• Ajouter un correctif client forçant les producteurs de blocs à avorter s'ils génèrent de gros blocs

Un service de transfert de fragment personnalisé du validateur a mal fonctionné, transmettant un bloc exceptionnellement grand (près de 150 000 fragments), plusieurs ordres de grandeur plus grand qu'un bloc standard, pendant son créneau de leader. Cela a submergé les filtres de déduplication du validateur, causant la réexpédition continue des données. Le problème s'est aggravé à mesure que de nouveaux blocs étaient produits, saturant finalement le protocole.

Panne de gros bloc, déchiquetures par bloc, février 2023 (Source : Laine, Michael Hubbard)

L’augmentation du trafic réseau anormal a submergé Turbine, forçant la transmission des données de bloc via le protocole de réparation de bloc de secours, beaucoup plus lent. Bien que Turbine soit conçu pour résister à de gros blocs en les filtrant, les services de transfert de déchiquetage fonctionnent en amont de cette logique de filtrage, ce qui diminue son efficacité. Au cours de la période dégradée, les chefs de bloc sont automatiquement passés en mode vote uniquement, un mécanisme de sécurité dans lequel les dirigeants excluent les transactions économiques sans droit de vote.

La cause première du problème était une défaillance de la logique de déduplication au sein des services de transfert de fragments, empêchant la retransmission redondante des fragments. De plus, le filtre de déduplication dans le pipeline de retransmission n'était pas initialement conçu pour empêcher les boucles au sein de l'arbre Turbine, exacerbant le problème.

Le réseau a été redémarré manuellement avec une rétrogradation vers la dernière version connue du logiciel de validation stable. Pour atténuer ces problèmes, Solana v1.13.7 et v1.14.17 ont apporté des améliorations à la logique de déduplication, ce qui améliore sa capacité à prévenir la saturation des filtres et à garantir des performances réseau plus robustes.

Boucle de recompilation infinie : février 2024

Temps d’arrêt : près de cinq heures

Problème racine : bogue provoquant une boucle de recompilation infinie dans le cache JIT

Correctifs:

• Désactiver le chargeur hérité v1.17.20

Le validateur Agave compile juste à temps (JIT) tous les programmes avant d'exécuter les transactions qui les référencent. Pour optimiser les performances, la sortie JIT des programmes fréquemment utilisés est mise en cache, réduisant les recompilations inutiles. Dans le cadre d'Agave v1.16, le mécanisme de mise en cache existant, LoadedPrograms, a été remplacé par une nouvelle implémentation appelée ExecutorsCache, qui a introduit plusieurs efficacités.

LoadedPrograms a fourni une vue globale et consciente des forks des programmes mis en cache, réduisant la duplication des données comptables et permettant aux threads d'exécution de chargement de nouveaux programmes de coopérer, prévenant ainsi les conflits de compilation. Une caractéristique clé de ce système était de suivre le slot où un programme devient actif (appelé la hauteur du slot effective) pour détecter les invalidations de cache lorsque les données du programme on-chain sont mises à jour.

La hauteur de slot effective de la plupart des programmes était dérivée de leur slot de déploiement, qui était stocké dans leur compte on-chain. Cependant, les programmes déployés à l'aide des chargeurs hérités n'ont pas conservé ce slot de déploiement dans leurs comptes. Les LoadedPrograms ont attribué à ces programmes une hauteur de slot effective de zéro en tant que solution de contournement.

Une exception se produisait lorsqu’une instruction deploy était détectée, signalant que le bytecode d’un programme avait été remplacé. Dans ce cas, LoadedPrograms a temporairement inséré une entrée avec la hauteur d’emplacement effective correcte. Cependant, comme une transaction n’a jamais fait référence à cette entrée, elle était très susceptible d’être expulsée. Lors de l’expulsion, la sortie JIT a été ignorée et le programme a été marqué comme déchargé, mais la hauteur effective de l’emplacement a été conservée.

Si une transaction référençait ultérieurement ce programme déchargé, LoadedPrograms le recompilait et réinsérait une entrée à sa hauteur d’emplacement effective. En règle générale, cela rend le programme disponible pour l’exécution lors de l’itération suivante. Cependant, pour les programmes de chargement hérités, la nouvelle sortie JIT s’est vu attribuer la hauteur de l’emplacement sentinelle de zéro, ce qui la place derrière l’entrée déchargée précédente. Par conséquent, LoadedPrograms n’a jamais reconnu le programme comme chargé, ce qui a déclenché une boucle de recompilation continue à chaque itération.

Dans Agave v1.16, LoadedPrograms ne prenait pas en charge le chargement coopératif, ce qui permettait à la transaction déclencheuse d’être compressée dans un bloc. Ce bloc a ensuite été propagé à travers le réseau, ce qui a amené chaque validateur à le rejouer et à entrer dans la même boucle de recompilation infinie. Étant donné que plus de 95 % de la mise en grappe exécutait Agave v1.17 pendant la panne, la plupart des validateurs se sont retrouvés bloqués sur ce bloc, ce qui a interrompu le réseau.

Ce bogue a été identifié la semaine précédente lors d’une enquête sur une panne de cluster Devnet, et un correctif a été planifié pour le déploiement. @jeffLa solution choisie a été de rétroporter les modifications vers Agave v1.17 et de supprimer immédiatement une fonctionnalité de gate lors du redémarrage du réseau. Cela a désactivé l'ancien chargeur responsable du déclenchement du bogue, empêchant ainsi d'autres occurrences.

Correctif de vulnérabilité coordonné : août 2024

Temps d’arrêt : Aucun

Problème racine : hypothèse d’alignement d’adresse ELF incorrecte

Correctifs:

• Mise à jour du correctif

Le 5 août, Les ingénieurs principaux d'Anza ont été alertés d'une vulnérabilité dans le client Agave, signalée par un chercheur externe. Un attaquant aurait pu exploiter cette faille pour faire planter les validateurs du leader, ce qui aurait entraîné un arrêt de l’ensemble du réseau. En réponse, les ingénieurs d’Anza ont rapidement développé un correctif, que plusieurs sociétés de sécurité tierces ont ensuite audité.

Les programmes Solana sont compilés à l'aide de LLVM dans le Format exécutable et liable (ELF). La vulnérabilité provenait d’une hypothèse d’alignement d’adresse incorrecte dans ces fichiers ELF générés. Bien que l’assainissement ELF applique généralement divers contrôles d’intégrité, il n’a pas validé l’alignement de la section .text. Cet oubli aurait pu permettre à un fichier ELF malveillant de définir une section .text mal alignée, ce qui aurait conduit la machine virtuelle à passer à une adresse non valide. Cela entraînerait une erreur de segmentation de l’hôte, faisant planter le validateur.

Un attaquant aurait pu exploiter cette vulnérabilité en :

• Création d’un programme Solana malveillant qui utilise l’opcode CALL_REG.
• Manipulation du fichier ELF pour désaligner la section .text.
• Déploiement et invocation du programme sur le réseau, déclenchant des plantages de validateur.

Processus de mise à jour du patch

Toute mise à jour de correctif publiée publiquement rendrait immédiatement la vulnérabilité claire pour tous. Cela pourrait donner à un attaquant suffisamment de temps pour faire de l’ingénierie inverse de la vulnérabilité et arrêter le réseau avant qu’une quantité suffisante de mise n’ait été mise à niveau. Une masse critique de validateurs devrait adopter n’importe quelle version de correctif le plus rapidement possible pour éviter un tel scénario.

D'ici au 7 août, plusieurs membres de la La Fondation Solana avait contacté les validateurs par messages privés sur diverses plateformes de communication, en les informant d’un correctif critique à venir et en partageant un message haché confirmant la date et l’identifiant unique de l’incident. Plusieurs membres éminents d’Anza, de Jito et de la Fondation Solana ont partagé ce hachage sur X, GitHub et LinkedIn pour vérifier l’exactitude du message. Exemple de hachage partagé :

Au cours de la journée suivante, les membres principaux ont continué à contacter les validateurs, soulignant l'importance de l'urgence et de la confidentialité. À l'heure prédéterminée, le 8 août à 14h UTC, les opérateurs de validateurs ont reçu un message supplémentaire contenant des instructions pour télécharger, vérifier et appliquer le correctif. Le correctif était hébergé sur le référentiel Github d'un ingénieur Anza connu, et non sur le référentiel principal de l'Agave. Les instructions comprenaient la vérification des fichiers de correctif téléchargés par rapport aux sommes de contrôle fournies.

À 20 heures UTC le 8 août, une grande majorité des enjeux avaient été corrigés, assurant la sécurité du réseau. Suite à cela, la vulnérabilité et le correctif correspondant ont été divulgués publiquement, accompagnés d’un appel à tous les validateurs restants pour qu’ils se mettent à niveau.

La distribution discrète du correctif et la coordination en coulisses des validateurs ont soulevé des inquiétudes quant à la décentralisation de Solana. Peu de temps après l’incident, le directeur exécutif de la Fondation Solana, Dan Albert, a répondu à ces critiques lors d’une interview avec les médias.

« Je pense qu’il est important de ne pas confondre centralisation et capacité de coordination. Il y a 1 500 nœuds de production de blocs dans le monde entier qui sont exploités par presque autant d’individus. La capacité de communiquer avec eux, ou avec certains d’entre eux, volontairement, ne doit pas être confondue avec la centralisation.

Semaine coréenne de la blockchain (KBW) 2024

Je pense qu'il est important de ne pas confondre la centralisation avec la capacité de coordonner. Il existe 1 500 nœuds de production de blocs dans le monde entier qui sont exploités par presque autant d'individus... La capacité de communiquer avec eux, ou certains d'entre eux, de manière volontaire, ne doit pas être confondue avec la centralisation.

Conclusion

Au moment d’écrire ces lignes, Solana a passé plus d’un an sans panne, franchissant une étape clé pour la suppression de la balise « bêta » du mainnet-beta. La fréquence des pannes semble diminuer à mesure que le réseau arrive à maturité, et l’introduction de Firedancer devrait améliorer la diversité des clients, réduisant ainsi le risque de bogues non découverts ou de cas extrêmes provoquant un arrêt complet à l’échelle du cluster. Cependant, certains dirigeants communautaires, dont le fondateur d’Helius, Mert Mumtaz, ont prédit que les pannes se poursuivraient. L’avenir nous le dira.

Un grand merci à Zantetsu (Shinobi Systems) et OxIchigo pour avoir relu les versions antérieures de ce travail.

Démenti:

1. Cet article est repris à partir de [Helius]. Tous les droits d'auteur appartiennent à l'auteur original [Lostin]. Si vous avez des objections à cette réimpression, veuillez contacter le Porte d’apprentissage et ils s’en occuperont rapidement.
2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. L'équipe Learn de gate effectue des traductions de l'article dans d'autres langues. Copier, distribuer ou plagier les articles traduits est interdit sauf mention contraire.