v0.3.10-pre.008
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md -->
|
||||
<!-- version: 16 -->
|
||||
<!-- version: 17 -->
|
||||
|
||||
# Acquisition, workers, jobs et pipelines spécialisés
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
Ce document définit le lifecycle opérationnel autour des couches :
|
||||
|
||||
```text
|
||||
RAW -> CORE -> DECODE -> SPECIALIZED
|
||||
RAW -> STRUCTURAL -> DECODED -> DOMAIN
|
||||
```
|
||||
|
||||
Il conserve la séparation stricte entre :
|
||||
@@ -20,7 +20,7 @@ Il conserve la séparation stricte entre :
|
||||
|
||||
## Règle de progression
|
||||
|
||||
RAW et CORE sont les deux premières couches horizontales. Elles ne nécessitent aucun decoder Program.
|
||||
RAW et STRUCTURAL sont les deux premières couches horizontales. Elles ne nécessitent aucun decoder Program.
|
||||
|
||||
Pour chacune, KSP peut terminer successivement :
|
||||
|
||||
@@ -31,7 +31,7 @@ persistence
|
||||
-> application de contrôle/inspection si utile
|
||||
```
|
||||
|
||||
À partir de DECODE, les processors/jobs/workers/scenarios sont introduits **avec le groupe Program concerné**, en vertical slice, au lieu de créer à l'avance une grande flotte générique de workers de décodage/materialisation sans programme réel.
|
||||
À partir de DECODED, les processors/jobs/workers/scenarios sont introduits **avec le groupe Program concerné**, en vertical slice, au lieu de créer à l'avance une grande flotte générique de workers de décodage/materialisation sans programme réel.
|
||||
|
||||
## RAW
|
||||
|
||||
@@ -86,7 +86,7 @@ Le job :
|
||||
- limite les hydrations concurrentes, avance seulement une frontier contiguë durable et retourne un checkpoint opaque caller-owned ;
|
||||
- arrête coopérativement les nouvelles admissions lors d'une annulation et draine une persistence Store déjà soumise ;
|
||||
- publie des snapshots latest-value sûrs sans payload RAW ni secrets/URLs Transport ;
|
||||
- n'effectue aucun décodage Program et n'écrit aucun fait CORE/DECODE/SPECIALIZED.
|
||||
- n'effectue aucun décodage Program et n'écrit aucun fait STRUCTURAL/DECODED/DOMAIN.
|
||||
|
||||
Le caller desktop spécialisé actuel est `ksp-app-backfill-desk`. Il compose Config, le pool HTTP et Store, puis remet ces ressources au runtime Backfill. Il peut retenir le checkpoint terminal uniquement en mémoire Rust pour un Resume in-session ; cette rétention applicative ne transforme pas le checkpoint en garantie de reprise durable après redémarrage.
|
||||
|
||||
@@ -204,7 +204,7 @@ L'archive kbot3 doit être relue uniquement comme **référence fonctionnelle**
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
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 D1 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.
|
||||
|
||||
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.
|
||||
|
||||
@@ -237,11 +237,11 @@ une stratégie live + gap repair
|
||||
|
||||
Le détail des RAW persistés reste la responsabilité de Store Desk.
|
||||
|
||||
## CORE
|
||||
## STRUCTURAL
|
||||
|
||||
### Pipeline RAW -> CORE
|
||||
### Pipeline RAW -> STRUCTURAL
|
||||
|
||||
La normalisation CORE est générique Solana :
|
||||
La normalisation STRUCTURAL est générique Solana :
|
||||
|
||||
```text
|
||||
D1 RAW
|
||||
@@ -250,15 +250,15 @@ D1 RAW
|
||||
Solana generic normalizer
|
||||
|
|
||||
v
|
||||
D2 CORE
|
||||
D2 STRUCTURAL
|
||||
```
|
||||
|
||||
Dépendances interdites :
|
||||
|
||||
```text
|
||||
CORE normalizer -X-> ksp-program-api
|
||||
CORE normalizer -X-> ksp-program-lib
|
||||
CORE normalizer -X-> ksp-materializer-api
|
||||
STRUCTURAL normalizer -X-> ksp-program-api
|
||||
STRUCTURAL normalizer -X-> ksp-program-lib
|
||||
STRUCTURAL normalizer -X-> ksp-materializer-api
|
||||
```
|
||||
|
||||
`ksp-interface-lib` peut fournir les wires Solana génériques nécessaires à la structure blockchain.
|
||||
@@ -271,21 +271,21 @@ Un job borné peut rejouer :
|
||||
RAW persisted range
|
||||
|
|
||||
v
|
||||
CORE normalizer
|
||||
STRUCTURAL normalizer
|
||||
|
|
||||
v
|
||||
D2 CORE
|
||||
D2 STRUCTURAL
|
||||
```
|
||||
|
||||
sans redemander les données au réseau.
|
||||
|
||||
### STRUCTURAL worker
|
||||
|
||||
Le STRUCTURAL worker continu peut consommer le backlog RAW nouvellement persisté et produire CORE.
|
||||
Le STRUCTURAL worker continu peut consommer le backlog RAW nouvellement persisté et produire STRUCTURAL.
|
||||
|
||||
Le Store reste source de vérité du backlog ; les notifications ne sont qu'un wake-up.
|
||||
|
||||
## DECODE et SPECIALIZED
|
||||
## DECODED et DOMAIN
|
||||
|
||||
### Introduction par groupe fonctionnel
|
||||
|
||||
@@ -294,7 +294,7 @@ KSP ne crée pas d'abord un unique « worker decoder de tout Solana » puis tous
|
||||
Chaque groupe prioritaire introduit les capacités nécessaires :
|
||||
|
||||
```text
|
||||
CORE inputs du groupe
|
||||
STRUCTURAL inputs du groupe
|
||||
|
|
||||
v
|
||||
Program decoder
|
||||
@@ -303,10 +303,10 @@ Program decoder
|
||||
decoded facts
|
||||
|
|
||||
v
|
||||
generic materialization / DECODE persistence
|
||||
generic materialization / DECODED persistence
|
||||
|
|
||||
v
|
||||
SPECIALIZED projection si utile
|
||||
DOMAIN projection si utile
|
||||
```
|
||||
|
||||
Puis le même groupe avance vers préparation d'exécution, policy, execution et scénarios Devnet.
|
||||
@@ -511,7 +511,7 @@ STRUCTURAL job / STRUCTURAL worker
|
||||
|
||||
Pas de Program API.
|
||||
|
||||
### Groupes DECODE/SPECIALIZED
|
||||
### Groupes DECODED/DOMAIN
|
||||
|
||||
Le composant de composition du groupe peut utiliser :
|
||||
|
||||
@@ -530,5 +530,5 @@ selon les capacités réellement introduites.
|
||||
- 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 ;
|
||||
- découpage des workers DECODED/DOMAIN par groupe lorsque les premiers groupes existent ;
|
||||
- mécanisme IPC des applications de contrôle futures.
|
||||
|
||||
Reference in New Issue
Block a user