Leyendo el Mempool de Ethereum: El Espacio de Nombres txpool y las Transacciones Pendientes

Qué es realmente el Mempool de Ethereum

Cuando envías una transacción mediante eth_sendRawTransaction, el nodo receptor la valida y, si es válida, la coloca en su pool de transacciones local (a menudo llamado mempool). Este pool no forma parte del consenso de Ethereum; es una caché por nodo de transacciones que han sido aceptadas pero aún no minadas. Cada nodo mantiene su propio pool, por lo que el contenido difiere de un nodo a otro. El pool se organiza típicamente en dos colas: pending (transacciones con nonces secuenciales que están listas para ser incluidas en un bloque) y queued (transacciones con huecos de nonce u otras condiciones que impiden su inclusión inmediata).

La documentación autoritativa para el espacio de nombres txpool es mantenida por los clientes de ejecución. Por ejemplo, la documentación de txpool de geth y la documentación de txpool de reth describen los métodos y su semántica. Estas son fuentes primarias para el comportamiento descrito aquí. El punto clave es que el pool es local: dos nodos pueden tener conjuntos de pendientes diferentes, y una transacción que está en el pool de un nodo puede estar ausente en el de otro.

Esta localidad tiene implicaciones profundas para los desarrolladores. Si dependes de un proveedor RPC alojado, normalmente compartes infraestructura con muchos otros usuarios. Los proveedores a menudo deshabilitan el espacio de nombres txpool por completo porque exponerlo filtraría información sobre las transacciones pendientes de sus usuarios y podría ser abusado. Como resultado, no puedes asumir que los métodos txpool_* están disponibles en un endpoint alojado. Siempre consulta la documentación de tu proveedor o prueba el método directamente.

• El mempool es local al nodo, no un componente global de la red.
• Las transacciones entran al pool después de la validación y salen cuando se minan o se descartan.
• El pool no es parte del consenso; es un detalle de implementación.
• Los proveedores alojados a menudo deshabilitan txpool_* por razones de privacidad y recursos.

El espacio de nombres txpool: Métodos y semántica

El espacio de nombres txpool proporciona tres métodos estándar, definidos en la especificación JSON-RPC de Ethereum e implementados por la mayoría de los clientes: txpool_content, txpool_inspect y txpool_status. Algunos clientes añaden extensiones, como txpool_contentFrom (geth) o métodos de historial específicos de Besu, pero estos no están estandarizados y su disponibilidad varía.

txpool_content devuelve los objetos de transacción completos en el pool, agrupados por dirección y nonce. La respuesta tiene dos claves de nivel superior: pending y queued. Cada una mapea una dirección a otro mapa de nonce a objeto de transacción. Esta es la vista más detallada, pero puede ser grande y rara vez es expuesta por los proveedores.

txpool_inspect devuelve un resumen más ligero: para cada dirección y nonce, da una cadena como value: gasPrice: gasLimit (por ejemplo, 0x...: 1000000000000 wei + 50000 gas × 20000000000 wei). Esto es útil para evaluar rápidamente la competencia de gas sin obtener los cuerpos completos de las transacciones.

txpool_status devuelve un objeto simple con conteos enteros de pending y queued. Esta es la forma más económica de verificar si el pool está activo y aproximadamente cuántas transacciones están esperando.

Algunos clientes también proporcionan txpool_contentFrom (geth) para filtrar por dirección de remitente, pero nuevamente, esto no es universal. Besu tiene sus propios métodos txpool_besu* para el historial de transacciones, pero son específicos de Besu. Siempre consulta la documentación de tu cliente.

• txpool_content: objetos de transacción completos, agrupados por dirección y nonce.
• txpool_inspect: resumen con estimaciones de precio de gas y valor.
• txpool_status: conteos de pendientes y en cola.
• Extensiones como txpool_contentFrom y txpool_besu* son específicas del cliente.

Por qué los proveedores alojados suelen ocultar el mempool

