Abordando Inconsistencias en el Archivo de Estado: Votación de Actualización de Protocolo la Próxima Semana

El 9 de octubre, SDF descubrió un error en la primera característica de archivo de estado de su tipo de Stellar. La función de archivo de Stellar archiva el estado no utilizado para su posterior restauración. La característica soluciona el problema de escalabilidad de la blockchain al prevenir la inflación del estado y mantener bajas las tarifas. El error, encontrado en Whisk (Protocolo 23) al cual la red se actualizó el 3 de septiembre de 2025, resultó en que las entradas desactualizadas se archivaran y luego se restauraran incorrectamente, produciendo un estado que no coincidía con la historia canónica en cadena.

Una vez identificado, los equipos realizaron inmediatamente una evaluación y propusieron actualizar los ajustes de la red para pausar temporalmente la expulsión del estado archivado, o la eliminación de datos no utilizados del almacenamiento activo en la blockchain de Stellar. Los validadores de Nivel 1 votaron para aceptar el cambio, lo que previno la escritura adicional de entradas corruptas. El 10 de octubre, SDF lanzó una actualización de Stellar Core que bloqueaba todas las transacciones que intentaban leer o escribir valores de entradas corruptas, efectivamente poniendo en cuarentena el estado erróneo. En pocas horas, todos los validadores de Nivel-1 se actualizaron a esa versión de parche.

Para entender el alcance del impacto, SDF analizó y revisó lo que sucedió en cadena desde que se introdujo el error hasta que los validadores implementaron la versión de parche que lo puso en cuarentena, e identificó cada protocolo y contrato de activo que fue afectado. El error impactó un subconjunto limitado de entradas de contratos inteligentes de Stellar — 478, para ser exactos. Antes de que se estableciera la cuarentena, 84 entradas corruptas fueron restauradas e incorporadas al estado del libro mayor en vivo y 77 de esas entradas fueron realmente modificadas; las 394 restantes no se restauraron. Ninguna otra entrada del libro mayor de los ~47m restantes se vio afectada. Aquí hay un ejemplo de cómo funcionó el error:

1. La entrada E tiene un saldo de 10 en el libro mayor n
2. E recibe un pago de 15 en el libro mayor n + 1, el nuevo saldo es 25
3. E es “archivada”, pero la versión desactualizada n se archiva con saldo 10
4. E se restaura más tarde, pero con el valor desactualizado n. Los registros del libro mayor marcan el saldo de E como 10 en lugar de 25

Una solución permanente requerirá una nueva versión del protocolo, lo que implicará una votación de los validadores para actualizar la red.

Durante la última semana, se consultó a los validadores de Nivel 1, organizaciones afectadas y miembros de la comunidad para explorar soluciones potenciales. Informados por ese feedback y análisis, se ha identificado una solución técnica viable, y los validadores de Nivel 1 han expresado su intención de apoyarla en una próxima votación oficial de la red.

La solución propuesta devolvería las entradas corrompidas durante el proceso de archivo a su estado previo al archivo, pero solo entradas que nunca se restauraron después de ser archivadas. Dado que estas entradas nunca fueron observadas por ninguna transacción, revertirlas plantea un riesgo mínimo. Este enfoque solucionaría la mayoría de las entradas impactadas (394 de 478). El pequeño subconjunto de entradas no abordadas por la actualización del protocolo se resolvería caso por caso por la organización afectada. Puedes revisar los detalles técnicos completos en el Propuesta de Avance del Core (CAP) que expone el cambio con instrucciones sobre cómo auditar los cambios propuestos tú mismo.

Importante, nada es definitivo hasta que los validadores voten, lo que sucederá la próxima semana. Solo entonces sabremos si esta solución se incorporará al protocolo de Stellar. Debido a la naturaleza sensible al tiempo de este problema, hemos colocado este CAP en su último período de comentarios públicos a partir de hoy, y permanecerá en ese estado hasta la votación de los validadores. Animamos fuertemente a todos en el ecosistema a revisar la propuesta y proporcionar feedback en la lista de correo de desarrolladores antes de que tenga lugar la votación.

* Lunes 20 de octubre – versiones estables para Stellar Core, RPC, Horizon

* Martes 21 de octubre 21:00 UTC – Actualización de Testnet

* Miércoles 22 de octubre 17:00 UTC – Votación de actualización de Mainnet. Si es ratificada por los validadores, la red se actualizará inmediatamente al Protocolo 24. Toda infraestructura que no ejecute software compatible con el Protocolo-24 perderá sincronización con la red.

Es importante que el historial de transacciones de Stellar permanezca inmutable. La solución realineará las bases de datos internas con valores corregidos, pero solo para datos corruptos que nunca se usaron ni fueron observados por ninguna transacción. Todas las transacciones registradas en Stellar permanecerán en el libro mayor permanente exactamente como ocurrieron. No se cambiarán ni eliminarán transacciones de forma retroactiva. La historia permanece inmutable.