Ethereum L2 network Starknet sufrió una caída en su red principal este lunes. Según el informe de análisis posterior publicado el 11 de enero, el incidente se originó por una inconsistencia de estado entre la capa de ejecución (blockifier) y la capa de prueba. En escenarios específicos de llamadas cruzadas entre funciones y combinaciones de rollback, la capa de ejecución registró incorrectamente un estado que ya había sido revertido, causando errores en la ejecución de transacciones. Aunque estas transacciones no obtuvieron confirmación final en L1, el evento activó una reorganización de bloques, y aproximadamente 18 minutos de actividad en la cadena fueron revertidos. Es importante destacar que esta es la segunda interrupción importante de Starknet desde 2025.
Detalles técnicos: “Desincronización” entre la capa de ejecución y la capa de prueba
Causas fundamentales del incidente
La causa técnica de esta caída es relativamente compleja. La arquitectura de Starknet involucra dos niveles clave: la capa de ejecución, que procesa la lógica de las transacciones, y la capa de prueba, que genera pruebas de conocimiento cero y las envía a la cadena principal de Ethereum. En este incidente, cuando se combinaron llamadas a funciones específicas y operaciones de rollback, la capa de ejecución (blockifier) registró incorrectamente un estado que debía ser revertido, provocando un conflicto de estado entre ambas capas.
La buena noticia es que la capa de prueba identificó correctamente el error y rechazó la transacción problemática, sin enviarla al libro mayor. Este mecanismo de “auto-corrección” evitó que el estado erróneo se consolidara en la cadena principal de Ethereum.
Por qué fue necesaria una reorganización
Debido a la desincronización entre la capa de ejecución y la capa de prueba, la red se vio obligada a realizar una reorganización de bloques para restaurar el estado normal. Esta reorganización provocó que aproximadamente 18 minutos de actividad en la red fueran revertidos, y los usuarios tuvieron que volver a enviar sus transacciones. Para transacciones no sensibles al tiempo, el impacto fue menor, pero para traders frecuentes o operaciones que requieren ejecución rápida (como liquidaciones de emergencia), esto pudo causar pérdidas reales.
Comparación histórica: aumento en la frecuencia de problemas
Fecha del incidente
Tipo de fallo
Duración de la caída
Tiempo de rollback
Causa raíz
Septiembre 2025
Vulnerabilidad del secuenciador
Más de 5 horas
Aproximadamente 1 hora
Error en la lógica del ordenamiento
Enero 2026
Inconsistencia de estado
Breve
Aproximadamente 18 minutos
Conflicto entre capa de ejecución y capa de prueba
Aunque esta vez el rollback fue más corto (18 minutos vs 1 hora), la frecuencia empieza a ser evidente. Desde septiembre hasta enero, Starknet ha experimentado dos interrupciones importantes en menos de medio año, con diferentes causas, lo que refleja riesgos potenciales en diferentes niveles del sistema.
Respuesta y compromiso del equipo
Acción inmediata
El equipo de Starknet, además de publicar el informe de análisis, hizo varias promesas:
Mejorar los procesos de prueba de código, especialmente en escenarios límite y complejos
Fortalecer las auditorías de código para prevenir problemas similares de inconsistencia de estado
Según información relacionada, Starknet planea lanzar la versión v0.14.1, que incluirá mejoras como actualización de funciones hash y bloques más rápidos
Estas medidas muestran un compromiso activo para mejorar la estabilidad del sistema, aunque aún queda por ver si serán efectivas para prevenir futuros fallos.
Impacto en el ecosistema
A nivel de usuario
El impacto real de este incidente fue relativamente limitado, ya que:
El tiempo de rollback fue corto (18 minutos), afectando un número reducido de transacciones
Las transacciones no obtuvieron confirmación final en L1, por lo que no se perdieron fondos realmente
Los usuarios solo tuvieron que volver a enviar sus transacciones, sin riesgo de pérdida de activos
A nivel del ecosistema
No obstante, desde una perspectiva más amplia, las interrupciones frecuentes representan un desafío para el desarrollo del ecosistema Starknet:
Disminuyen la confianza de los usuarios en la estabilidad de la red
Podrían afectar la voluntad de desplegar aplicaciones DeFi
En la competencia con otros proyectos L2 (como Arbitrum, Optimism), puede poner a Starknet en desventaja
Es importante señalar que, según información relacionada, Starknet está activamente expandiendo sus casos de uso, colaborando con Noon en la creación de BitcoinVault, y con proyectos como AlchemyPay. La capacidad del ecosistema para compensar los efectos negativos de la estabilidad será un factor a seguir.
Resumen
El incidente de caída de Starknet refleja los desafíos técnicos que enfrentan las redes L2 en escenarios complejos. Más que un grave fallo de seguridad, parece una insuficiencia en el manejo de condiciones límite. El mecanismo de “auto-corrección” de la capa de prueba evitó pérdidas de fondos, pero no se puede ignorar la recurrencia de interrupciones.
Lo crucial será si las mejoras del equipo serán efectivas. Fortalecer pruebas y auditorías es necesario, pero la verdadera solución dependerá del rendimiento de futuras versiones. Para los participantes del ecosistema, confiar en Starknet también implica monitorear su progreso en la mejora de la estabilidad.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Starknet se ha caído otra vez: la capa de ejecución y la capa de prueba están en conflicto, 18 minutos de actividad fueron revertidos
Ethereum L2 network Starknet sufrió una caída en su red principal este lunes. Según el informe de análisis posterior publicado el 11 de enero, el incidente se originó por una inconsistencia de estado entre la capa de ejecución (blockifier) y la capa de prueba. En escenarios específicos de llamadas cruzadas entre funciones y combinaciones de rollback, la capa de ejecución registró incorrectamente un estado que ya había sido revertido, causando errores en la ejecución de transacciones. Aunque estas transacciones no obtuvieron confirmación final en L1, el evento activó una reorganización de bloques, y aproximadamente 18 minutos de actividad en la cadena fueron revertidos. Es importante destacar que esta es la segunda interrupción importante de Starknet desde 2025.
Detalles técnicos: “Desincronización” entre la capa de ejecución y la capa de prueba
Causas fundamentales del incidente
La causa técnica de esta caída es relativamente compleja. La arquitectura de Starknet involucra dos niveles clave: la capa de ejecución, que procesa la lógica de las transacciones, y la capa de prueba, que genera pruebas de conocimiento cero y las envía a la cadena principal de Ethereum. En este incidente, cuando se combinaron llamadas a funciones específicas y operaciones de rollback, la capa de ejecución (blockifier) registró incorrectamente un estado que debía ser revertido, provocando un conflicto de estado entre ambas capas.
La buena noticia es que la capa de prueba identificó correctamente el error y rechazó la transacción problemática, sin enviarla al libro mayor. Este mecanismo de “auto-corrección” evitó que el estado erróneo se consolidara en la cadena principal de Ethereum.
Por qué fue necesaria una reorganización
Debido a la desincronización entre la capa de ejecución y la capa de prueba, la red se vio obligada a realizar una reorganización de bloques para restaurar el estado normal. Esta reorganización provocó que aproximadamente 18 minutos de actividad en la red fueran revertidos, y los usuarios tuvieron que volver a enviar sus transacciones. Para transacciones no sensibles al tiempo, el impacto fue menor, pero para traders frecuentes o operaciones que requieren ejecución rápida (como liquidaciones de emergencia), esto pudo causar pérdidas reales.
Comparación histórica: aumento en la frecuencia de problemas
Aunque esta vez el rollback fue más corto (18 minutos vs 1 hora), la frecuencia empieza a ser evidente. Desde septiembre hasta enero, Starknet ha experimentado dos interrupciones importantes en menos de medio año, con diferentes causas, lo que refleja riesgos potenciales en diferentes niveles del sistema.
Respuesta y compromiso del equipo
Acción inmediata
El equipo de Starknet, además de publicar el informe de análisis, hizo varias promesas:
Estas medidas muestran un compromiso activo para mejorar la estabilidad del sistema, aunque aún queda por ver si serán efectivas para prevenir futuros fallos.
Impacto en el ecosistema
A nivel de usuario
El impacto real de este incidente fue relativamente limitado, ya que:
A nivel del ecosistema
No obstante, desde una perspectiva más amplia, las interrupciones frecuentes representan un desafío para el desarrollo del ecosistema Starknet:
Es importante señalar que, según información relacionada, Starknet está activamente expandiendo sus casos de uso, colaborando con Noon en la creación de BitcoinVault, y con proyectos como AlchemyPay. La capacidad del ecosistema para compensar los efectos negativos de la estabilidad será un factor a seguir.
Resumen
El incidente de caída de Starknet refleja los desafíos técnicos que enfrentan las redes L2 en escenarios complejos. Más que un grave fallo de seguridad, parece una insuficiencia en el manejo de condiciones límite. El mecanismo de “auto-corrección” de la capa de prueba evitó pérdidas de fondos, pero no se puede ignorar la recurrencia de interrupciones.
Lo crucial será si las mejoras del equipo serán efectivas. Fortalecer pruebas y auditorías es necesario, pero la verdadera solución dependerá del rendimiento de futuras versiones. Para los participantes del ecosistema, confiar en Starknet también implica monitorear su progreso en la mejora de la estabilidad.