> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Mempool

> Comment les transactions sont admises, conservées, séquencées et diffusées avant que le consensus ne les entérine dans un bloc.

Le mempool est ce qui se tient entre une transaction signée et un bloc entériné. Il décide de ce qui vaut la peine d’être conservé, de la séquence dans laquelle les transactions d’un émetteur deviennent éligibles, des pairs qui entendent parler d’une transaction, et de ce qui est écarté quand la demande dépasse la capacité.

Pour un réseau de trading, c’est structurant et non accessoire. Le trafic d’ordres et d’annulations arrive par rafales, se concentre sur quelques émetteurs et réagit à la latence de façon asymétrique : une annulation qui arrive en retard est pire qu’un ordre qui arrive en retard. Les structures ci-dessous existent parce qu’une simple file FIFO ne gère bien aucun de ces aspects.

<h2 id="the-path-in">
  Le chemin d’entrée
</h2>

<div className="dg" data-dg="mempool-admission">
  <div className="dg-c" style={{aspectRatio:"720 / 252"}}>
    <svg className="dg-w" viewBox="0 0 720 252" aria-hidden="true">
      <path className="dg-wire dg--blue" d="M 124.00 145.00 L 145.60 145.00" />

      <path className="dg-head dg--blue" d="M 152.00 145.00 L 145.60 149.40 L 145.60 140.60 Z" />

      <path className="dg-wire dg--orange" d="M 340.00 145.00 L 356.00 145.00 L 356.00 46.00 L 365.60 46.00" />

      <path className="dg-head dg--orange" d="M 372.00 46.00 L 365.60 50.40 L 365.60 41.60 Z" />

      <path className="dg-wire dg--sky" d="M 340.00 145.00 L 365.60 145.00" />

      <path className="dg-head dg--sky" d="M 372.00 145.00 L 365.60 149.40 L 365.60 140.60 Z" />

      <path className="dg-wire dg--sky dg-soft" d="M 541.00 145.00 L 566.40 120.45" />

      <path className="dg-head dg--sky" d="M 571.00 116.00 L 569.46 123.61 L 563.34 117.28 Z" />

      <path className="dg-wire dg--sky dg-soft" d="M 541.00 145.00 L 566.55 171.40" />

      <path className="dg-head dg--sky" d="M 571.00 176.00 L 563.39 174.46 L 569.71 168.34 Z" />
    </svg>

    <div className="dg-b dg--blue" style={{left:"0.0000%",top:"46.8254%",width:"16.6667%",height:"21.4286%"}}><span className="dg-t">Transaction signée</span></div>
    <div className="dg-b dg--yellow" style={{left:"21.6667%",top:"42.8571%",width:"25.0000%",height:"29.3651%"}}><span className="dg-t">Validation</span><span className="dg-s">signature · format · état du compte · capacité à payer</span></div>
    <div className="dg-b dg--orange dg-left" style={{left:"52.2222%",top:"7.9365%",width:"47.7778%",height:"20.6349%"}}><span className="dg-t">Écartée, avec un motif renvoyé</span><span className="dg-s">pas en silence — l’émetteur sait pourquoi</span></div>
    <div className="dg-b dg--sky" style={{left:"52.2222%",top:"46.8254%",width:"22.2222%",height:"21.4286%"}}><span className="dg-t">Magasin de transactions</span></div>
    <div className="dg-b dg--sky" style={{left:"80.0000%",top:"36.5079%",width:"20.0000%",height:"19.0476%"}}><span className="dg-t">Diffusion aux pairs</span></div>
    <div className="dg-b dg--sky" style={{left:"80.0000%",top:"60.3175%",width:"20.0000%",height:"19.0476%"}}><span className="dg-t">Formation de lots, puis consensus</span></div>
    <div className="dg-free" style={{left:"0.0000%",top:"85.7143%",width:"100.0000%"}}><div className="dg-n">La validation est peu coûteuse et locale : les ressources coûteuses en aval ne servent qu’aux transactions qui pourraient s’exécuter.</div></div>
    <div className="dg-lbl" style={{left:"49.4444%",top:"36.5079%"}}>rejetée</div>
    <div className="dg-lbl" style={{left:"49.4444%",top:"51.9841%"}}>acceptée</div>
  </div>
