Comment Solana a neutralisé une attaque de 6 Tbps en utilisant un protocole spécifique de gestion du trafic qui rend impossible la mise à l’échelle du spam

Lorsqu’un réseau se vante de son débit, il se vante en réalité de la quantité de chaos qu’il peut absorber avant de s’étouffer. C’est pourquoi la partie la plus intéressante du dernier « stress test » de Solana est qu’il n’y a tout simplement pas d’histoire à raconter.

Un réseau de livraison appelé Pipe a publié des données indiquant qu’une récente attaque contre Solana aurait atteint environ 6 térabits par seconde, et les cofondateurs de Solana ont confirmé cette estimation dans des publications publiques. Si ce chiffre est exact, il s’agit d’un volume de trafic généralement réservé aux plus grandes cibles d’Internet, le genre de chose sur laquelle Cloudflare écrit de longs articles de blog parce que ce n’est pas censé être normal.

Et pourtant, Solana a continué à produire des blocs. Il n’y a pas eu de redémarrage coordonné ni de discussion de groupe entre validateurs virant au film catastrophe nocturne.

Le propre rapport de CryptoSlate sur l’incident indique que la production de blocs est restée stable et que les confirmations ont continué, sans augmentation significative des frais pour les utilisateurs. Il y avait même un contrepoint dans les discussions : SolanaFloor a noté qu’un contributeur d’Anza a soutenu que le chiffre de 6 Tbps représentait un pic bref plutôt qu’un mur de trafic constant sur une semaine, ce qui est important car un « pic » peut être à la fois vrai et un peu théâtral.

Ce genre de nuance est acceptable. Dans le monde réel des attaques par déni de service, le pic est souvent le but, car un coup bref peut tout de même faire tomber un système calibré pour un état stable.

Les rapports sur les menaces de Cloudflare soulignent que de nombreuses attaques majeures se terminent rapidement, parfois trop vite pour que les humains puissent réagir, c’est pourquoi la défense moderne doit être automatique. Le dernier incident de Solana montre désormais un réseau qui a appris à rendre le spam ennuyeux.

Quel type d’attaque était-ce, et que veulent réellement les attaquants ?

Un DDoS est l’arme la plus grossière mais la plus efficace d’Internet : submerger le trafic normal d’une cible en l’inondant de trafic indésirable provenant de nombreuses machines à la fois. La définition de Cloudflare est directe ; il s’agit d’une tentative malveillante de perturber le trafic normal en submergeant la cible ou l’infrastructure voisine avec un flot de trafic Internet, généralement issu de systèmes compromis.

Voilà pour la version web2, et c’est celle à laquelle Pipe fait référence avec son graphique en térabits par seconde. Les réseaux crypto ajoutent une seconde variante, plus native à la crypto : du spam qui n’est pas tant des « paquets indésirables sur un site web » que des « transactions sans fin sur une blockchain », souvent parce qu’il y a de l’argent à gagner de l’autre côté de la congestion.

L’historique des pannes de Solana ressemble à un manuel sur ce problème d’incitation. En septembre 2021, la blockchain a été hors ligne pendant plus de 17 heures, et le premier rapport d’incident de Solana a présenté l’afflux de transactions générées par des bots comme, en fait, un événement de déni de service lié à un IDO hébergé par Raydium.

En avril 2022, le rapport officiel de panne de Solana a décrit un mur de transactions entrantes encore plus intense, 6 millions par seconde, avec des nœuds individuels voyant plus de 100 Gbps. Le rapport indiquait qu’il n’y avait aucune preuve d’une campagne classique de déni de service, et que les empreintes ressemblaient à des bots essayant de gagner un mint NFT où le premier arrivé est le premier servi.

Le réseau a cessé de produire des blocs ce jour-là et a dû coordonner un redémarrage.

Alors, que veulent les attaquants, à part de l’attention et le plaisir de gâcher le dimanche de tout le monde ? Parfois, il s’agit d’extorsion pure et simple : payez-nous, ou nous laissons le robinet ouvert.

Parfois, il s’agit de nuire à la réputation, car une blockchain qui ne peut pas rester en ligne ne peut pas héberger de manière crédible les applications que les gens veulent construire. Parfois, il s’agit de jeux de marché, où une expérience utilisateur dégradée crée des prix étranges, des liquidations retardées et des détournements forcés qui récompensent ceux qui sont positionnés pour profiter du désordre.

Dans la version on-chain du spam, l’objectif peut être direct : gagner le mint, gagner la transaction, gagner la liquidation, gagner l’espace de bloc.

Ce qui change aujourd’hui, c’est que Solana a développé plus de moyens de refuser l’invitation.

Les changements de conception qui ont permis à Solana de continuer à fonctionner

Solana est devenu plus résilient en modifiant l’endroit où la douleur se fait sentir. En 2022, les échecs avaient une forme familière : trop de requêtes entrantes, trop de pression sur les ressources des nœuds, trop peu de capacité à ralentir les mauvais acteurs, et des effets en cascade transformant la congestion en problèmes de disponibilité.

