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

> Cómo se admiten, se guardan, se ordenan y se difunden las transacciones antes de que el consenso las confirme en un bloque.

El mempool es lo que se interpone entre una transacción firmada y un bloque confirmado. Decide qué merece la pena guardar, en qué orden se vuelven elegibles las transacciones de un remitente, qué pares se enteran de una transacción y qué se descarta cuando la demanda supera la capacidad.

Para una red de trading esto es estructural, no incidental. El tráfico de órdenes y cancelaciones llega a ráfagas, se concentra en pocos remitentes y es sensible a la latencia de forma asimétrica: una cancelación que llega tarde es peor que una orden que llega tarde. Las estructuras de abajo existen porque una única cola FIFO no maneja bien nada de eso.

<h2 id="the-path-in">
  La ruta de entrada
</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">Transacción firmada</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">Validación</span><span className="dg-s">firma · formato · estado de la cuenta · ¿puede pagarla el remitente?</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">Descartada, con motivo devuelto</span><span className="dg-s">no en silencio — quien la envió sabe por qué</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">Almacén de transacciones</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">Difusión a pares</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">Formación de lotes, luego consenso</span></div>
    <div className="dg-free" style={{left:"0.0000%",top:"85.7143%",width:"100.0000%"}}><div className="dg-n">La validación es barata y local, así que los recursos caros de aguas abajo se gastan solo en transacciones que podrían ejecutarse de verdad.</div></div>
    <div className="dg-lbl" style={{left:"49.4444%",top:"36.5079%"}}>rechazada</div>
    <div className="dg-lbl" style={{left:"49.4444%",top:"51.9841%"}}>aceptada</div>
  </div>
</div>

Una transacción se valida antes de llegar a almacenarse. La validación es barata y local (firma, formato, estado de la cuenta y si el remitente puede pagar lo que pide) y existe para que los recursos caros de aguas abajo se gasten solo en transacciones que realmente podrían ejecutarse. Un rechazo aquí devuelve un motivo a quien la envió en lugar de desaparecer en silencio.

<h2 id="how-transactions-are-held">
  Cómo se guardan las transacciones
</h2>

Las transacciones aceptadas no se guardan en una sola cola plana. El almacén mantiene varias vistas sobre el mismo conjunto, y cada una responde a una pregunta distinta.

<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 conjunto de transacciones aceptadas</span><span className="dg-s">cinco vistas sobre él, no cinco colas</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">Orden por cuenta</span><span className="dg-s">Para este remitente, ¿cuál es la siguiente?</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">Índice de prioridad</span><span className="dg-s">Entre todos los remitentes, ¿qué se ofrece antes 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">Índice de caducidad</span><span className="dg-s">¿Qué ha superado su plazo?</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">Índice de línea temporal</span><span className="dg-s">¿De qué no se ha enterado este par?</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">Zona de espera</span><span className="dg-s">¿Qué está bien formado pero aún no es elegible?</span></div>
    <div className="dg-free" style={{left:"0.0000%",top:"89.1566%",width:"100.0000%"}}><div className="dg-n">La zona de espera es donde se ve un fallo de integración: una transacción válida que aún no es la siguiente de su remitente queda en espera, no rechazada — y se vuelve elegible en cuanto se cierra el hueco de delante.</div></div>
  </div>
</div>

| Vista                        | Pregunta que responde                                                 |
| ---------------------------- | --------------------------------------------------------------------- |
| **Orden por cuenta**         | Para este remitente, ¿cuál es la siguiente transacción?               |
| **Índice de prioridad**      | Entre todos los remitentes, ¿qué debería ofrecerse antes al consenso? |
| **Índice de caducidad**      | ¿Qué ha superado su plazo y debería eliminarse?                       |
| **Índice de línea temporal** | ¿De qué no se ha enterado todavía este par?                           |
| **Zona de espera**           | ¿Qué está bien formado pero todavía no es elegible?                   |