Si estás utilizando un servicio RPC alojado como el servicio API de OnFinality, puedes encontrar que los métodos txpool_* devuelven un error como the method txpool_content does not exist/is not available. Esto no es un error; es una decisión de diseño deliberada. Los proveedores operan infraestructura compartida donde muchos usuarios envían transacciones a través de los mismos nodos. Exponer el pool local revelaría transacciones pendientes de todos los usuarios, creando riesgos de privacidad y permitiendo el front-running. Además, servir el contenido completo del pool a cada solicitud sería intensivo en recursos.

La arquitectura del nodo de Ethereum en sí no requiere un mempool global. Cada nodo valida y almacena transacciones pendientes de forma independiente. Cuando envías una transacción a un proveedor, se transmite a la red, pero el nodo del proveedor solo mantiene una copia local. Otros nodos pueden tenerla en sus pools, pero no puedes consultarlos directamente a menos que ejecutes tu propio nodo.

Por lo tanto, si tu integración depende de inspeccionar el mempool, tienes dos caminos realistas: ejecutar tu propio nodo completo (o un nodo ligero que soporte el espacio de nombres) y consultarlo directamente, o usar métodos alternativos que no dependan del pool local. Para la mayoría de los casos de uso, como verificar si una transacción fue aceptada, eth_getTransactionByHash y el sondeo de recibos son más confiables porque consultan el estado de la cadena canónica, no una caché local.

• Los proveedores alojados a menudo deshabilitan txpool_* por razones de privacidad y recursos.
• El pool es local, por lo que incluso si un proveedor lo expusiera, solo mostraría la vista de ese proveedor.
• Para el estado de las transacciones, usa eth_getTransactionByHash y el sondeo de recibos.
• Ejecutar tu propio nodo es la única forma de obtener acceso completo a txpool_*.

Casos de uso prácticos y cómo abordarlos

Las consultas de búsqueda que llevan a este artículo a menudo provienen de desarrolladores que intentan responder una de tres preguntas: '¿Mi transacción ya está en el pool?', '¿Qué tan congestionada está la red?' y '¿Estoy expuesto al front-running?'. Abordemos cada una.

¿Mi transacción está en el pool? Si enviaste una transacción a través de un proveedor, el nodo del proveedor puede tenerla en su pool local, pero generalmente no puedes consultar ese pool. En su lugar, usa eth_getTransactionByHash con el hash de tu transacción. Si la transacción aún está pendiente, este método devuelve el objeto de transacción; si ha sido minada, devuelve la transacción con un hash de bloque; si no se encuentra, puede haber sido descartada o nunca aceptada. El sondeo de un recibo es la forma definitiva de saber si fue minada.

Analizando la competencia de gas. Si ejecutas tu propio nodo, txpool_content o txpool_inspect pueden mostrarte las transacciones pendientes y sus precios de gas. Esto te ayuda a estimar el precio mínimo de gas necesario para ser incluido en el próximo bloque. Sin embargo, recuerda que esta es solo la vista de tu nodo; otros nodos pueden tener transacciones diferentes.

Exposición al front-running. El mempool público es un vector conocido para ataques de front-running y sandwich. Si estás construyendo una aplicación sensible al orden (por ejemplo, un intercambio en DEX), debes asumir que tu transacción es visible para cualquiera que monitoree el pool. Usar un relé de transacciones privado (como Flashbots) es un canal separado que evita el pool público, pero no es un respaldo de OnFinality; es una herramienta que puedes evaluar para tu caso de uso.

• Para el estado de las transacciones, usa eth_getTransactionByHash y el sondeo de recibos.
• Para el análisis de gas, txpool_inspect da un resumen rápido.
• Las transacciones del mempool público son visibles para todos; considera relés privados para flujos sensibles.
• Nunca asumas que un proveedor alojado expone el pool.

Ejecutando métodos txpool contra tu propio nodo

