Análisis post-mortem del problema de archivo estatal

El 9 de octubre de 2025 (UTC), Stellar Development Foundation (SDF) identificó un problema en la red pública relacionado con una nueva característica llamada “Priorización del Estado Activo de Soroban”. Esta característica, introducida en el Protocolo Whisk 23 (P23), tenía como objetivo mejorar cómo la red maneja y almacena datos. Sin embargo, un error en esta característica comenzó a corromper ciertas entradas de datos desde el 4 de septiembre de 2025, y permaneció sin detectarse durante 35 días.

La Fundación trabajó rápidamente con las partes afectadas y los validadores para contener (para el 10 de octubre de 2025) y resolver (para el 23 de octubre de 2025).

En total, 478 entradas de datos fueron originalmente corrompidas, pero la mayoría de ellas pudieron ser reparadas a su valor esperado. Después de las correcciones, solo 84 permanecieron corruptas y se tuvieron que tomar mitigaciones por parte de protocolos y emisores.

La causa raíz del incidente fue un error en la manera en que la red gestionaba la transición de entradas de datos entre diferentes áreas de almacenamiento. La característica se describe con más detalle en “Priorización del Estado Activo de Soroban” que introduce un novedoso almacenamiento de libro mayor de dos niveles que ayuda a desbloquear innovación no vista en otras cadenas.

Para hacer esto más claro, aquí hay explicaciones breves de términos clave:

• Estado del libro mayor “Activo” (área de almacenamiento de trabajo): este es el espacio principal de almacenamiento que representa todos los estados que pueden ser accedidos y modificados directamente por las transacciones.
• “Archivo-caliente” (área de almacenamiento de respaldo): esto es como un espacio secundario de almacenamiento donde se guarda datos menos activos, liberando espacio en el área principal para trabajos más urgentes.
• Lista de Cubos (historial de datos estructurado): cada área de almacenamiento está organizada como Listas de Cubos. Una Lista de Cubos es una manera estructurada para que el sistema organice todos los datos históricos, similar a un archivador por niveles. Cada “nivel” contiene registros de diferentes períodos, ayudando al sistema a llevar un registro de los cambios a lo largo del tiempo.
• Desalojo (mover datos del estado “activo” al “archivo-caliente”): cuando la red decide que ciertas piezas de datos no se están usando frecuentemente, las mueve del área principal de trabajo (estado “activo”) a un área de almacenamiento de respaldo llamada “archivo-caliente”.
• Restauración (mover datos del “archivo-caliente” al estado “activo”): cuando los usuarios necesitan usar datos que previamente fueron desalojados, invocan un proceso de restauración que mueve los datos de vuelta al estado “activo”.
• TTL (Tiempo de Vida) (cuánto tiempo los datos permanecen válidos): Esta configuración determina cuánto tiempo una pieza de datos debe permanecer activa antes de que se considere expirada y elegible para ser removida o archivada.
• Entradas Persistentes y Temporales: Las entradas persistentes son aquellas que se mueven entre esas diferentes áreas de almacenamiento, las entradas temporales simplemente se eliminan en lugar de ser movidas al “Archivo-caliente” al ser desalojadas.

El error ocurrió durante el “desalojo”: en lugar de mover la versión más actualizada de cada entrada persistente, el sistema a veces movía una copia desactualizada (como guardar un borrador viejo en lugar del último). Cuando estas entradas desactualizadas fueron luego restauradas, la red terminó operando con información inconsistente.

Descripción del Error

Durante el escaneo de desalojo al aplicar libros mayores, el sistema generó una lista de candidatos para el “archivo-caliente” incluyendo su valor. El problema fue que estos candidatos eran entradas encontradas durante el escaneo de la Lista de Cubos en niveles arbitrarios que representan diferentes puntos en el tiempo. Para usar la analogía anterior, a veces eran sacados de la capa incorrecta del archivador por niveles. Aunque el código verificaba correctamente la expiración cargando el último valor de Tiempo de Vida (TTL), fallaba en cargar la última versión de la entrada misma si había una, llevando a registrar un valor desactualizado en el “archivo-caliente”.

Nota que antes de Whisk (P23), este mecanismo no era un problema porque el desalojo se hacía dentro del estado activo, y para eso solo necesitábamos el valor TTL actualizado: las temporales serían eliminadas, y las entradas persistentes simplemente permanecerían intactas en el libro mayor.

La solución

La solución es que cada candidato a desalojo cargue la última versión de la entrada desde la instantánea de la Lista de Cubos.

Cómo llegamos ahí