La **zona de espera** merece la mayor atención, porque es donde se hace visible toda una clase de fallo de integración. Una transacción puede ser perfectamente válida y aun así no ser la siguiente en la cola de su remitente: casi siempre porque una transacción anterior de la misma cuenta no ha llegado o no se ha confirmado. Esa transacción queda en espera en lugar de ser rechazada: sigue disponible y se vuelve elegible en cuanto se cierra el hueco que tiene delante. Un cliente que envía fuera de orden experimenta por tanto un retraso, no un fallo, pero un cliente que nunca rellena el hueco deja trabajo en espera hasta que caduca.

El **índice de línea temporal** es lo que hace incremental la difusión entre pares. De cada par se registra hasta qué punto de la línea temporal se le ha servido, de modo que una difusión envía lo que a ese par le falta en lugar de reenviar el pool entero. La línea temporal está segmentada en lugar de ser una fila única, lo que impide que un remitente pesado monopolice todos los turnos de difusión.

<h2 id="dissemination-and-fairness">
  Difusión y reparto equitativo
</h2>

Los nodos no se enteran de las transacciones cada uno por su cuenta. Un nodo que acepta una transacción la difunde a sus pares, y no todos los pares reciben el mismo trato: los pares aguas arriba tienen prioridad, para que una transacción avance hacia los validadores que pueden actuar sobre ella en lugar de difundirse de forma uniforme por la red.

El reparto equitativo se controla sobre el historial reciente en lugar de imponerse mensaje a mensaje. El mempool mantiene un registro móvil de qué remitentes y qué tipos de tráfico han consumido capacidad recientemente, y lo usa para modelar qué se sirve a continuación. Este es el mecanismo que impide que la tormenta de órdenes y cancelaciones de una sola cuenta desplace al resto de la red, sin necesidad de un límite de solicitudes duro por cuenta que penalizaría al market making legítimo.

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

El consenso no toma las transacciones del mempool de una en una. Las transacciones se reúnen en **lotes**, los lotes se difunden a los validadores en segundo plano y los validadores acusan recibo de cada lote hasta que su originador puede demostrar que una parte suficiente de la red lo tiene. Solo entonces puede una propuesta de bloque referenciarlo.

La consecuencia es que una propuesta de bloque lleva digests de lotes en lugar de cuerpos de transacción, así que el tamaño de los mensajes de consenso se mantiene plano cuando sube el rendimiento, y un bloque confirmado siempre es reejecutable, porque se demostró que los datos que hay detrás estaban disponibles antes de referenciarlos. Consulta [IntentionBFT](/es/protocol/architecture/intention-bft) para ver cómo se forma y se usa esa prueba.

<Note>
  Por eso también la admisión al mempool no es lo mismo que la inclusión. Una transacción aceptada, almacenada y difundida ha entrado en la cola; no ha sido ordenada. Nada sobre el destino de una transacción queda decidido hasta que el consenso confirma el bloque que la contiene.
</Note>

<h2 id="what-this-means-for-a-client">
  Qué significa esto para un cliente
</h2>

* **Un rechazo en el envío es informativo.** Ocurrió antes de que la transacción se almacenara, y el motivo describe algo que el cliente puede arreglar.
* **El silencio no es un rechazo.** Una transacción puede estar en espera detrás de un hueco que el propio cliente ha creado. Lleva la cuenta de lo que has enviado y de lo que se ha confirmado, en vez de dar por supuesto que la falta de acuse de recibo significa un descarte.
* **El orden dentro de una cuenta importa; el orden entre cuentas no.** Dos transacciones de un mismo remitente tienen una secuencia definida. Dos transacciones de remitentes distintos las ordena el consenso, no quién envió primero.
* **Las cancelaciones no tienen privilegio en el mempool.** La prioridad de cancelación es una propiedad de la [ejecución del kernel](/es/protocol/architecture/kernel), donde las cancelaciones se ejecutan antes que las colocaciones agresivas del mismo bloque, no de las colas.