Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.3.9-pre.006-fix.003

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-05 13:53:36 +02:00
parent c3c9a80310
commit 9a998e7b52
36 changed files with 186 additions and 131 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md -->
<!-- version: 12 -->
<!-- version: 13 -->
# Acquisition, workers, jobs et pipelines spécialisés
@@ -204,20 +204,11 @@ L'archive kbot3 doit être relue uniquement comme **référence fonctionnelle**
#### `mainnet` et `mainnet-beta`
La terminologie réseau est un audit explicite avant toute modification. Les sources Solana actuelles utilisent de plus en plus `mainnet` alors que plusieurs surfaces/outils historiques conservent `mainnet-beta`.
L'audit `0.3.9` a conclu que `mainnet` est l'identité logique canonique KSP du réseau de production Solana. `mainnet-beta` reste un alias legacy/externe ou un libellé provider lorsqu'une API externe l'emploie réellement ; il ne constitue plus l'identité persistée cible de Store/RAW/Config.
KSP ne doit jamais créer deux identités persistées pour le même cluster par simple renommage. L'audit doit donc inventorier :
Depuis `0.3.9-pre.006-fix.003`, les profils Mainnet engagés dans Config/Store/Transport utilisent `mainnet`, de même que les tests et exemples runtime associés. KSP ne crée donc pas deux identités persistées pour le même cluster. Les anciennes données N1 RAW portant `mainnet-beta` sont considérées comme expérimentales et peuvent être droppées/recréées ; aucune migration destructive n'est imposée avant finalisation des Jobs/Workers RAW.
```text
RawNetworkId et valeurs persistées Store
Config profile ids / cluster labels
Transport descriptors et provider metadata
CLI/external aliases réellement acceptés
compatibilité des checkpoints/fingerprints existants
migration ou canonicalisation éventuellement nécessaire
```
Aucun renommage de données persistées ou de profil n'est effectué en `0.3.8`. `0.3.10` ne l'implémente que si l'audit `0.3.9` établit une stratégie de compatibilité sûre.
Les frontières externes restent libres de documenter ou d'accepter un nom provider legacy lorsque nécessaire, sans recopier ce nom dans `RawNetworkId` canonique.
#### Idempotence et multi-source
@@ -527,7 +518,7 @@ selon les capacités réellement introduites.
- nom final de la crate pipeline RAW si la réutilisation worker + backfill justifie réellement une crate dédiée ;
- taxonomie exacte des stratégies/source capabilities de `ksp-worker-raw-transaction-ingest-lib`, à décider par l'audit de fin `0.3.9` ;
- stratégie sûre de canonicalisation/aliasing `mainnet` / `mainnet-beta`, si un changement KSP est réellement nécessaire ;
- politique d'alias externe `mainnet-beta` à matérialiser uniquement aux frontières qui en ont réellement besoin, sans créer une seconde identité Store ;
- modèle de claim/lease PostgreSQL pour les futurs processors continus ;
- taille de batch et stratégie backpressure des workers de processing ;
- découpage des workers DECODE/SPECIALIZED par groupe lorsque les premiers groupes existent ;

4
docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md -->
<!-- version: 5 -->
<!-- version: 6 -->
# Acquisition et alimentation `RawTransaction`
@@ -609,7 +609,7 @@ priorités/composition
Les prix/tiers d'audit ne doivent pas devenir une politique runtime.
`mainnet` devient l'identité réseau durable KSP. `mainnet-beta` reste uniquement un alias de compatibilité/historique ou un libellé externe lorsqu'un provider/API l'emploie. La phase N1 RAW étant encore une phase de test, aucune donnée existante ne doit forcer la conservation de `mainnet-beta` comme identité canonique : la base peut être droppée/recréée lors de la normalisation si nécessaire.
`mainnet` est l'identité réseau durable KSP. `mainnet-beta` reste uniquement un alias de compatibilité/historique ou un libellé externe lorsqu'un provider/API l'emploie. Depuis `0.3.9-pre.006-fix.003`, les profils Config/Store/Transport Mainnet engagés utilisent `mainnet` comme identité logique, et les exemples/tests associés ont été normalisés. Les endpoints publics Solana engagés suivent également la nomenclature Mainnet courante (`https://api.mainnet.solana.com` et `wss://api.mainnet.solana.com`). Aucune migration de données N1 n'est exigée : les données RAW Mainnet encore expérimentales peuvent être droppées/recréées si elles portent l'ancienne identité.
## 13. Normalisation RAW commune sans couplage Job/Worker