--- id: 11 title: "Pourquoi un EVM monothread plafonne le TPS : histoire de la congestion et modèle d'exécution" slug: evm-single-thread-bottleneck date: 2026/08/22 summary: Les grands épisodes de congestion d'Ethereum partagent une même racine de conception — l'EVM exécute les transactions une par une. Cet article explique pourquoi relever la limite de gaz et l'EIP-1559 ne peuvent pas réécrire ce modèle d'exécution, et comment le délai de confirmation amplifie le plafond monothread. keywords: EVM monothread,plafond de TPS,congestion du gaz,EIP-1559,latence de confirmation heroImage: /images/community-bg.png --- Dans les débats sur la performance des chaînes publiques, le TPS est souvent traité comme l'unique étalon. Demandez pourquoi le mainnet Ethereum stagne depuis longtemps autour d'une dizaine de transactions par seconde dans des conditions ordinaires, et la réponse est rarement « pas assez de matériel ». C'est le modèle d'exécution lui-même : la machine virtuelle Ethereum est conçue pour terminer une transaction avant d'en commencer une autre. Cette contrainte achète une relecture déterministe à l'échelle du réseau — et cloue le débit à une borne physique monothread. Comprendre cette borne importe plus que mémoriser tel ou tel chiffre instantané de TPS. Des articles ultérieurs traitent la carte de scalabilité, les voies d'exécution parallèle et le contrôle de concurrence optimiste. Cet article commence par cerner le problème : pourquoi un EVM monothread plafonne le TPS, comment la congestion historique l'a confirmé à plusieurs reprises, et pourquoi ni une limite de gaz plus élevée ni l'EIP-1559 ne corrigent le modèle d'exécution. ## L'exécution sérielle n'est pas un bogue — c'est le prix du déterminisme La sémantique de l'EVM impose que les transactions d'un bloc s'exécutent dans l'ordre canonique. Ce n'est qu'après l'achèvement des écritures d'état d'une transaction que la suivante peut commencer à lire l'état. L'avantage est immédiat : tout nœud honnête qui rejoue la même séquence atteint la même racine d'état. Le consensus n'a besoin que d'un accord sur l'ordre des transactions et le contenu des blocs, et non sur la manière dont un entrelacement parallèle doit résoudre les écritures. Le coût est tout aussi direct. Les serveurs modernes exposent des dizaines de cœurs logiques, mais un nœud EVM classique se comporte encore sur le chemin chaud à peu près comme « un cœur travaille pendant que les autres regardent ». Deux virements sans lien — A paie B, C paie D — ne peuvent pas progresser ensemble dans le modèle sériel, car l'ordonnanceur suppose que toute transaction peut toucher n'importe quel recoin de l'arbre d'état global. Le trie de Merkle Patricia accroche les comptes et les emplacements de stockage à une seule structure énorme, ce qui renforce l'habitude d'ingénierie de refuser le parallélisme en l'absence d'informations préalables sur les dépendances. L'écart structurel s'ensuit : la bande passante et les E/S disque peuvent monter en gamme verticalement, tandis que le débit d'exécution reste bloqué à « une par une ». Tant que la demande reste sous ce plafond dur, les utilisateurs ne s'en aperçoivent guère. Quand elle le franchit, les transactions excédentaires s'accumulent dans la mempool et le marché des frais prend le relais — c'est la définition technique de la congestion. ## Congestion historique : même maladie, symptômes différents CryptoKitties en 2017 a été le premier épisode de congestion à grande échelle largement documenté. Au pic, le jeu de chats occupait une part substantielle des transactions on-chain, la file d'attente des transactions en attente a gonflé, des virements ordinaires sont passés de quelques secondes à plusieurs heures, et les prix du gaz ont grimpé jusqu'à plusieurs centaines de gwei. Les analyses post-mortem ont souvent incriminé « un jeu devenu trop populaire ». Plus précisément, une application chaude n'a fait qu'exposer un plafond de capacité déjà présent. Le scénario s'est répété. Pendant la composabilité dense de la DeFi en 2020–2021, le gaz est resté élevé pendant de longues périodes. Lors des mints de NFT de type titres fonciers, comme Otherside en 2022, de brèves guerres d'enchères ont poussé les frais à l'extrême — y compris des cas où de minuscules virements se voyaient facturer des frais astronomiques. Les déclencheurs différaient — jeux, yield farming, ruées sur les NFT — mais pas la logique de mise en file : le moteur d'exécution ne peut digérer qu'une certaine quantité de « calcul utile » par seconde, et la demande excédentaire est rationnée par des enchères plus élevées qui évincent les transactions moins chères. Ces épisodes ont aussi montré comment les enchères de gaz prioritaires amplifient la douleur. Sous le premier modèle au prix le plus offrant, des opportunités rares (places de mint, fenêtres d'arbitrage) déclenchaient des enchères en cascade qui faisaient monter le niveau des frais à l'échelle du réseau, si bien que les utilisateurs ordinaires payaient pour le point chaud d'un autre. La congestion n'est pas seulement « lente » ; elle est « coûteuse », et le coût pousse souvent les utilisateurs marginaux hors chaîne plus tôt que la latence seule ne le ferait. ## Limites de gaz : élargir une voie, pas en ajouter La communauté Ethereum a relevé à plusieurs reprises la limite de gaz par bloc pour extraire davantage de capacité. Une limite plus élevée permet à chaque bloc de porter plus de calcul, de sorte que le TPS peut monter à court terme. Cela se produit toujours à l'intérieur de l'exécution sérielle : on élargit une seule voie au lieu de transformer l'autoroute en voies parallèles. Cette voie a des rendements décroissants évidents et des coûts externes. Plus la limite de gaz est élevée, plus les nœuds complets doivent exécuter, vérifier et stocker de changements d'état par unité de temps — les exigences de synchronisation et de matériel augmentent avec elle. Traiter la « scalabilité » comme « relevons la limite de gaz pour toujours » finit par pousser la validation décentralisée au-delà de ce que des opérateurs ordinaires peuvent exécuter. Le réglage de la limite de gaz est un bouton opérationnel utile, pas un substitut au modèle d'exécution. Il répond à « combien de travail supplémentaire entasser sous une contrainte monothread », et non à « comment faire progresser d'un coup de nombreuses transactions sans conflit ». Les chiffres de TPS d'Ethereum publiés par les observateurs publics — une dizaine en conditions ordinaires, des pics courts plus élevés, un plafond théorique plus haut encore — relèvent du même cadre. Les décimales exactes varient avec le temps et les fenêtres de mesure ; ce qui compte est l'ordre de grandeur : le modèle monothread fixe le plafond dans une fourchette qui paraît étroite pour un récit de « couche de règlement mondiale », et l'exploitation quotidienne se situe souvent plusieurs fois en dessous des pics théoriques. ## EIP-1559 : formation des frais, pas largeur d'exécution L'EIP-1559, en service depuis 2021, a refondu le marché des frais. Des frais de base s'ajustent avec l'utilisation des blocs et sont brûlés ; les utilisateurs ajoutent des frais de priorité pour une inclusion plus rapide. Les motivations de recherche incluaient la réduction du surpaiement systématique dans les enchères au prix le plus offrant, l'atténuation des écarts brutaux de cotation à l'intérieur d'un bloc et la réduction de la capacité des mineurs/validateurs à extraire de la valeur des frais de base eux-mêmes. En pratique, l'EIP-1559 a amélioré la prévisibilité des frais et atténué le réflexe « enchéris toujours comme si le réseau était congestionné ». Elle n'a jamais promis d'augmenter le débit physique de l'exécution sérielle. Quand les blocs restent pleins, les frais de base montent et expulsent la demande excédentaire du marché — de la découverte de prix, non de l'expansion de capacité. Lire l'EIP-1559 comme une « solution de scalabilité » est une erreur courante ; une meilleure étiquette serait « une mise en file et une tarification plus propres à capacité d'exécution fixe ». Les frais de priorité et les mécanismes ultérieurs liés au MEV concernent de même la manière dont les transactions sont ordonnées et dont la valeur d'ordonnancement est captée, en supposant toujours que l'étape d'exécution se termine de façon sérielle. Aucune sophistication de la couche d'ordonnancement ne supprime le plafond dur tant que l'exécution digère une transaction à la fois. ## Délai de confirmation : l'axe que le TPS masque Le TPS demande combien de transactions se terminent par unité de temps ; le délai de confirmation demande combien de temps un utilisateur attend entre la diffusion et le moment où le résultat est « jugé suffisamment fiable pour être irréversible ». Les deux sont corrélés, mais non équivalents. Un TPS moyen peut paraître acceptable alors que l'arriéré de la mempool étire encore l'attente d'une transaction au-delà de la tolérance produit. Ethereum superpose aussi une sémantique de confirmation liée au consensus : intervalle de bloc, gadgets de finalité, risque de réorganisation — tout cela entre dans la « confirmation » telle que les utilisateurs la vivent. Quand la couche d'exécution se congestionne, les transactions peuvent rester en attente ; les délais d'expiration applicatifs, les fenêtres de pont et le risque d'inventaire des teneurs de marché s'amplifient ensemble. Pour les paiements et les interactions à haute fréquence, les pics de latence nuisent souvent plus aux produits que le TPS moyen. Le tableau complet du goulot d'étranglement monothread est donc le suivant : le plafond de débit décide de ce que le système peut absorber ; la mise en file et les frais décident qui entre ; le délai de confirmation décide du temps que prend l'entrée. Même racine — une largeur d'exécution insuffisante — symptômes différents. Toute affirmation de « scalabilité » devrait être notée séparément sur chaque axe. ## Conclusion : ce qu'il faut changer, c'est le modèle d'exécution Placez côte à côte la congestion historique, les relèvements de limite de gaz et l'EIP-1559, et la conclusion s'affûte : les marchés de frais et les paramètres de bloc gèrent la rareté ; ils n'en suppriment pas la cause. Tant que l'EVM conserve la forme classique d'un état global plus une exécution sérielle une par une, le TPS a un plafond dur, et les applications chaudes entraîneront périodiquement tout le réseau vers des frais élevés et une forte latence. Briser ce plafond reformule le problème : comment des transactions sans conflit peuvent-elles s'exécuter en parallèle tout en préservant un déterminisme vérifiable ? Les réponses ne sont pas uniques — pré-déclaration déterministe, contrôle de concurrence optimiste, modèles à objets, etc. Les projets qui veulent encore la compatibilité du bytecode et de l'outillage Ethereum font face à un éventail d'options plus étroit. Ces questions relèvent de la carte de scalabilité et des discussions sur les voies parallèles. Cet article n'a besoin que de la prémisse : l'objet d'une vraie correction est le modèle d'exécution, et non un tour de plus du bouton de gaz. ## Pour aller plus loin - Suivant : [« Cartographier la scalabilité des chaînes de blocs : ce que résolvent respectivement le parallélisme L1, les L2, le sharding et la DA »](/fr/blog/blockchain-scaling-map) - Associés : [« Trois voies vers l'exécution parallèle : ordonnancement déterministe, OCC optimiste et modèles à objets »](/fr/blog/parallel-execution-approaches), [« Glossaire des métriques de performance : TPS, BPS, latence de confirmation, finalité et taux de conflit »](/fr/blog/performance-metrics-glossary)