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

> Come le transazioni vengono ammesse, tenute, ordinate e diffuse prima che il consenso le confermi in un blocco.

Il mempool è ciò che sta tra una transazione firmata e un blocco confermato. Decide che cosa vale la pena tenere, in quale ordine le transazioni di un mittente diventano idonee, quali peer vengono a sapere di una transazione e che cosa viene scartato quando la domanda supera la capacità.

Per una rete di trading questo è portante, non accessorio. Il traffico di ordini e annullamenti è a raffiche, concentrato su pochi mittenti e sensibile alla latenza in modo asimmetrico: un annullamento che arriva tardi è peggio di un ordine che arriva tardi. Le strutture qui sotto esistono perché una singola coda FIFO non gestisce bene niente di tutto questo.

<h2 id="the-path-in">
  Il percorso di ingresso
</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">Transazione firmata</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">Validazione</span><span className="dg-s">firma · formato · stato del conto · capacità del mittente di pagare</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">Scartata, con un motivo</span><span className="dg-s">non in silenzio — chi ha inviato sa perché</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">Archivio transazioni</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">Broadcast ai peer</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">Formazione dei batch, poi consenso</span></div>
    <div className="dg-free" style={{left:"0.0000%",top:"85.7143%",width:"100.0000%"}}><div className="dg-n">La validazione è locale e poco costosa: le risorse costose a valle sono spese solo su transazioni che potrebbero davvero essere eseguite.</div></div>
    <div className="dg-lbl" style={{left:"49.4444%",top:"36.5079%"}}>rifiutata</div>
    <div className="dg-lbl" style={{left:"49.4444%",top:"51.9841%"}}>accettata</div>
  </div>
</div>

Una transazione viene validata prima ancora di essere memorizzata. La validazione è locale e poco costosa — firma, formato, stato del conto e capacità del mittente di pagare quello che chiede — ed esiste perché le risorse costose a valle vengano spese solo su transazioni che potrebbero davvero essere eseguite. Un rifiuto qui restituisce un motivo a chi ha inviato, invece di sparire in silenzio.

<h2 id="how-transactions-are-held">
  Come vengono tenute le transazioni
</h2>

Le transazioni accettate non sono tenute in un'unica coda piatta. L'archivio mantiene più viste sullo stesso insieme, ognuna delle quali risponde a una domanda diversa.

<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 insieme di transazioni accettate</span><span className="dg-s">cinque viste, non cinque code</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">Ordinamento per conto</span><span className="dg-s">Per questo mittente, qual è la prossima?</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">Indice di priorità</span><span className="dg-s">Tra tutti i mittenti, che cosa va offerto per primo al consenso?</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">Indice di scadenza</span><span className="dg-s">Che cosa è scaduto?</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">Indice timeline</span><span className="dg-s">Di che cosa questo peer non sa ancora?</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">Parcheggio</span><span className="dg-s">Che cosa è ben formato ma non ancora idoneo?</span></div>
    <div className="dg-free" style={{left:"0.0000%",top:"89.1566%",width:"100.0000%"}}><div className="dg-n">Il parcheggio è dove diventa visibile un bug di integrazione: una transazione valida ma non ancora la prossima per il suo mittente viene parcheggiata, non rifiutata — diventa idonea appena il buco davanti a lei si chiude.</div></div>
  </div>
</div>

| Vista                     | Domanda a cui risponde                                           |
| ------------------------- | ---------------------------------------------------------------- |
| **Ordinamento per conto** | Per questo mittente, qual è la transazione successiva?           |
| **Indice di priorità**    | Tra tutti i mittenti, che cosa va offerto per primo al consenso? |
| **Indice di scadenza**    | Che cosa ha superato la scadenza e va rimosso?                   |
| **Indice timeline**       | Di che cosa questo peer non è ancora stato informato?            |
| **Parcheggio**            | Che cosa è ben formato ma non ancora idoneo?                     |

