Files

2026-07-23 16:37:12 +02:00

3.5 KiB

Raw Blame History

Cycle de vie du stockage transactionnel Solana

Principe général

Le stockage rejouable repose désormais sur une transaction Solana canonique unique par signature. Les formats d’origine JSON-RPC, WebSocket Helius ou Yellowstone Protobuf sont des formats de transport, pas des modèles de stockage métier.

Le cycle est :

acquisition
  -> normalisation canonique
    -> persistance raw canonique
      -> extraction core
        -> décodage
          -> matérialisation
            -> compaction / archivage / purge éventuelle

Transaction canonique

kb_sol_raw_transactions conserve suffisamment d’information pour :

auditer une transaction ;
reconstruire les tables core ;
rejouer de nouvelles versions de décodeurs ;
rejouer de nouvelles versions de matérialiseurs ;
comparer plusieurs sources sans dépendre de leur format.

La ligne est unique par signature. canonical_format_version permet de faire évoluer le contrat sans ambiguïté.

Observations d’acquisition

kb_sol_obs_transaction_observations conserve les preuves techniques d’acquisition :

fournisseur et endpoint ;
protocole et méthode ;
origine live/backfill/replay/réparation ;
commitment ;
session et filtre ;
timestamps de détection, réception, normalisation et persistance ;
taille du message ;
statut et erreur éventuelle.

Cette table ne conserve pas le payload complet. Elle peut contenir plusieurs lignes pour une même signature.

Ancienne table WebSocket

kb_sol_raw_ws_notifications est une table historique de 0.2.3, supprimée pendant la transition validée 0.3.1. Elle n’existe plus dans la baseline SQL active.

Les nouvelles notifications WebSocket ne doivent pas être stockées intégralement par défaut. Une notification de logs peut rester temporairement dans une queue mémoire jusqu’à l’hydratation de la transaction.

États de rétention

Les états de rétention de kb_sol_raw_transactions sont :

full
compacted
archived
purged

`full`

Le document canonique complet est présent dans PostgreSQL.

`compacted`

Une représentation réduite ou un stockage externe permet encore l’audit minimal, mais le payload canonique complet n’est plus dans la ligne chaude.

`archived`

Le payload a été déplacé vers un stockage d’archive durable.

`purged`

Le payload n’est plus disponible. Le hash canonique, la signature, le slot et les données dérivées doivent rester suffisants pour les diagnostics autorisés.

États de traitement

received
core_extracted
decoded
materialized
failed

L’état décrit la progression de la transaction canonique, pas celle de chaque observation de source.

Conditions avant compaction ou purge

Aucune purge destructive ne doit être activée avant validation de :

l’extraction core idempotente ;
la couverture des décodeurs prioritaires ;
la reconstruction depuis archive ;
la stabilité du hash canonique ;
la conservation du ledger de traitement ;
la stratégie de sauvegarde PostgreSQL.

Payloads fournisseur de diagnostic

Les payloads complets spécifiques à un fournisseur peuvent être exportés temporairement pour une session de test. Ils ne doivent pas devenir une dépendance du replay métier.

Un export de diagnostic doit être :

opt-in ;
borné en durée et en taille ;
associé à une session ;
supprimable indépendamment de PostgreSQL.

3.5 KiB Raw Blame History Unescape Escape