MSTR Cat

Blockchain/Nivel II · Mecánica/2.2 Transacciones/Lección 5

El mempool

La sala de espera local que cada nodo gestiona de forma independiente

MaterialesUn explorador de bloques con vista del mempool (p. ej., mempool.space)Opcional: un nodo de Bitcoin Core (‘getmempoolinfo’)

Curiosidad

  1. ¿Por qué una transacción válida en un nodo completo es rechazada por su vecino?
  2. ¿Qué sucede con las transacciones de tarifa más baja cuando un nodo alcanza su límite de memoria?
  3. ¿Cómo deciden los mineros qué transacciones no confirmadas merecen espacio en su próximo bloque?

Explorar

  1. El mempool no es una base de datos central; es una lista local en memoria que cada nodo completo mantiene de forma independiente. Bitcoin Core descarta las transacciones no confirmadas que permanecen allí por demasiado tiempo: 72 horas desde la introducción del plazo de vencimiento en la versión 0.12, y dos semanas (336 horas) desde la versión 0.14. Dos nodos que reciben las transacciones en un orden diferente o tienen configuraciones distintas, albergan mempools ligeramente diferentes.
  2. Cada nodo aplica reglas de consenso (como scripts válidos y prohibición del gasto doble), además de reglas de política local, como las tarifas mínimas y los ajustes RBF. Si una transacción no cumple con el umbral mínimo de tarifa establecido por un nodo específico, ese nodo la rechazará o la descartará si ya está incluida, incluso si otros nodos la aceptan.
  3. Por defecto, Bitcoin Core limita el tamaño del mempool a 300 MB mediante el parámetro ‘maxmempool’ en el archivo bitcoin.conf. Cuando se alcanza este límite, el nodo eleva dinámicamente su umbral de tarifa mínima para dar espacio a transacciones más rentables, expulsando primero las menos valiosas. Ejecute ‘getmempoolinfo’ y observe cómo ‘mempoolminfee’ supera la ‘minrelaytxfee’ estática cuando el mempool se llena.
  4. Los mineros seleccionan transacciones de sus propios mempools para construir bloques, dando prioridad a la mayor tarifa por byte virtual, evaluada junto con cualquier transacción padre no confirmada. Cuando llega un bloque válido, cada nodo elimina de su mempool las transacciones confirmadas y las que presentan conflictos.
  5. La política no es un consenso. Una transacción que la mayoría de los nodos se niegan a retransmitir, porque está por debajo del umbral de comisión establecido o utiliza un formato no estándar, aún puede ser válida en un bloque, y algunos mineros aceptan directamente tales transacciones. Por lo tanto, el mempool de cada nodo es solo una estimación de lo que contendrá el próximo bloque, y los diferentes nodos pueden discrepar ligeramente.
  6. Al cerrarse, Bitcoin Core guarda su mempool en un archivo, mempool.dat, y lo vuelve a cargar al iniciar, descartando todo lo que ya no es válido, de modo que un nodo reiniciado no comience con un mempool vacío. Para observar cómo funciona el mempool, abra mempool.space: sus bloques proyectados muestran qué transacciones es probable que incluyan los mineros a continuación, y cada nuevo bloque elimina la capa superior del mempool.

Datos clave

  • El mempool es un pool de memoria local en cada nodo, no un servicio universal único.
  • Bitcoin Core tiene como valor predeterminado un límite de 300 MB para el tamaño del mempool a través de ‘maxmempool’.
  • Por defecto, Bitcoin Core descarta las transacciones no confirmadas después de dos semanas (336 horas, desde la versión 0.14).
  • Los nodos aplican tanto las reglas de consenso como las reglas de política local, incluidas las tarifas mínimas.
  • Cuando el mempool está lleno, los nodos elevan dinámicamente los umbrales de tarifa para expulsar las transacciones menos rentables.
  • Bitcoin Core guarda su mempool en ‘mempool.dat’ al cerrarse, para que sobreviva a un reinicio.

Ejercicio nueve, seis, tres, uno

9ReunirEnumera 9 transacciones distintas y no confirmadas desde la vista del mempool de un explorador de bloques. Anota sus tasas de tarifa actuales, tamaños en bytes virtuales y números de confirmaciones (todos cero).
6AgruparAgrupa las 9 transacciones en 6 categorías según la razón por la cual podrían quedar atascadas: tasa de tarifa baja, tamaño elevado, señalización RBF, entradas no confirmadas, estado de huérfano u otras razones relacionadas con las políticas.
3DestilarReduce los 6 grupos a 3 razones principales por las cuales un nodo rechazaría o expulsaría una transacción de su mempool a pesar de que sea válida según el consenso.
1CristalizarEscribe 1 oración que explique cómo las diferencias en las políticas locales entre los nodos generan una visión fragmentada y no universal de las transacciones pendientes en toda la red.

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

Abrir en la academia interactiva →

EN PT ZH JA KO RU DE FR MS