Qué es lo que realmente sucede cuando envías una transacción de Ethereum
--> El Problema
Haces clic en “Enviar” en tu wallet. La interfaz confirma la transacción.
Pero luego... no pasa nada.
A veces se confirma en segundos.
A veces se queda colgado por minutos—o falla completamente.
¿Por qué?
La mayoría de las explicaciones se detienen en “va a la blockchain.”
Eso no es útil si estás construyendo sistemas en .
Desglosamos lo que realmente sucede detrás de las cámaras.
Modelo Mental (Orientación Rápida)
Una transacción no se ejecuta instantáneamente.
Se mueve a través de tres fases distintas:
Propagación (mempool)
Inclusión (propuesta de bloque)
Ejecución (transición de estado)
Cada fase introduce latencia, riesgo y modos de falla.
Paso 1: Creación de Transacción
Cuando presionas “enviar”:
Tu billetera construye una transacción:
a
valor
gasLimit
maxFeePerGas
datos (si hay interacciones con contratos)
Firma la transacción usando tu clave privada
En este punto:
👉 La transacción es válida pero aún no es conocida por la red
Paso 2: Difundir a la Red
Tu billetera envía la transacción a un nodo.
Ese nodo:
Verifica la firma
Verifica el nonce
Asegura validez básica
Si es válido → entra en el mempool
Paso 3: El Mempool (Donde las Cosas se Ponen Interesantes)
El mempool es:
Un área de espera temporal
No es globalmente consistente
Diferente entre nodos
Esto significa:
👉 Tu transacción puede existir en algunos nodos—pero no en otros
Comportamiento clave:
Los nodos priorizan transacciones por tarifa
Mayor maxFeePerGas = mayor prioridad
📊 Diagrama 1: Flujo de Propagación de Transacciones
El diagrama debería mostrar:
Billetera de usuario → Nodo A → Nodo B → Nodo C
Cada nodo tiene su propio mempool
Flechas que muestran la propagación de gossip
Destacar: “No todos los mempools son idénticos”
Paso 4: Propuesta de Bloque
Los validadores seleccionan transacciones de su mempool.
Ellos eligen:
Transacciones con tarifas más altas primero
Transacciones que se ajustan a los límites de gas
Importante:
👉 Tu transacción está compitiendo con otras
Paso 5: Ejecución (Nivel EVM)
Una vez incluida en un bloque
La transacción se ejecuta dentro del EVM
Los cambios de estado ocurren:
Actualizaciones de saldo
Cambios en el almacenamiento del contrato inteligente
Si la ejecución falla:
El gas aún se consume
Los cambios de estado se revierten
📊 Diagrama 2: Flujo de Ejecución
El diagrama debería mostrar:
Bloque → EVM → Transición de Estado
Entradas:
Transacción
Estado actual
Salida:
Nuevo estado
Incluir “consumo de gas” en cada paso
Casos Extremosos & Modos de Falla
Aquí es donde la mayoría de los artículos fallan. Vamos más profundo.
❌ 1. Transacción Atascada en el Mempool
Tarifa demasiado baja
Nunca seleccionada por los validadores
❌ 2. Transacción Eliminada
El nodo lo elimina debido a:
Tarifa baja
Desbordamiento de mempool
❌ 3. Transacción Reemplazada
Mismo nonce + tarifa más alta → reemplaza el original
❌ 4. Ejecución Fuera de Gas
La ejecución se detiene a mitad de camino
El estado se revierte
Gas perdido
❌ 5. Reorganización de Cadena (Reorg)
El bloque es reemplazado
La transacción puede desaparecer temporalmente
Implicaciones en el mundo real
Para Desarrolladores:
No puedes asumir finalización instantánea
Debes manejar estados pendientes
Para UX:
Los usuarios ven “pendiente” → confusión
La estimación de tarifas se vuelve crítica
Para Diseños de Sistemas
La lógica de reintento es necesaria
El monitoreo de transacciones es obligatorio
Puntos Clave
Una transacción es un proceso de múltiples etapas, no un solo evento
El mempool es no determinístico y fragmentado
Las tarifas impactan directamente la probabilidad de ejecución
El fallo puede ocurrir en múltiples capas
Los sistemas deben ser diseñados paraincertidumbre y retraso
Si estás construyendo en Ethereum, entender este pipeline no es opcional—es fundamental$ETH