--- title: "Mempools y pools de transacciones" description: "Guía centrada en el carácter local de la admisión de transacciones de Ethereum, nonces pendientes y en cola, propagación, elegibilidad por comisiones, sustitución, flujo privado, inclusión, expulsión y reorganización." 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 y pools de transacciones > Solo con fines educativos; no constituye asesoramiento ni recomendación de inversión. Las inversiones pueden ocasionar pérdidas. ## Respuesta directa Un mempool, o pool de transacciones, es el conjunto temporal, mantenido en memoria y a veces persistido, de transacciones firmadas que un nodo ha aceptado conforme a sus reglas actuales de validación y política, pero que no forman parte de su cadena canónica. No es un objeto de consenso, una cola global ni una promesa de inclusión. Dos nodos honestos pueden contener transacciones distintas porque recibieron gossip diferente, ejecutan clientes o configuraciones diferentes, se reiniciaron, expulsaron entradas o usan rutas públicas y privadas distintas. En un cliente de ejecución de Ethereum, una transacción ejecutable con el siguiente `nonce` de la cuenta suele calificarse como pendiente; un nonce posterior bloqueado por un salto suele calificarse como en cola. Son etiquetas de interfaces de clientes, no estados finales del protocolo. Una transacción puede ser rechazada antes de la admisión, propagada, sustituida por otra transacción firmada del mismo emisor y nonce, expulsada, descartada, incluida con éxito, incluida y revertida o reconsiderada tras una reorganización. ## Cómo funciona 1. Fijar el entorno: chain ID, cliente de ejecución y versión, cabecera y tarifa base actuales, tipo de transacción, emisor, nonce, valor, calldata, límite de gas, topes de comisión y ruta de envío. Distinguir gossip público, relay o builder privado y una ruta ERC-4337 de `UserOperation`; no comparten un pool universal. 2. Decodificar los bytes firmados y efectuar comprobaciones previas a la admisión. Verificar firma y emisor, chain ID, tipo y codificación, gas intrínseco, relación del nonce, saldo para valor más exposición máxima a comisiones, campos de comisión y cualquier sidecar de blob necesario. Un rechazo aquí no es un `REVERT` de la EVM y normalmente no genera recibo ni comisión onchain. 3. Cartografiar la política local del pool. Registrar si el cliente clasifica la transacción como pendiente o en cola, capacidades por cuenta y global, filtros de comisión mínima, vida útil, exenciones para cuentas locales, incremento de sustitución y persistencia. Los flags y valores predeterminados de Geth documentan Geth, no el consenso de Ethereum ni todos los proveedores. 4. Observar la propagación sin inventar una vista global. Comparar hash y bytes firmados de la transacción sin procesar entre nodos independientes, pero interpretar la ausencia como ambigua: el nodo quizá no la recibió, la rechazó por su política local, la expulsó o no expone su pool. Una ruta privada puede evitar el gossip público y compartir a la vez la transacción con operadores y builders. 5. Modelar elegibilidad y ordenación en el bloque candidato. Para una transacción de tipo 2, el precio del gas de ejecución es `min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas)`; si la tarifa base supera la tarifa máxima, la transacción no es elegible bajo ese tope. Dependencias de nonce, límites de gas y blobs, validez del estado, bundles de builders y MEV pueden importar más que el orden de llegada. 6. Gestionar deliberadamente el ciclo de vida. Esperar o enviar una sustitución documentada con el mismo nonce solo tras confirmar cadena activa, emisor y política de sustitución. Una transferencia a uno mismo con el mismo nonce es solo otra candidata a sustituir, no una primitiva de cancelación. No repetir una transferencia de valor porque un explorador haya dejado de mostrar la original. 7. Conciliar con el estado de consenso. Conservar cada hash firmado y el linaje de sustituciones; comprobar después recibo canónico, hash de bloque, estado, gas usado, logs, nonce consumido y estado de cuenta o contrato al nivel requerido de confirmación o finalidad. Si una reorganización elimina el bloque, una transacción aún válida puede regresar a algunos pools locales, pero depende del cliente y del estado. ## Ejemplos desarrollados - **Elegibilidad por tope de comisión.** Una transferencia de tipo 2 tiene `gasUsed = 21,000`, `baseFeePerGas = 32 gwei`, `maxPriorityFeePerGas = 3 gwei` y `maxFeePerGas = 34 gwei`. Su precio efectivo es `min(34, 32 + 3) = 34 gwei`, por lo que la propina real es `2 gwei`. La comisión es `21,000 * 34 = 714,000 gwei = 0.000714 ETH`, dividida entre `0.000672 ETH` de tarifa base quemada y `0.000042 ETH` de propina. Si la tarifa base del bloque candidato sube a `35 gwei`, el tope de `34 gwei` no basta para ese bloque. - **Salto de nonce.** El nonce canónico de la cuenta es `10`. Un pool local recibe transacciones con nonces `10` y `12`, pero ninguna con `11`; puede clasificar `10` como pendiente y `12` como en cola. Tras incluir el nonce `10`, el nonce canónico pasa a `11`, y `12` sigue bloqueado hasta incluir una transacción válida con nonce `11`. Ver el nonce `12` en un pool no lo hace ejecutable de forma independiente. - **Sustitución específica de una política.** Bajo una configuración didáctica de Geth con `txpool.pricebump = 10`, una transacción antigua tiene `maxFeePerGas = 40 gwei` y `maxPriorityFeePerGas = 2 gwei`. Un incremento del 10% da umbrales de `44 gwei` y `2.2 gwei`. Una propuesta de `43 gwei` y `3 gwei` aún puede rechazarse porque uno de los topes no alcanza el incremento configurado; `44 gwei` y `2.2 gwei` alcanzan ambos umbrales didácticos. El redondeo entero, tipo de transacción y lógica de aceptación exactos dependen de la versión, y otro nodo puede conservar otra candidata. - **No existe un pool global.** El nodo A informa `120,000` hashes distintos, el nodo B `100,000`, y su intersección es `80,000`. La unión es `120,000 + 100,000 - 80,000 = 140,000`; la coincidencia de Jaccard es `80,000 / 140,000 = 57.1428571429%`. Hay `40,000` hashes visibles solo para A y `20,000` solo para B. Ningún recuento demuestra qué pueden ver un builder, un relay privado o el resto de la red. ## Riesgos - Firmar o difundir en la chain ID o red equivocada. - Confiar en un endpoint RPC malicioso, obsoleto o mal configurado. - Firma, tipo de transacción, codificación o sidecar de blob inválidos. - Saldo insuficiente para valor más exposición máxima a comisiones. - Rechazo previo por reglas de gas intrínseco o calldata. - Nonce ya consumido o demasiado bajo. - Salto de nonce que deja en cola transacciones posteriores. - Sustitución con el mismo nonce rechazada por comisión insuficiente según política local. - Tarifa máxima inferior a la tarifa base del bloque candidato. - Prioridad efectiva baja o restricciones de recursos que retrasan la inclusión. - Discrepancia de política entre cliente, proveedor, versión o configuración. - Capacidad, caducidad, reinicio o expulsión del pool que elimina la transacción. - Propagación deficiente, eclipse o comportamiento selectivo del relay. - Filtración, censura, caída o falta de participación de builders en un relay privado. - Frontrunning, sandwich u otro MEV sobre el flujo público. - Reordenación por builders, bundles o transacciones privadas que alteran el estado de ejecución. - Simulación que queda obsoleta antes de la inclusión. - Envío duplicado a ciegas o pérdida del linaje de sustituciones. - `REVERT` incluido, falta de gas o fallo atrapado en una subllamada pese a la admisión al pool. - Reorganización, confusión de finalidad o tratar un mempool alternativo ERC-4337 como txpool ordinario. ## Errores comunes - El mempool es una única cola global sincronizada con disciplina FIFO. - Un hash de transacción demuestra que la red aceptó o propagó la transacción. - Pendiente significa incluida, exitosa, irreversible o pagada al destinatario. - Una comisión suficientemente alta garantiza inclusión y ejecución exitosa. - Una ruta de envío privada es automáticamente confidencial, resistente a censura y de inclusión garantizada. ## Temas relacionados - [Tarifas de gas](/es/crypto/gas-fee/) - [Sustitución en el mempool](/es/crypto/mempool-replacement/) - [MEV](/es/crypto/mev/) ## Fuentes - [Transactions](https://ethereum.org/developers/docs/transactions/) - Ethereum.org (consultado: 2026-08-13) - [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559) - Ethereum Improvement Proposals (consultado: 2026-08-13) - [txpool Namespace](https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-txpool) - go-ethereum (consultado: 2026-08-13) - [Command-line Options](https://geth.ethereum.org/docs/fundamentals/command-line-options) - go-ethereum (consultado: 2026-08-13) - [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (consultado: 2026-08-13) - [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consultado: 2026-08-13) - [ERC-4337: Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337) - Ethereum Improvement Proposals (consultado: 2026-08-13) - [MEV Protection Overview](https://docs.flashbots.net/flashbots-protect/overview) - Flashbots Documentation (consultado: 2026-08-13) Source: https://wiki.fcontext.com/es/crypto/mempool/index.mdx