Eventos de Stellar: Eventos Retroactivos

Cuando Protocolo 23 se implemente más adelante este año, CAP-67 no solo comenzará a emitir eventos para nuevos registros. También puede generar eventos para registros pasados si se configura para hacerlo. Eso significa que cualquier proveedor que quiera un flujo de eventos unificados verdaderamente completo debe reingresar toda la historia con dos nuevas banderas principales activadas.

Esta es una actualización de protocolo atípica: P23 tiene la capacidad de emitir nuevos datos de eventos en el TransactionMeta para registros pasados. Si tu servicio o herramientas almacenan la historia completa de Stellar para los usuarios finales, ya sean billeteras, exchanges, plataformas de análisis o indexadores personalizados, necesitarás optar por participar; de lo contrario, te perderás todos los movimientos de operaciones clásicas que ocurrieron antes de P23.

configuraciones para admitir dos nuevas banderas. Por defecto, ambas banderas están desactivadas. Los operadores deben optar explícitamente:

yaml

```

# en tu stellar-core.cfg o stellar-core.conf

# añade operaciones clásicas al flujo unificado

EMIT_CLASSIC_EVENTS: true

# genera nuevos eventos para todos los registros históricos

BACKFILL_STELLAR_ASSET_EVENTS: true

```

• EMIT_CLASSIC_EVENTS
  Cuando verdadero, se emiten dos nuevos tipos de eventos: eventos de tarifas y movimientos de tokens de operaciones clásicas (pagos, pagos de ruta, recuperaciones, etc.). El evento de tarifa cubre todas las tarifas de transacción cobradas, incluidas las transacciones de Soroban y reembolsos. No se emiten eventos de tarifas a menos que esta bandera esté establecida, ni siquiera para transacciones de Soroban. Estos eventos se agregarán al flujo de eventos hacia adelante (desde la actualización de P23 en adelante).
• BACKFILL_STELLAR_ASSET_EVENTS
  Cuando verdadero, Core emitirá nuevos eventos para todos los registros pasados (génesis → presente), permitiéndote llenar cualquier brecha en tu flujo de eventos históricos. El operador necesitará activar el relleno; la bandera solo permite que core cree nuevos datos para registros pasados.

Nota: Protocolo 23 introduce una nueva versión de TransactionMeta XDR, TransactionMetaV4. Si operas un nodo RPC, Horizon o Galaxie, el soporte para la nueva versión meta se incluirá con la actualización del protocolo.

Tus Tres Caminos de Actualización

Nota: La opción 3 desbloquea la capacidad de calcular con precisión los saldos de las cuentas, la oferta circulante y otras analíticas de tokens, pero requiere la reingestión completa de la historia.

Beneficios

• Análisis completos: saldos históricos, métricas de suministro, rastreos de auditoría
• API Uniforme: un esquema de evento para cada movimiento de token, pasado y futuro
• Mejor UX: billeteras, exchanges y dApps obtienen una historia consistente

Costos / Compensaciones

• Crecimiento en tamaño de DB: Stellar RPC con EMIT_CLASSIC_EVENTS=true vio un aumento de tamaño de DB de ~2.5 GB por día. Para RPCs con una ventana de retención de 7 días, esto es un aumento de ~10% en tamaño
• Crecimiento en Almacenamiento Analítico: El almacenamiento de eventos completos sin comprimir es de ~7TB
• Los impactos en rendimiento de CPU y RAM son despreciables y no requerirán redimensionar componentes de infraestructura

1. Revisa tu base de usuarios: si sirves a billeteras, exchanges, dApps o plataformas de análisis que rastrean flujos de tokens, se recomienda encarecidamente apoyar una historia completa de Eventos Clásicos.
2. Actualiza tu Core/Galaxie/RPC compatible con P23 para configurar estas banderas.
3. Planea una reingestión completa de la historia si necesitas datos pasados completos.

De esa manera, tu flujo de eventos unificados realmente cubrirá cada acuñación, transferencia, quema y operación de recuperación, incluso las operaciones clásicas pre-P23.

Para más sobre el diseño general de CAP-67 ve Eventos de Stellar: Rastrea Todo, y para detalles completos del lanzamiento de P23, revisa el Anuncio del Protocolo 23 y la correspondiente Guía de Actualización.