💻 computer science

Position Paper: Denial-of-Service Against Multi-Round Transaction Simulation

Cet article présente des attaques par déni de service asymétriques, évolutives et peu coûteuses contre les services de regroupement de transactions Ethereum, telles que Flashbots, en exploitant les dépendances inter-transactionnelles et les fonctionnalités spécifiques au regroupement pour perturber la production de blocs et réduire les revenus des constructeurs, tout en proposant des stratégies d'atténuation.

Auteurs originaux : Yuzhe Tang, Yibo Wang, Wanning Ding, Jiaqi Chen, Taesoo Kim

Publié 2026-04-24

📖 4 min de lecture☕ Lecture pause café

CC BY 4.0

Auteurs originaux : Yuzhe Tang, Yibo Wang, Wanning Ding, Jiaqi Chen, Taesoo Kim

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

🏗️ Le Contexte : Une Cuisine de Restaurant Très Tournée

Imaginez la blockchain (comme Ethereum) comme un immense restaurant très fréquenté.

Les clients sont les utilisateurs qui veulent envoyer des commandes (des transactions).
Les cuisiniers sont les "constructeurs de blocs" (Block Builders). Leur travail est de prendre les commandes, de les organiser dans un ordre logique, de les cuisiner, et de les servir sur un plateau (le bloc) pour le chef final (le validateur).
Les "Bundles" (Paquets) : Certains clients (les chercheurs de MEV) ne veulent pas juste une commande, mais un paquet spécial de plusieurs commandes qui doivent être exécutées ensemble, comme un menu complet. Pour cela, ils utilisent un service spécial appelé Flashbots, qui aide les cuisiniers à préparer ces paquets complexes.

🚧 Le Problème : Comment Saboter la Cuisine ?

Dans le passé, des pirates essayaient de faire des "Déni de Service" (DoS). C'est comme si quelqu'un envoyait des milliers de commandes fausses ou très compliquées pour :

Épuiser les fourneaux (la puissance de calcul).
Bloquer les cuisiniers avec des plats qui prennent trop de temps à cuisiner.

Mais il y a un problème : Les cuisiniers modernes (les "constructeurs multi-tours") sont très intelligents. Ils ne cuisinent pas tout de suite. Ils font des essais préliminaires (des "tours").

Tour 1 : Ils testent les commandes pour voir si elles marchent.
Tour 2 : Ils réorganisent les meilleures commandes.
Tour final : Ils cuisinent vraiment pour le service.

Les anciennes attaques échouaient car elles se déclenchaient trop tôt. Le cuisinier disait : "Ah, cette commande est trop lente ? Pas de souci, je la jette pendant l'essai préliminaire. Je ne perds pas de temps à la cuisiner." Le pirate perdait son temps et son argent sans ralentir le vrai service.

🕵️‍♂️ La Nouvelle Attaque : Le Cheval de Troie en plusieurs étapes

Les auteurs de ce papier ont trouvé une faille astucieuse. Au lieu d'envoyer une seule commande explosive, ils envoient une série de commandes qui dépendent les unes des autres, comme une histoire à plusieurs chapitres.

L'analogie du "Jeu de l'Oie" empoisonné :
Imaginez que vous envoyez une série de 10 commandes au cuisinier, mais avec une règle secrète :

La commande 1 dit : "Mets le sel."
La commande 2 dit : "Si le sel est là, mets le poivre."
La commande 3 dit : "Si le poivre est là, mets le feu."
...
La commande 10 dit : "Si tout le reste est là, explose la cuisine."

Comment ça marche ?

Les tours d'essai (1 à 9) : Le cuisinier teste la commande 1. Elle est simple, il la valide. Il teste la 2, elle dépend de la 1, il la valide aussi. À chaque tour d'essai, le cuisinier pense : "Tout semble normal, rien n'explose encore." Il ne rejette rien car rien n'est encore dangereux.
Le tour final : C'est seulement au dernier tour, quand toutes les commandes sont empilées dans l'ordre final, que la commande 10 se déclenche.
Le résultat : Comme toutes les commandes sont maintenant dans la même file d'attente, la commande 10 (l'explosion) bloque tout le monde derrière elle. Le cuisinier ne peut plus rien faire, et le service est paralysé.

💰 Pourquoi c'est grave ?

Pas cher : L'attaquant n'a pas besoin de dépenser des millions. Il utilise juste l'astuce de la logique.
Invisible : Pendant les tests, tout semble normal. Le cuisinier ne se méfie pas.
Dégâts réels : Cela ralentit tout le restaurant, réduit les profits du cuisinier et empêche les clients honnêtes d'être servis.

🛡️ La Solution ? (Ou le manque de solution)

Les chercheurs proposent quelques idées pour se défendre, comme vérifier plus soigneusement les dépendances entre les commandes. Mais ils admettent un fait inquiétant : il est très difficile, voire impossible, de protéger totalement un système qui fonctionne par "tours" contre ce genre d'attaque. C'est comme essayer de protéger un château contre des espions qui se déguisent en citoyens ordinaires jusqu'à ce qu'ils soient à l'intérieur.

En résumé

Ce papier révèle que les pirates peuvent maintenant piéger les systèmes de blockchain modernes en utilisant une stratégie de patience et de dépendance. Au lieu de frapper de front, ils construisent un piège qui ne se déclenche qu'au moment où le système est le plus vulnérable, rendant la défense très difficile.

Titre du papier

Attaque par Déni de Service (DoS) contre la Simulation de Transactions Multi-Tours

1. Problématique

