Reconciliando Eventos Stellar

El lanzamiento del protocolo Whisk Eventos Stellar (especificado por CAP-67), que permitió a todos seguir fácilmente todos los movimientos de tokens a través de la red de Stellar. El reciente problema de archivo de estado causó que algunos Eventos Stellar se omitieran cuando deberían haber sido emitidos en los metadatos del ledger de la red.

Stellar Core v24.1.0, que se lanzó el 11/11/2025, garantizará que cualquiera que reproduzca la historia de la red desde el génesis tendrá una imagen completa y detallada de todos los movimientos de tokens que ocurrieron en la red, cumpliendo la promesa original de los Eventos Stellar. Sin embargo, los operadores que ya estaban en vivo y operativos cuando el problema estaba presente en la red se perdieron estos eventos entre el Protocolo 23 (secuencia de ledger 58762517) y el Protocolo 24 (secuencia de ledger 59501299).

La recomendación varía dependiendo del producto de infraestructura específico que ejecutes.

Galexie

Los operadores que alojan un Data Lake de Galexie (S3 o GCS) deben planificar volver a exportar todos los ledgers que ocurrieron entre los Protocolos 23 y 24 para asegurarse de que tienen un historial completo de todos los Eventos Stellar que ocurrieron en la red.

El Galexie v24.1.0 lanzamiento agregó una nueva función de reemplazo para facilitar este proceso. Te permite sobrescribir archivos existentes en tu data lake de manera fluida y sin tiempo de inactividad, así:

$ galexie reemplazar --start 58762517 --end 59501299

Este trabajo tomará aproximadamente 80 horas en ejecutarse en el hardware recomendado. Es posible paralelizar esto si deseas acelerar el proceso.

Horizon

Los operadores que alojan Horizon y configuraron cualquiera de los siguientes valores de configuración deben considerar ingerir la historia entre los Protocolos 23 y 24 para asegurar un historial completo de todos los Eventos Stellar que ocurrieron en la red.

• SKIP_TXMETA = false
• EMIT_CLASSIC_EVENTS = true
• BACKFILL_STELLAR_ASSET_EVENTS = true

Ten en cuenta que si no configuras explícitamente ninguno de estos valores en tu configuración, entonces el comportamiento predeterminado es que no necesitas tomar ninguna acción.

Si identificas que necesitas reingerir la historia en tu base de datos de Horizon, se puede hacer así:

• Verifica HISTORY_RETENTION_COUNT para asegurarte de que retendrás al menos suficientes ledgers para alcanzar la secuencia de ledger 58762517
• Detén tu instancia de Horizon en vivo; la reingestión no se puede realizar al mismo tiempo que la ingestión en vivo. Por esta razón, es mejor realizar este proceso sin conexión o en una instancia de reserva/secundaria.
• Realiza la reingestión. Si lo deseas, este comando puede ser paralelizado.

$ stellar-horizon db reingest range 58762517 59501299

• Reinicia tu instancia de Horizon en vivo.

Stellar RPC

La ventana de retención histórica predeterminada para RPC es de 7 días. Como tal, todos los Eventos Stellar que no se emitieron en tiempo real ya han ocurrido fuera de la ventana de retención de RPC. Por lo tanto, no se recomienda que los operadores de RPC tomen ninguna acción.

Los proveedores pueden considerar expandir su oferta para incluir un nodo RPC de archivo, ya que la demanda de los consumidores para reingerir datos históricos puede aumentar dado este problema.

Si has estado consumiendo Eventos Stellar desde el lanzamiento del Protocolo 23, se aconseja que audites la lista de claves de ledger que fueron afectadas por el bug de restauración. Esta lista es relativamente pequeña, por lo que hay una buena posibilidad de que, incluso si estás consumiendo Eventos Stellar, aún no te veas afectado por este problema.

Asumiendo que has determinado que necesitas consumir los Eventos Stellar relacionados con las claves de ledger afectadas, tu remediación dependerá de dónde estés consumiendo esos eventos. Independientemente de la fuente, asegúrate de confirmar con tu proveedor de infraestructura que ya han realizado la reingestión necesaria por su parte.

Galexie

Se recomienda que vuelvas a descargar todos los metadatos de ledger históricos entre los Protocolos 23 y 24 e identifiques cualquier evento que previamente haya sido omitido por tu sistema de ingestión.

Stellar RPC

RPC retiene solo 7 días de datos históricos, por lo que todos los eventos omitidos ya están más allá del punto en el tiempo que RPC tendría disponible. Hay un par de opciones para obtener datos históricos a través de RPC:

• Encuentra un proveedor de RPC que proporcione un RPC de archivo
• Ejecuta RPC localmente y dirígelo a un proveedor que expone un Data Lake público

Usando esta instancia de RPC de archivo, extrae metadatos de ledger históricos entre los Protocolos 23 y 24 e identifica cualquier evento que previamente haya sido omitido por tu sistema de ingestión. Ten en cuenta que el soporte histórico en los RPC de archivo está limitado al endpoint getLedgers.

Horizon

No es necesario tomar ninguna acción, ya que Horizon no expone Eventos Stellar en la meta de transacción por defecto.

Si has configurado personalizadamente una instancia de Horizon autoalojada para exponer eventos con cualquiera de las dos configuraciones mencionadas anteriormente, entonces deberías volver a consultar todos los metadatos de ledger entre los Protocolos 23 y 24, a través de cualquiera que sea el endpoint desde el que estás obteniendo esos datos. Ten en cuenta que Horizon de SDF (horizon.stellar.org) no expone Eventos Stellar y, por lo tanto, no tomará ninguna acción como resultado de este lanzamiento.

Hubble

Si usas o reflejas el conjunto de datos analíticos de BigQuery público, necesitarás reprocesar cualquier canalización analítica que contenga datos del Protocolo 23 al Protocolo 24. SDF reingerirá y sobrescribirá los datos en Hubble; los consumidores aguas abajo serán responsables de reconciliar sus propias canalizaciones aguas abajo desde BigQuery.

Contacta en el Discord de Hubble con cualquier pregunta o inquietud.

Indexadores de Terceros o Proveedores de Analíticas

Contacta directamente a tus proveedores para obtener un cronograma de la disponibilidad del conjunto completo de datos. Ellos estarán siguiendo los pasos de remediación recomendados por SDF para operadores (arriba) y, por lo tanto, pueden necesitar algo de tiempo antes de que los datos estén disponibles para consumo por sus clientes.