Réponses>En savoir plus sur l'évolutivité et les performances>Quelles sont les causes de la congestion de la blockchain ?
Quelles sont les causes de la congestion de la blockchain ?
// Tags
surcharge de la blockchainfrais de gaz élevés
En bref : la congestion d’une blockchain survient lorsque le nombre de transactions soumises au réseau dépasse la capacité d’accueil du bloc suivant. Chaque blockchain dispose d’une capacité maximale de calcul ou de données qu’elle peut traiter par bloc, et lorsque la demande dépasse cette limite, un arriéré s’accumule dans le mempool (la zone d’attente des transactions non confirmées). La congestion entraîne une hausse des frais de transaction (les utilisateurs se disputant un espace limité dans les blocs), des délais de confirmation plus longs et une expérience utilisateur dégradée. Parmi les causes profondes, on peut citer la capacité fixe des blocs, les pics de demande liés à des événements populaires, la dynamique du marché des frais, ainsi que les compromis de conception fondamentaux qui privilégient la sécurité et la décentralisation au détriment du débit brut.
L'explication simple
Une blockchain traite les transactions par lots appelés « blocs ». Chaque bloc a une capacité maximale. Sur Ethereum, cette limite est exprimée en « gas limit » (actuellement environ 30 millions de gas par bloc). Sur Bitcoin, il s’agit d’une limite de poids (4 millions d’unités de poids par bloc). Sur Solana, c’est une combinaison d’unités de calcul et de verrouillages de comptes par « slot ». Quel que soit le mécanisme spécifique, chaque chaîne a un plafond quant à la quantité de travail qu’elle peut effectuer par bloc.
Lorsque le nombre de transactions soumises au réseau est inférieur à la capacité d'un bloc, tout fonctionne sans heurts. Les transactions sont incluses dans le bloc suivant, les frais sont faibles et la confirmation est rapide. Lorsque le nombre de transactions dépasse la capacité d'un bloc, une file d'attente se forme. Cette file d'attente est le « mempool », une zone d'attente gérée par chaque nœud où les transactions valides mais non confirmées attendent d'être incluses dans un futur bloc.
Le mempool ne fonctionne pas selon le principe du « premier arrivé, premier servi ». Il s’agit d’une file d’attente prioritaire basée sur les frais. Les producteurs de blocs (mineurs ou validateurs) sélectionnent les transactions qui paient les frais les plus élevés, car cela maximise leurs revenus. Lorsque le mempool est plein, les utilisateurs qui souhaitent que leurs transactions soient confirmées rapidement doivent surenchérir sur tous les autres en proposant des frais plus élevés. C’est cette guerre d’enchères qui provoque la flambée des prix du gaz en période de congestion. Les utilisateurs qui ne souhaitent pas ou ne peuvent pas payer ces frais élevés voient leurs transactions rester bloquées dans le mempool pendant des minutes, des heures, voire parfois des jours.
Pics de demande
La cause la plus visible de la congestion est une hausse soudaine de la demande d’espace de bloc. Ces pics sont souvent déclenchés par des événements spécifiques. Une frappe de NFT très prisée peut générer des dizaines de milliers de transactions en quelques minutes, les collectionneurs se précipitant pour s’assurer d’obtenir des jetons en édition limitée. Le lancement d’un protocole DeFi ou la réclamation d’un airdrop attire un afflux d’utilisateurs qui interagissent simultanément avec de nouveaux contrats intelligents. Un krach boursier majeur déclenche une vague de liquidations, de clôtures de positions et de ventes de panique, les participants à la DeFi s’empressant d’ajuster leurs positions.
Sur Ethereum, certains des pires épisodes de congestion de l’histoire du réseau ont été provoqués par des applications spécifiques. L’engouement pour les CryptoKitties en décembre 2017 a paralysé le réseau pendant plusieurs jours. La frappe de NFT « Otherside » par Yuga Labs en mai 2022 a fait grimper le prix du gaz au-delà de 8 000 gwei, certains utilisateurs ayant dû payer des milliers de dollars de frais pour des transactions qui ont finalement échoué. Les demandes d’airdrop pour des tokens tels que l’UNI d’Uniswap et l’ARB d’Arbitrum ont provoqué une congestion persistante pendant des heures, alors que des millions de portefeuilles éligibles se sont précipités pour en bénéficier.
Le trading de jetons « meme » provoque des encombrements récurrents sur des chaînes telles que Solana et Base, où le lancement viral d’un jeton peut générer des millions de transactions d’échange en quelques heures. Contrairement aux événements planifiés (pour lesquels les utilisateurs savent au moins que l’encombrement est imminent), les pics d’activité liés aux jetons « meme » sont imprévisibles et peuvent saturer la capacité du réseau sans crier gare.
Capacité et taux de production fixes du bloc
La cause profonde de la congestion réside dans le fait que la capacité des blocs et le taux de production sont fixés par la conception du protocole, tandis que la demande est variable et peut parfois connaître une croissance explosive. Ethereum produit un bloc toutes les 12 secondes avec une limite de gaz d’environ 30 millions de gas. Un simple transfert d’ETH coûte 21 000 gas. Un échange sur Uniswap coûte entre 150 000 et 300 000 gas. Une interaction DeFi complexe peut coûter 500 000 unités de gaz, voire plus. Dans des conditions idéales, Ethereum peut traiter environ 15 à 30 transactions par seconde, selon la complexité de ces transactions. Lorsque des milliers d’utilisateurs tentent simultanément de créer un NFT, d’échanger un token ou de réclamer un airdrop, un débit de 15 à 30 TPS est loin d’être suffisant. Bitcoin est confronté à la même contrainte fondamentale, avec des limites encore plus strictes. Les blocs sont générés toutes les 10 minutes (contre 12 secondes pour Ethereum), et chaque bloc peut contenir environ 2 000 à 3 000 transactions. Cela confère au Bitcoin un débit d’environ 5 à 7 TPS. En période de forte demande, le mempool du Bitcoin peut accumuler des centaines de milliers de transactions non confirmées, les transactions à faibles frais pouvant attendre plusieurs jours avant d’être confirmées.
Ces limites de capacité ne sont pas arbitraires. Elles visent à préserver la décentralisation. Si les blocs étaient plus volumineux ou générés plus rapidement, moins de nœuds seraient en mesure de répondre aux exigences en matière de traitement des données, ce qui entraînerait une centralisation du réseau autour d’opérateurs disposant d’un matériel coûteux. Le compromis entre débit et décentralisation est au cœur de la conception de la blockchain et est souvent appelé le « trilemme de la blockchain » (la difficulté d’atteindre simultanément l’évolutivité, la sécurité et la décentralisation).
MEV et enchères prioritaires de gaz
La valeur maximale extractible (MEV) contribue à la congestion d’une manière moins évidente mais néanmoins significative. Le MEV désigne le profit que les producteurs de blocs et les « searchers » peuvent tirer en réorganisant, en insérant ou en censurant des transactions au sein d’un bloc. Lorsqu’une opportunité de MEV rentable se présente (comme un arbitrage entre deux DEX), plusieurs « searchers » se font concurrence pour en tirer profit en soumettant des transactions avec des frais de plus en plus élevés. Cette enchère prioritaire sur le « gas » consomme de l’espace dans les blocs et fait grimper les frais pour tout le monde, même pour les utilisateurs dont les transactions n’ont aucun rapport avec l’opportunité de MEV.
Les « attaques en sandwich » constituent un type spécifique d’exploitation de la valeur extra-monétaire (MEV) qui affecte directement les utilisateurs lambda. Un spéculateur détecte une transaction d’échange importante dans le mempool, passe un ordre d’achat avant celle-ci (front-running) et un ordre de vente après celle-ci (back-running), tirant ainsi profit de l’impact sur les prix généré par la transaction de la victime. Ces transactions de front-running et de back-running occupent de l’espace supplémentaire dans les blocs et augmentent la congestion au-delà de ce que la demande naturelle des utilisateurs entraînerait.
Solutions de couche 2 et réduction de la congestion
Les réseaux de couche 2 (tels qu’Arbitrum, Base, Optimism et zkSync) ont été conçus en partie pour réduire la congestion sur la couche 1 d’Ethereum. En traitant les transactions sur une chaîne distincte et en renvoyant des résumés compressés vers Ethereum, les réseaux de couche 2 augmentent considérablement le débit total disponible pour les utilisateurs. Une transaction qui coûte 5 $ de gaz sur la couche 1 d’Ethereum en période de congestion peut ne coûter que 0,01 $ sur une couche 2. Cependant, les couches 2 peuvent également connaître leur propre congestion lors de pics de demande extrêmes, et elles héritent de certaines limitations de la couche 1 sur laquelle elles effectuent le règlement.
Solana adopte une approche différente de la gestion de la congestion grâce à ses marchés de frais locaux. Au lieu d’un marché mondial unique des frais où toutes les transactions se disputent le même espace de bloc, Solana tente d’isoler la congestion à certains comptes « très sollicités ». Les transactions interagissant avec un contrat saturé (comme un pool DEX très fréquenté) paient des frais plus élevés, tandis que celles qui interagissent avec des contrats non concernés ne sont pas affectées. Cette conception réduit les répercussions collatérales des pics de congestion, sans toutefois les éliminer complètement.
Combien de temps dure la congestion de la blockchain ?
La durée de la congestion dépend de sa cause. Un événement programmé, comme une frappe de NFT très médiatisée ou une réclamation d’airdrop, entraîne généralement un pic brutal qui disparaît en quelques minutes à quelques heures, une fois que l’afflux de demandeurs s’est calmé. La congestion persistante est différente : lorsqu’une chaîne fonctionne de manière constante à près de sa capacité maximale (par exemple, lors d’un marché haussier prolongé ou d’un cycle viral de jetons « mème »), les frais élevés et les confirmations lentes peuvent durer plusieurs jours. La congestion sur Bitcoin a tendance à se résorber plus lentement que sur Ethereum, car son temps de bloc de 10 minutes implique que le mempool se vide par paliers plus importants et moins fréquents. Le signe concret indiquant que la congestion s’atténue est une diminution de la taille du mempool, associée à une baisse des frais de priorité.
En quoi les limites de blocs diffèrent-elles d'une blockchain à l'autre ?
Comme chaque chaîne limite la quantité de travail pouvant être traitée dans un bloc, la marge disponible avant l'apparition d'un engorgement varie considérablement. Le tableau ci-dessous résume les contraintes de capacité approximatives qui déterminent la rapidité avec laquelle chaque réseau s'engorge sous la charge.
Blockchain
Durée du bloc
Indicateur de capacité
Débit approx.
Bitcoin
environ 10 minutes
4 millions d'unités de poids
5 à 7 TPS
Ethereum L1
environ 12 secondes
environ 30 millions de gaz par bloc
15 à 30 TPS
Solana
intervalle d'environ 400 ms
Unités de calcul et verrouillages de compte
Des milliers de TPS
Arbitrum / Base (L2)
Inférieure à une seconde
Gaz L2, ramené au niveau L1
Des centaines, voire des milliers de TPS
Les chaînes à débit plus élevé et les réseaux de couche 2 absorbent mieux les pics de demande, mais aucune architecture n'est à l'abri. Pour approfondir la relation entre vitesse et capacité, consultez les articles « Débit vs latence » et « Qu'est-ce qu'une blockchain de couche 2 ? ».
Quelle est la différence entre une congestion et un arrêt en chaîne ?
Pour un utilisateur final, la congestion et l'arrêt de la chaîne donnent tous deux l'impression que « le réseau est en panne », mais il s'agit de situations fondamentalement différentes, dont les causes et les solutions varient. La congestion signifie que la chaîne continue de produire des blocs ; elle est simplement saturée et coûteuse. Un arrêt de la chaîne signifie que la production de blocs a complètement cessé.
Aspect
Embouteillages
Arrêt de chaîne
Production par blocs
Se poursuit normalement
Arrêté
Transactions
Confirmez lentement, frais élevés
Ne pas confirmer du tout
Cause profonde
La demande dépasse la capacité du bloc
Échec du consensus ou bug côté client
Résolution type
La demande s'essouffle, les frais baissent
Les validateurs coordonnent un redémarrage
En résumé, la congestion est un problème lié aux tarifs et à la capacité, tandis qu’un blocage de la chaîne est un problème de disponibilité. Les activités liées au MEV, telles que les enchères de gaz prioritaires, peuvent aggraver la congestion ; c’est pourquoi comprendre ce qu’est le MEV permet d’expliquer pourquoi les frais augmentent plus rapidement que ne le laisserait supposer la seule demande brute des utilisateurs.
Comment les promoteurs immobiliers peuvent-ils réduire l'impact des embouteillages ?
Les applications ne peuvent pas éliminer la congestion, mais elles peuvent rester fiables malgré celle-ci. Privilégiez l’estimation dynamique des frais plutôt que des prix du gaz codés en dur, mettez en place une logique de réessai avec une gestion appropriée des nonces, et mettez en file d’attente les transactions non urgentes pour les périodes de faible affluence. Du côté des données, privilégiez la diffusion de type « push » plutôt que les boucles d’interrogation serrées afin que votre ingestion suive le rythme à mesure que les blocs grossissent. Comprendre le fonctionnement des requêtes RPC, privilégier le streaming plutôt que l’interrogation, et tenir compte de la limitation de débit RPC des fournisseurs : toutes ces mesures réduisent le risque que la congestion entraîne des pertes de données ou l’échec des transactions des utilisateurs.
Foire aux questions
Pourquoi les frais de transaction augmentent-ils en période de congestion ?
L'espace disponible dans un bloc est limité, et le mempool fonctionne comme une file d'attente prioritaire basée sur les frais. Lorsque le nombre de transactions en concurrence dépasse la capacité d'un bloc, les utilisateurs proposent des frais plus élevés pour que leur transaction soit traitée en priorité. Cette surenchère fait grimper le prix du gaz jusqu'à ce que la demande redescende en dessous de la capacité du bloc.
Une congestion signifie-t-elle que la blockchain est hors service ?
Non. En cas d'engorgement, la chaîne continue de produire des blocs et de confirmer les transactions ; ces opérations sont simplement plus lentes et plus coûteuses. Un réseau qui cesse de produire des blocs subit un arrêt de la chaîne, ce qui constitue un problème distinct.
Les réseaux de couche 2 peuvent-ils eux aussi être saturés ?
Oui. Les couches 2 offrent un débit bien supérieur à celui de la couche 1 d’Ethereum ; elles peuvent donc supporter des pics de trafic plus importants, mais une demande extrême peut tout de même saturer leur capacité et faire grimper les frais. Elles héritent également de certaines contraintes de la couche 1 sur laquelle elles effectuent le règlement.
Comment savoir si la congestion s'atténue ?
Surveillez la taille du mempool et les frais de priorité. Une diminution du nombre de transactions non confirmées en attente, associée à une baisse des frais de priorité, est le signe le plus évident que la demande est retombée en dessous de la capacité du bloc.
Pourquoi les blockchains ne se contentent-elles pas d'augmenter la taille des blocs ?
Des blocs plus volumineux ou plus rapides augmentent le coût matériel lié à l'exploitation d'un nœud, ce qui écarte les petits opérateurs et favorise la centralisation du réseau. Les limites de capacité constituent un compromis délibéré visant à préserver la décentralisation, une tension souvent qualifiée de « trilemme de la blockchain ».
L'impact de la congestion sur les développeurs utilisant Quicknode
Pour les développeurs, la congestion affecte à la fois l’envoi des transactions et l’ingestion des données. Du côté de l’envoi, les transactions dont les frais de gaz sont insuffisants restent bloquées dans le mempool ou sont purement et simplement rejetées. Les applications ont besoin d’une estimation fiable des frais, d’une logique de réessai et d’une gestion des nonces pour gérer en douceur les situations de congestion. L’API Core de Quicknode garantit un envoi fiable des transactions avec des performances constantes, même en période de forte congestion, tandis que des méthodes API améliorées aident les applications à estimer les prix du gaz appropriés en fonction des conditions actuelles du réseau.
Du côté de l’ingestion des données, la congestion se traduit par un nombre accru de transactions par bloc, des blocs plus volumineux, davantage d’événements à traiter et des volumes de données plus importants. Les architectures basées sur l’interrogation (polling) rencontrent des difficultés en cas de congestion, car le volume de données par bloc augmente tandis que l’intervalle d’interrogation reste fixe, ce qui engendre un retard de traitement. Quicknode Streams gère la congestion de manière optimale grâce à son architecture de type « push » qui s'adapte à la taille des blocs. Qu'un bloc contienne 100 ou 1 000 transactions, Streams transmet l'intégralité des données à votre destination avec la même garantie de livraison et le même ordre de transmission. Le regroupement par lots et la compression configurables permettent de gérer l'augmentation du volume de données pendant les périodes de congestion prolongées.
