Aller au contenu
Financial Context Wiki

Mempools et pools de transactions

Guide centré sur le caractère local de l'admission des transactions Ethereum, les nonces en attente et en file, la propagation, l'admissibilité par les frais, le remplacement, le flux privé, l'inclusion, l'éviction et la réorganisation.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Un mempool, ou pool de transactions, est l’ensemble temporaire, conservé en mémoire et parfois persisté, des transactions signées qu’un nœud a acceptées selon ses règles courantes de validation et de politique, mais qui ne figurent pas dans sa chaîne canonique. Ce n’est ni un objet de consensus, ni une file globale, ni une promesse d’inclusion. Deux nœuds honnêtes peuvent conserver des transactions différentes parce qu’ils ont reçu un gossip différent, exécutent des clients ou réglages distincts, ont redémarré, évincé des entrées ou empruntent des circuits publics et privés différents.

Sur un client d’exécution Ethereum, une transaction exécutable portant le prochain nonce du compte est généralement qualifiée d’en attente ; un nonce ultérieur bloqué par un trou est généralement qualifié d’en file. Ces libellés appartiennent aux interfaces des clients et ne sont pas des états finaux du protocole. Une transaction peut être rejetée avant admission, propagée, remplacée par une autre transaction signée du même émetteur et du même nonce, évincée, abandonnée, incluse avec succès, incluse puis revertée, ou réexaminée après une réorganisation.

1
Créer

Un portefeuille construit une transaction avec la destination, la valeur, les paramètres de frais et les données de protection contre la relecture telles que les entrées dépensées ou un occasionnel.

Fonctionnement

  1. Fixer l’environnement : chain ID, client d’exécution et version, tête et frais de base courants, type de transaction, émetteur, nonce, valeur, calldata, limite de gas, plafonds de frais et circuit de soumission. Distinguer gossip public, relais ou builder privé et circuit ERC-4337 de UserOperation ; ils ne partagent pas un pool universel.
  2. Décoder les octets signés et effectuer les contrôles préalables à l’admission. Vérifier signature et émetteur, chain ID, type et encodage, gas intrinsèque, relation du nonce, solde couvrant valeur et exposition maximale aux frais, champs de frais et tout sidecar de blob requis. Un rejet à ce stade n’est pas un REVERT de l’EVM et ne produit normalement ni reçu ni frais onchain.
  3. Cartographier la politique locale du pool. Consigner le classement de la transaction comme en attente ou en file, les capacités par compte et globale, les filtres de frais minimaux, la durée de vie, les exemptions des comptes locaux, la majoration de remplacement et la persistance. Les options et valeurs par défaut de Geth documentent Geth, pas le consensus Ethereum ni chaque fournisseur.
  4. Observer la propagation sans inventer de vue globale. Comparer hash et octets signés de la transaction brute entre nœuds indépendants, mais considérer l’absence comme ambiguë : le nœud peut ne pas l’avoir reçue, la rejeter selon sa politique locale, l’avoir évincée ou ne pas exposer son pool. Un circuit privé peut contourner le gossip public tout en partageant la transaction avec ses opérateurs et builders.
  5. Modéliser l’admissibilité et l’ordre dans le bloc candidat. Pour une transaction de type 2, le prix du gas d’exécution est min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas) ; si les frais de base dépassent les frais maximaux, la transaction n’est pas admissible sous ce plafond. Dépendances de nonce, limites de gas et de blobs, validité de l’état, bundles de builders et MEV peuvent compter davantage que l’ordre d’arrivée.
  6. Gérer délibérément le cycle de vie. Attendre ou soumettre un remplacement documenté avec le même nonce uniquement après avoir confirmé chaîne active, émetteur et politique de remplacement. Un transfert à soi-même avec le même nonce n’est qu’un autre candidat au remplacement, pas une primitive d’annulation. Ne jamais répéter un transfert de valeur parce qu’un explorateur a cessé d’afficher l’original.
  7. Réconcilier avec l’état du consensus. Conserver chaque hash signé et la lignée des remplacements, puis contrôler reçu canonique, hash du bloc, statut, gas consommé, logs, nonce consommé et état du compte ou du contrat au niveau requis de confirmation ou de finalité. Si une réorganisation retire le bloc, une transaction toujours valide peut réintégrer certains pools locaux, selon le client et l’état.