Il **parcheggio** è la vista che merita più attenzione, perché è lì che diventa visibile una classe di bug di integrazione. Una transazione può essere perfettamente valida e comunque non essere la prossima in fila per il suo mittente, quasi sempre perché una transazione precedente dello stesso conto non è arrivata o non è stata confermata. Una transazione così viene parcheggiata invece che rifiutata: resta disponibile e diventa idonea nel momento in cui il buco davanti a lei si chiude. Un client che invia fuori ordine subisce quindi un ritardo, non un fallimento; ma un client che quel buco non lo colma mai lascia lavoro parcheggiato fino alla scadenza.

L'**indice timeline** è ciò che rende incrementale la diffusione verso i peer. Per ogni peer si tiene traccia di quanto è stato servito lungo la timeline, così un broadcast invia ciò che a quel peer manca invece di rispedire l'intero pool. La timeline è suddivisa in bucket anziché essere una fila unica, e questo impedisce a un singolo mittente pesante di monopolizzare ogni slot di broadcast.

<h2 id="dissemination-and-fairness">
  Diffusione ed equità
</h2>

I nodi non vengono a conoscenza delle transazioni ciascuno per conto proprio. Un nodo che accetta una transazione la trasmette ai peer, e i peer non sono trattati allo stesso modo: quelli a monte hanno la precedenza, così una transazione si muove verso i validatori che possono darle seguito invece di diffondersi in modo uniforme nella rete.

L'equità è tracciata sulla storia recente invece che imposta messaggio per messaggio. Il mempool tiene un registro scorrevole di quali mittenti e quali tipi di traffico hanno consumato capacità di recente, e lo usa per modulare che cosa servire dopo. È il meccanismo che impedisce alla tempesta di ordini e annullamenti di un singolo conto di soffocare il resto della rete, senza bisogno di un rate limit rigido per conto che penalizzerebbe il market making legittimo.

<h2 id="handoff-to-consensus">
  Il passaggio al consenso
</h2>

Il consenso non prende le transazioni dal mempool una alla volta. Le transazioni vengono raccolte in **batch**, i batch vengono diffusi ai validatori in background e ogni batch viene riscontrato finché chi lo ha originato può dimostrare che una parte sufficiente della rete lo detiene. Solo allora una proposta di blocco può farvi riferimento.

La conseguenza è che una proposta di blocco porta i digest dei batch e non i corpi delle transazioni, così la dimensione dei messaggi di consenso resta piatta al crescere del throughput — e un blocco confermato è sempre rieseguibile, perché i dati sottostanti sono stati provati disponibili prima di essere referenziati. Vedi [IntentionBFT](/it/protocol/architecture/intention-bft) per capire come quella prova viene formata e usata.

<Note>
  È anche per questo che l'ammissione al mempool non equivale all'inclusione. Una transazione accettata, memorizzata e trasmessa è entrata in coda; non è stata ordinata. Nulla del destino di una transazione è deciso finché il consenso non conferma il blocco che la contiene.
</Note>

<h2 id="what-this-means-for-a-client">
  Che cosa significa per un client
</h2>

* **Un rifiuto all'invio è informativo.** È avvenuto prima che la transazione fosse memorizzata, e il motivo descrive qualcosa che il client può correggere.
* **Il silenzio non è un rifiuto.** Una transazione può essere parcheggiata dietro un buco creato dal client stesso. Tieni traccia di che cosa è stato inviato e di che cosa è stato confermato, invece di dare per scontato che un riscontro mancante significhi uno scarto.
* **L'ordine dentro un conto conta; l'ordine tra conti diversi no.** Due transazioni dello stesso mittente hanno una sequenza definita. Due transazioni di mittenti diversi sono ordinate dal consenso, non da chi ha inviato per primo.
* **Nel mempool gli annullamenti non sono privilegiati.** La priorità dell'annullamento è una proprietà dell'[esecuzione del kernel](/it/protocol/architecture/kernel), dove gli annullamenti vengono eseguiti prima delle immissioni aggressive nello stesso blocco — non dell'accodamento.