Le papier aborde un problème de sécurité critique dans l'écosystème Ethereum, spécifiquement concernant les services d'agrégation de transactions (bundling services) utilisés par les constructeurs de blocs (block builders). Ces services, comme Flashbots Bundles, sont essentiels pour les chercheurs de MEV (Maximal Extractable Value) afin de regrouper des transactions et maximiser les revenus des validateurs.

Le défi : Les attaques par déni de service (DoS) existantes contre les constructeurs de blocs se sont révélées inefficaces contre les architectures modernes dites « multi-tours ».
La limitation des attaques précédentes : Les attaques antérieures (telles que ConditionalExhaust ou GhostTX) reposent sur une inspection passive pour détecter si l'exécution est spéculative. Elles déclenchent des charges utiles épuisant les ressources (CPU/Gas) uniquement si elles pensent être dans un environnement vulnérable. Cependant, dans un système multi-tours, ces vérifications passives ne permettent pas de distinguer le tour d'exécution. Par conséquent, les charges utiles sont souvent déclenchées prématurément lors des tours préliminaires, où elles n'affectent que les threads adverses et ne perturbent pas les transactions normales exécutées en parallèle.
L'objectif : Développer une attaque DoS asymétrique, furtive (évasive), sans risque financier et à faible coût, capable de cibler spécifiquement le dernier tour d'exécution d'un constructeur multi-tours.

2. Méthodologie

Les auteurs proposent une nouvelle approche proactive exploitant les dépendances inter-transactionnelles via l'état des contrats intelligents, un vecteur d'attaque négligé dans la littérature précédente.

Principe de base : L'attaque utilise une séquence de transactions qui interagissent avec un état partagé d'un contrat intelligent.
Mécanisme d'évasion :
- Sur un constructeur à $n$ tours, le contrat malveillant dissimule la charge utile épuisante derrière une série de $(n-1)$ conditions de branchement.
- Chaque condition dépend d'une variable d'état distincte.
- L'attaquant envoie plus de $n$ transactions : les $(n-1)$ premières transactions servent uniquement à configurer le contexte (modifier l'état) sans déclencher la charge utile.
Déclenchement de l'attaque :
- Les transactions adverses se comportent normalement et réussissent lors de tous les tours préliminaires (pré-tours), évitant ainsi toute invalidation ou rejet.
- Ce n'est que lors du dernier tour (le tour final d'exécution séquentielle) que les conditions sont toutes remplies, déclenchant la charge utile épuisante.
- À ce stade, les transactions adverses et normales s'exécutent en ordre sériel. Le ralentissement ou l'épuisement des ressources causé par une transaction adverse retarde directement toutes les transactions suivantes dans le bloc.
Avantages de la méthode :
- Évolutivité : L'attaque fonctionne indépendamment des mécanismes de protection du gaz lors de la validation du bloc.
- Coût : Elle est peu coûteuse en capital et opérationnelle car elle abuse de fonctionnalités spécifiques aux bundles (comme l'inclusion atomique).
- Risque nul : Les transactions sont valides et s'exécutent correctement dans les tours préliminaires, évitant les pertes de fonds pour l'attaquant.

3. Contributions Clés

Ce travail apporte plusieurs contributions majeures à la sécurité des blockchains :

Nouveau problème de sécurité : Il identifie et formalise la vulnérabilité des constructeurs de blocs multi-tours face aux DoS, un domaine non couvert par les recherches précédentes qui se concentraient uniquement sur les architectures mono-tour.
Nouvelles techniques d'attaque : Présentation d'une série d'attaques DoS furtives et à faible coût qui exploitent les dépendances d'état entre les transactions à travers plusieurs tours d'exécution. C'est une rupture par rapport aux designs d'attaque antérieurs basés sur des séquences de transactions indépendantes et isolées.
Stratégies d'atténuation : Les auteurs explorent l'espace de conception des défenses et proposent plusieurs stratégies pour mitiger ces risques, tout en identifiant un défi fondamental pour sécuriser tout constructeur à tours finis contre ce type d'attaque.

4. Résultats Expérimentaux

Les expériences menées sur le service d'agrégation Flashbots (le seul service open-source connu à l'époque) démontrent l'efficacité de l'approche :

Taux de réussite élevé : Les attaques réussissent à déclencher la charge utile au moment critique (dernier tour) avec une fiabilité quasi totale.
Impact économique : Les revenus des constructeurs de blocs (builders) sont considérablement réduits.
Impact sur le réseau : La production de blocs est ralentie, affectant la performance globale du réseau.
Efficacité des coûts : L'attaque démontre qu'il est possible de perturber le système avec un investissement financier minimal, rendant l'attaque économiquement viable pour des acteurs malveillants.

5. Signification et Implications

Ce papier met en lumière une faille de sécurité systémique dans l'évolution des infrastructures Ethereum vers des modèles de construction de blocs plus complexes (multi-tours).

Changement de paradigme : Il démontre que les mécanismes de défense actuels, basés sur l'isolation des transactions ou la détection passive de l'exécution spéculative, sont insuffisants face à des attaques coordonnées exploitant l'état global du contrat.
Menace pour l'écosystème MEV : En dégradant l'expérience des chercheurs de MEV et en réduisant les revenus des constructeurs, ces attaques pourraient inciter à une centralisation du marché des constructeurs ou à une instabilité des relais de propositions.
Appel à l'action : L'étude souligne la nécessité urgente de repenser les modèles de validation et de simulation pour intégrer la détection des dépendances inter-transactionnelles complexes, afin de garantir la résilience et l'équité du réseau Ethereum.

En résumé, cette recherche révèle que la complexité accrue des modèles de construction de blocs introduit de nouvelles surfaces d'attaque subtiles, nécessitant une révision fondamentale des stratégies de sécurité pour les blockchains publiques.