Exemples détaillés

  • Admissibilité sous le plafond de frais. Un transfert de type 2 présente gasUsed = 21,000, baseFeePerGas = 32 gwei, maxPriorityFeePerGas = 3 gwei et maxFeePerGas = 34 gwei. Son prix effectif est min(34, 32 + 3) = 34 gwei, donc le pourboire réel est de 2 gwei. Les frais sont de 21,000 * 34 = 714,000 gwei = 0.000714 ETH, répartis entre 0.000672 ETH de frais de base brûlés et 0.000042 ETH de pourboire. Si les frais de base du bloc candidat atteignent 35 gwei, le plafond de 34 gwei ne suffit pas pour ce bloc.
  • Trou de nonce. Le nonce canonique du compte est 10. Un pool local reçoit des transactions de nonces 10 et 12, mais aucune de nonce 11 ; il peut classer 10 comme en attente et 12 comme en file. Après inclusion du nonce 10, le nonce canonique devient 11, et 12 reste bloqué jusqu’à l’inclusion d’une transaction valide de nonce 11. Voir le nonce 12 dans un pool ne le rend pas exécutable indépendamment.
  • Remplacement propre à une politique. Dans une configuration pédagogique de Geth avec txpool.pricebump = 10, une ancienne transaction présente maxFeePerGas = 40 gwei et maxPriorityFeePerGas = 2 gwei. Une majoration de 10 % donne des seuils de 44 gwei et 2.2 gwei. Une proposition à 43 gwei et 3 gwei peut encore être rejetée parce qu’un plafond n’atteint pas la majoration configurée ; 44 gwei et 2.2 gwei atteignent les deux seuils pédagogiques. Arrondi entier, type de transaction et logique d’acceptation exacts dépendent de la version ; un autre nœud peut conserver un candidat différent.
  • Pas de pool global. Le nœud A signale 120,000 hash distincts, le nœud B 100,000, leur intersection étant de 80,000. Leur union est 120,000 + 100,000 - 80,000 = 140,000 ; leur similarité de Jaccard est 80,000 / 140,000 = 57.1428571429%. 40,000 hash ne sont visibles que par A et 20,000 que par B. Aucun décompte ne prouve ce que voient un builder, un relais privé ou le reste du réseau.

Risques

  • Signer ou diffuser sur le mauvais chain ID ou réseau.
  • Faire confiance à un endpoint RPC malveillant, obsolète ou mal configuré.
  • Signature, type de transaction, encodage ou sidecar de blob invalide.
  • Solde insuffisant pour couvrir valeur et exposition maximale aux frais.
  • Rejet avant admission selon les règles de gas intrinsèque ou de calldata.
  • Nonce déjà consommé ou trop faible.
  • Trou de nonce laissant les transactions suivantes en file.
  • Remplacement de même nonce rejeté comme sous-évalué par la politique locale.
  • Frais maximaux inférieurs aux frais de base du bloc candidat.
  • Faible priorité effective ou contraintes de ressources retardant l’inclusion.
  • Divergence de politique entre client, fournisseur, version ou configuration.
  • Capacité, expiration, redémarrage ou éviction du pool retirant la transaction.
  • Mauvaise propagation, éclipse ou comportement sélectif du relais.
  • Fuite, censure, panne ou absence de builders sur le relais privé.
  • Frontrunning, sandwich ou autre MEV sur le flux public.
  • Réordonnancement par les builders, bundles ou transactions privées modifiant l’état.
  • Simulation devenue obsolète avant inclusion.
  • Double soumission aveugle ou perte de la lignée des remplacements.
  • REVERT inclus, manque de gas ou échec de sous-appel intercepté malgré l’admission.
  • Réorganisation, confusion de finalité ou mempool ERC-4337 traité comme txpool ordinaire.

Idées reçues

  • Le mempool est une seule file FIFO synchronisée à l’échelle mondiale.
  • Un hash prouve que le réseau a accepté ou propagé la transaction.
  • En attente signifie incluse, réussie, irréversible ou payée au destinataire.
  • Des frais suffisamment élevés garantissent inclusion et réussite de l’exécution.
  • Un circuit privé est automatiquement confidentiel, résistant à la censure et garanti.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...