Para usar el espacio de nombres txpool, necesitas acceso a un nodo que lo exponga. Esto es típicamente un nodo completo autogestionado con el espacio de nombres habilitado. Los siguientes ejemplos con curl asumen que tienes un endpoint en http://localhost:8545. Reemplaza la URL con la dirección de tu nodo.

Primero, verifica el estado del pool:

curl -X POST http://localhost:8545 \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"txpool_status","params":[],"id":1}'

# Respuesta esperada (los valores varían)
{"jsonrpc":"2.0","id":1,"result":{"pending":"12","queued":"3"}}

Ejemplo: Inspeccionando transacciones pendientes

Para ver un resumen de las transacciones pendientes, usa txpool_inspect. La salida es un mapa de direcciones a nonces, cada uno con una cadena que describe el valor y el gas de la transacción. Aquí hay un ejemplo:

curl -X POST http://localhost:8545 \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"txpool_inspect","params":[],"id":1}'

# Respuesta esperada (truncada)
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "pending": {
      "0x...address1": {
        "0": "0x...to: 1000000000000 wei + 50000 gas × 20000000000 wei"
      }
    },
    "queued": {}
  }
}

Ejemplo: Contenido completo de la transacción

Para los objetos de transacción completos, usa txpool_content. Esto devuelve los datos completos de la transacción, incluyendo from, to, gas, gasPrice, value e input. La respuesta puede ser grande, así que ten cuidado al usarla en un nodo ocupado.

curl -X POST http://localhost:8545 \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"txpool_content","params":[],"id":1}'

# Respuesta esperada (truncada)
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "pending": {
      "0x...address1": {
        "0": {
          "hash": "0x...",
          "nonce": "0x0",
          "from": "0x...",
          "to": "0x...",
          "value": "0xde0b6b3a7640000",
          "gas": "0x5208",
          "gasPrice": "0x4a817c800",
          "input": "0x"
        }
      }
    },
    "queued": {}
  }
}

Interpretando los resultados: Una tabla para completar

Cuando ejecutes estos métodos, registra tus observaciones en una tabla como la siguiente. Esto te ayuda a entender el estado del pool de tu nodo en un momento dado. Los valores no son puntos de referencia; son instantáneas que varían según las condiciones de la red y la configuración del nodo.

• Conteo de pendientes: número de transacciones listas para inclusión.
• Conteo en cola: transacciones con huecos de nonce u otros problemas.
• Precio de gas más alto en pendientes: indica el umbral competitivo actual.
• Precio de gas más bajo en pendientes: muestra el mínimo para ser incluido pronto.
• Número de remitentes únicos: ayuda a evaluar si el pool está dominado por pocas direcciones.

Solución de problemas: ¿Por qué mi transacción no está en el pool?

Si envías una transacción y no aparece en el pool (o no puedes verla), revisa esta lista de verificación. El problema a menudo no es el pool en sí, sino la validez de la transacción o el comportamiento de tu proveedor.

1. Verifica si la transacción fue aceptada. Usa eth_getTransactionByHash. Si devuelve null, la transacción no está en el pool del nodo y puede haber sido rechazada. Si devuelve un objeto de transacción, está pendiente o minada.

2. Verifica errores de nonce. Una razón común para el rechazo es un nonce demasiado bajo (ya usado) o demasiado alto (hueco). Usa eth_getTransactionCount con el parámetro de bloque pending para ver el próximo nonce esperado para tu dirección. Consulta nuestra guía sobre gestión de nonce EVM y eth_getTransactionCount para más detalles.

3. Verifica el precio del gas. Si tu precio de gas es demasiado bajo, la transacción puede quedarse atascada en el pool o ser descartada por nodos que eliminan transacciones de baja tarifa. Geth, por ejemplo, tiene un límite de precio predeterminado y eliminará transacciones por debajo de él. El comportamiento exacto está documentado en el código fuente del cliente.