</div>

Une transaction est validée avant même d’être stockée. La validation est peu coûteuse et locale — signature, format, état du compte, et capacité de l’émetteur à payer ce qu’il demande — et elle existe pour que les ressources coûteuses en aval ne soient dépensées que sur des transactions qui pourraient réellement s’exécuter. Un rejet à ce stade renvoie un motif à l’émetteur, au lieu de disparaître en silence.

<h2 id="how-transactions-are-held">
  Comment les transactions sont conservées
</h2>

Les transactions acceptées ne sont pas conservées dans une file unique et plate. Le magasin maintient plusieurs vues sur le même ensemble, chacune répondant à une question différente.

<div className="dg" data-dg="mempool-views">
  <div className="dg-c" style={{aspectRatio:"720 / 332"}}>
    <svg className="dg-w" viewBox="0 0 720 332" aria-hidden="true">
      <path className="dg-wire dg-soft" d="M 195.00 148.00 L 245.00 36.00" />

      <path className="dg-wire dg-soft" d="M 195.00 148.00 L 245.00 92.00" />

      <path className="dg-wire dg-soft" d="M 195.00 148.00 L 245.00 148.00" />

      <path className="dg-wire dg-soft" d="M 195.00 148.00 L 245.00 204.00" />

      <path className="dg-wire dg-soft" d="M 195.00 148.00 L 245.00 260.00" />
    </svg>

    <div className="dg-b dg--blue dg-round" style={{left:"0.0000%",top:"31.0241%",width:"26.3889%",height:"27.1084%"}}><span className="dg-t">Un ensemble de transactions acceptées</span><span className="dg-s">cinq vues dessus, pas cinq files</span></div>
    <div className="dg-b dg--sky" style={{left:"34.7222%",top:"3.0120%",width:"65.2778%",height:"15.6627%"}}><span className="dg-t">Séquence par compte</span><span className="dg-s">Pour cet émetteur, quelle transaction ensuite ?</span></div>
    <div className="dg-b dg--sky" style={{left:"34.7222%",top:"19.8795%",width:"65.2778%",height:"15.6627%"}}><span className="dg-t">Index de priorité</span><span className="dg-s">Tous émetteurs confondus, que proposer au consensus en premier ?</span></div>
    <div className="dg-b dg--sky" style={{left:"34.7222%",top:"36.7470%",width:"65.2778%",height:"15.6627%"}}><span className="dg-t">Index d’expiration</span><span className="dg-s">Qui a dépassé son échéance ?</span></div>
    <div className="dg-b dg--sky" style={{left:"34.7222%",top:"53.6145%",width:"65.2778%",height:"15.6627%"}}><span className="dg-t">Index chronologique</span><span className="dg-s">De quoi ce pair n’a-t-il pas eu vent ?</span></div>
    <div className="dg-b dg--yellow" style={{left:"34.7222%",top:"70.4819%",width:"65.2778%",height:"15.6627%"}}><span className="dg-t">Aire d’attente</span><span className="dg-s">Bien formé mais pas encore éligible ?</span></div>
    <div className="dg-free" style={{left:"0.0000%",top:"89.1566%",width:"100.0000%"}}><div className="dg-n">C’est dans l’aire d’attente qu’un bug d’intégration devient visible : une transaction valide mais pas encore la prochaine de son émetteur est mise en attente, pas rejetée — elle devient éligible dès que le trou devant elle se comble.</div></div>
  </div>
</div>

| Vue                     | Question à laquelle elle répond                                          |
| ----------------------- | ------------------------------------------------------------------------ |
| **Séquence par compte** | Pour cet émetteur, quelle est la transaction suivante ?                  |
| **Index de priorité**   | Tous émetteurs confondus, que faut-il proposer au consensus en premier ? |
| **Index d’expiration**  | Qu’est-ce qui a dépassé son échéance et doit être retiré ?               |
| **Index chronologique** | De quoi ce pair n’a-t-il pas encore entendu parler ?                     |
| **Aire d’attente**      | Qu’est-ce qui est bien formé mais pas encore éligible ?                  |

