---
title: "Mempools et pools de transactions"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Mempools et pools de transactions

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

<a id="answer"></a>

## 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.

<a id="mechanism"></a>

## 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.

<a id="example"></a>

## 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.

<a id="risks"></a>

## 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.

<a id="misconceptions"></a>

## 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.

<a id="related"></a>

## Sujets connexes

- [Frais de gas](/fr/crypto/gas-fee/)
- [Remplacement dans le mempool](/fr/crypto/mempool-replacement/)
- [MEV](/fr/crypto/mev/)

<a id="sources"></a>

## Sources

- [Transactions](https://ethereum.org/developers/docs/transactions/) - Ethereum.org (consulté le : 2026-08-13)
- [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559) - Ethereum Improvement Proposals (consulté le : 2026-08-13)
- [txpool Namespace](https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-txpool) - go-ethereum (consulté le : 2026-08-13)
- [Command-line Options](https://geth.ethereum.org/docs/fundamentals/command-line-options) - go-ethereum (consulté le : 2026-08-13)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (consulté le : 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consulté le : 2026-08-13)
- [ERC-4337: Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337) - Ethereum Improvement Proposals (consulté le : 2026-08-13)
- [MEV Protection Overview](https://docs.flashbots.net/flashbots-protect/overview) - Flashbots Documentation (consulté le : 2026-08-13)

Source: https://wiki.fcontext.com/fr/crypto/mempool/index.mdx