Abordando Inconsistencias de 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 en Stellar. La característica de archivo de Stellar archiva el estado no utilizado para su restauración posterior. La característica resuelve el problema de escalabilidad de la blockchain evitando la inflación del estado y manteniendo bajas las tarifas. El error, encontrado en Whisk (Protocolo 23) al cual la red se actualizó el 3 de septiembre de 2025, resultó en entradas desactualizadas siendo archivadas y luego restauradas 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 una actualización de 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 primer nivel votaron para aceptar el cambio, lo que previno la escritura adicional de entradas corruptas. El 10 de octubre, SDF lanzó una versión de parche 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 primer nivel 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 se vio afectado. El error impactó un subconjunto limitado de entradas de contratos inteligentes de Stellar — 478, para ser exactos. Antes de que se pusiera en marcha 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 fueron restauradas. 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 es archivada con saldo 10
4. E es restaurada 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 validadores de primer nivel, 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 primer nivel 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 corruptas durante el proceso de archivo a su estado pre-archivo, pero solo entradas que nunca fueron restauradas 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 afectadas (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 la 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 – lanzamientos estables para Stellar Core, RPC, Horizon

* Martes 21 de octubre 17: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 fueron utilizados u observados por ninguna transacción. Todas las transacciones registradas en Stellar permanecerán en el libro mayor permanente exactamente como ocurrieron. Ninguna transacción será cambiada o eliminada retroactivamente. La historia permanece inmutable.