## Solana's « système immunitaire » évolution : pourquoi une attaque de 6 Тb/s prouve la résilience du réseau

Généralement, pour évaluer la robustesse d’un réseau blockchain, on se demande : jusqu’à quel point peut-il supporter le chaos sans s’effondrer ? L’épreuve récente que Solana a traversée répond précisément à cette question.

Selon les données publiées par la société d’infrastructure Pipe, Solana a récemment été victime d’une attaque de trafic d’environ 6 Тb/s — un chiffre qui entre dans la catégorie des « menaces » courantes sur Internet, généralement réservée aux plus grands sites web. Mais l’essentiel ne réside pas dans la taille de l’attaque, mais dans la réaction de Solana : le réseau a continué à produire des blocs normalement, la validation n’a pas été interrompue, les frais utilisateurs n’ont pas connu d’augmentation anormale. Pas de redémarrage d’urgence, pas de chaos entre validateurs.

Cela contraste fortement avec l’histoire passée de Solana. En septembre 2021, une vague de transactions automatisées (provoquée par un IDO sur Raydium) a mis le réseau hors ligne pendant plus de 17 heures. En avril 2022, lors d’une attaque encore plus violente, le réseau a reçu jusqu’à 6 millions de transactions par seconde, avec certains nœuds atteignant 100 Гbіт/s de trafic. Cet incident a directement causé l’arrêt de la génération de blocs, forçant un redémarrage coordonné de tout le réseau.

Mais cette fois, l’histoire ne s’est pas répétée.

## Du « coup passif » à la « défense proactive »

Ce qui a permis à Solana de surmonter cette épreuve, c’est une série d’innovations fondamentales dans sa conception de base.

D’abord, la mise à niveau du protocole de communication. Solana a adopté le protocole QUIC en remplacement du modèle de connexion traditionnel. L’avantage principal de QUIC réside dans sa conception multi-tâches native, ce qui signifie que les acteurs malveillants ne peuvent pas, comme avec l’ancien protocole, générer facilement du trafic inutile à faible coût. Dans le cadre du Transaction Processing Unit (TPU) de Solana, QUIC introduit plusieurs mécanismes de limitation :

- Limitation des connexions simultanées basées sur l’identifiant client
- Limitation du flux par connexion
- Limitation dynamique en fonction du stake (participation) du sendeur

La conception la plus ingénieuse ici est le QoS (Qualité de Service) pondéré par le stake. En résumé, si un валідатор détient 1 % du stake total, il a le droit d’envoyer 1 % des paquets de données. Cela crée un nouveau pare-feu : l’attaquant doit non seulement disposer de bande passante, mais aussi d’un stake réel. Les petits détenteurs de stake ne peuvent plus simplement inonder le réseau par une attaque par déni de service.

Ensuite, la réforme locale du marché des frais. Autrefois, lorsqu’une application était attaquée ou générait beaucoup de transactions spam, tout le réseau en souffrait — toutes les transactions étaient en file d’attente, les frais montaient en flèche. Solana a introduit un marché local des frais (Local Fee Markets) et un mécanisme de frais prioritaires (Priority Fees).

Les utilisateurs peuvent fixer une limite de calcul pour leur transaction et payer volontairement des frais supplémentaires pour obtenir une priorité. Le point clé : ces frais prioritaires sont basés sur la limite déclarée de calcul, et non sur la consommation réelle. Cela signifie qu’une limite trop haute sera « punie », encourageant une estimation précise. Ainsi, abuser des ressources de calcul devient coûteux, et le réseau dispose d’un levier pour modérer les abus.

## De la « catastrophe collective » à la « défense en couches »

Quel est l’effet combiné de ces changements ? Solana est passée d’un modèle « tout ou rien, une panne entraîne tout » à un système de défense à plusieurs couches.

Lorsque le trafic d’attaque atteint la limite, il est d’abord bloqué par une barrière basée sur le stake — sans stake suffisant, on ne peut pas générer un grand volume de paquets. Même si cette barrière est franchie, le mécanisme de frais prioritaires augmente le coût des transactions malveillantes, leur imposant une dépense économique réelle. Enfin, même si quelqu’un est prêt à payer pour inonder le réseau, des mécanismes d’isolation locale garantissent qu’un engorgement d’une application ne ralentira pas l’ensemble.

D’un autre point de vue, le валідатор devient un acteur doté d’un « ticket d’entrée ». Il ne s’agit plus simplement d’attaquer via la bande passante ou la technique, mais d’avoir un stake réel investi. Cela filtre naturellement ceux qui ont « du vrai argent » dans le système, et augmente considérablement le coût d’une attaque.

## Réalité et compromis

Mais il faut noter qu’aucun système n’est parfait. Concernant cette attaque de 6 Тb/s, la communauté discute encore : s’agissait-il d’un barrage de trafic continu ou d’un pic temporaire ? La perception de la « réussite » de la défense dépend de ces interprétations. La mesure du trafic Internet est elle-même complexe, et sans audit indépendant, il est difficile de certifier à 100 % que le réseau a tenu.

Un autre point subtil : ce système de priorité basé sur le stake tend à favoriser les opérateurs disposant de gros capitaux. Les petits валідator ou nœuds individuels seront désavantagés en cas d’engorgement. Le système pourrait encore devenir un terrain de chasse pour des bots payants.

Cependant, la transformation la plus importante a déjà eu lieu : Solana est passée du « passif face à l’effondrement » au « proactive face aux attaques ». L’histoire précédente était celle d’un arrêt de production, d’un redémarrage global, d’une longue coordination. La nouvelle histoire, c’est que le réseau reste actif, les transactions continuent d’être confirmées, et l’expérience utilisateur est minimale.

Cela montre que Solana a évolué d’un « réseau facilement abattable » à un « réseau qui fait fatiguer l’attaquant ». Ce changement d’état d’esprit, peut-être plus significatif que n’importe quelle mise à jour technique, est une étape essentielle.