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 en Vivo 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 tan temprano como 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 corrompidas y se tuvieron que tomar mitigaciones por parte de los protocolos y emisores.

La causa raíz del incidente fue un error en la forma 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 en Vivo 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 de libro mayor “en vivo” (á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 de almacenamiento secundario donde se mantienen datos menos activos, liberando espacio en el área principal para trabajos más urgentes.
• Lista de Cubos (historial de datos estructurados): cada área de almacenamiento está organizada como Listas de Cubos. Una Lista de Cubos es una forma estructurada para que el sistema organice todos los datos históricos, similar a un archivador en capas. Cada “nivel” contiene registros de diferentes períodos, ayudando al sistema a rastrear cambios a lo largo del tiempo.
• Evicción (mover datos del estado “en vivo” al “archivo-caliente”): cuando la red decide que ciertas piezas de datos no se están utilizando frecuentemente, los mueve del área principal de trabajo (estado “en vivo”) a un área de almacenamiento de respaldo llamada “archivo-caliente”.
• Restauración (mover datos del “archivo-caliente” al estado “en vivo”): cuando los usuarios necesitan usar datos que fueron previamente evadidos, invocan un proceso de restauración que mueve los datos de vuelta al estado “en vivo”.
• TTL (Tiempo de Vida) (cuánto tiempo permanecen válidos los datos): Esta configuración determina cuánto tiempo debe permanecer activa una pieza de datos antes de que se considere expirada y elegible para eliminación o archivado.
• 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 moverse al “Archivo-caliente” en la evicción.

El error ocurrió durante la “evicción”: 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 se restauraban más tarde, la red terminaba operando con información inconsistente.

Descripción del Error

Durante el escaneo de evicción 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 retomar la analogía anterior, a veces se sacaban de la capa incorrecta del archivador en capas. Mientras 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 la evicción se hacía dentro del estado en vivo, y para eso solo necesitábamos el valor de 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 evicción cargue la última versión de la entrada desde la instantánea de la Lista de Cubos.

Cómo llegamos allí

• 2023-24-08 : Implementación inicial de evicción (CAP-0046-12 incluido en el lanzamiento original del contrato inteligente Soroban de Stellar).
  • https://github.com/stellar/stellar-core/pull/3874.
  • Esta implementación inicial no tenía el error.
  • El escaneo de evicción 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.
• 2024-25-04: Verificación de datos/entrada eliminada por rendimiento
  • https://github.com/stellar/stellar-core/pull/4191.
  • En ese momento, el escaneo todavía era correcto para las evicciones temporales, ya que la versión de las entradas temporales evadidas no importaba ya que se eliminarían de todos modos.
• 2025-01-06: Error introducido oficialmente con la evicción persistente (implementación de CAP-0062 )
  • https://github.com/stellar/stellar-core/pull/4585.
  • Evicción persistente adaptada pero no se añadió verificación de versión de entrada de código/datos.
  • El cambio se clasificó como de bajo riesgo porque parecía quirúrgico – no se trataba solo 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 obtuvieron el nivel adecuado de escrutinio.
• 2025-13-06: Mal test introducido para múltiples versiones de clave en “archivo-caliente”
  • https://github.com/stellar/stellar-core/pull/4773.
  • Un test incluyó múltiples versiones de una entrada en la Lista de Cubos, pero en realidad no verificó el contenido de la entrada restaurada.
  • Otro test también debería haber cubierto este caso, “entradas sombreadas no evadidas”, pero no se actualizó para el caso de entrada persistente.
• 2025-08-07: 23.0.0 estable conteniendo el error se publica.
• 2025-08-21: auditoría de seguridad de P23 completada, sin hallazgos relacionados con el archivo de estado, despejando P23 para producción.
• 2025-09-03: P23 votado 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 priorizar 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 el testing de propiedades y fuzzing. Nos aseguraremos de que al menos una de estas se despliegue en componentes críticos.
• Habilitar Empresas de Auditoría de Seguridad: Repensaremos 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 permanezca resiliente a largo plazo.

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