• 24-08-2023 : Implementación inicial de desalojo (CAP-0046-12 incluido en la liberación original del contrato inteligente de Stellar Soroban).
  • https://github.com/stellar/stellar-core/pull/3874.
  • Esta implementación inicial no tenía el error.
  • El escaneo de desalojo inicial verificó que tanto el TTL como la entrada de código/datos estuvieran actualizados.
  • Las entradas temporales expiradas fueron eliminadas (el único cambio en alcance), las entradas persistentes se dejaron intactas.
• 25-04-2024: Verificación de datos/entrada eliminada por rendimiento
  • https://github.com/stellar/stellar-core/pull/4191.
  • En ese momento, el escaneo aún era correcto para desalojos temporales, ya que la versión de las entradas temporales desalojadas no importaba ya que se eliminarían de todos modos.
• 01-06-2025: Error introducido oficialmente con el desalojo persistente (implementación de CAP-0062 )
  • https://github.com/stellar/stellar-core/pull/4585.
  • Desalojo persistente adaptado pero verificación de versión de entrada de código/datos no agregada.
  • El cambio fue clasificado como de bajo riesgo porque parecía quirúrgico – no se trataba de lo que cambió sino también de lo que no cambió. Como consecuencia, solo tuvo un revisor, en contraste con muchos otros cambios en P23 que recibieron el nivel adecuado de escrutinio.
• 13-06-2025: Prueba incorrecta introducida para múltiples versiones de clave en “archivo-caliente”
  • https://github.com/stellar/stellar-core/pull/4773.
  • Una prueba incluyó múltiples versiones de una entrada en la Lista de Cubos, pero no verificó realmente el contenido de la entrada restaurada.
  • Otra prueba también debería haber cubierto este caso, “entradas en sombra no desalojadas”, pero no se actualizó para el caso de entrada persistente.
• 07-08-2025: 23.0.0 estable conteniendo el error se publica.
• 21-08-2025: auditoría de seguridad de P23 completada, sin hallazgos relacionados con el archivo de estado, despejando P23 para producción.
• 03-09-2025: P23 votó en la red pública.

Pasamos tiempo con el equipo interno, desarrolladores externos y socios para discutir áreas de mejora que comenzamos a implementar de inmediato, incluyendo:

• Monitoreo y Detección: El equipo que trabaja en la capa del protocolo central asegurará que los invariantes se implementen correctamente para inclinarse hacia la seguridad sobre la disponibilidad siempre que sea posible. SDF luego trabajará con el ecosistema para habilitar verificaciones de invariantes específicas para protocolos y emisores que pueden no ser detectables en la capa central. Esto requerirá asegurar que existan capacidades, y se utilicen para proporcionar tanta redundancia como sea posible cuando se trata de monitorear partes críticas del ecosistema.
• Coordinación y Gobernanza de Validadores: Hay una oportunidad para trabajar con los validadores para tener la información y las herramientas necesarias para alinearse en un plan para estar mejor preparados para emergencias.

Para fortalecer aún más nuestra red y procesos, estamos implementando estrategias específicas:

• Desacoplar el Trabajo Arriesgado y Sensible al Tiempo: Las características de alto riesgo se desarrollarán y validarán por separado de las actualizaciones urgentes para evitar problemas derivados de cambios complejos.
• Asegurar que el Código Crítico para la Misión Sea Identificado Como Tal: Nos aseguraremos de que el código crítico para la misión sea identificado como tal en el momento del diseño y revisión y pase por una lista de verificación sistemática de calidad del código durante la revisión del código. Esto incluye hacer un uso adecuado de las abstracciones, reducir la complejidad del código y tener invariantes de código adecuados.
• Mejorar las Pruebas y Validación: Similar a los estándares de codificación, nos aseguraremos de que el tipo de técnicas de prueba desplegadas contra áreas específicas de alto riesgo sea adecuado. Ya hacemos uso de muchas formas de técnica desde la verificación formal hasta las pruebas de propiedades y el fuzzing. Nos aseguraremos de que al menos una de estas se despliegue en componentes críticos.
• Habilitar Empresas de Auditoría de Seguridad: Reconsideraremos cómo nos involucramos y colaboramos con las Empresas de Auditoría de Seguridad para aprovechar su fortaleza. Si bien la revisión de código tiene sus méritos, podemos hacer más para ayudar a esas empresas a entender mejor el código y escribir mejor automatización para que el código se mantenga resiliente a largo plazo.

Al abrazar estas mejoras, SDF reafirma nuestro compromiso con la transparencia, la fiabilidad y la colaboración continua con todas las partes interesadas en apoyo de la red Stellar.