4.0 KiB
Delta 0.3.9-pre.006-fix.001
1. Objet
Corriger la synthèse architecturale RAW de pre.006 sans modifier le runtime.
Le document docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md était fonctionnellement riche mais conservait la forme de deux audits chronologiques A/B auxquels une synthèse avait été ajoutée. Cette structure masquait aussi la séparation stricte attendue entre les deux producteurs de RawTransaction.
Le correctif réécrit intégralement l'owner comme une synthèse unique centrée sur Store / RawTransaction.
2. Architecture corrigée
Le modèle durable devient explicitement :
sources/protocoles/providers
-> capabilities d'acquisition
-> Job Backfill OU Worker Ingest selon l'intention
-> normalisation RAW source-neutral
-> Store
-> RawTransaction + observations/provenance
Les deux producteurs sont indépendants :
Job Backfill
= historique demandé
= paramètres métier explicites
= campagne bornée et terminable
Worker Raw Transaction Ingest
= acquisition continue depuis start
= aucun paramètre métier de campagne au start
= stop pour terminer normalement
Aucun edge, appel, délégation, checkpoint partagé ou coordination lifecycle Job <-> Worker n'est admis.
3. Protocoles et capabilities
Le correctif supprime toute lecture implicite :
HTTP = Backfill
WS/gRPC = Worker
La règle correcte est :
HTTP / WS / gRPC / archive / EARLY
= moyens d'acquisition
= utilisables par le producer dont l'intention correspond
Exemples :
- HTTP
getTransactionsert au Worker pour hydrater un signal live et au Job pour hydrater une signature historique ; - HTTP
getBlockpeut servir au Worker en live polling/repair de continuité et au Job pour une plage historique ; - Yellowstone
from_slotpeut réparer la continuité d'un Worker depuis son frontier actif ou alimenter un Job de replay historique borné ; - une API archive/provider history appartient au Job lorsqu'elle répond à une campagne historique.
4. Frontière de continuité Worker
Le Worker peut réparer uniquement les pertes de continuité liées à son acquisition active :
frontier live
-> gap détecté
-> replay/hydration/block recovery
-> frontier restauré
-> live continue
Il ne reçoit jamais une requête arbitraire « remonte avant telle date/slot/signature ». Cette responsabilité appartient au Job Backfill.
5. Normalisation commune
ksp-raw-transaction-lib reste retenu comme lower-layer source-neutral commun afin d'éviter la duplication du canonicalizer RAW v1.
Cette dépendance inférieure ne crée aucune relation fonctionnelle entre Job et Worker :
Job ------> raw common ------> Store
Worker ---> raw common ------> Store
aucun edge Job <-> Worker
6. Données d'audit conservées
La réécriture conserve et réorganise :
- la matrice exhaustive des méthodes standard HTTP/WS/Yellowstone ;
- l'applicabilité Worker / Job par méthode ;
- les providers et infrastructures connus ;
- les réseaux ;
- les prix/tiers datés au 4 septembre 2026 ;
- les statuts
PROUVÉ,TESTABLE,NON PROUVÉ,BLOQUÉ TIER,À REVALIDER; - les sources EARLY/shreds ;
- la stratégie de preuve Mainnet/Devnet/Testnet/local ;
- les gaps Transport/Config ;
- les handoffs
0.3.10Worker et0.3.12Backfill.
7. Version
Correctif strictement documentaire. Conformément aux règles KSP applicables aux fixes documentaires :
workspace.package.version = 0.3.9-pre.6
Aucun changement Cargo.toml n'est effectué.
8. Fichiers
Modifiés :
docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md
docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md
docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md
Ajouté :
deltas/0.3.9/pre.006-fix.001.md
Aucun fichier Rust, Config, Store, Transport, endpoint ou secret n'est modifié.