L’**aire d’attente** mérite le plus d’attention, parce que c’est là qu’une catégorie de bug d’intégration devient visible. Une transaction peut être parfaitement valide sans être pour autant la prochaine de son émetteur — le plus souvent parce qu’une transaction antérieure du même compte n’est pas arrivée ou n’a pas été entérinée. Une telle transaction est mise en attente plutôt que rejetée : elle reste disponible et devient éligible dès que le trou devant elle est comblé. Un client qui soumet dans le désordre subit donc un délai plutôt qu’un échec, mais un client qui ne comble jamais le trou laisse du travail en attente jusqu’à son expiration.

L’**index chronologique** est ce qui rend la diffusion entre pairs incrémentale. Le mempool retient, pour chaque pair, jusqu’où il a été servi dans la chronologie, de sorte qu’une diffusion lui envoie ce qui lui manque plutôt que tout le pool. La chronologie est répartie en compartiments plutôt qu’en file unique, ce qui empêche un émetteur volumineux de monopoliser tous les créneaux de diffusion.

<h2 id="dissemination-and-fairness">
  Diffusion et équité
</h2>

Les nœuds n’apprennent pas chacun de leur côté l’existence des transactions. Un nœud qui accepte une transaction la diffuse à ses pairs, et les pairs ne sont pas traités de la même façon — les pairs en amont sont prioritaires, afin qu’une transaction se dirige vers les validateurs capables d’y donner suite plutôt que de se répandre uniformément sur le réseau.

L’équité est suivie sur l’historique récent plutôt qu’imposée message par message. Le mempool tient un relevé glissant des émetteurs et des types de trafic ayant récemment consommé de la capacité, et s’en sert pour façonner ce qui sera servi ensuite. C’est le mécanisme qui empêche la tempête d’ordres et d’annulations d’un seul compte d’évincer le reste du réseau, sans exiger une limite de débit stricte par compte qui pénaliserait du market making légitime.

<h2 id="handoff-to-consensus">
  Passage au consensus
</h2>

Le consensus ne prend pas les transactions du mempool une par une. Les transactions sont rassemblées en **lots**, les lots sont diffusés aux validateurs en arrière-plan, et chacun est acquitté jusqu’à ce que son émetteur puisse prouver qu’une part suffisante du réseau le détient. Ce n’est qu’alors qu’une proposition de bloc peut le référencer.

La conséquence est qu’une proposition de bloc porte des empreintes de lots plutôt que des corps de transactions, si bien que la taille des messages de consensus reste stable quand le débit augmente — et qu’un bloc entériné est toujours rejouable, parce que les données qui le sous-tendent ont été prouvées disponibles avant d’être référencées. Voir [IntentionBFT](/fr/protocol/architecture/intention-bft) pour la façon dont cette preuve est formée et utilisée.

<Note>
  C’est aussi pourquoi l’admission dans le mempool n’équivaut pas à l’inclusion. Une transaction acceptée, stockée et diffusée est entrée dans la file ; elle n’a pas été séquencée. Rien du sort d’une transaction n’est arrêté tant que le consensus n’a pas entériné le bloc qui la contient.
</Note>

<h2 id="what-this-means-for-a-client">
  Ce que cela signifie pour un client
</h2>

* **Un rejet à la soumission est informatif.** Il est survenu avant le stockage de la transaction, et le motif décrit quelque chose que le client peut corriger.
* **Le silence n’est pas un rejet.** Une transaction peut être en attente derrière un trou que le client a lui-même créé. Suivez ce qui a été soumis et ce qui a été entériné, au lieu de supposer qu’un accusé de réception manquant signifie une perte.
* **La séquence compte à l’intérieur d’un compte, pas entre comptes.** Deux transactions d’un même émetteur ont une séquence définie. Deux transactions d’émetteurs différents sont séquencées par le consensus, pas par celui qui a soumis en premier.
* **Les annulations ne sont pas privilégiées dans le mempool.** La priorité d’annulation est une propriété de l’[exécution du noyau](/fr/protocol/architecture/kernel), où les annulations passent avant les placements agressifs du même bloc — ce n’est pas une propriété de la mise en file.