--- id: 20 title: Points chauds de conflit et charges de travail : quand l'EVM parallèle aide vraiment slug: parallel-evm-workload-hotspots date: 2026/09/13 summary: L'EVM parallèle échoue rarement sur les benchmarks de virements, mais s'effondre souvent sur le trafic d'AMM, de prêt et de mint de NFT. Cet article explique comment se forment les points chauds de conflit, comment la granularité des ensembles lecture/écriture détermine les taux de conflit, et comment le TPS de pointe se dégrade sous des charges réelles. keywords: EVM parallèle,point chaud de conflit,charge de travail,ensemble lecture/écriture,AMM,TPS heroImage: /images/community-bg.png --- L'exécution parallèle ressemble à « activez plus de cœurs et le débit monte ». Pour les charges à faible conflit, cette intuition est à peu près juste : les transactions qui ne touchent jamais les mêmes emplacements d'état peuvent être traitées simultanément par différents moteurs d'exécution, et l'utilisation multicœur augmente. Mais le trafic qui congestionne réellement les chaînes publiques est rarement constitué de virements pair-à-pair propres. Ce sont des appels de contrats qui lisent et écrivent de façon répétée les mêmes comptes ou emplacements de stockage chauds. Alors le parallélisme n'est plus borné par le nombre de CPU ; il est borné par le **taux de conflit**. Une fois cela compris, vous pouvez lire correctement n'importe quel chiffre de performance d'« EVM parallèle » : le même moteur peut varier d'un ordre de grandeur selon la charge. ## Faible conflit contre fort conflit : deux jeux différents Une charge à faible conflit ressemble à de nombreux virements simples sans lien, à des transferts entre détenteurs de NFT indépendants ou à des requêtes en lecture seule sur des instances de contrats distinctes. Les ensembles lecture/écriture se recouvrent à peine, de sorte que le parallélisme optimiste peut approcher une « accélération idéale » : N moteurs absorbent près de N fois le travail sans conflit, moins un coût fixe d'ordonnancement et de vérification des versions. Une charge à fort conflit est l'inverse. La même paire d'AMM, le même indice de taux d'intérêt de prêt ou le même compteur de mint de NFT entassent de nombreuses transactions dans un ensemble d'état minuscule. L'exécution optimiste prend toujours de l'avance en parallèle, mais la validation découvre des conflits de version et de nombreuses transactions doivent être refaites dans l'ordre sériel. Les moteurs semblent occupés tandis que le débit effectif s'effondre vers les niveaux monothread, avec en plus la surcharge de retour en arrière et de réexécution. Ainsi, « l'EVM parallèle est-il rapide ? » n'est pas une question fermée. C'est « combien plus rapide, sous quelle distribution de conflits ? » ## Pourquoi les AMM, le prêt et le mint de NFT nuisent au débit Les teneurs de marché automatisés concentrent la liquidité et le prix dans un petit nombre d'emplacements de stockage du contrat de pool. Plusieurs swaps dans le même bloc lisent et écrivent souvent les mêmes emplacements `reserve` ou liés au prix, si bien que le conflit est structurel. Même lorsque les adresses d'utilisateurs diffèrent, des **points chauds côté contrat** suffisent à aplatir le parallélisme. Le prêt est similaire : les indices de taux d'intérêt, les totaux d'emprunts globaux et les paramètres de liquidation partagés deviennent des points de rencontre entre utilisateurs. Une transaction « l'utilisateur A dépose » peut partager des variables globales avec l'emprunt de l'utilisateur B et la liquidation de l'utilisateur C. Le mint de NFT est plus extrême : les identifiants séquentiels, les compteurs d'offre et les bitmaps de liste blanche constituent souvent un point d'écriture unique sous une contention de courte durée. Les ruées historiques sur les mints d'Ethereum ont poussé les enchères de gaz dans des zones absurdes, non seulement parce que « beaucoup de gens se sont présentés », mais parce que la couche d'exécution ne pouvait pas scinder ces écritures étroitement couplées. ## Granularité des ensembles lecture/écriture : le bouton caché du taux de conflit Le parallélisme optimiste utilise les ensembles lecture/écriture pour décider si deux transactions sont sans conflit. Les ensembles peuvent être aussi grossiers que le niveau du compte ou aussi fins que des emplacements de stockage individuels. - Des ensembles plus grossiers signalent trop de conflits : deux transactions qui touchent des emplacements différents d'un même contrat sont de toute façon sérialisées. - Des ensembles plus fins augmentent le coût d'analyse et de gestion des versions : le graphe de dépendances se fragmente et les métadonnées croissent, mais le parallélisme réel croît aussi. L'ingénierie arbitre habituellement entre des heuristiques au niveau du compte et une précision au niveau de l'emplacement, avec une analyse statique des dépendances avant exécution, une surveillance des versions pendant l'exécution et une vérification de la racine d'état après exécution (voir [Introduction au contrôle de concurrence optimiste (OCC)](/fr/blog/optimistic-concurrency-control-intro)). Pour les développeurs d'applications, l'implication est concrète : répartir l'état sans lien entre plusieurs emplacements, réduire les compteurs globaux et éviter un unique chemin `totalSupply` chaud améliore souvent l'expérience de confirmation plus que changer de chaîne. ## Comment le TPS de pointe se dégrade sur les points chauds Les benchmarks préfèrent les charges synthétiques sans conflit, car les courbes sont belles. Les blocs réels sont mixtes : certains virements se parallélisent ; certains appels DeFi s'enrayent sur les points chauds. Le débit effectif est à peu près contraint par (à titre illustratif, pas une formule exacte) : débit effectif ≈ gain parallèle sur la part sans conflit + débit quasi sériel sur la part en conflit − coût de retour en arrière/réexécution. À mesure que la part en conflit augmente, les deux derniers termes dominent. Il en résulte un décalage fréquent entre marketing et ingénierie : les documents citent un « TPS de pointe sous charge idéale », tandis que les utilisateurs, le jour d'un mint ou pendant des marchés volatils, ressentent une confirmation plus lente et davantage de réessais. Une divulgation honnête présente **à la fois les chiffres à faible conflit et à fort conflit**, en précisant le matériel, la version du client et le mélange de transactions (voir [Glossaire des métriques de performance](/fr/blog/performance-metrics-glossary)). Les chaînes à EVM parallèle optimiste qui choisissent d'affronter la DeFi composable — plutôt que d'optimiser uniquement les benchmarks de virements — font de la qualité de la détection des conflits et du regroupement dynamique l'écart entre le débit d'affiche et le débit visible par l'utilisateur. ## Implications pratiques pour la conception des contrats et des protocoles 1. **Trouvez les emplacements chauds** : cartographiez les écritures à haute fréquence lors des audits ; les compteurs globaux, les pools de liquidité uniques et les bits de configuration partagés sont les principaux suspects. 2. **Répartissez l'état** : isolez les écritures par utilisateur, par pool ou par shard autant que possible, au lieu de les canaliser vers un seul emplacement. 3. **Abandonnez les hypothèses d'ordre implicite** : une logique qui repose sur un « ordre implicite dans le bloc » est plus fragile sous parallélisme optimiste ; encodez l'ordre explicitement ou rendez la conception tolérante aux conflits. 4. **Interprétez les benchmarks via le taux de conflit** : quand vous voyez un chiffre de TPS, demandez d'abord le mélange de transactions ; un pic sans distribution de conflits a une valeur de référence limitée. ## En guise de conclusion : le parallélisme n'est pas gratuit L'EVM parallèle n'utilise plusieurs cœurs que lorsque la charge contient suffisamment de transactions sans conflit. Les contrats chauds ne disparaissent pas parce que le moteur d'exécution a changé ; ils déplacent le goulot d'étranglement de « l'interpréteur monothread » vers « la détection de conflits et la réexécution ». L'expliquer est plus utile qu'un nouveau discours de vente : cela indique aux développeurs s'ils doivent modifier la disposition du stockage, et aux lecteurs comment douter de la prochaine affiche de performance. ## Pour aller plus loin - Précédent : [Décentralisation et performance : seuils des validateurs, matériel et géographie](/fr/blog/decentralization-performance-tradeoff) - Associés : [Trois voies vers l'exécution parallèle : déterministe, optimiste et modèles à objets](/fr/blog/parallel-execution-approaches) - Associés : [Introduction au contrôle de concurrence optimiste (OCC) : une vue des bases de données sur l'exécution d'une chaîne de blocs](/fr/blog/optimistic-concurrency-control-intro) - Associés : [Glossaire des métriques de performance : TPS, BPS, latence de confirmation, finalité, taux de conflit](/fr/blog/performance-metrics-glossary)