Que se passe-t-il réellement quand tu envoies une transaction Ethereum
--> Le Problème
Tu cliques sur "Envoyer" dans ton portefeuille. L'interface confirme la transaction.
Mais ensuite… rien ne se passe.
Parfois, ça se confirme en quelques secondes.
Parfois, ça reste bloqué pendant des minutes—ou échoue complètement.
Pourquoi ?
La plupart des explications s'arrêtent à "ça va sur la blockchain."
Ce n'est pas utile si tu construis des systèmes dessus.
Décomposons ce qui se passe réellement sous le capot.
Modèle Mental (Orientation Rapide)
Une transaction n'est pas exécutée instantanément.
Ça passe par trois phases distinctes :
Propagation (mempool)
Inclusion (proposition de bloc)
Exécution (transition d'état)
Chaque phase introduit de la latence, des risques et des modes de défaillance.
Étape 1 : Création de transaction
Quand tu appuies sur « envoyer » :
Ton portefeuille construit une transaction :
à
valeur
limiteDeGaz
maxFeePerGas
données (si interactions avec des contrats)
Il signe la transaction en utilisant ta clé privée
À ce stade :
👉 La transaction est valide mais pas encore connue du réseau
Étape 2 : Diffusion au réseau
Ton portefeuille envoie la transaction à un nœud.
Ce nœud :
Vérifie la signature
Vérifie le nonce
Assure la validité de base
Si valide → elle entre dans la mempool
Étape 3 : La Mempool (Où les choses deviennent intéressantes)
La mempool est :
Une zone de stockage temporaire
Pas globalement cohérent
Différent selon les nœuds
Cela signifie :
👉 Ta transaction peut exister dans certains nœuds—mais pas dans d'autres
Comportement clé :
Les nœuds priorisent les transactions par frais
Frais maxFeePerGas plus élevés = priorité plus élevée
📊 Diagramme 1 : Flux de propagation de la transaction
Le diagramme doit montrer :
Portefeuille utilisateur → Nœud A → Nœud B → Nœud C
Chaque nœud a sa propre mempool
Flèches montrant la propagation des rumeurs
Surligner : « Tous les mempools ne sont pas identiques »
Étape 4 : Proposition de bloc
Les validateurs sélectionnent des transactions de leur mempool.
Ils choisissent :
Transactions avec les frais les plus élevés en premier
Transactions qui s'inscrivent dans les limites de gaz
Important :
👉 Ta transaction est en concurrence avec d'autres
Étape 5 : Exécution (niveau EVM)
Une fois incluse dans un bloc
La transaction s'exécute à l'intérieur de l'EVM
Les changements d'état se produisent :
Mises à jour de solde
Changements de stockage de contrat intelligent
Si l'exécution échoue :
Le gaz est toujours consommé
Les changements d'état reviennent
📊 Diagramme 2 : Flux d'exécution
Le diagramme doit montrer :
Bloc → EVM → Transition d'état
Entrées :
Transaction
État actuel
Sortie :
Nouvel état
Inclure « consommation de gaz » à chaque étape
Cas limites & Modes de défaillance
C'est là que la plupart des articles échouent. Allons plus loin.
❌ 1. Transaction bloquée dans la mempool
Frais trop bas
Jamais choisi par les validateurs
❌ 2. Transaction abandonnée
Le nœud le retire en raison de :
Frais faibles
Dépassement de la mempool
❌ 3. Transaction remplacée
Même nonce + frais plus élevés → remplace l'original
❌ 4. Exécution hors gaz
L'exécution s'arrête en cours de route
L'état revient en arrière
Gaz perdu
❌ 5. Réorganisation de chaîne (Reorg)
Le bloc est remplacé
La transaction peut disparaître temporairement
Implications dans le monde réel
Pour les développeurs :
Tu ne peux pas supposer une finalité instantanée
Doit gérer les états en attente
Pour l'UX :
Les utilisateurs voient « en attente » → confusion
L'estimation des frais devient critique
Pour les conceptions de systèmes
La logique de réessai est nécessaire
La surveillance des transactions est obligatoire
Points clés à retenir
Une transaction est un processus multi-étapes, pas un événement unique
La mempool est non déterministe et fragmentée
Les frais impactent directement la probabilité d'exécution
L'échec peut se produire à plusieurs niveaux
Les systèmes doivent être conçus pourl'incertitude et le retard
Si tu construis sur Ethereum, comprendre ce pipeline n'est pas optionnel—c'est fondamental$ETH