4. Verifica los límites del pool. Geth limita el número de transacciones en cola por cuenta (predeterminado 64) y el número total de transacciones en cola (predeterminado 1024). Si excedes estos límites, tu transacción puede ser rechazada. Estos son valores predeterminados documentados; consulta la documentación de tu cliente para los valores actuales.

5. Considera el comportamiento del proveedor. Si estás usando un proveedor alojado, es posible que no transmitan tu transacción a la red inmediatamente, o que tengan sus propias reglas de validación. Siempre consulta la documentación del proveedor para cualquier restricción.

• Usa eth_getTransactionByHash para confirmar la aceptación.
• Verifica tu nonce con eth_getTransactionCount.
• Asegúrate de que tu precio de gas esté por encima del mínimo del nodo.
• Ten en cuenta los límites por cuenta y totales del pool.
• Los proveedores alojados pueden tener restricciones adicionales.

Limitaciones, privacidad y consideraciones de seguridad

El mempool público es un arma de doble filo. Por un lado, proporciona transparencia y permite que cualquiera vea las transacciones pendientes. Por otro lado, expone tus intenciones antes de que se finalicen. Si estás intercambiando grandes cantidades o ejecutando arbitraje, tu transacción puede ser objeto de front-running por bots que monitorean el pool. Este es un problema bien conocido en DeFi.

Para mitigar esto, algunos desarrolladores usan relés de transacciones privados que envían transacciones directamente a mineros o validadores, evitando el pool público. Flashbots es uno de esos servicios, pero hay otros. OnFinality no respalda ningún servicio específico; debes evaluar las compensaciones tú mismo.

Otra limitación es que el mempool no es una fuente confiable de verdad. Debido a que es local al nodo, no puedes conocer el estado global de las transacciones pendientes. Una transacción puede estar en el pool de un nodo pero no en el de otro, y puede ser minada antes de que siquiera la veas. Por lo tanto, no construyas lógica crítica asumiendo que el pool refleja toda la red.

Finalmente, ten en cuenta que algunos nodos pueden no implementar el espacio de nombres txpool en absoluto, o pueden restringirlo a conexiones locales por seguridad. Siempre prueba el método en tu endpoint objetivo antes de depender de él.

• Las transacciones del mempool público son visibles para todos; los flujos sensibles deben considerar relés privados.
• El pool es local al nodo, por lo que no es una vista global.
• Algunos nodos deshabilitan el espacio de nombres por seguridad.
• Siempre prueba la disponibilidad del método antes de construir sobre él.

Próximos pasos y lecturas adicionales

Entender el mempool es solo una pieza del dominio de RPC de Ethereum. Para construir aplicaciones robustas, también debes entender cómo elegir el nodo adecuado para tus necesidades. Nuestra guía Cómo elegir un nodo RPC de Ethereum (Asistente RPC) explica las diferencias entre nodos completos, de archivo y ligeros, y cómo afectan tu acceso a métodos como txpool_*.

Si estás lidiando con problemas del ciclo de vida de las transacciones, revisa nuestras guías sobre tiempos de espera y reintentos de RPC de Ethereum y manejo de desconexiones de WebSocket de Ethereum. Estos son puntos de dolor comunes al enviar transacciones y monitorear su estado.

Para una perspectiva más amplia sobre las interacciones con la red Ethereum, consulta el centro de aprendizaje de OnFinality y la página de la red Ethereum. Si estás evaluando proveedores RPC, nuestra página de precios de RPC puede ayudarte a entender las estructuras de costos, y la documentación del servicio API describe lo que ofrece OnFinality.

Finalmente, si estás monitoreando tu propio nodo, nuestra guía sobre monitoreo de endpoints RPC y salud del nodo proporciona consejos prácticos para mantener tu infraestructura confiable.

• Aprende sobre los tipos de nodos y sus capacidades.
• Comprende el manejo de tiempos de espera y WebSocket para aplicaciones robustas.
• Explora el centro de aprendizaje de OnFinality para más guías.
• Revisa los detalles de precios y servicios API si estás considerando un proveedor.