Les améliorations les plus importantes se situent à la périphérie du réseau, là où le trafic atteint les validateurs et les leaders. L’une d’elles est la transition vers QUIC pour la communication réseau, que Solana a ensuite listée comme faisant partie de ses travaux de stabilité, aux côtés des marchés de frais locaux et de la qualité de service pondérée par le stake.

QUIC n’est pas magique, mais il est conçu pour des connexions contrôlées et multiplexées, plutôt que pour les anciens schémas de connexion qui facilitent les abus.

Plus important encore, la documentation côté validateur de Solana décrit comment QUIC est utilisé dans le chemin de l’Unité de Traitement des Transactions : des limites sur les connexions QUIC simultanées par identité client, des limites sur les flux simultanés par connexion, et des limites qui évoluent avec le stake de l’expéditeur. Elle décrit également une limitation du taux de paquets par seconde basée sur le stake, et précise que le serveur peut interrompre des flux avec un code de limitation, les clients étant censés se retirer temporairement.

Cela transforme le « spam » en « spam relégué sur la voie lente ». Il ne suffit plus d’avoir de la bande passante et un botnet, car il faut désormais un accès privilégié à la capacité du leader, ou bien se battre pour une part plus étroite de celle-ci.

Le guide développeur de Solana pour la QoS pondérée par le stake l’explique clairement : avec cette fonctionnalité activée, un validateur détenant 1 % du stake a le droit de transmettre jusqu’à 1 % des paquets au leader. Cela empêche les expéditeurs à faible stake de submerger tous les autres et renforce la résistance à Sybil.

En d’autres termes, le stake devient une sorte de revendication de bande passante, pas seulement un poids de vote.

Il y a ensuite le volet des frais, où Solana tente d’éviter que « une application bruyante ne ruine toute la ville ». Les marchés de frais locaux et les frais de priorité offrent aux utilisateurs un moyen de rivaliser pour l’exécution sans transformer chaque moment chargé en une enchère à l’échelle de la blockchain.

La documentation sur les frais de Solana explique comment les frais de priorité fonctionnent via les unités de calcul, les utilisateurs pouvant définir une limite d’unités de calcul et un prix d’unité de calcul optionnel, qui agit comme un pourboire pour encourager la priorisation. Elle note également un piège pratique : le frais de priorité est basé sur la limite d’unités de calcul demandée, et non sur l’utilisation réelle, donc des réglages imprécis peuvent entraîner le paiement d’une marge inutilisée.

Cela valorise les comportements gourmands en calcul et donne au réseau un levier pour rendre les abus plus coûteux là où ça fait mal.

En combinant ces éléments, on obtient un mode d’échec différent. Au lieu d’un flot de bruit entrant poussant les nœuds vers des spirales de mort mémoire, le réseau dispose de plus de moyens pour limiter, prioriser et contenir.

Solana lui-même, en revenant sur l’ère 2022, a présenté QUIC, les marchés de frais locaux et la QoS pondérée par le stake comme des mesures concrètes prises pour éviter que la fiabilité ne soit sacrifiée au profit de la vitesse.

C’est pourquoi un week-end à l’échelle du térabit peut passer sans véritables répercussions : la blockchain dispose de plus de « non » automatiques à la porte d’entrée et de plus de moyens de maintenir la file d’attente pour les utilisateurs qui ne cherchent pas à la casser.

Cela ne signifie pas que Solana est immunisé contre les mauvaises journées. Même ceux qui saluent l’anecdote des 6 Tbps débattent de la signification du chiffre et de sa durée, ce qui est une façon polie de dire que les mesures sur Internet sont désordonnées et que les droits de se vanter ne s’accompagnent pas d’un rapport d’audit.

Et les compromis ne disparaissent pas. Un système qui lie un meilleur traitement du trafic au stake est, par conception, plus favorable aux opérateurs bien capitalisés qu’aux validateurs amateurs. Un système qui reste rapide sous la charge peut toujours devenir un terrain de jeu pour les bots prêts à payer.

Néanmoins, le fait que le réseau soit resté calme est important. Les précédentes pannes de Solana n’étaient pas « les gens ont remarqué un peu de latence ». La production de blocs s’arrêtait complètement, suivie de redémarrages publics et de longues fenêtres de coordination, y compris l’arrêt d’avril 2022 qui a mis des heures à être résolu.

En revanche, l’histoire de cette semaine est que la blockchain est restée en ligne alors que le trafic aurait atteint une échelle plus habituelle dans les rapports de menaces de Cloudflare que dans le folklore crypto.

Solana se comporte comme un réseau qui s’attend à être attaqué et qui a décidé que c’est l’attaquant qui devrait se fatiguer le premier.

L’article How Solana neutralized a 6 Tbps attack using a specific traffic-shaping protocol that makes spam impossible to scale est apparu en premier sur CryptoSlate.