--- id: 11 title: "Por qué una EVM de un solo hilo limita el TPS: historia de la congestión y el modelo de ejecución" slug: evm-single-thread-bottleneck date: 2026/08/22 summary: Los grandes episodios de congestión de Ethereum comparten una misma raíz de diseño: la EVM ejecuta las transacciones una por una. Este artículo explica por qué subir el límite de gas y EIP-1559 no pueden reescribir ese modelo de ejecución, y cómo el retraso de confirmación amplifica el techo del hilo único. keywords: EVM de un solo hilo,techo de TPS,congestión de gas,EIP-1559,latencia de confirmación heroImage: /images/community-bg.png --- En los debates públicos sobre rendimiento de cadenas, el TPS suele tratarse como la única vara de medir. Pregunte por qué la mainnet de Ethereum se ha quedado mucho tiempo en los primeros números de la decena de transacciones por segundo en condiciones cotidianas, y la respuesta rara vez es «falta hardware». Es el modelo de ejecución mismo: la máquina virtual de Ethereum está diseñada para terminar una transacción antes de empezar la siguiente. Esa restricción compra la reproducción determinista en toda la red, y clava el rendimiento a un límite físico de un solo hilo. Entender ese límite importa más que memorizar cualquier cifra instantánea de TPS. Los artículos posteriores cubren el mapa de escalabilidad, los caminos de ejecución paralela y el control de concurrencia optimista. Este artículo fija primero el problema: por qué una EVM de un solo hilo limita el TPS, cómo la congestión histórica lo confirmó una y otra vez y por qué ni un límite de gas más alto ni EIP-1559 arreglan el modelo de ejecución. ## La ejecución serial no es un error: es el precio del determinismo La semántica de la EVM exige que las transacciones de un bloque corran en orden canónico. Solo después de que terminan las escrituras de estado de una transacción puede la siguiente empezar a leer estado. La ventaja es inmediata: cualquier nodo honesto que reproduzca la misma secuencia alcanza la misma raíz de estado. El consenso solo necesita acuerdo sobre el orden de las transacciones y el contenido de los bloques, no sobre cómo debería resolver las escrituras un entrelazado paralelo. El costo es igual de directo. Los servidores modernos exponen decenas de núcleos lógicos, y aun así un nodo de EVM clásico se comporta en la ruta crítica más o menos como «un núcleo trabaja mientras los demás miran». Dos transferencias sin relación —A paga a B, C paga a D— no pueden avanzar juntas bajo el modelo serial, porque el planificador asume que cualquier transacción puede tocar cualquier rincón del árbol de estado global. El árbol de Merkle Patricia cuelga las cuentas y los slots de almacenamiento de una única estructura enorme, lo que refuerza la costumbre de ingeniería de rechazar el paralelismo sin información previa de dependencias. La brecha estructural es la consecuencia: el ancho de banda y la E/S de disco pueden escalar en vertical, mientras el rendimiento de ejecución se queda atascado en «una por vez». Cuando la demanda se mantiene bajo ese techo duro, los usuarios apenas lo notan. Cuando la cruza, las transacciones sobrantes se encolan en el mempool y el mercado de comisiones toma el control: la definición técnica de congestión. ## Congestión histórica: la misma enfermedad, síntomas distintos CryptoKitties en 2017 fue el primer episodio de congestión a gran escala ampliamente documentado. En su pico, el juego de gatos ocupó una porción sustancial de las transacciones en cadena, la cola pendiente se infló, las transferencias ordinarias pasaron de segundos a horas y los precios del gas se empujaron a los cientos de gwei. Los análisis posteriores solían culpar a «un juego que se hizo demasiado popular». Con más precisión: una aplicación caliente solo dejó al descubierto un techo de capacidad que ya existía. El guion se repitió. Durante la densa composabilidad DeFi de 2020–2021, el gas se mantuvo elevado durante largos tramos. Durante acuñaciones de NFT estilo escritura de tierras como Otherside en 2022, breves guerras de pujas llevaron las comisiones a extremos, incluidos casos en los que a transferencias diminutas se les cotizaron comisiones astronómicas. Los detonantes cambiaron —juegos, yield farming, fiebre de NFT—, pero la lógica de encolamiento no: el motor de ejecución solo puede digerir cierta cantidad de «cómputo útil» por segundo, y el exceso de demanda se raciona con pujas más altas que desplazan a las transacciones más baratas. Estos episodios también mostraron cómo las subastas de gas por prioridad amplifican el dolor. Bajo el modelo temprano de primer precio, las oportunidades escasas (cupos de acuñación, ventanas de arbitraje) desataban pujas en cascada que elevaban los niveles de comisión en toda la red, de modo que los usuarios ordinarios pagaban por el hotspot de otro. La congestión no es solo «lenta»: es «cara», y el gasto a menudo empuja a los usuarios marginales fuera de cadena antes de lo que la latencia por sí sola lo haría. ## Límites de gas: ensanchar un carril, no agregar carriles La comunidad de Ethereum ha subido repetidamente el límite de gas por bloque para exprimir más capacidad. Un límite más alto permite que cada bloque cargue más cómputo, así que el TPS puede subir a corto plazo. Eso sigue ocurriendo dentro de la ejecución serial: se ensancha un solo carril en lugar de convertir la autopista en carriles paralelos. El camino tiene rendimientos decrecientes claros y costos externos. Cuanto más alto el límite de gas, más cambios de estado deben ejecutar, verificar y almacenar los nodos completos por unidad de tiempo; los requisitos de sincronización y hardware suben con él. Tratar la «escalabilidad» como «subir el límite de gas para siempre» acaba empujando la validación descentralizada más allá de lo que pueden correr los operadores ordinarios. Ajustar el límite de gas es una perilla operativa útil, no un sustituto del modelo de ejecución. Responde «cuánto más trabajo meter bajo una restricción de un solo hilo», no «cómo avanzar muchas transacciones sin conflicto a la vez». Las cifras de TPS de Ethereum de los monitores públicos —una decena en condiciones diarias, picos cortos más altos, un techo teórico aún más alto— pertenecen al mismo marco. Los decimales exactos cambian con el tiempo y las ventanas de medición; lo que importa es el orden de magnitud: el modelo de un solo hilo fija el techo en un rango que se siente estrecho para una narrativa de «capa de liquidación global», y la operación cotidiana suele quedar varias veces por debajo de los picos teóricos. ## EIP-1559: formación de comisiones, no ancho de ejecución EIP-1559, vigente desde 2021, rediseñó el mercado de comisiones. Una comisión base se ajusta con la utilización del bloque y se quema; los usuarios agregan una comisión de prioridad para una inclusión más rápida. Entre las motivaciones de la investigación estaban reducir el sobrepago sistemático bajo subastas de primer precio, amortiguar los vaivenes salvajes de cotización dentro del bloque y recortar la capacidad de mineros y validadores de extraer de la propia comisión base. En la práctica, EIP-1559 mejoró la previsibilidad de las comisiones y alivió el «pujar siempre como si hubiera congestión». Nunca prometió elevar el rendimiento físico de la ejecución serial. Cuando los bloques siguen llenos, la comisión base sube y exprime el exceso de demanda fuera del mercado: descubrimiento de precios, no ampliación de capacidad. Leer EIP-1559 como una «solución de escalabilidad» es un error común; una etiqueta mejor es «encolamiento y precios más limpios bajo capacidad de ejecución fija». Las comisiones de prioridad y los mecanismos posteriores relacionados con el MEV también tratan de cómo se ordenan las transacciones y de cómo se captura el valor del ordenamiento, siempre asumiendo que la etapa de ejecución termina de forma serial. Ninguna sofisticación de la capa de ordenamiento elimina el techo duro mientras la ejecución digiere una transacción por vez. ## Retraso de confirmación: el eje que el TPS esconde El TPS pregunta cuántas transacciones terminan por unidad de tiempo; el retraso de confirmación pregunta cuánto espera un usuario desde la difusión hasta que el resultado es «lo bastante confiable como para ser irreversible». Se correlacionan, pero no son equivalentes. El TPS promedio puede verse aceptable mientras el atraso del mempool todavía estira la espera de una sola transacción más allá de lo que tolera el producto. Ethereum además superpone semánticas de confirmación del consenso: intervalo de bloque, gadgets de finalidad, riesgo de reorganización, todo entra en la «confirmación» tal como la experimentan los usuarios. Cuando la capa de ejecución se congestiona, las transacciones pueden quedarse pendientes; los tiempos de espera de las aplicaciones, las ventanas de los puentes y el riesgo de inventario de los creadores de mercado se amplifican juntos. Para pagos e interacción de alta frecuencia, los picos de latencia suelen dañar más a los productos que el TPS medio. El cuadro completo del cuello de botella de un solo hilo es, por tanto: el techo de rendimiento decide cuánto puede absorber el sistema; el encolamiento y las comisiones deciden quién entra; el retraso de confirmación decide cuánto tarda ese «entrar». La misma raíz —ancho de ejecución insuficiente— y síntomas distintos. Cualquier afirmación de «escalabilidad» debería puntuarse en cada eje por separado. ## Conclusión: lo que hay que cambiar es el modelo de ejecución Ponga lado a lado la congestión histórica, las subidas del límite de gas y EIP-1559, y la conclusión se afila: los mercados de comisiones y los parámetros de bloque administran la escasez; no eliminan su causa. Mientras la EVM conserve la forma clásica de estado global más ejecución serial una por una, el TPS tiene un techo duro, y las aplicaciones calientes arrastrarán periódicamente a toda la red hacia comisiones y latencias altas. Romper ese techo replantea el problema: ¿cómo pueden correr en paralelo las transacciones sin conflicto mientras se mantiene un determinismo verificable? Las respuestas no son únicas: predeclaración determinista, control de concurrencia optimista, modelos de objetos y más. Los proyectos que aún quieren compatibilidad con el bytecode y las herramientas de Ethereum enfrentan un conjunto de opciones más estrecho. Esas preguntas pertenecen al mapa de escalabilidad y a los debates de caminos paralelos. Este artículo solo necesita la premisa: el objeto de una solución real es el modelo de ejecución, no otra vuelta de la perilla del gas. ## Lecturas relacionadas - Siguiente: ["Mapear la escalabilidad de la cadena de bloques: qué resuelve cada enfoque —paralelismo en L1, L2, sharding y disponibilidad de datos"](/es/blog/blockchain-scaling-map) - Relacionado: ["Tres caminos hacia la ejecución paralela: planificación determinista, OCC optimista y modelos de objetos"](/es/blog/parallel-execution-approaches), ["Glosario de métricas de rendimiento: TPS, BPS, latencia de confirmación, finalidad y tasa de conflicto"](/es/blog/performance-metrics-glossary)