Files
khadhroony-solana-project/deltas/0.3.9/pre.006-fix.001.md

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 getTransaction sert au Worker pour hydrater un signal live et au Job pour hydrater une signature historique ;
  • HTTP getBlock peut servir au Worker en live polling/repair de continuité et au Job pour une plage historique ;
  • Yellowstone from_slot peut 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.10 Worker et 0.3.12 Backfill.

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é.