3.5 KiB
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.