diff --git a/deltas/0.3.9/pre.006-fix.001.md b/deltas/0.3.9/pre.006-fix.001.md new file mode 100644 index 0000000..4f8465b --- /dev/null +++ b/deltas/0.3.9/pre.006-fix.001.md @@ -0,0 +1,135 @@ + + + +# 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 : + +```text +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 : + +```text +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 : + +```text +HTTP = Backfill +WS/gRPC = Worker +``` + +La règle correcte est : + +```text +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 : + +```text +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 : + +```text +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 : + +```text +workspace.package.version = 0.3.9-pre.6 +``` + +Aucun changement `Cargo.toml` n'est effectué. + +## 8. Fichiers + +Modifiés : + +```text +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é : + +```text +deltas/0.3.9/pre.006-fix.001.md +``` + +Aucun fichier Rust, Config, Store, Transport, endpoint ou secret n'est modifié. diff --git a/docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md b/docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md index e7cd125..91313e4 100644 --- a/docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md +++ b/docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md @@ -1,240 +1,813 @@ - + -# Acquisition RAW Transaction +# Acquisition et alimentation `RawTransaction` -## 1. Rôle +## 1. Rôle du document -Ce document est l'owner durable de la taxonomie d'acquisition `RawTransaction` de KSP. Il sépare volontairement : +Ce document est l'owner durable de l'architecture d'alimentation des `RawTransaction` de KSP. -- les invariants durables de convergence vers Store ; -- les rôles/capabilities d'acquisition ; -- les audits datés de protocoles/providers ; -- les gaps à transmettre aux releases d'implémentation. - -Il ne définit ni un endpoint secret, ni un quota provider figé, ni une configuration utilisateur. Les disponibilités et limites externes sont réauditées à la date indiquée dans chaque section d'audit. - -## 2. Invariants durables - -La convergence RAW reste indépendante de la source : +Il ne suit pas l'ordre chronologique des audits `pre.004` / `pre.005`. Il synthétise directement le modèle cible : ```text -identité canonique transaction = (network, signature) -contenu canonique = source-independent -acquisition utile = RawTransactionObservation distincte -provider/protocole/endpoint = provenance, jamais identité transactionnelle -même identité + même contenu = idempotence -même identité + contenu divergent = conflit explicite +sources/protocoles/providers + | + | capacités d'acquisition + v ++-----------------------------+ +---------------------------------------+ +| ksp-job-backfill-lib | | ksp-worker-raw-transaction-ingest-lib | +| historique paramétré | | acquisition continue start/stop | ++-----------------------------+ +---------------------------------------+ + | | + | producteurs indépendants | + +------------------+-------------------+ + v + normalisation RAW commune + | + v + Store + | + RawTransaction + observations ``` -Une source n'est admise pour persister un `RawTransaction` que si KSP peut reconstruire le payload canonique complet attendu par Store. Un signal incomplet reste une discovery et doit être hydraté par une autre capability. +Le **Store et `RawTransaction` sont le centre**. Le Job Backfill et le Worker Ingest sont deux producteurs indépendants qui convergent vers le même contrat durable. Ils ne se pilotent pas mutuellement, ne se délèguent pas du travail et ne dépendent pas l'un de l'autre. -## 3. Taxonomie de rôles +Les protocoles ne sont pas affectés à un producteur par nature : HTTP, WS, gRPC, archive ou shred peuvent servir au Job, au Worker ou aux deux si leur sémantique correspond au rôle concerné. -| Rôle | Responsabilité | Exemple standard actuel | -|-------------------------|-----------------------------------------------------------|------------------------------------------------------------------| -| `live_direct_full` | transaction/bloc complet reçu directement | WS blockSubscribe aujourd’hui ; autres sources en pre.005 | -| `live_discovery` | référence/signature reçue puis hydration séparée | WS logsSubscribe | -| `targeted_confirmation` | signature déjà connue surveillée jusqu’au commitment | WS signatureSubscribe | -| `history_discovery` | énumération de références historiques | HTTP getSignaturesForAddress ; HTTP getBlocks/getBlocksWithLimit | -| `hydration` | récupération de transaction complète depuis une référence | HTTP getTransaction | -| `gap_boundary` | détermination d’une fenêtre ou d’une limite de rétention | getSlot/getFirstAvailableBlock/minimumLedgerSlot | -| `gap_repair` | réacquisition explicite après perte de continuité | HTTP bloc ou adresse selon le scope disponible | +Les prix, tiers, quotas et disponibilités provider sont des données d'audit datées. Ils ne deviennent jamais des constantes métier KSP. -Ces rôles sont orthogonaux au protocole. Une stratégie concrète peut combiner plusieurs rôles et plusieurs transports ; la configuration future ne doit pas réduire le modèle à `Http | WebSocket | Grpc`. +## 2. Centre du modèle : Store et `RawTransaction` -## 4. Audit daté A — Solana standard +### 2.1 Vérité RAW durable -Audit effectué le **4 septembre 2026** à partir de la documentation RPC Solana courante et de la surface KSP `0.3.9-pre.3`. - -### 4.1 Matrice fonctionnelle - -| Voie | Capability | RAW complet | Temporalité utile | Décision | État KSP | -|------------------------------------------------------|------------------------------------|----------------------------------|-----------------------------------------|------------------------|-----------------------------------------------------------------------------------| -| HTTP `getSignaturesForAddress` + `getTransaction` | discovery adresse + hydration | non / oui | historique, catch-up, repair ciblé | ADMIS | déjà utilisé par Backfill ; `getTransaction` observé conserve provider + endpoint | -| HTTP `getBlocks` / `getBlocksWithLimit` + `getBlock` | discovery slots/blocs + extraction | non / oui | catch-up global, gap repair, historique | ADMIS SOUS GAP | `getBlock` typé existe mais pas de variante observée | -| HTTP `getSlot` | borne haute selon commitment | non | pilotage catch-up / gap | AUXILIAIRE | surface typée KSP disponible | -| HTTP `getFirstAvailableBlock` | borne basse des blocs conservés | non | admission historique / diagnostic | AUXILIAIRE | surface typée KSP disponible | -| HTTP `minimumLedgerSlot` | borne basse ledger du nœud | non | diagnostic de rétention/provider | AUXILIAIRE | surface typée KSP disponible | -| WS `logsSubscribe` | discovery live par logs | non | live + signal de gap | ADMIS | hydration `getTransaction` obligatoire pour RAW complet | -| WS `signatureSubscribe` | suivi d’une signature déjà connue | non | confirmation/repair ciblé | SECONDAIRE | one-shot ; ne découvre pas un flux de transactions | -| WS `blockSubscribe` | bloc live contenant transactions | oui si `transactionDetails=full` | live / catch-up très court | ADMIS SOUS CONTRAINTES | méthode Solana instable + activation validator requise | -| WS `slotSubscribe` | signal slot/parent/root | non | détection/pilotage de gap | AUXILIAIRE | stable mais ne transporte aucune transaction | -| WS `slotsUpdatesSubscribe` | lifecycle détaillé de slot | non | diagnostic de continuité | OPTIONNEL | méthode Solana instable ; pas une source RAW directe | - -### 4.2 HTTP adresse : discovery + hydration - -`getSignaturesForAddress` retourne des signatures confirmées associées à une adresse, ordonnées du plus récent au plus ancien, avec `before`, `until`, `limit`, `commitment` et `minContextSlot`. La discovery est donc naturellement **adressée** : elle ne constitue pas une discovery globale de toutes les transactions du réseau. - -`getTransaction` retourne ensuite la transaction confirmée complète ou `null`. Pour KSP, cette combinaison est la référence actuelle du Backfill et reste admise pour : +L'identité canonique reste : ```text -historique adressé -catch-up adressé -repair ciblé -hydration d'un signal WS qui connaît déjà la signature +RawTransaction identity = (network, signature) ``` -Elle n'est pas retenue comme source live globale par polling. - -### 4.3 HTTP bloc : scan global par slots - -`getBlocks` et `getBlocksWithLimit` énumèrent des slots confirmés ; la documentation courante borne leurs ranges/limits à 500 000. `getBlock` peut retourner les transactions complètes du bloc avec `confirmed` ou `finalized` et les options de détail/encodage. - -Cette famille est admise comme stratégie potentielle de : +Le contenu canonique doit être indépendant de la source d'acquisition : ```text -catch-up global par slots -gap repair global -historique lorsque le provider conserve la plage demandée +même identité + même contenu canonique + -> idempotence + +même identité + contenu canonique divergent + -> conflit explicite + -> jamais first-provider-wins silencieux ``` -Elle n'est pas équivalente à `getSignaturesForAddress` : la discovery est par slot/bloc et l'hydration est un conteneur de plusieurs transactions. Le worker doit extraire chaque transaction, reconstruire son identité `(network, signature)` et produire une observation propre à chaque acquisition durable. +La provenance d'acquisition n'est pas l'identité de la transaction. Elle appartient aux observations associées. -### 4.4 Bornes de continuité HTTP +### 2.2 Observations et provenance -`getSlot`, `getFirstAvailableBlock` et `minimumLedgerSlot` ne produisent aucune transaction. Ils servent à décider si un gap est encore réparable sur un endpoint et à borner un scan : +Une même transaction peut être acquise plusieurs fois : ```text -getSlot -> borne haute selon commitment -getFirstAvailableBlock -> premier bloc confirmé encore disponible -minimumLedgerSlot -> plus ancien slot encore présent dans le ledger du nœud +PublicNode Yellowstone +Helius WSS +HTTP getTransaction +blockSubscribe +archive provider +... ``` -Ces méthodes ne prouvent pas à elles seules qu'une transaction précise est disponible ; elles sont des primitives d'admission/diagnostic. +Ces acquisitions peuvent converger vers un seul `RawTransaction` et plusieurs `RawTransactionObservation` distinctes lorsque leurs clés d'observation sont différentes et utiles. -### 4.5 WS logsSubscribe : discovery live - -`logsSubscribe` peut écouter `all`, `allWithVotes` ou les transactions mentionnant **un seul** pubkey par appel. La notification KSP contient le contexte de slot, la signature, l'erreur nullable et les logs ordonnés. - -Cette notification n'est pas un `RawTransaction` complet. Elle est admise comme **live discovery** : +La provenance sûre peut conserver notamment : ```text -logsSubscribe notification - -> signature + slot - -> getTransaction observed - -> normalisation RAW - -> persistence transaction + observation +provider +protocole +méthode +origin logique +endpoint logique +commitment +filter id +capture session id +timestamps +hash/taille du payload source ``` -Le filtre `mentions` limité à une adresse par subscription implique que la surveillance de nombreux programmes/comptes consomme plusieurs subscriptions, sauf utilisation de `all`/`allWithVotes` avec filtrage côté consumer. +Aucune URL secrète, clé API ou payload sensible ne doit traverser ce contrat durable. -### 4.6 WS signatureSubscribe : confirmation ciblée +### 2.3 Complétude avant persistence -`signatureSubscribe` surveille une signature déjà connue et s'arrête automatiquement après la notification terminale au commitment demandé. Il ne découvre donc aucune nouvelle transaction. +Une source n'est autorisée à produire directement un `RawTransaction` que si elle permet de reconstruire le payload canonique complet attendu par Store. -Décision : **capability secondaire** pour confirmation/repair ciblé, jamais source principale d'ingestion. Une hydration reste nécessaire pour persister le RAW complet. - -### 4.7 WS blockSubscribe : direct full sous contraintes - -`blockSubscribe` peut fournir les blocs `confirmed`/`finalized`, filtrés par `all` ou par `mentionsAccountOrProgram`. Avec `transactionDetails=full`, il peut transporter directement les transactions nécessaires à la normalisation RAW. - -La méthode reste toutefois documentée comme **instable** par Solana et n'est disponible que si le validator active explicitement la block subscription ainsi que l'historique transactionnel requis. KSP doit donc la traiter comme capability annoncée/testée par endpoint, pas comme propriété universelle de tout endpoint WS standard. - -### 4.8 slotSubscribe et slotsUpdatesSubscribe - -`slotSubscribe` fournit slot/parent/root et peut aider le worker à détecter que la chaîne avance. `slotsUpdatesSubscribe` fournit un lifecycle de slot plus détaillé, mais reste officiellement instable. - -Aucune de ces voies ne transporte une transaction. Elles restent auxiliaires pour continuité/diagnostic et ne justifient jamais une observation Store `RawTransaction` seules. - -### 4.9 Reconnect, ordering et gaps - -Le protocole standard ne transforme pas une reconnexion en replay des notifications perdues. KSP Transport sait resouscrire les subscriptions logiques après reconnexion et expose un compteur de gaps de continuité, mais cela ne prouve pas quels slots/transactions ont été manqués. - -Invariants de composition retenus : +Un signal incomplet reste un matériau de discovery/hydration : ```text -reconnect WS != replay -duplicate notification = acceptable et dédupliquée par identité/contenu/observation -gap détecté = déclenche une stratégie de repair distincte -repair = HTTP slot/block ou HTTP adresse selon le scope connu +signature seule +logs +transaction status +transaction body sans execution meta +shreds +slot/block meta ``` -## 5. Inventaire KSP existant +Il doit être complété avant la persistence RAW canonique. -### 5.1 Transport +## 3. Deux producteurs indépendants -| Surface KSP | Disponible | Filtres / entrée | Provenance / remarque | -|------------------------------------------------------------------|---------------|-----------------------------------------|--------------------------------------------------------------| -| `get_signatures_for_address` | oui | adresse + before/until/limit/commitment | aucune observation durable nécessaire pour la discovery | -| `get_transaction_observed` | oui | signature + config | provider + endpoint gagnant sûrs | -| `get_blocks` / `get_blocks_with_limit` | oui | range/limit + commitment | discovery de slots uniquement | -| `get_block` | oui | slot + config | GAP : pas de provider/endpoint gagnant observé | -| `get_slot` / `get_first_available_block` / `minimum_ledger_slot` | oui | bornes de continuité | auxiliaires, sans payload RAW | -| `logs_subscribe` | oui | all / allWithVotes / mentions(1 pubkey) | session snapshot fournit endpoint/provider/cluster/protocole | -| `signature_subscribe` | oui | signature connue + commitment | one-shot, terminal côté serveur | -| `block_subscribe` | oui, instable | all / mentionsAccountOrProgram + config | session snapshot fournit provenance de session | -| `slot_subscribe` / `slots_updates_subscribe` | oui | aucun filtre | signaux de continuité uniquement | +### 3.1 Job Backfill : historique paramétré et borné -Le runtime WS possède déjà des queues bornées. Une overflow d'une subscription lente est terminale pour cette subscription plutôt que de créer un backlog non borné. Le worker devra traiter cette terminaison comme une cause potentielle de gap et réparer avant de déclarer la continuité retrouvée. +`ksp-job-backfill-lib` a pour rôle de **récupérer un historique demandé**. -### 5.2 Store - -Store possède déjà les invariants nécessaires à la convergence multi-source : +Une campagne reçoit des paramètres métier explicites, par exemple : ```text -RawTransactionReference = network + signature -RawTransaction = reference + slot + block_time + payload canonique +signature ou liste de signatures +program_id / address / compte ciblé +slot ou plage de slots +borne temporelle +before / after / until +limit / page bounds +commitment +stratégie ou politique de sélection admissible +``` + +Le Job choisit ensuite, selon Config et les capabilities réellement disponibles, une stratégie en une ou plusieurs étapes : + +```text +discovery -> hydration -> normalisation -> Store +stream replay borné -> normalisation -> Store +archive -> extraction -> normalisation -> Store +``` + +Le Job est : + +```text +paramétré +borné +terminable +checkpointable lorsque la stratégie le nécessite +orienté historique / catch-up demandé +``` + +Il peut utiliser **HTTP, WS, Yellowstone gRPC, replay provider ou archive** si ces capacités permettent de satisfaire la requête historique. Il ne doit pas être modélisé comme « un Worker arrêté après N éléments ». + +### 3.2 Worker Raw Transaction Ingest : acquisition continue start/stop + +`ksp-worker-raw-transaction-ingest-lib` a pour rôle de **remplir continuellement Store à partir du moment où il est démarré**. + +Son contrôle métier V1 est volontairement court : + +```text +start +stop +snapshot / notifications +``` + +Le caller ne lui fournit pas une signature, un `program_id`, une plage historique, une limite de campagne ou une requête de backfill. Les endpoints, réseaux, sources activées, capabilities et secrets proviennent de Config/composition, pas d'un payload métier de `start`. + +À partir de son démarrage, le Worker : + +```text +acquiert les nouvelles transactions disponibles +hydrate les signaux live incomplets si nécessaire +normalise puis persiste RawTransaction + observations +publie ses notifications indépendamment de leurs lecteurs +continue jusqu'à stop ou fault +``` + +Le Worker peut utiliser **WS, Yellowstone gRPC, HTTP, block polling, provider streams ou sources EARLY** si ces capacités servent l'acquisition live. + +Il ne lance pas de campagne historique arbitraire. + +### 3.3 Continuité Worker ≠ Backfill + +Le Worker peut utiliser un replay ou HTTP pour **réparer une perte de continuité apparue pendant son acquisition active** : + +```text +stream actif + -> gap détecté + -> replay from_slot / HTTP hydration / block recovery + -> frontier live restauré + -> reprise du flux +``` + +Cette réparation reste liée au frontier du Worker et ne transforme pas le Worker en moteur historique. + +Inversement : + +```text +« récupère les transactions du programme X depuis le slot Y » +« récupère les 100 000 dernières signatures de cette adresse » +« rejoue cette plage d'archive » +``` + +sont des campagnes Job Backfill. + +### 3.4 Absence de relation Job ↔ Worker + +Le modèle interdit les dépendances fonctionnelles suivantes : + +```text +Worker -> Job Backfill +Job Backfill -> Worker +Worker délègue un gap au Job +Job démarre un Worker temporaire +coordination obligatoire entre leurs lifecycles +checkpoint partagé entre Job et Worker +``` + +Ils peuvent être actifs séparément ou simultanément. S'ils observent la même transaction, **Store et les invariants RAW** fournissent l'idempotence et la détection de conflit ; il ne s'agit pas d'une collaboration entre les deux producteurs. + +## 4. Capabilities d'acquisition orthogonales aux producteurs + +La configuration et l'architecture ne doivent pas réduire les sources à un enum fermé `HTTP | WS | gRPC`. + +Les capabilities utiles sont plutôt : + +```text +live_direct_transaction +live_direct_block +live_transaction_discovery +live_early_transaction +transaction_hydration +block_hydration +history_discovery +bounded_replay +continuity_boundary +continuity_repair +archive_history +``` + +Une source concrète peut fournir plusieurs capabilities. Une capability peut être consommée par le Job, le Worker ou les deux selon l'intention. + +## 5. Matrice des méthodes et de leur applicabilité + +| Famille / méthode | Contenu obtenu | RAW complet | Usage Worker live | Usage Job Backfill | Remarque | +|-----------------------------------------------------------------|---------------------------------------|------------------------------|------------------------------------------------------------|---------------------------------------------|------------------------------------------------------| +| HTTP `getTransaction(signature)` | transaction depuis signature connue | oui si disponible | oui, hydration d'un signal live | oui, hydration historique | dépend de la rétention du RPC | +| HTTP `getSignaturesForAddress` + `getTransaction` | discovery adressée puis transaction | oui après hydration | non comme campagne de scan | oui, stratégie historique principale | naturellement paramétré par adresse/programme | +| HTTP `getBlocks` / `getBlocksWithLimit` | slots confirmés | non | oui pour suivre/recoller le frontier courant si nécessaire | oui pour énumérer une plage historique | discovery par slots | +| HTTP `getBlock(slot)` full | bloc et transactions | oui | oui pour live polling ou repair de continuité | oui pour historique par bloc | nécessite provenance observed en pool multi-endpoint | +| HTTP `getSlot` / `getFirstAvailableBlock` / `minimumLedgerSlot` | bornes de ledger | non | oui, continuité | oui, admission d'une campagne | aucune transaction directe | +| WS `logsSubscribe` | signature + logs | non | oui, discovery live + hydration | non pour historique pur | `mentions` standard limité à un pubkey | +| WS `signatureSubscribe` | statut d'une signature connue | non | oui, confirmation ciblée interne | possible pour une requête ciblée en attente | one-shot | +| WS `blockSubscribe` full | bloc + transactions | oui | oui | non sans mécanisme de replay historique | méthode standard instable | +| Helius `transactionSubscribe` full | transaction + meta | oui | oui | non comme source historique | extension provider | +| Yellowstone `transactions` | transaction exécutée + meta | oui | oui | oui si replay borné demandé/disponible | filters server-side | +| Yellowstone `blocks` avec transactions | bloc + transactions | oui | oui | oui si replay borné demandé/disponible | utile au live et au backfill | +| Yellowstone `transactions_status` | signature/status/error | non | oui + hydration | oui si replay/filtre borné | discovery/statut uniquement | +| Yellowstone slots / `blocks_meta` | continuité de slots | non | oui | auxiliaire | aucune transaction full | +| Yellowstone `from_slot` / replay | reprise d'un stream depuis slot | dépend du stream | oui uniquement pour continuité du Worker | oui pour campagne historique bornée | profondeur provider-specific | +| API provider historique adressée | historique signatures ou transactions | provider-dependent | non comme campagne historique | oui | exemple Helius `getTransactionsForAddress` | +| RPC archive standard | méthodes HTTP sur ledger ancien | oui selon méthode | non pour recherche historique | oui | provider ou self-host | +| Old Faithful / `yellowstone-faithful` | historique par RPC/index | oui pour données disponibles | non | oui | archive spécialisée | +| transaction body pré-exécution | signature/corps sans meta finale | non | oui, EARLY + hydration | non principal | faible latence | +| shreds / deshred | fragments ou transaction reconstruite | non sans meta d'exécution | oui, EARLY + hydration | non principal | adapter spécialisé | +| Agave RPC auto-hébergé | méthodes standard | selon méthode | oui | oui | mêmes rôles que RPC standard | +| Agave + Yellowstone auto-hébergé | streams Yellowstone | selon stream | oui | oui avec rétention/replay opérateur | capability opérateur | + +Cette matrice est intentionnellement **usage-first**. HTTP n'est pas « Backfill » et gRPC n'est pas « Worker » : leur rôle dépend de l'opération effectuée. + +## 6. Stratégies Worker live + +### 6.1 Acquisition directe + +Sources capables de produire directement un matériau transactionnel complet : + +```text +Yellowstone transactions +Yellowstone blocks avec transactions +WS blockSubscribe full +Helius transactionSubscribe full +provider stream compatible full transaction +``` + +Chemin logique : + +```text +source live full + -> adaptation source-neutral + -> canonicalisation RAW + -> Store + -> notification Worker +``` + +### 6.2 Discovery live + hydration + +Sources rapides mais incomplètes : + +```text +logsSubscribe +transactions_status +signature/status feed +transaction body pré-exécution +shreds/deshred +``` + +Chemin logique : + +```text +signal live + -> identité/signature + -> getTransaction ou autre hydration admissible + -> canonicalisation RAW + -> Store +``` + +HTTP est donc une capability normale du Worker lorsqu'il sert l'hydration live. + +### 6.3 Suivi live par blocs HTTP + +Une implémentation Worker peut aussi suivre le réseau sans subscription push : + +```text +getSlot / borne courante + -> nouveaux slots depuis le démarrage + -> getBlock full + -> extraction transaction par transaction + -> Store +``` + +Cette stratégie est du **live polling** tant qu'elle suit le frontier depuis le démarrage ; elle devient historique si on lui demande une plage ancienne, auquel cas le rôle revient au Job Backfill. + +### 6.4 Réparation de continuité + +Le Worker doit distinguer reconnexion et continuité : + +```text +reconnect réussi != absence de gap +``` + +Pour un gap survenu pendant son run, il peut utiliser dans cet ordre de préférence selon les capabilities : + +```text +1. replay adressable du stream depuis le frontier connu +2. source live redondante ayant couvert la plage +3. HTTP getBlock/getTransaction pour les références/slots manquants +4. reprise live une fois le frontier réconcilié +``` + +Aucune étape ne reçoit une requête historique arbitraire du caller. + +### 6.5 Notifications + +Le Worker persiste d'abord la vérité RAW durable puis publie une projection/notification adaptée à son API concrète. Les notifications sont indépendantes de leurs lecteurs : + +```text +aucun consumer obligatoire +aucune callback consumer-owned +aucune queue non bornée imposée par ksp-worker-api +``` + +## 7. Stratégies Job Backfill + +### 7.1 Discovery adressée + +Vertical slice déjà prouvé : + +```text +request avec address/program_id/borne + -> getSignaturesForAddress + -> getTransaction observed + -> canonicalisation + -> Store +``` + +### 7.2 Signatures explicites + +```text +request avec signatures + -> getTransaction observed + -> canonicalisation + -> Store +``` + +### 7.3 Historique par blocs + +```text +request avec plage slot/temps/limite + -> getBlocks/getBlocksWithLimit + -> getBlock observed + -> extraction transaction par transaction + -> Store +``` + +### 7.4 Replay Yellowstone borné + +Si un provider sert réellement `from_slot`/replay : + +```text +request historique bornée + -> transactions ou blocks depuis from_slot + -> arrêt lorsque la borne de campagne est atteinte + -> Store +``` + +Le fait d'utiliser un stream gRPC ne change pas la nature Job : la campagne reste paramétrée, bornée et terminable. + +### 7.5 APIs historiques provider + +Exemples admis : + +```text +Helius getTransactionsForAddress +provider archive via RPC standard +provider persistent history stream +``` + +Ces stratégies restent des adapters spécialisés et ne remplacent pas les primitives standard. + +### 7.6 Archives + +Pour les historiques hors fenêtre RPC/replay : + +```text +Old Faithful / yellowstone-faithful +archive provider +CAR / Filecoin / S3 / Bigtable ou autre substrat futur +``` + +Les substrats directs restent une extension plus lointaine ; l'adapter doit toujours converger vers le même matériau source-neutral et le même format RAW canonique. + +## 8. Taxonomie de preuve + +Le support architectural et la preuve live restent séparés : + +```text +possibilité connue = protocole/provider/infrastructure capable en principe +support KSP = adapter/capability implémenté ou planifié +preuve KSP = comportement réellement exercé sur un endpoint accessible +``` + +Codes : + +| Code | Sens | +|---------------|-----------------------------------------------------------------------| +| `ADMIS` | capability à représenter dans le socle KSP | +| `SPÉCIALISÉ` | adapter provider/source autorisé sans contaminer le contrat générique | +| `EARLY` | signal incomplet précoce ; hydration/confirmation obligatoire | +| `SUNSET` | voie historique conservée seulement pour traçabilité/migration | +| `EXISTANT` | surface KSP déjà présente | +| `PLANIFIÉ` | adaptation à implémenter dans la release indiquée | +| `PROUVÉ` | propriété exercée ou directement démontrée pour le périmètre indiqué | +| `TESTABLE` | accès disponible mais smoke KSP encore à produire | +| `NON PROUVÉ` | capability admise sans preuve live actuelle | +| `BLOQUÉ TIER` | branche admise mais accès live indisponible avec les comptes actuels | +| `À REVALIDER` | documentation provider insuffisante ou contradictoire | + +Règles : + +```text +NON PROUVÉ != REJETÉ +PAYANT/BLOQUÉ != NON SUPPORTÉ +IMPLÉMENTÉ != PROUVÉ LIVE +PROUVÉ CHEZ UN PROVIDER != GARANTI CHEZ TOUS LES PROVIDERS +``` + +## 9. Matrice providers, réseaux, coût et preuve + +Audit externe daté du **4 septembre 2026**. + +| Provider / infrastructure | Réseaux utiles documentés | HTTP / WSS standard | Yellowstone / stream full | Historique / replay | Prix / tier utile au 04-09-2026 | Accès KSP actuel | Preuve / décision KSP | +|---------------------------------|-----------------------------------------|-----------------------------|-------------------------------------------|-----------------------------------------------------|-------------------------------------------------------------------------------|--------------------------------|------------------------------------------------------------------------| +| Solana public RPC | Mainnet-beta, Devnet, Testnet | oui | non | ledger public borné | gratuit, fortement rate-limité | oui | standard `PROUVÉ/TESTABLE`, baseline seulement | +| provider RPC standard générique | selon provider | oui si méthodes exposées | éventuel | selon provider | variable | selon compte | `ADMIS` par capabilities, jamais par nom | +| Agave auto-hébergé | Mainnet, Devnet, Testnet, local, custom | oui | Yellowstone si plugin | rétention opérateur | coût infrastructure | non actuellement | `ADMIS`, environnement KSP `NON PROUVÉ` | +| Helius | Mainnet + Devnet | Free+ | Devnet Developer+, Mainnet Business+ | LaserStream 24 h, history API | Free $0, Developer $49, Business $499, Professional $999 | HTTP/WSS gratuit | standard `TESTABLE`, gRPC Mainnet `BLOQUÉ TIER`, replay 24 h documenté | +| PublicNode | Mainnet + Testnet | gratuit | Yellowstone gRPC gratuit | archive sur demande, profondeur replay inconnue | endpoint public gratuit | Mainnet gRPC + RPC disponibles | gRPC Mainnet déjà exercé, profondeur replay `NON PROUVÉE` | +| OrbitFlare | Mainnet + Devnet | oui | Devnet Free/Developer, Mainnet add-on/Pro | archival data, profondeur gRPC inconnue | Free $0, Developer $49, Growth $399, Scale $799, Pro $999, Mainnet gRPC +$500 | Devnet gratuit possible | Devnet `TESTABLE`, Mainnet payant, replay `NON PROUVÉ` | +| QuickNode | Mainnet-beta, Testnet, Devnet | oui | Scale/Business ou add-on | `fromSlot` jusqu'à 3000 slots, archive selon réseau | Scale $499, Business $999 | pas de tier gRPC actuel | `BLOQUÉ TIER`, replay provider documenté | +| Alchemy | Mainnet + Devnet | oui | Yellowstone PAYG/Enterprise | replay documenté mais contradictoire | $75/TB gRPC, PAYG/Enterprise | standard gratuit possible | gRPC `BLOQUÉ/À REVALIDER` | +| Chainstack | Mainnet + Devnet RPC, gRPC Mainnet | Free Developer + payant | add-on Yellowstone Growth+ | archive Growth+, replay gRPC inconnu | Developer $0, Growth $49, gRPC $49/2, $149/7, $449/25 streams | standard gratuit possible | standard `TESTABLE`, gRPC `BLOQUÉ TIER`, replay `NON PROUVÉ` | +| Shyft | Mainnet + Devnet RPC | Free RPC | Build/Grow/Accelerate Yellowstone | replay jusqu'à 150 slots | Free $0, Build $199, Grow $349, Accelerate $649 | RPC gratuit possible | standard `TESTABLE`, gRPC `BLOQUÉ TIER`, 150 slots documentés | +| Triton One | Solana, réseau par endpoint | oui / Whirligig | Dragon's Mouth, Riptide, Fumarole | Fumarole persistant, Old Faithful | dépôt PAYG $125, streaming $0.08/GB, RPC $0.08/GB + $10/M calls | pas de compte actuel | `BLOQUÉ TIER`, architecture `ADMIS` | +| dRPC | Solana, réseau gRPC à qualifier | HTTP/WSS | Yellowstone Premium/Advanced | profondeur replay inconnue | Premium $399, Advanced $599 | standard éventuellement | gRPC `BLOQUÉ TIER`, replay `NON PROUVÉ` | +| Ankr | Mainnet + Devnet | Freemium/Premium HTTP + WSS | Yellowstone Solana non prouvé | ledger rolling, archive générique | $0.00005 par request/subscription/notification Solana | freemium possible | standard `TESTABLE`, ne pas inférer gRPC Solana | +| GetBlock | Mainnet-beta + Devnet | Free+ HTTP/WSS | Yellowstone dedicated/add-on | archive selon plan | Free $0, Starter $49, Advanced $199, Pro $499, Enterprise $999 | standard gratuit possible | standard `TESTABLE`, gRPC payant `NON PROUVÉ` | +| autre Yellowstone-compatible | provider/network-dependent | variable | oui si protocole compatible | provider-dependent | inconnu | non | `ADMIS` via descriptors/capabilities | + +### 9.1 Alchemy : replay à revalider + +Les pages Alchemy courantes ne sont pas cohérentes entre elles : certaines mentionnent environ **6000 slots**, tandis que la page dédiée Historical Replay annonce `from_slot` dans environ **432 000 slots / ~48 h**. + +KSP ne doit donc pas encoder une constante Alchemy. La capability replay doit être qualifiée par documentation courante + test au moment de l'activation. + +## 10. Sources ultra-low-latency et pre-execution + +Ces voies sont conservées dans le socle de possibilités pour le Worker, mais elles ne deviennent jamais une vérité RAW complète tant que les métadonnées d'exécution nécessaires ne sont pas disponibles. + +| Source | Transport | Réseau / accès | Contenu utile | Meta d'exécution | Prix / accès daté | Usage KSP | +|----------------------------------|---------------------|----------------------------|--------------------------------------|------------------|--------------------------------------------|-------------------------------------| +| Helius Shred Delivery | UDP shreds | Mainnet, beta/qualified | shreds bruts | non | Professional+, prix non figé | `EARLY`, deshred + hydration | +| Helius preprocessed transactions | gRPC | Helius Shred Delivery | transaction prétraitée | non | Professional+, 20 crédits/MB | `EARLY`, body/signature + hydration | +| OrbitFlare Jetstream | gRPC basé shreds | provider-dependent | transaction faible latence | non | depuis environ $500/mo selon offre | `EARLY` + hydration | +| Shyft RabbitStream | gRPC depuis shreds | provider-dependent, payant | transactions extraites des shreds | non/à confirmer | Build+ $199+ | `EARLY` + hydration | +| Triton Deshred | extension gRPC | shared/dedicated Triton | transaction reconstruite | non | offre streaming PAYG | `EARLY` + hydration | +| Triton Shred Streaming | shred stream | Triton | shreds | non | $1500/mo/IP/datacenter | phase avancée | +| bloXroute Transaction Streamer | gRPC | Solana | signature + bytes transaction + slot | non | $500/mo | `EARLY`, body + hydration | +| bloXroute Shreds | UDP/gateway | Solana | shreds | non | $500/mo | phase avancée | +| DoubleZero Edge | UDP multicast | feed Solana shreds | shreds bruts | non | $450/$900/$1500 par machine/mo selon metro | deshred + hydration | +| Jito ShredStream | shreds/local decode | Solana | shreds -> transactions | non | sunset | `SUNSET` le 5 septembre 2026 | +| Turbine/shred feed auto-opéré | UDP/local | cluster opéré | shreds bruts | non | coût infrastructure | possibilité générique future | + +Jito prévoit l'arrêt complet de ShredStream le **5 septembre 2026** et recommande DoubleZero Edge. La ligne Jito reste uniquement pour exhaustivité historique/migration. + +## 11. Réseaux et stratégie de preuve + +Le support de stratégie doit rester network-neutral ; les smokes utilisent pragmatiquement les accès disponibles. + +| Réseau KSP | Preuves prioritaires disponibles | Branches complémentaires | Règle | +|----------------|-------------------------------------------------------------------------------|-----------------------------------------------------------------------------------|-----------------------------------------------------| +| `mainnet-beta` | HTTP/WS standard multi-provider, PublicNode Yellowstone gRPC, Helius HTTP/WSS | Helius gRPC payant, QuickNode, Alchemy, Chainstack, Shyft, Triton, dRPC, GetBlock | identité réseau canonique Store | +| `devnet` | Solana public HTTP/WS, Helius standard, OrbitFlare Yellowstone gratuit | Helius LaserStream Developer+, Alchemy, self-host | terrain privilégié pour protocole sans coût Mainnet | +| `testnet` | Solana public HTTP/WS, PublicNode RPC/WS/Yellowstone | self-host et autres providers | ne pas extrapoler disponibilité provider | +| local/custom | fixtures, Agave local, Yellowstone local si nécessaire | serveurs contrôlés | prouver gaps, replay, backpressure et erreurs | + +Plan de preuve : + +```text +1. tests déterministes pour chaque adapter/capability implémenté +2. smokes live opt-in sur combinaisons gratuites/accessibles +3. smokes live ignored pour branches payantes jusqu'à obtention du tier +``` + +Une branche peut donc être **implémentée mais non prouvée live**, à condition que la documentation le dise explicitement. + +## 12. Inventaire KSP disponible + +### 12.1 Transport standard HTTP + +KSP possède déjà : + +```text +get_signatures_for_address +get_transaction / get_transaction_observed +get_blocks / get_blocks_with_limit +get_block +get_slot +get_first_available_block +minimum_ledger_slot +``` + +Gap principal : `getBlock` n'a pas encore d'équivalent `get_block_observed`. Pour un pool multi-endpoint, la provenance provider/endpoint exacte doit être conservée avant de persister une observation. + +### 12.2 Transport WebSocket + +KSP possède déjà : + +```text +logsSubscribe +signatureSubscribe +blockSubscribe +slotSubscribe +slotsUpdatesSubscribe +Helius transactionSubscribe +``` + +Le runtime WS possède des queues bornées et une logique de reconnect/resubscribe. Un reconnect ne constitue toutefois pas un replay adressable. + +### 12.3 Yellowstone gRPC + +Le moteur KSP expose déjà les familles nécessaires : + +```text +transactions +transactions_status +blocks +blocks_meta +slots +from_slot +SubscribeReplayInfo / snapshot de continuité associé +``` + +Il faut réutiliser ce moteur générique pour les providers compatibles plutôt que créer un client gRPC par provider. + +### 12.4 Store + +Les primitives de convergence existent déjà autour de : + +```text +RawTransactionReference +RawTransaction RawTransactionObservation RawAcquisitionProvenance RawTransactionWrite::persist_raw_transaction_acquisition RawTransactionObservationWrite::record_raw_transaction_observation ``` -`RawAcquisitionProvenance` sait déjà conserver de manière sûre : provider, protocole, méthode, origin, endpoint logique, commitment, filter id, capture session id, timestamps et hash/taille du payload source. Aucun DTO Transport ne doit être persistant directement. +Aucun backend physique ne doit entrer dans le Worker ou le Job. -### 5.3 Normalisation RAW actuelle +### 12.5 Config -Le premier canonicalizer RAW v1 est actuellement implémenté dans `ksp-job-backfill-lib::conversion` autour de `getTransaction` observé. Cette implémentation a démontré le format, le hash canonique, la provenance et la persistence du vertical slice Backfill, mais son ownership Job n'est pas réutilisable comme dépendance du futur Worker. - -Décision de cette tranche : **ne pas copier** cette logique dans `0.3.10`. Le handoff final devra choisir une ownership commune ou une extraction compatible avec les frontières de dépendances. - -### 5.4 Config et réseaux - -| Profil | Cluster Transport | Surfaces standard | État | -|-------------------------|-------------------|---------------------------|------------------------------------| -| `devnet_public` | devnet | HTTP + WS standard | déjà présent | -| `mainnet_public` | mainnet-beta | HTTP + WS standard | déjà présent | -| `mainnet_backfill_pool` | mainnet-beta | HTTP pool + WS standard | déjà présent ; rôles backfill HTTP | -| `publicnode_mainnet` | mainnet-beta | HTTP + WS standard + gRPC | gRPC traité en pre.005 | -| `publicnode_testnet` | testnet | HTTP + WS standard + gRPC | gRPC traité en pre.005 | - -Les URLs et secrets restent exclusivement Config-owned. `0.3.9` n'ajoute aucun endpoint ni secret. - -#### Canonicalisation Mainnet - -L'audit interne montre une distinction existante : +Config reste seul propriétaire : ```text -profile/composite id : mainnet -network / cluster : mainnet-beta +réseau +endpoints +provider/protocole +secrets +activation des sources +capabilities déclarées +priorités/composition ``` -`std.store.json` et `std.transport.json` utilisent déjà `mainnet-beta` comme identité réseau/cluster. Quelques exemples/tests de Backfill utilisent encore `RawNetworkId("mainnet")` comme valeur synthétique. Pour l'ingestion durable, la direction retenue est de conserver **`mainnet-beta` comme identité réseau canonique** et de réserver `mainnet` aux identifiants de profil/UI lorsque nécessaire. Aucune migration n'est effectuée en `pre.004`. +Les prix/tiers d'audit ne doivent pas devenir une politique runtime. -### 5.5 Interface passive +`mainnet-beta` reste l'identité réseau durable ; `mainnet` peut rester un identifiant de profil/composition/UI. -`ksp-interface-lib` possède `TransactionExecutionEvent` et `SlotLifecycleEvent`, utiles lorsque plusieurs producers/consumers partagent exactement ces faits passifs. Ils ne remplacent ni les DTOs Transport riches ni `RawTransaction`/`RawTransactionObservation` et ne doivent pas être utilisés comme conteneurs d'acquisition génériques. +## 13. Normalisation RAW commune sans couplage Job/Worker -## 6. Gaps préparatoires identifiés en pre.004 +La canonicalisation RAW v1 actuellement prouvée dans `ksp-job-backfill-lib::conversion` ne doit ni y rester enfermée ni être copiée dans le Worker. -| ID | Owner futur | Gap / décision à matérialiser | Release cible | Motif | -|-------|-------------------------|---------------------------------------------------------------------------------------------------------------|-----------------|---------------------------------------------------------------------------------------------------------------------| -| TR-A | Transport | ajouter une voie observée pour `getBlock` si le scan bloc est admis en V1 | 0.3.10 | nécessaire pour provider/endpoint exacts dans `RawTransactionObservation` avec pool multi-endpoint | -| TR-B | Transport/ingest | définir l’extraction déterministe transaction-par-transaction depuis `SolanaConfirmedBlock` | 0.3.10 | le DTO bloc existe, la conversion RAW transactionnelle commune n’existe pas encore | -| RAW-A | Architecture/code owner | sortir la normalisation RAW v1 de l’enfermement Backfill sans duplication | 0.3.10 | la logique canonique actuelle vit dans `ksp-job-backfill-lib::conversion` | -| REC-A | Worker ingest | associer reconnect WS à une stratégie explicite de gap repair | 0.3.10 | resubscribe != replay ; `continuity_gap_count` n’identifie pas les transactions manquées | -| CFG-A | Config/composition | exprimer des rôles/capabilities d’acquisition, pas un simple enum HTTP/WS/gRPC | 0.3.10 | les profils existent déjà mais le rôle ingest multi-source n’est pas matérialisé | -| NET-A | Naming | retenir `mainnet-beta` comme identité réseau durable/configurée et `mainnet` seulement comme profile/UI alias | 0.3.10 / 0.3.12 | Store + Transport Config utilisent déjà `mainnet-beta`; quelques exemples/tests Backfill utilisent encore `mainnet` | +Le handoff retient une petite crate source-neutral commune, à matérialiser pendant `0.3.10` : -Ces gaps sont des entrées de handoff. `pre.004` ne les implémente pas. +```text +ksp-raw-transaction-lib +``` -## 7. Sources externes de l'audit daté +Elle n'organise aucune collaboration entre Job et Worker. Elle constitue une dépendance inférieure commune, au même titre qu'un contrat Store partagé. -Consultées le 4 septembre 2026 : +Responsabilités prévues : -| Source Solana | URL | +```text +format id/version RAW +matériau source-neutral transaction complète +canonical payload bytes +content hash +construction RawTransaction +construction/projection d'observation depuis métadonnées sûres +validation réseau/signature/slot/meta/version/index +``` + +Responsabilités interdites : + +```text +runtime +HTTP/WS/gRPC +Config +scheduler +Job lifecycle +Worker lifecycle +backend Store physique +``` + +Graphe conceptuel : + +```text +ksp-job-backfill-lib --------------------> ksp-raw-transaction-lib ----> Store façade +ksp-worker-raw-transaction-ingest-lib ---> ksp-raw-transaction-lib ----> Store façade + +ksp-job-backfill-lib --------------------> ksp-onchain-transport-lib +ksp-worker-raw-transaction-ingest-lib ---> ksp-onchain-transport-lib + +aucun edge Job <-> Worker +``` + +La migration doit préserver exactement les golden bytes/hash RAW v1 déjà prouvés. Aucun RAW v2 n'est justifié. + +## 14. Handoff `0.3.10` : Worker live + +### 14.1 Contrat fonctionnel + +`ksp-worker-raw-transaction-ingest-lib` doit : + +```text +être un consumer de ksp-worker-api +être démarré/arrêté sans requête historique métier +ouvrir les sources activées par Config +acquérir à partir du démarrage +supporter plusieurs sources simultanées +normaliser et persister RawTransaction + observations +publier snapshots/notifications concrètes Worker +réparer seulement ses propres pertes de continuité live +``` + +Il ne doit pas : + +```text +recevoir signature/program_id/plage/limit de campagne au start +chercher arbitrairement avant son frontier live +instancier ou appeler ksp-job-backfill-lib +attendre un Job pour continuer +hardcoder un provider unique +``` + +### 14.2 Sources Worker V1 à représenter + +À implémenter autant que possible, même si certaines preuves live restent bloquées par tier : + +```text +Yellowstone transactions +Yellowstone blocks +Yellowstone status + hydration +WS logsSubscribe + HTTP getTransaction +WS blockSubscribe full +Helius transactionSubscribe full +HTTP live block polling +HTTP hydration +replay Yellowstone pour continuité du run +sources EARLY via adapter extensible +``` + +### 14.3 Gaps Transport Worker + +| ID | Adaptation | Motif | +|--------|-----------------------------------------------------------------------------------|------------------------------------------------------| +| `TR-B` | `get_block_observed` symétrique de `get_transaction_observed` | provenance exacte en pool HTTP | +| `TR-C` | projection source-neutral des transactions full WS/Yellowstone | éviter plusieurs canonicalizers filaires | +| `TR-D` | métadonnées sûres d'acquisition live au moment de la conversion | observation uniforme | +| `TR-E` | conserver/exploiter `from_slot`, replay info et snapshots de continuité existants | ne pas créer un second moteur Yellowstone | +| `TR-F` | adapters EARLY uniquement quand leur protocole est réellement implémenté | réserver la capability sans tout coder immédiatement | + +### 14.4 Config Worker + +La composition doit exprimer des routes/capabilities de sources, pas des requêtes métier de campagne : + +```text +source id +network +endpoint ref +capabilities +priority +enabled +settings techniques nécessaires +``` + +Elle peut activer plusieurs providers/endpoints simultanément. Les secrets restent Config-owned, avec réutilisation unique de `KSP_SECRET_HELIUS_API_KEY` pour les surfaces Helius concernées. + +## 15. Handoff `0.3.12` : Job Backfill multi-stratégie + +Le Job doit conserver son vertical slice existant puis ajouter des stratégies historiques choisies selon requête + capabilities + configuration. + +| Stratégie | Entrée de campagne typique | Acquisition | Admission | +|----------------------------------------|-----------------------------------|----------------------------|------------------| +| GSFA + getTransaction | address/program_id + bornes/limit | discovery + hydration HTTP | déjà existante | +| signatures explicites + getTransaction | signatures | hydration HTTP | déjà existante | +| scan blocs | slots/temps/limit | getBlocks + getBlock | oui | +| Yellowstone transactions replay | from slot/plage/filtre | stream full borné | oui | +| Yellowstone blocks replay | plage/filtre | stream bloc borné | oui | +| Helius getTransactionsForAddress | address + filtres provider | history API | oui spécialisé | +| provider archive via RPC | plage historique | RPC standard archive | oui | +| Old Faithful | plage historique | RPC/index archive | oui expérimental | +| substrat archive direct | dataset + plage | adapter spécifique | futur | + +Le Job peut donc utiliser gRPC ou WS/replay si cela répond à une campagne historique. Sa nature reste Job parce que l'entrée est paramétrée, la campagne bornée et la terminaison attendue. + +## 16. Priorité de réalisation sans réduire le socle + +L'exhaustivité de l'architecture ne signifie pas que chaque intégration vendor-specific doit être codée dans la première prerelease. + +Ordre conseillé : + +```text +0.3.10 P0 : normalisation RAW commune +0.3.10 P0 : observed getBlock + adapters source-neutral +0.3.10 P0 : Yellowstone transactions/blocks live +0.3.10 P0 : WS logs + hydration, blockSubscribe, Helius transactionSubscribe +0.3.10 P0 : HTTP live block polling/hydration +0.3.10 P1 : multi-source concurrency, dedup, provenance, continuity repair +0.3.10 P1 : smokes gratuits Mainnet/Devnet/Testnet +0.3.10 P2 : EARLY adapters accessibles +0.3.12 P0 : block scan historique +0.3.12 P0 : replay Yellowstone borné +0.3.12 P1 : provider history/archive +0.3.12 P1 : Old Faithful +plus tard : substrats directs et sources vendor-specific sans accès actuel +``` + +Une branche `ADMIS` reste dans le modèle même si son smoke live est impossible aujourd'hui. + +## 17. Référence fonctionnelle historique kbot3 + +L'archive kbot3 fournie par l'opérateur a été auditée uniquement comme référence fonctionnelle historique. + +Elle confirme notamment les besoins : + +```text +discovery adressée +hydration getTransaction +pagination/reprise bornée +frontier/checkpoint pour campagne historique +retries/concurrency bornés +session WS persistante +reconnect/resubscribe +provenance d'acquisition +``` + +Elle confirme aussi deux limites que KSP ne doit pas reproduire : + +```text +retry d'une route choisie != provenance multi-source complète +reconnect WS != replay historique +``` + +Aucun code, DTO, Config, endpoint, secret, dépendance ou convention de version kbot3 n'est repris. + +## 18. Sources externes auditées + +Sources consultées le **4 septembre 2026**. Cette liste consolide les anciens audits A/B dans un seul registre documentaire. + +### 18.1 Solana standard + +| Sujet | URL | |-------------------------|-------------------------------------------------------------| +| clusters/public RPC | https://solana.com/docs/references/clusters | | getSignaturesForAddress | https://solana.com/docs/rpc/http/getsignaturesforaddress | | getTransaction | https://solana.com/docs/rpc/http/gettransaction | | getBlocks | https://solana.com/docs/rpc/http/getblocks | @@ -249,658 +822,65 @@ Consultées le 4 septembre 2026 : | slotSubscribe | https://solana.com/docs/rpc/websocket/slotsubscribe | | slotsUpdatesSubscribe | https://solana.com/docs/rpc/websocket/slotsupdatessubscribe | -Les quotas, tiers provider et capacités Helius/Yellowstone ne sont volontairement pas documentés ici ; ils appartiennent à l'audit `pre.005`. +### 18.2 Yellowstone et providers -## 8. État après pre.004 +| Source | URL | +|----------------------------------|---------------------------------------------------------------------------------------------------| +| Yellowstone proto | https://github.com/rpcpool/yellowstone-grpc/blob/master/yellowstone-grpc-proto/proto/geyser.proto | +| Yellowstone README | https://github.com/rpcpool/yellowstone-grpc/blob/master/README.md | +| Yellowstone changelog | https://github.com/rpcpool/yellowstone-grpc/blob/master/CHANGELOG.md | +| Helius data streaming | https://www.helius.dev/docs/data-streaming | +| Helius LaserStream | https://www.helius.dev/blog/introducing-laserstream | +| Helius WebSockets | https://www.helius.dev/blog/laserstream-websockets | +| Helius enhanced WebSockets | https://www.helius.dev/blog/introducing-next-generation-enhanced-websockets | +| Helius getTransactionsForAddress | https://www.helius.dev/blog/introducing-gettransactionsforaddress | +| Helius preprocessed transactions | https://www.helius.dev/docs/shred-delivery/preprocessed-transactions | +| PublicNode Solana | https://solana.publicnode.com/ | +| OrbitFlare Yellowstone | https://docs.orbitflare.com/data-streaming/yellowstone | +| OrbitFlare RPC | https://orbitflare.com/products/rpc-nodes | +| OrbitFlare gRPC | https://orbitflare.com/products/solana-grpc | +| QuickNode Yellowstone | https://www.quicknode.com/guides/solana-development/tooling/solana-grpc/solana-grpc | +| QuickNode gRPC plans | https://www.quicknode.com/blog/solana-grpc-is-now-included-with-scale-and-business-plans | +| Alchemy Solana gRPC | https://www.alchemy.com/solana-grpc | +| Alchemy Yellowstone quickstart | https://www.alchemy.com/docs/reference/yellowstone-grpc-quickstart | +| Alchemy historical replay | https://www.alchemy.com/docs/reference/yellowstone-grpc-historical-replay | +| Alchemy compute/bandwidth | https://www.alchemy.com/docs/reference/compute-unit-costs | +| Chainstack Yellowstone | https://chainstack.com/yellowstone-grpc-more-streams-same-price/ | +| Shyft Yellowstone | https://shyft.to/solana-yellowstone-grpc | +| Shyft pricing | https://shyft.to/solana-rpc-grpc-pricing | +| Shyft RabbitStream | https://shyft.to/solana-shreds-rabbitstream | +| Triton pricing | https://triton.one/pricing | +| Triton Yellowstone | https://blog.triton.one/complete-guide-to-solana-streaming-and-yellowstone-grpc/ | +| Triton Fumarole | https://blog.triton.one/introducing-yellowstone-fumarole/ | +| Triton Deshred | https://blog.triton.one/deshred-transactions-the-fastest-path-to-solana-data/ | +| dRPC Yellowstone | https://drpc.org/docs/solana-yellowstone-geyser-grpc | +| Ankr Solana | https://www.ankr.com/docs/rpc-service/chains/chains-list/s-t/ | +| Ankr pricing | https://www.ankr.com/docs/rpc-service/pricing/ | +| GetBlock pricing | https://getblock.io/pricing-new/ | +| bloXroute pricing | https://bloxroute.com/pricing/ | +| Jito ShredStream | https://docs.jito.wtf/lowlatencytxnfeed/ | +| DoubleZero Edge | https://docs.malbeclabs.com/Edge%20Subscriber%20Connection/ | +| Old Faithful | https://github.com/rpcpool/yellowstone-faithful | -Décisions fermées pour le standard Solana : +Les URLs sont documentaires. Aucun endpoint runtime, token ou secret de compte n'est ajouté au dépôt par cet audit. + +## 19. Décisions fermées après `pre.006` ```text -HTTP address discovery + hydration = admis historique/catch-up/repair -HTTP block scan = admis sous gap de provenance observée -WS logsSubscribe = admis comme live discovery + hydration -WS signatureSubscribe = secondaire, signature déjà connue -WS blockSubscribe = admis sous capability explicite et instabilité -slot/ledger methods = auxiliaires de continuité -reconnect WS = jamais considéré comme replay -mainnet-beta = identité réseau canonique à préserver +centre du modèle = Store / RawTransaction +producers = Job Backfill et Worker Ingest indépendants +Job Backfill = historique paramétré, borné, terminable +Worker Ingest = acquisition continue start/stop, sans requête métier historique +protocol ownership = aucun ; HTTP/WS/gRPC/archive sont des capabilities réutilisables +Worker continuity repair = seulement gaps liés à son acquisition live, pas campagne historique +Store convergence = identité (network, signature), idempotence + conflit canonique explicite +observations = plusieurs acquisitions/provenances possibles pour un même RAW +support vs preuve = axes séparés ; NON PROUVÉ n'implique pas REJETÉ +provider model = capabilities/configuration, jamais enum provider fermé +network identity = mainnet-beta canonique +RAW canonicalisation = lower-layer commune, sans edge Job <-> Worker +0.3.10 = Worker live multi-source + adaptations communes nécessaires +0.3.12 = Job Backfill multi-stratégie historique ``` -Restent ouverts pour `pre.005`/`pre.006` : Helius, Yellowstone, autres providers, replay provider-specific, quotas/tier, stratégie multi-source V1 exacte et décision finale d'ownership du canonicalizer RAW. - -## 9. Audit daté B — Helius, Yellowstone/providers et kbot3 historique - -Audit effectué le **4 septembre 2026**. Cette tranche réaudite les capacités providers et le protocole Yellowstone avec sources primaires courantes. L'archive kbot3 fournie par l'opérateur est utilisée exclusivement comme référence fonctionnelle historique ; aucun code, DTO, URL d'endpoint, Config, secret, dependency ou convention de version n'est transféré. - -### 9.1 Helius — surfaces et tiers courants - -Depuis le 31 mars 2026, Helius indique que ses WebSockets standard et enhanced sont servis par l'infrastructure LaserStream. Cela améliore l'ingestion multi-nœuds, le failover et l'ordering côté provider, mais ne change pas le contrat filaire consommé par KSP : les méthodes WSS standard/enhanced n'exposent toujours pas de `from_slot` adressable comme Yellowstone gRPC. - -| Surface | Réseau | Accès courant | Rôle RAW | Replay / continuité | Limites utiles auditées | Décision KSP | -|------------------------------|---------------------------------------|----------------------|---------------------------------------------|-------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------| -| RPC HTTP standard | Mainnet + Devnet | Free+ | history_discovery + hydration + gap_repair | aucun replay stream ; archive standard | RPC RPS 10 / 50 / 200 / 500 selon Free / Developer / Business / Professional | ADMIS ; réutilise les wrappers standard KSP | -| WSS standard LaserStream | Mainnet + Devnet | Free+ | rôles WS standard de pre.004 | failover/replay annoncés côté service ; pas de curseur replay KSP | 5 / 150 / 250 / 1 000 connexions ; 1 000 subscriptions/connexion | ADMIS ; gap repair explicite KSP conservé | -| WSS transactionSubscribe | Mainnet + Devnet | Developer+ | live_direct_full si transactionDetails=full | continuité provider-managed ; pas de from_slot WSS KSP | filtres include/exclude/required jusqu’à 50 000 adresses ; Developer annoncé jusqu’à 100 tx subscriptions/connexion | ADMIS spécialisé ; surface KSP déjà typée | -| LaserStream gRPC Yellowstone | Devnet Developer+ ; Mainnet Business+ | Developer+/Business+ | live_direct_full + gap_repair court | from_slot + replay explicite jusqu’à 24 h | 10 M pubkeys ; 10 connexions Business, 100 Professional | PRIORITAIRE pour V1 multi-source si Config l’active | -| getTransactionsForAddress | archive adressée | Developer+ | history_discovery + hydration combinées | pagination historique, pas stream | 100 crédits/appel ; 1 000 signatures ou 100 transactions full/page | SPÉCIALISÉ backfill 0.3.12 ; option 0.3.10 non nécessaire | -| Preconfirmations | signal leader partiel | Professional+ | signal ultra-précoce spécialisé | couverture partielle ; confirmation downstream obligatoire | 10 crédits/transaction ; filtres server-side | HORS RAW canonique V1 comme source autoritative | -| Parsed Streams | live confirmed décodé | plans payants, beta | flux sémantique provider-decoded | beta ; pas owner RAW | décodage provider de 3 600+ programmes annoncé | HORS RAW canonique V1 ; utile plus tard côté decode | - -Les tarifs généraux Helius consultés affichent actuellement Free / Developer / Business / Professional à **$0 / $49 / $499 / $999** par mois, avec **10 / 50 / 200 / 500 RPC RPS**. Le trafic WSS et LaserStream est unifié à 20 crédits/MB. Ces valeurs sont des données d'audit datées et ne deviennent jamais des constantes KSP. - -#### Replay WSS Helius : distinction provider/KSP - -Helius annonce un replay de 24 heures et des reconnexions automatiques pour l'infrastructure LaserStream qui sous-tend désormais les WSS. KSP ne doit toutefois pas transformer cette annonce en garantie de protocole native : - -```text -provider Helius WSS : continuité/failover/replay gérés par le service -protocole WSS KSP : aucun curseur from_slot ni fenêtre de replay explicitement demandable -conclusion KSP : conserver gap detection + repair explicite tant que le client ne peut pas adresser la plage manquée -``` - -Cette distinction empêche de déclarer une continuité vérifiable seulement parce qu'un provider annonce une infrastructure gapless. - -#### transactionSubscribe - -`transactionSubscribe` est une extension Helius et non une méthode Solana standard. Avec `transactionDetails=full`, la notification transporte un contenu transactionnel suffisamment riche pour être candidate `live_direct_full`, sans hydration HTTP obligatoire. Les filtres `accountInclude`, `accountExclude` et `accountRequired` acceptent jusqu'à 50 000 adresses selon la documentation Helius courante. - -La surface KSP correspondante existe déjà dans `ksp-onchain-transport-lib` avec types/filtres dédiés et `HeliusLaserStreamWsSession::transaction_subscribe`. Aucune nouvelle API Transport n'est requise pour la recevoir en `0.3.10`; restent à définir la conversion RAW commune, la provenance ingest et la composition Config. - -#### LaserStream gRPC - -LaserStream gRPC est Yellowstone-compatible et documente explicitement `fromSlot` avec une rétention de replay jusqu'à 24 heures. C'est la première voie auditée qui combine : - -```text -live transaction full -filters server-side -reconnect/replay adressable par slot -gap repair court sur le même protocole -provenance provider explicite -``` - -Le tier courant est Devnet à partir de Developer et Mainnet à partir de Business. KSP possède déjà le moteur Yellowstone générique ; `0.3.10` devra donc préférer une composition provider/capability plutôt qu'une deuxième implémentation Helius gRPC. Aucun endpoint Helius gRPC n'est ajouté en `0.3.9`. - -#### getTransactionsForAddress - -Helius propose aussi `getTransactionsForAddress`, qui combine discovery adressée et hydration avec tri ascendant/descendant, filtres temporels/slot/statut et pagination. La documentation annonce jusqu'à 1 000 signatures ou 100 transactions complètes par page, pour 100 crédits/appel, sur les plans payants. - -Cette voie est principalement un candidat **Backfill `0.3.12`**. Elle ne doit pas remplacer la primitive standard `getSignaturesForAddress + getTransaction` dans l'architecture générique, mais peut devenir une stratégie provider spécialisée lorsque son coût/capability est explicitement sélectionné. - -#### Signaux Helius non retenus comme RAW canonique V1 - -Deux surfaces actuelles sont enregistrées sans les promouvoir comme sources RAW autoritatives : - -- **Preconfirmations** : signal après exécution locale du leader mais avant propagation/finalité ; couverture partielle et confirmation downstream obligatoire. Le flux transporte la transaction et le statut mais ne prouve pas que le bloc deviendra canonique. Il est complémentaire aux sources on-chain normales, pas leur remplacement. -- **Parsed Streams** : flux confirmed déjà décodé côté provider, en beta. Il est utile pour des couches de decode/analytics futures mais ne doit pas devenir la vérité RAW canonique, précisément parce que la sémantique est transformée par le provider. - -### 9.2 Yellowstone upstream — sémantique du protocole - -Le protobuf upstream courant expose dans `SubscribeRequest` les maps `transactions`, `transactions_status`, `blocks`, `blocks_meta`, `accounts`, `slots`, `entry`, ainsi qu'un `commitment`, un `ping` et un `from_slot` optionnel. La présence de `from_slot` prouve une primitive de protocole ; elle ne prouve pas la profondeur réelle de rétention d'un provider. - -| Surface Yellowstone | Contenu | RAW complet | Filtres principaux | Rôle | Décision | -|---------------------|------------------------------------------------------|-----------------------------|-------------------------------------------------------------------------------------|----------------------------------|---------------------------------------------------------------------------------------| -| transactions | transaction + meta/execution | oui | vote/failed/signature/account include/exclude/required + extensions proto courantes | live_direct_full | source générique V1 privilégiée | -| transactions_status | signature + statut/erreur/index | non | mêmes familles de filtres transactionnels | live_discovery / targeted status | hydration requise si utilisée pour RAW | -| blocks | bloc assemblé + transactions optionnelles | oui si include_transactions | account_include + include_transactions/accounts/entries | live_direct_full par conteneur | utile pour couverture globale ; coût/volume supérieurs | -| blocks_meta | métadonnées de bloc | non | tous les blocs | gap_boundary / continuity | aucune persistence RawTransaction seule | -| from_slot | curseur de reprise | n/a | champ SubscribeRequest | gap_repair / catch-up court | capability à qualifier par provider et rétention réelle | -| SubscribeReplayInfo | first_available | n/a | unary | gap_boundary | permet de borner une rétention si le provider l’implémente | -| SubscribeDeshred | transaction pré-exécution sans TransactionStatusMeta | partiel | vote + accounts include/exclude/required | signal précoce spécialisé | proto/client exposés ; serveur OSS standard UNIMPLEMENTED, extension Triton seulement | - -Les limites de filtres Yellowstone ne sont **pas des constantes universelles du protocole** : le serveur upstream permet de configurer des limites différentes, voire de ne pas appliquer certaines contraintes lorsque la section correspondante est absente. KSP doit donc découvrir/documenter les limites provider et garder ses propres bornes défensives. - -Le changelog upstream du 22 juillet 2026 est également une alerte de conception : une régression avait accepté `from_slot` avec un filtre `blocks` tout en ne rejouant aucun bloc. La présence syntaxique du replay ne suffit donc jamais ; KSP doit caractériser la version/service provider et vérifier la reprise observée. - -### 9.3 Replay provider par provider - -| Provider / voie | Réseaux prouvés | Protocole | Replay explicite audité | Applicabilité | Conclusion | -|-------------------------|-------------------------------------------------|------------------------|-----------------------------------------------------------|-------------------------------|-------------------------------------------------------------------------------------| -| Helius LaserStream gRPC | Mainnet + Devnet selon tier | Yellowstone compatible | PROUVÉ : 24 h | live_direct_full + gap_repair | provider spécialisé du standard Yellowstone ; candidat V1 prioritaire | -| PublicNode Yellowstone | Mainnet + Testnet | Yellowstone gRPC | NON PROUVÉ par source officielle consultée | live_direct_full | alternative générique ; KSP possède déjà profils/smokes live, replay à caractériser | -| OrbitFlare Yellowstone | Devnet gratuit/Developer ; accès payant au-delà | Yellowstone gRPC | NON PROUVÉ explicitement dans docs Yellowstone consultées | live_direct_full | alternative générique ; archive HTTP complète comme complément repair/history | -| OrbitFlare archive HTTP | historique depuis genesis annoncé | Solana HTTP standard | n/a | history + gap_repair | complément historique fort, pas remplacement du live | - -Pour **PublicNode**, la page Solana officielle du provider expose Mainnet/Testnet avec RPC, WS RPC, Yellowstone gRPC et archive disponible. Aucune source officielle consultée pendant cette tranche ne donne une profondeur `from_slot`, des limites de filtres ou une fenêtre de replay contractualisable. Les smokes KSP historiques prouvent le streaming live, pas le replay. - -Pour **OrbitFlare**, la documentation Yellowstone expose transactions/slots/blocks/accounts/entries, filtres et keepalive. Le pricing courant donne gRPC Devnet sur Free/Developer, puis accès payant sur les tiers supérieurs. Les docs consultées ne matérialisent pas `fromSlot` dans le request de base et ne donnent pas de profondeur de replay ; cette capability reste donc **NON PROUVÉE** pour le provider. En revanche, OrbitFlare annonce une archive Solana complète depuis genesis via les méthodes HTTP standard, ce qui constitue un complément de repair/history indépendant du flux live. - -### 9.4 État KSP face aux providers - -L'inventaire `ksp-onchain-transport-lib` montre que les deux familles les plus importantes sont déjà présentes : - -```text -Helius LaserStream WSS + transactionSubscribe -> surface provider-specific déjà typée -Yellowstone gRPC standard -> transactions/status/blocks/meta + from_slot + replay info -``` - -Le runtime Yellowstone KSP sait conserver la dernière requête, avancer `from_slot` à partir du plus haut slot observé, consulter/clamp la reprise au `first_available` et compter gaps/duplicates/replay. Cette mécanique est générique ; elle ne doit pas être transformée en garantie de lossless/exactly-once. - -La conséquence architecturale pour `0.3.10` est de **réutiliser le moteur Yellowstone existant** pour Helius/PublicNode/OrbitFlare lorsque leur configuration le permet, avec des descriptors/capabilities provider-specific. Le Worker ingest ne doit pas brancher directement sur des SDK providers. - -### 9.5 Audit fonctionnel historique de kbot3 - -L'archive kbot3 fournie a été inspectée uniquement pour identifier des comportements déjà utiles historiquement. Les constats pertinents sont : - -| Domaine historique | Comportement observé | Propriété | Leçon KSP | -|--------------------|-----------------------------------------------------------------------|--------------------------------------|--------------------------------------------------------------------------------------------| -| Historique HTTP | `BackfillSource::ExplicitSignatures` ou `AddressHistory` before/after | discovery + hydration getTransaction | concept déjà refondé dans ksp-job-backfill-lib ; ne rien recopier | -| Pagination/reprise | page_size/max_pages + `resume_before_signature` + frontier contigu | reprise historique bornée | confirme l’intérêt d’un checkpoint de job, pas d’un Worker API commun | -| Hydration | client getTransaction sélectionné puis retries bornés | payload transaction canonique | faible failover dynamique : 0.3.10 doit préférer routing/capability multi-source explicite | -| Live WS | session persistante + standard subscriptions dont logsSubscribe | reconnect/resubscribe bornés | resubscribe sans replay explicite ; repair externe requis | -| Provenance | provider/endpoint/protocol/method/commitment/capture/filter | observation par acquisition | principe conservé par Store KSP ; aucun DTO historique repris | -| Fallback | pools HTTP/WS round-robin par rôle/capability | sélection initiale | utile comme référence fonctionnelle, insuffisant seul pour continuité multi-source V1 | - -L'audit ne trouve pas de voie Yellowstone ou `transactionSubscribe` servant de fondation générique dans le chemin fonctionnel historique principal de kbot3. Il ne doit donc pas limiter les capabilities plus récentes déjà présentes dans KSP. - -La leçon conservée est fonctionnelle seulement : séparer discovery/hydration, borner retries/concurrency, conserver une frontier de reprise contiguë pour les jobs historiques, maintenir une session live persistante, et enregistrer une provenance par acquisition. Les noms de types, structures, endpoints, secrets et implémentations de kbot3 ne sont pas réutilisés. - -### 9.6 Relations entre les voies auditées - -Les premières relations sont désormais suffisamment claires pour préparer la synthèse `pre.006` : - -```text -Yellowstone transactions <-> Helius LaserStream gRPC : même famille protocolaire ; provider specialization -PublicNode Yellowstone <-> OrbitFlare Yellowstone : alternatives provider pour live direct full -Helius transactionSubscribe <-> Yellowstone tx : alternatives de transport, JSON spécialisé vs gRPC générique -standard logsSubscribe + getTransaction : alternative live discovery+hydration, plus coûteuse mais très portable -Yellowstone blocks / blockSubscribe : alternatives par conteneur bloc pour couverture globale -Helius gTFA / OrbitFlare archive / standard HTTP : stratégies historiques complémentaires ou alternatives pour Backfill -preconfirmations / deshred / parsed streams : spécialisations précoces ou sémantiques, pas vérité RAW V1 -``` - -La sélection V1 exacte, les priorités/fallbacks et les règles de combinaison restent volontairement ouvertes jusqu'à `pre.006`. - -### 9.7 Gaps supplémentaires ouverts en pre.005 - -| ID | Owner futur | Gap / décision | Cible | Motif | -|--------|--------------------|-----------------------------------------------------------------------------------------------------------------|--------|--------------------------------------------------------------------------------------------| -| TR-C | Transport/ingest | caractériser une observation RAW commune pour transactionSubscribe et Yellowstone transaction | 0.3.10 | les DTOs live diffèrent mais doivent converger vers le même contenu canonique | -| GRPC-A | Config/composition | déclarer provider/network/capabilities Yellowstone sans SDK ni protocole provider parallèle | 0.3.10 | le moteur gRPC KSP est déjà générique ; seule la composition doit sélectionner le provider | -| GRPC-B | Ingest | ne considérer from_slot comme gap repair que si replay + first_available sont réellement supportés/observés | 0.3.10 | capability protocolaire != garantie de rétention provider | -| WS-A | Ingest | conserver un repair externe pour WSS même chez Helius tant que le replay n’est pas adressable par le client KSP | 0.3.10 | continuité provider-managed non équivalente à reprise déterministe KSP | -| CFG-B | Config | réutiliser exclusivement KSP_SECRET_HELIUS_API_KEY pour toutes les surfaces Helius sélectionnées | 0.3.10 | aucun second secret Helius ne doit être créé | -| BF-A | Backfill | évaluer gTFA/archives provider comme stratégies spécialisées derrière capabilities historiques | 0.3.12 | optimiser le backfill sans contaminer le Worker live | - -Aucun de ces gaps n'est implémenté en `pre.005`. - -### 9.8 Sources externes de l'audit providers - -Consultées le 4 septembre 2026 : - -| Source | URL | -|------------------------------------|---------------------------------------------------------------------------------------------------| -| Helius — LaserStream WebSockets | https://www.helius.dev/blog/laserstream-websockets | -| Helius — RPC quickstart | https://www.helius.dev/docs/quickstart | -| Helius — WebSocket quickstart | https://www.helius.dev/docs/rpc/websocket/quickstart | -| Helius — pricing | https://www.helius.dev/pricing | -| Helius — rate limits | https://www.helius.dev/docs/billing/rate-limits | -| Helius — LaserStream gRPC | https://www.helius.dev/blog/introducing-laserstream | -| Helius — getTransactionsForAddress | https://www.helius.dev/blog/introducing-gettransactionsforaddress | -| Helius — Enhanced WebSockets | https://www.helius.dev/blog/introducing-next-generation-enhanced-websockets | -| Helius — Preconfirmations | https://www.helius.dev/blog/solana-preconfirmations | -| Helius — Parsed Streams | https://www.helius.dev/blog/parsed-events-and-streams | -| Yellowstone — protobuf | https://github.com/rpcpool/yellowstone-grpc/blob/master/yellowstone-grpc-proto/proto/geyser.proto | -| Yellowstone — README | https://github.com/rpcpool/yellowstone-grpc/blob/master/README.md | -| Yellowstone — changelog | https://github.com/rpcpool/yellowstone-grpc/blob/master/CHANGELOG.md | -| PublicNode — Solana | https://solana.publicnode.com/ | -| OrbitFlare — Yellowstone docs | https://docs.orbitflare.com/data-streaming/yellowstone | -| OrbitFlare — pricing | https://orbitflare.com/pricing | -| OrbitFlare — archive | https://orbitflare.com/products/historical-data | -| OrbitFlare — gRPC | https://orbitflare.com/products/solana-grpc | - -Les URLs ci-dessus sont des **sources documentaires**. Aucun endpoint runtime provider n'est ajouté ou modifié dans KSP par cette tranche. - -## 10. État après pre.005 - -Décisions fermées par l'audit B : - -```text -Helius standard WSS = admis, continuité provider-managed mais repair KSP conservé -Helius transactionSubscribe = admis comme live_direct_full spécialisé -Helius LaserStream gRPC = admis comme Yellowstone provider + replay 24 h prouvé -Yellowstone transactions = source générique live_direct_full prioritaire -Yellowstone transaction_status = signal/status incomplet ; hydration requise pour RAW -Yellowstone blocks = direct full si transactions incluses -Yellowstone blocks_meta = continuité seulement -from_slot = capability à qualifier provider par provider -PublicNode replay = non prouvé par docs officielles consultées -OrbitFlare replay gRPC = non prouvé ; archive HTTP depuis genesis prouvée -kbot3 = référence fonctionnelle seulement, aucune source de code/Config -``` - -La synthèse `pre.006` doit maintenant convertir ces faits en matrice complète, stratégie multi-source V1, priorités/fallbacks et handoff exact `0.3.10` / `0.3.12`. - -## 11. Synthèse multi-source exhaustive — pre.006 - -Synthèse effectuée le **4 septembre 2026**. Cette section transforme les audits A/B en contrat de handoff. Son principe directeur est volontairement plus large que le périmètre actuellement testable : **une possibilité documentée n'est pas exclue parce que KSP ne dispose pas encore du tier, du compte ou de l'endpoint permettant de la prouver en live**. - -Trois axes doivent toujours rester séparés : - -```text -possibilité connue = le protocole, le provider ou une infrastructure opérateur peut fournir la voie -support KSP = KSP possède déjà ou prévoit explicitement l'adapter/capability correspondant -preuve KSP = cette voie a effectivement été exercée avec un endpoint accessible et un résultat attendu -``` - -En particulier : - -```text -NON PROUVÉ != REJETÉ -PAYANT/BLOQUÉ != NON SUPPORTÉ -IMPLÉMENTÉ != PROUVÉ LIVE -PROUVÉ CHEZ UN PROVIDER != GARANTI CHEZ TOUS LES PROVIDERS DU MÊME PROTOCOLE -``` - -### 11.1 Légende de décision et de preuve - -| Code | Sens | -|---------------|---------------------------------------------------------------------------------------------------------------------------| -| `ADMIS` | voie à représenter dans le socle KSP ; l'activation dépend ensuite des capabilities/configurations réelles | -| `SPÉCIALISÉ` | voie utile mais non nécessaire au socle générique ; adapter provider/source autorisé sans contaminer les contrats communs | -| `BACKFILL` | voie principalement destinée au Job historique/catch-up | -| `EARLY` | signal précoce ou corps transactionnel incomplet ; jamais vérité RAW v1 complète sans hydration/confirmation | -| `SUNSET` | voie historique à documenter mais sur laquelle aucune nouvelle implémentation KSP ne doit être engagée | -| `EXISTANT` | surface KSP nécessaire déjà présente | -| `PLANIFIÉ` | surface/adaptation à réaliser dans la release indiquée | -| `PROUVÉ` | comportement exercé par KSP ou preuve provider/protocole suffisamment directe pour la propriété considérée | -| `TESTABLE` | accès actuel disponible permettant un smoke live, mais preuve KSP encore à produire | -| `NON PROUVÉ` | possibilité admise mais propriété provider/non-régression non démontrée | -| `BLOQUÉ TIER` | branche architecturale admise mais live test impossible avec les comptes actuels | -| `À REVALIDER` | documentation provider incohérente, évolutive ou insuffisante ; ne pas encoder la valeur comme garantie | - -### 11.2 Matrice exhaustive des familles de sources RAW - -Cette matrice est **source-family first** : un provider peut remplir plusieurs lignes, et une ligne peut être fournie par plusieurs providers. C'est cette séparation qui interdit un enum simpliste `Http | WebSocket | Grpc` comme modèle de configuration du worker. - -| Famille / méthode | Réseaux possibles | Temporalité | Découverte / contenu reçu | RAW v1 complet ? | Replay / repair | Worker `0.3.10` | Backfill `0.3.12` | Décision | -|------------------------------------------------------------------------|-------------------------------------|---------------------------------|---------------------------------------------|------------------------------------|------------------------------------|-----------------|-------------------|--------------| -| HTTP `getTransaction(signature)` | tout cluster RPC | hydration / repair / historique | signature connue -> transaction | oui si réponse disponible | dépend de la rétention/archive RPC | oui | oui | `ADMIS` | -| HTTP `getSignaturesForAddress` + `getTransaction` | tout cluster RPC | catch-up / historique ciblé | discovery adresse puis hydration | oui après hydration | pagination par signatures | repair ciblé | oui | `ADMIS` | -| HTTP `getBlocks` / `getBlocksWithLimit` + `getBlock` | tout cluster RPC | catch-up / gap / historique | discovery slots puis blocs | oui avec `transactionDetails=full` | fenêtre ledger/archive provider | oui | oui | `ADMIS` | -| HTTP `getBlock(slot)` | tout cluster RPC | repair / historique ciblé | slot connu -> bloc | oui avec `transactionDetails=full` | fenêtre ledger/archive provider | oui | oui | `ADMIS` | -| HTTP bornes `getSlot` / `getFirstAvailableBlock` / `minimumLedgerSlot` | tout cluster RPC | continuité | aucune transaction | non | borne seulement | auxiliaire | auxiliaire | `ADMIS` | -| API historique provider `getTransactionsForAddress` ou équivalent | provider-dependent | historique ciblé | discovery + éventuellement transaction full | provider-dependent | archive provider | optionnel | oui | `SPÉCIALISÉ` | -| WS standard `logsSubscribe` + hydration HTTP | Mainnet/Devnet/Testnet si exposé | live | signature/logs | non ; hydration requise | resubscribe sans replay adressable | oui | non principal | `ADMIS` | -| WS standard `signatureSubscribe` + hydration | Mainnet/Devnet/Testnet si exposé | live ciblé | statut d'une signature déjà connue | non ; hydration requise | one-shot | ciblé | non principal | `ADMIS` | -| WS standard `blockSubscribe` full | provider/validator-dependent | live global/filtré | bloc + transactions | oui si full | reconnect ; repair externe | oui | non principal | `ADMIS` | -| WS provider `transactionSubscribe` full | provider-dependent | live filtré/global selon offre | transaction + meta | oui | provider-managed ou repair externe | oui | non principal | `SPÉCIALISÉ` | -| Yellowstone `transactions` | tout réseau exposé par endpoint | live | transaction exécutée + meta | oui | `from_slot` si provider le sert | oui | oui/replay | `ADMIS` | -| Yellowstone `blocks` + transactions | tout réseau exposé par endpoint | live / replay | bloc + transactions | oui | `from_slot` si provider le sert | oui | oui/replay | `ADMIS` | -| Yellowstone `transactions_status` + hydration | tout réseau exposé par endpoint | live | signature/status/error | non ; hydration requise | `from_slot` provider-dependent | oui | optionnel | `ADMIS` | -| Yellowstone `blocks_meta` / slots | tout réseau exposé par endpoint | continuité | slots/bloc meta sans tx full | non | aide à détecter/borner gaps | auxiliaire | auxiliaire | `ADMIS` | -| Yellowstone `from_slot` + `SubscribeReplayInfo` | provider-dependent | replay récent / catch-up | même stream depuis slot demandé | selon famille souscrite | profondeur provider-specific | oui | oui | `ADMIS` | -| stream persistant provider compatible Yellowstone | provider-dependent | live + reprise durable | transaction/account/entry selon produit | oui pour transaction full | provider-managed persistant | oui | oui/replay | `SPÉCIALISÉ` | -| shred/pre-exec -> transaction reconstruite + hydration | surtout Mainnet, provider-dependent | ultra-live | shreds ou transaction avant exécution | non : meta d'exécution absente | aucun replay canonique implicite | oui, phase 2 | non principal | `EARLY` | -| transaction body extraite de shreds + hydration | surtout Mainnet, provider-dependent | ultra-live | signature/corps tx | non : meta d'exécution absente | source-dependent | oui, phase 2 | non principal | `EARLY` | -| Agave RPC auto-hébergé | Mainnet/Devnet/Testnet/local/custom | live + ledger local | toutes méthodes activées | oui selon méthode | rétention opérateur | oui | oui | `ADMIS` | -| Agave + Yellowstone Geyser auto-hébergé | Mainnet/Devnet/Testnet/local/custom | live | mêmes familles Yellowstone | oui pour tx/blocks full | rétention/plugin opérateur | oui | oui | `ADMIS` | -| Old Faithful / `yellowstone-faithful` via JSON-RPC | Mainnet ; indexes Testnet/Devnet | archive historique | getBlock/getTransaction/GSFA/getBlocks | oui pour données archivées | historique par epochs | repair froid | oui | `BACKFILL` | -| archive provider exposée via RPC standard | provider/network-dependent | archive historique | mêmes RPC standard | oui | rétention provider | repair froid | oui | `BACKFILL` | -| substrat archive direct CAR/Filecoin/S3/Bigtable | source-dependent | archive historique | format stockage, pas API KSP standard | potentiellement | intégralité dépend du dataset | non V1 direct | futur possible | `SPÉCIALISÉ` | - -Les lignes `EARLY` sont volontairement incluses dans le **socle de possibilités**. Elles peuvent alimenter une file de discovery/hydration et fournir un avantage de latence, mais elles ne doivent pas créer un `RawTransaction` canonique complet tant que les métadonnées d'exécution nécessaires n'ont pas été observées ou hydratées. - -### 11.3 Matrice providers / réseaux / prix / preuve - -Les prix et tiers ci-dessous sont des **données datées au 4 septembre 2026**. Ils guident les tests et la composition ; ils ne deviennent ni constantes Rust ni règles de validation KSP. `?` signifie que la source officielle consultée ne suffit pas à contractualiser la propriété. - -| Provider / infrastructure | Réseaux documentés utiles | Standard HTTP/WSS | Yellowstone / stream full | Historique / replay | Prix / tier utile au 04-09-2026 | Accès KSP actuel | Preuve / décision KSP | -|---------------------------------|------------------------------------------------|--------------------------------|-------------------------------------------------------|------------------------------------------------------|----------------------------------------------------------------------------------------|--------------------------------|-----------------------------------------------------------------------------------------| -| Solana public RPC | Mainnet-beta, Devnet, Testnet | oui | non | ledger public borné | gratuit ; fortement rate-limité ; non destiné production | oui | `PROUVÉ/TESTABLE` standard ; baseline seulement | -| provider RPC standard générique | selon provider | oui si méthodes exposées | éventuel | selon provider | variable | oui selon compte | `ADMIS` par capabilities, jamais par nom de provider | -| Agave auto-hébergé | Mainnet/Devnet/Testnet/local/custom | oui | Yellowstone si plugin installé | ledger/rétention opérateur | coût infrastructure opérateur | non actuellement | `ADMIS`, `NON PROUVÉ` en environnement KSP actuel | -| Helius | Mainnet + Devnet | Free+ | Devnet Developer+ ; Mainnet Business+ | LaserStream 24 h ; history API | Free $0 ; Developer $49 ; Business $499 ; Professional $999 | HTTP/WSS gratuit | standard `TESTABLE`; gRPC Mainnet `BLOQUÉ TIER`; 24 h provider `PROUVÉ` par docs | -| PublicNode | Mainnet + Testnet | gratuit | Yellowstone gRPC gratuit | archive accessible sur demande ; replay depth ? | gratuit pour endpoint public ; archive prix/conditions non publiés dans source auditée | Mainnet gRPC + RPC disponibles | gRPC Mainnet `TESTABLE/PROUVÉ` par smokes antérieurs ; profondeur replay `NON PROUVÉE` | -| OrbitFlare | Mainnet + Devnet | oui | Devnet Free/Developer ; Mainnet add-on/Pro | archival data incluse ; profondeur gRPC ? | Free $0 ; Developer $49 ; Growth $399 ; Scale $799 ; Pro $999 ; Mainnet gRPC +$500 | Devnet gratuit possible | `TESTABLE` Devnet ; Mainnet payant ; replay gRPC `NON PROUVÉ` | -| QuickNode | Mainnet-beta, Testnet, Devnet | oui | Scale/Business ou add-on | `fromSlot` jusqu'à 3000 slots ; archive selon réseau | Scale $499 ; Business $999 ; add-on possible Build/Accelerate | pas de tier gRPC actuel | `BLOQUÉ TIER`; protocole `ADMIS`; replay provider documenté | -| Alchemy | Mainnet + Devnet | oui | Yellowstone gRPC PAYG/Enterprise | replay documenté mais pages contradictoires | $75/TB gRPC ; accès PAYG/Enterprise | standard gratuit possible | gRPC `BLOQUÉ/À REVALIDER`; 6000 vs ~432000 slots dans docs : ne rien figer | -| Chainstack | Mainnet + Devnet RPC ; gRPC Mainnet | Free Developer + plans payants | add-on Yellowstone Growth+ | archive Growth+ ; replay gRPC ? | Developer $0 ; Growth $49 ; gRPC $49/2, $149/7, $449/25 streams | standard gratuit possible | standard `TESTABLE`; gRPC `BLOQUÉ TIER`; replay `NON PROUVÉ` | -| Shyft | Mainnet + Devnet RPC ; gRPC réseau à qualifier | Free RPC | Build/Grow/Accelerate Yellowstone | replay jusqu'à 150 slots | Free $0 ; Build $199 ; Grow $349 ; Accelerate $649 | RPC gratuit possible | standard `TESTABLE`; gRPC `BLOQUÉ TIER`; replay 150 slots documenté | -| Triton One | Solana ; réseau par endpoint | oui / Whirligig | Dragon's Mouth/Riptide/Fumarole | Fumarole persistant ; Old Faithful full history | dépôt PAYG $125 ; streaming $0.08/GB ; RPC $0.08/GB + $10/M calls | pas de compte actuel | `BLOQUÉ TIER`; architecture `ADMIS`; historique Old Faithful également auto-hébergeable | -| dRPC | Solana ; réseau gRPC à qualifier | HTTP/WSS | Yellowstone gRPC Premium/Advanced | replay depth ? | Premium $399 : 25 streams/5 TB ; Advanced $599 : 50 streams/10 TB | standard éventuellement | gRPC `BLOQUÉ TIER`; replay `NON PROUVÉ`; docs récentes supplantent comparatifs anciens | -| Ankr | Mainnet + Devnet | Freemium/Premium HTTP + WSS | Solana Yellowstone non prouvé par docs chain-specific | ledger rolling ; archive générique annoncée | Solana RPC/WSS $0.00005 par request/subscription/notification | freemium possible | standard `TESTABLE`; ne pas inférer gRPC Solana depuis pricing gRPC générique | -| GetBlock | Mainnet-beta + Devnet | Free+ HTTP/WSS | Yellowstone sur dedicated/add-on | archive selon plan | Free $0 ; Starter $49 ; Advanced $199 ; Pro $499 ; Enterprise $999 ; dedicated +gRPC | standard gratuit possible | standard `TESTABLE`; gRPC paid `NON PROUVÉ` | -| autre Yellowstone-compatible | provider/network-dependent | variable | oui si protocole compatible | provider-dependent | inconnu | non | `ADMIS` via descriptor/capabilities ; aucun code provider requis si protocole standard | - -#### Cas Alchemy : documentation de replay contradictoire - -Les sources Alchemy courantes ne sont pas cohérentes entre elles : certaines pages Yellowstone mentionnent environ **6000 slots**, tandis que la page dédiée « Historical Replay » annonce `from_slot` dans les **~432 000 derniers slots (~48 h)**. KSP doit donc représenter la capability replay comme **qualifiée au runtime/test**, et non encoder une constante Alchemy dans Config ou le Worker. - -### 11.4 Sources ultra-low-latency / pre-execution à garder dans le socle - -| Source | Transport | Réseau / accès courant | Contenu utile | Meta d'exécution ? | Prix / accès daté | Usage KSP proposé | -|----------------------------------|---------------------|----------------------------|-------------------------------------------------|--------------------|----------------------------------------------|----------------------------------------------------------------------| -| Helius Shred Delivery UDP | UDP shreds | Mainnet, beta/qualified | shreds bruts | non | Professional+/accès qualifié ; prix non figé | `EARLY` discovery ; deshred + hydration | -| Helius preprocessed transactions | gRPC | Helius Shred Delivery | transaction décodée ~pré-processed | non | Professional+ ; 20 crédits/MB | `EARLY` body/signature -> hydration | -| OrbitFlare Jetstream | gRPC basé shreds | provider-dependent | transaction faible latence, sans full meta | non | gRPC depuis $500/mo selon offre | `EARLY` -> hydration ; Yellowstone reste voie full | -| Shyft RabbitStream | gRPC depuis shreds | provider-dependent, payant | transactions extraites des shreds | non/à confirmer | Build+ ($199+) | `EARLY` -> hydration | -| Triton Deshred | extension gRPC | shared/dedicated Triton | transaction reconstruite avant replay/exécution | non | inclus dans offre streaming PAYG | `EARLY` -> hydration ; extension spécialisée | -| Triton Shred Streaming | shred stream | Triton | shreds | non | $1500/mo/IP/datacenter | `EARLY` phase avancée | -| bloXroute Transaction Streamer | gRPC | Solana | signature + bytes transaction + slot | non | $500/mo | `EARLY` body -> hydration | -| bloXroute Shreds | UDP/gateway | Solana | shreds | non | $500/mo | `EARLY` phase avancée | -| DoubleZero Edge | UDP multicast | feed Solana shreds | shreds bruts | non | $450/$900/$1500 par machine/mo selon metro | successeur shred générique à prévoir ; deshred + hydration | -| Jito ShredStream | shreds/local decode | Solana | shreds -> transactions | non | sunset | `SUNSET` le 5 septembre 2026 ; aucune nouvelle implémentation KSP V1 | -| Turbine/shred feed auto-opéré | UDP/local | cluster opéré | shreds bruts | non | coût infra | possibilité générique future, jamais provider hardcodé | - -Le lendemain de cet audit, **5 septembre 2026**, Jito prévoit l'arrêt complet de ShredStream et recommande explicitement DoubleZero Edge. La ligne Jito est conservée pour exhaustivité/historique et migration, pas comme cible d'implémentation nouvelle. - -### 11.5 Matrice réseau et stratégie de preuve - -Le support KSP doit être **network-neutral** au niveau des stratégies. La preuve live, elle, est pragmatique et utilise les accès disponibles. - -| Réseau logique KSP | Preuves prioritaires avec accès actuel | Branches complémentaires possibles | Règle KSP | -|--------------------|------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------| -| `mainnet-beta` | HTTP/WS standard multi-provider ; PublicNode Yellowstone gRPC ; Helius standard HTTP/WSS | Helius gRPC payant, QuickNode/Alchemy/Chainstack/Shyft/Triton/dRPC/GetBlock | réseau canonique Store/identité ; `mainnet` peut rester alias de profil/UI | -| `devnet` | Solana public HTTP/WS ; Helius standard ; OrbitFlare Yellowstone gratuit ; autres providers gratuits | Helius LaserStream Developer+, Alchemy gRPC, self-host | meilleur terrain pour canaries protocole sans coût Mainnet | -| `testnet` | Solana public HTTP/WS ; PublicNode RPC/WS/Yellowstone | self-host / providers qui exposent Testnet | utile pour caractériser comportements distincts sans supposer disponibilité chez tous les vendors | -| local/custom | Agave local + éventuellement Yellowstone plugin | fixtures et serveurs contrôlés | permet de prouver erreurs, replay, gaps et backpressure sans dépendance fournisseur | - -Le plan de preuve `0.3.10`/`0.3.12` doit donc avoir trois étages : - -```text -1. tests déterministes fixtures/mock pour chaque adapter admis -2. smokes live opt-in sur les combinaisons gratuites/accessibles -3. smokes live opt-in BLOQUÉS/IGNORÉS pour les branches payantes jusqu'à disponibilité du tier -``` - -Une branche peut être livrée comme **support implémenté non prouvé live** si ses contrats déterministes, son parsing, ses bornes, son redaction et ses erreurs sont testés, à condition que la documentation et les capabilities ne la présentent pas comme validée live. - -### 11.6 Handoff `0.3.10` — modèle de sources du Worker live - -`ksp-worker-raw-transaction-ingest-lib` doit être multi-source dès V1, mais ne doit pas exposer un enum protocol/provider fermé. La composition construit une collection de stratégies selon **rôles/capabilities**. - -Capabilities minimales retenues : - -```text -live_direct_transaction reçoit une transaction exécutée complète -live_direct_block reçoit un bloc contenant les transactions complètes -live_transaction_discovery reçoit signature/référence, nécessite hydration -live_early_transaction reçoit shreds/corps pré-exécution, nécessite hydration/confirmation -transaction_hydration résout une signature en transaction complète -block_hydration résout un slot en bloc complet -gap_boundary observe slot/first_available/ledger bounds -gap_repair_scan reconstruit une plage via slots/blocs/requêtes HTTP -replay_transaction_stream reprend un stream full depuis un slot -replay_block_stream reprend un stream block depuis un slot -``` - -Chaque stratégie déclare séparément : - -```text -network -role/capabilities -provider + endpoint identity safe -protocol + method/source code -commitment/finality support -filter capabilities and bounds -live/catch-up/history applicability -replay support: none | provider_managed | requested_from_slot -replay first-available observability -runtime admission limits -proof status (metadata/doc only, jamais secret) -``` - -Le Worker ne doit **pas** lire une valeur de prix pour décider du runtime. Prix/tier servent à la documentation et au choix de profil par l'opérateur ; Config sélectionne uniquement des endpoints/capabilities effectivement autorisés. - -#### Ensemble V1 à implémenter autant que possible - -Le socle V1 `0.3.10` doit viser les adapters suivants, même si certains smokes live restent bloqués : - -1. Yellowstone `transactions` full ; -2. Yellowstone `blocks` full ; -3. Yellowstone `transactions_status` + hydration ; -4. Yellowstone replay `from_slot` qualifié par `SubscribeReplayInfo`/provider ; -5. WS standard `blockSubscribe` full ; -6. WS standard `logsSubscribe` + HTTP `getTransaction` ; -7. Helius `transactionSubscribe` full via la surface Transport existante ; -8. HTTP block scan `getBlocks/getBlock` comme gap repair global ; -9. HTTP signature hydration observée `getTransaction` ; -10. au moins un hook/adaptor contract `EARLY` source-neutral, sans obliger l'implémentation UDP/shred de tous les vendors dans la première tranche. - -Les sources `EARLY` vendor-specific peuvent être matérialisées progressivement derrière ce contrat commun. Elles ne doivent pas retarder la fermeture du socle full-transaction si leur accès payant/UDP demande une release dédiée. - -### 11.7 Orchestration multi-source : complément, redondance et fallback - -Les stratégies ne sont pas mutuellement exclusives. Le runtime doit accepter : - -```text -Yellowstone transactions --------------------+ -Helius transactionSubscribe -----------------+--> normalisation commune --> Store -blockSubscribe full --------------------------+ -logsSubscribe --+ | - +--> HTTP getTransaction -----+ -EARLY source ----+--> hydration/confirmation -+ -``` - -Une source directe full et une source discovery peuvent fonctionner simultanément. Une source de replay peut être inactive tant qu'aucun gap n'est détecté. Une source archive peut être réservée au Job mais réutilisée comme dernier recours de repair explicite si la politique du caller l'autorise. - -Le fallback ne doit pas être codé comme « si gRPC échoue alors WS sinon HTTP ». Il doit sélectionner **une autre stratégie offrant la capability manquante sur le même réseau**, en tenant compte des limites et de la disponibilité runtime. - -### 11.8 Déduplication de contenu vs observations de provenance - -Identité canonique inchangée : - -```text -RawTransaction identity = (network, signature) -``` - -La source, le provider, le protocole et l'endpoint ne font jamais partie de cette identité. - -Règle multi-source : - -```text -même (network, signature) + mêmes bytes canoniques - -> une RawTransaction - -> plusieurs RawTransactionObservation utiles/autonomes - -même (network, signature) + bytes canoniques incompatibles - -> conflit explicite - -> jamais "le premier provider gagne" silencieusement -``` - -La déduplication de la transaction **ne doit donc pas supprimer la provenance**. Une observation provenant de PublicNode gRPC et une observation Helius WSS de la même transaction peuvent toutes deux être persistées si leurs clés d'observation sont distinctes et utiles. - -Pour les signaux `EARLY`, aucun `RawTransactionObservation` complet ne doit être fabriqué si le contrat Store exige une acquisition complète. Le Worker peut conserver une référence interne bornée vers l'hydration, puis produire la provenance finale avec la chaîne de discovery/hydration requise par le futur contrat commun. - -### 11.9 Stratégie de gap repair - -Le Worker doit détecter la continuité à partir des slots/block meta/stream snapshots, mais ne jamais déduire « aucun gap » de la seule reconnexion d'un client. - -Ordre fonctionnel proposé, piloté par capabilities et non par provider : - -```text -A. replay natif adressable depuis le dernier frontier si provider qualifié - -> Yellowstone from_slot + first_available/replay info - -B. source live redondante ayant déjà observé la plage - -> dédup par Store/provenance - -C. scan HTTP global par slots - -> getBlocks/getBlocksWithLimit + getBlock observed - -D. hydration ciblée des signatures déjà découvertes - -> getTransaction observed - -E. archive/historical source si la fenêtre live est perdue - -> provider archive / Old Faithful / autre stratégie Backfill -``` - -Le niveau E peut être exécuté par le Worker pour un repair court seulement si le contrat final `0.3.10` reste simple ; sinon il délègue explicitement une campagne de Job. Aucune dépendance `Worker -> Job` n'est autorisée. - -### 11.10 Handoff Transport `0.3.10` - -Gaps confirmés à traiter **après** cet audit : - -| ID | Adaptation Transport proposée | Pourquoi | -|--------|-----------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------| -| `TR-B` | ajouter un `get_block_observed` symétrique de `get_transaction_observed` | provenance provider/endpoint exacte lors d'un scan bloc multi-endpoint | -| `TR-C` | fournir un chemin de projection source-neutral des transactions full issues de WS Helius et Yellowstone | éviter que Worker possède deux canonicalizers filaires concurrents | -| `TR-D` | exposer proprement les métadonnées sûres d'une acquisition live au moment de la conversion, sans URL/secret | produire `RawTransactionObservation` uniforme | -| `TR-E` | conserver `from_slot`, `SubscribeReplayInfo`, snapshot reconnect/gap et provider/cluster/endpoint déjà disponibles | ces primitives sont suffisantes ; ne pas créer un second moteur Yellowstone | -| `TR-F` | adapter les families `EARLY` seulement quand leur protocole est réellement implémenté ; ne pas forcer UDP/shred dans Transport V1 | le socle doit réserver la capability sans introduire prématurément tous les clients vendor-specific | - -Aucun SDK provider n'est nécessaire pour HTTP/WS/Yellowstone lorsque les surfaces actuelles KSP suffisent. Les extensions non standard doivent rester derrière un adapter explicite et une capability, pas une branche globale dans le Worker. - -### 11.11 Handoff Config `0.3.10` - -Config doit rester propriétaire des endpoints/secrets et permettre plusieurs sources simultanées. Le modèle cible doit exprimer **des routes/capabilities par réseau**, par exemple : - -```text -source id = identité de composition stable -network = mainnet-beta / devnet / testnet / custom -transport endpoint ref = HTTP / WS / gRPC déjà enregistré dans Config -roles = live_direct, discovery, hydration, replay, gap_repair... -priority / enabled = politique de composition -filters = références sûres/typed settings si nécessaires -``` - -Contraintes fermées : - -- ne pas copier les prix/tiers provider dans Config comme logique runtime ; -- ne pas hardcoder une liste fermée de providers dans le Worker ; -- réutiliser **uniquement** `KSP_SECRET_HELIUS_API_KEY` pour toutes les surfaces Helius qui en ont besoin ; -- permettre plusieurs endpoints d'un même protocole/provider et plusieurs providers sur le même réseau ; -- conserver `mainnet-beta` comme identité réseau canonique de transaction ; `mainnet` reste un alias de profil/composition si nécessaire ; -- rejeter avant démarrage une source dont la capability demandée n'est pas réellement offerte par son endpoint/configuration. - -### 11.12 Ownership commun de la normalisation RAW - -Le besoin Worker + Backfill ferme `RAW-A` : la canonicalisation RAW v1 ne doit rester ni enfermée dans le Job ni être copiée dans le Worker. - -Le handoff retient une petite crate commune à créer en `0.3.10` : - -```text -ksp-raw-transaction-lib - -> ksp-core-lib - -> ksp-store-lib # default-features = false ; aucun backend imposé - -> serde_json / sha2 si le format v1 actuel les exige -``` - -Responsabilités : - -```text -format id/version RAW Transaction KSP -entrée source-neutral transaction complète -canonical payload bytes + content hash -construction RawTransaction -construction/projection de provenance et observation à partir de métadonnées sûres fournies par le caller -validation réseau/signature/slot/meta/version/index commune -aucun runtime -aucun réseau -aucune Config -aucun scheduler/job/worker -aucun backend Store physique -``` - -Les adapters Worker/Backfill restent responsables de transformer les DTOs Transport/provider en **matériau source-neutral**. Ainsi `ksp-raw-transaction-lib` n'a pas besoin de dépendre de `ksp-onchain-transport-lib`, et aucune dépendance inverse Transport -> Store n'est créée. - -Graphe cible : - -```text -ksp-job-backfill-lib ------------------+ - +--> ksp-raw-transaction-lib --> ksp-store-lib -ksp-worker-raw-transaction-ingest-lib -+ - -les deux consumers dépendent aussi de ksp-onchain-transport-lib pour leurs adapters respectifs -``` - -La migration de la conversion déjà prouvée dans `ksp-job-backfill-lib` vers cette crate doit être faite avec golden bytes/hash inchangés et tests de non-régression. Aucun nouveau format RAW v2 n'est justifié. - -### 11.13 Handoff `0.3.12` — stratégies Backfill à ajouter - -`ksp-job-backfill-lib` doit conserver son premier vertical HTTP adressé, puis devenir multi-stratégie sans changer `ksp-job-api` pour des notions Solana. - -| Stratégie historique | Réseaux | Direct/full ou hydration | Source typique | Admission `0.3.12` | -|-------------------------------------------------|-------------------------|-------------------------------|--------------------------------------------|--------------------| -| GSFA + getTransaction | tout RPC | discovery + hydration | Solana standard / tous providers | déjà existante | -| getBlocks/getBlocksWithLimit + getBlock | tout RPC | full par bloc | standard/archive RPC | oui | -| liste de signatures explicites + getTransaction | tout RPC | hydration | tout provider | déjà existante | -| Yellowstone from_slot transactions | provider replay-capable | direct full | Helius/QuickNode/Shyft/etc selon tier | oui | -| Yellowstone from_slot blocks | provider replay-capable | direct full bloc | provider-compatible | oui | -| Helius getTransactionsForAddress | Helius networks | full ou signatures selon mode | Helius history API | oui spécialisé | -| provider archive via RPC standard | provider-dependent | standard | OrbitFlare/QuickNode/Chainstack/Triton/etc | oui | -| Old Faithful / yellowstone-faithful | surtout Mainnet | standard historical RPC | self-host/Filecoin/Triton | oui expérimental | -| substrat archive direct | dataset-dependent | adapter spécifique | CAR/Filecoin/S3/Bigtable | futur, non V1 | - -Le Job doit pouvoir déclarer la stratégie choisie et son checkpoint spécifique, mais ne doit jamais devenir un « Worker arrêté après N éléments ». Ses campagnes restent bornées et terminables. - -### 11.14 Priorité d'implémentation vs exhaustivité du socle - -L'exhaustivité de la matrice **ne signifie pas** que toutes les intégrations vendor-specific doivent être codées simultanément dans la première prerelease de `0.3.10`. - -Ordre recommandé : - -```text -P0 : normalisation RAW commune + observed getBlock + adapters standard -P0 : Yellowstone transactions/blocks + replay qualifié -P0 : WS logsSubscribe + hydration + blockSubscribe full -P0 : Helius transactionSubscribe déjà supporté par Transport -P1 : multi-source concurrency/dedup/provenance/gap repair -P1 : smokes Mainnet/Devnet/Testnet accessibles gratuitement -P2 : provider-specific history/replay adapters payants -P2 : EARLY transaction-body/deshred abstraction + premiers adapters disponibles -P3 : UDP/raw-shred direct et archives de substrat lorsque besoin/accès justifiés -``` - -Cette priorité est une stratégie de réalisation ; **toutes les lignes `ADMIS` restent dans le modèle de capabilities** afin de ne pas enfermer l'architecture dans les seuls comptes gratuits disponibles en septembre 2026. - -### 11.15 Sources externes complémentaires de la synthèse - -Consultées le 4 septembre 2026, en complément des sources des sections 7 et 9.8 : - -| Source | URL | -|------------------------------------|------------------------------------------------------------------------------------------| -| Solana — clusters/public RPC | https://solana.com/docs/references/clusters | -| QuickNode — Yellowstone guide | https://www.quicknode.com/guides/solana-development/tooling/solana-grpc/solana-grpc | -| QuickNode — gRPC plans | https://www.quicknode.com/blog/solana-grpc-is-now-included-with-scale-and-business-plans | -| Alchemy — Solana gRPC | https://www.alchemy.com/solana-grpc | -| Alchemy — Yellowstone quickstart | https://www.alchemy.com/docs/reference/yellowstone-grpc-quickstart | -| Alchemy — historical replay | https://www.alchemy.com/docs/reference/yellowstone-grpc-historical-replay | -| Alchemy — compute/bandwidth costs | https://www.alchemy.com/docs/reference/compute-unit-costs | -| Chainstack — Yellowstone add-on | https://chainstack.com/yellowstone-grpc-more-streams-same-price/ | -| Shyft — Yellowstone gRPC | https://shyft.to/solana-yellowstone-grpc | -| Shyft — pricing | https://shyft.to/solana-rpc-grpc-pricing | -| Shyft — RabbitStream | https://shyft.to/solana-shreds-rabbitstream | -| Triton — pricing | https://triton.one/pricing | -| Triton — Yellowstone overview | https://blog.triton.one/complete-guide-to-solana-streaming-and-yellowstone-grpc/ | -| Triton — Fumarole | https://blog.triton.one/introducing-yellowstone-fumarole/ | -| Triton — Deshred | https://blog.triton.one/deshred-transactions-the-fastest-path-to-solana-data/ | -| dRPC — Solana Yellowstone | https://drpc.org/docs/solana-yellowstone-geyser-grpc | -| Ankr — Solana support | https://www.ankr.com/docs/rpc-service/chains/chains-list/s-t/ | -| Ankr — pricing | https://www.ankr.com/docs/rpc-service/pricing/ | -| GetBlock — pricing | https://getblock.io/pricing-new/ | -| bloXroute — pricing | https://bloxroute.com/pricing/ | -| Helius — data streaming | https://www.helius.dev/docs/data-streaming | -| Helius — preprocessed transactions | https://www.helius.dev/docs/shred-delivery/preprocessed-transactions | -| Jito — ShredStream sunset | https://docs.jito.wtf/lowlatencytxnfeed/ | -| DoubleZero Edge — shreds | https://docs.malbeclabs.com/Edge%20Subscriber%20Connection/ | -| Yellowstone Old Faithful | https://github.com/rpcpool/yellowstone-faithful | -| PublicNode — Solana | https://solana.publicnode.com/ | -| OrbitFlare — RPC plans | https://orbitflare.com/products/rpc-nodes | -| OrbitFlare — gRPC | https://orbitflare.com/products/solana-grpc | - -Les URLs sont documentaires. Aucun endpoint runtime, token, secret ou identifiant de compte n'est introduit dans KSP par `pre.006`. - -## 12. État après pre.006 - -La synthèse ferme les décisions architecturales suivantes : - -```text -catalogue de possibilités = exhaustif par familles ; non limité aux preuves gratuites actuelles -support vs preuve = axes distincts ; NON PROUVÉ n'implique jamais REJETÉ -Worker V1 = multi-source par capabilities, pas enum protocole/provider -full live = Yellowstone tx/blocks, blockSubscribe full, Helius transactionSubscribe -portable live = logsSubscribe + getTransaction observed -repair = replay qualifié -> redondance -> block scan observed -> hydration -> archive -EARLY = admis comme discovery/body, jamais RAW v1 complet sans meta d'exécution -canonicalisation = nouvelle crate commune ksp-raw-transaction-lib en 0.3.10 -Transport = get_block_observed + projection/provenance commune à adapter en 0.3.10 -Config = plusieurs sources/endpoints/capabilities par réseau ; prix hors runtime -Helius secret = réutilisation unique de KSP_SECRET_HELIUS_API_KEY -network identity = mainnet-beta canonique ; mainnet alias de composition seulement -Backfill 0.3.12 = block scan + replay Yellowstone + archives/provider history + Old Faithful -preuves = fixtures déterministes + smokes gratuits + smokes payants ignorés jusqu'à accès -``` - -`0.3.9` n'implémente aucune de ces adaptations. La release a maintenant fourni l'audit nécessaire ; les changements de code commencent en `0.3.10` après le gate final, la réconciliation documentaire et la publication de `0.3.9`. - +`0.3.9` n'implémente aucune nouvelle stratégie d'acquisition. Il ferme l'architecture et l'inventaire nécessaires aux releases suivantes. diff --git a/docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md b/docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md index 0004f4e..ca113fc 100644 --- a/docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md +++ b/docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md @@ -1,5 +1,5 @@ - + # Plan v0.3.9 — Worker API générique + audit RAW Transaction @@ -506,15 +506,18 @@ Après freeze fonctionnelle de `ksp-worker-api` en `pre.003`, l’audit RAW est docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md ``` -Ce document séparera : +Après la synthèse `pre.006-fix.001`, ce document doit être lu comme une **architecture unique centrée sur Store / `RawTransaction`**, et non comme la juxtaposition chronologique des audits A/B. Il sépare : ```text -partie durable : taxonomy capabilities/roles/combinations/convergence -partie audit daté : disponibilité provider, quotas, replay, tiers et liens sources primaires -handoff : gaps Transport/Config 0.3.10 et applicability Backfill 0.3.12 +centre durable : Store / RawTransaction / observations / provenance +producteur 1 : Job Backfill historique, paramétré, borné et terminable +producteur 2 : Worker Ingest continu, start/stop, sans requête métier historique +capabilities : HTTP / WS / gRPC / archive / EARLY utilisables selon l'intention +preuve datée : providers, réseaux, tiers, prix, replay et accès réellement prouvés +handoffs : Worker 0.3.10 et Backfill 0.3.12, sans edge Job <-> Worker ``` -Ce choix évite de transformer le plan de release en registre provider tout en donnant à `0.3.10` et `0.3.12` une référence architecturale réauditable. L’index architecture ne sera synchronisé qu’au moment où ce document sera réellement créé, puis réconcilié dans le couloir documentaire final. +Les protocoles n'appartiennent à aucun producteur. Une capability gRPC/WS peut servir au Job lorsqu'elle fournit un historique/replay borné ; HTTP peut servir au Worker pour hydration, live block polling ou repair de sa continuité active. L’index architecture ne sera synchronisé qu’au moment où ce document sera réellement créé, puis réconcilié dans le couloir documentaire final. kbot3 ne sera alors utilisé que pour inventorier des comportements historiques. Aucun code, DTO, Config, URL, dependency ou version n’en sera repris. @@ -595,7 +598,13 @@ Budget cible : **15-20 min**. `docs/architecture/011-RAW_TRANSACTION_ACQUISITION **Statut : réalisé ; synthèse exhaustive des possibilités, y compris non prouvées/non testables actuellement, sans changement runtime.** -Budget cible : **15-20 min**. `docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md` ferme la matrice par familles de sources, providers, réseaux, prix/tier datés, temporalité, complétude, replay, destination Worker/Backfill et statut de preuve. La synthèse sépare explicitement possibilité connue, support KSP et preuve live afin qu'un tier payant ou un compte indisponible n'exclue jamais une branche de l'architecture. Le handoff `0.3.10` retient un Worker multi-source par capabilities, les adapters standard/Yellowstone/Helius déjà auditables, les hooks EARLY, la stratégie de gap repair et l'extraction de la canonicalisation dans `ksp-raw-transaction-lib`; `0.3.12` reçoit les stratégies block scan, replay Yellowstone, archives/provider history et Old Faithful. Aucun endpoint, secret ou client provider n'est ajouté ici. +Budget cible : **15-20 min**. `docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md` ferme la matrice par familles de sources, providers, réseaux, prix/tier datés, temporalité, complétude, replay, destination Worker/Backfill et statut de preuve. La synthèse sépare explicitement possibilité connue, support KSP et preuve live afin qu'un tier payant ou un compte indisponible n'exclue jamais une branche de l'architecture. Le handoff distingue deux producteurs indépendants de Store : `0.3.10` reçoit le Worker live start/stop, sans requête historique métier, et les adaptations communes nécessaires ; `0.3.12` reçoit l'extension du Job Backfill historique paramétré. Les protocoles restent orthogonaux aux rôles : HTTP peut servir au Worker et WS/gRPC au Job lorsque leur sémantique le justifie. Aucun endpoint, secret ou client provider n'est ajouté ici. + +#### `pre.006-fix.001` — synthèse Store-centrique et séparation stricte Worker / Backfill + +**Statut : réalisé ; correctif documentaire uniquement.** + +Réécriture complète de `docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md` pour supprimer l'effet « audit A + audit B + synthèse ajoutée ». Le document devient une référence architecturale unique centrée sur `RawTransaction` dans Store. Il fixe explicitement : Job Backfill = historique paramétré/borné ; Worker Ingest = acquisition continue start/stop sans paramètres métier historiques ; aucun edge, délégation ou coordination obligatoire entre les deux ; capabilities HTTP/WS/gRPC/archive classifiées par usage et non par producteur. Le replay/repair Worker est limité à la continuité de son acquisition active et ne devient jamais une campagne historique. Correctif strictement documentaire : `workspace.package.version` reste `0.3.9-pre.6`. ### `pre.007` — gate technique final diff --git a/docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md b/docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md index 9b798aa..6d3f432 100644 --- a/docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md +++ b/docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md @@ -1,5 +1,5 @@ - + # Validation v0.3.9 — Worker API + audit RAW Transaction @@ -212,6 +212,19 @@ Aucun item ci-dessous n’est déclaré exécuté en `pre.001`. - [X] Applicability `0.3.12` Backfill indiquée par source/méthode : GSFA, block scan, explicit signatures, Yellowstone replay, provider history/archive et Old Faithful. - [X] `docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md` créé dès `pre.004` comme owner durable, à enrichir en `pre.005`/`pre.006`. +#### `pre.006-fix.001` — synthèse Store-centrique et rôles indépendants + +- [X] `011-RAW_TRANSACTION_ACQUISITION.md` réécrit intégralement comme une synthèse unique ; les anciens blocs A/B ne structurent plus le document. +- [X] Store / `RawTransaction` explicitement placé au centre ; observations/provenance restent autour du RAW durable. +- [X] Job Backfill figé comme producteur historique paramétré, borné et terminable. +- [X] Worker Raw Transaction Ingest figé comme producteur continu start/stop sans signature/program_id/plage/limit de campagne au démarrage. +- [X] Aucun edge, délégation, coordination lifecycle ou checkpoint partagé Job <-> Worker. +- [X] Protocoles classifiés par capability/usage : HTTP peut servir au Worker ; WS/gRPC/replay peuvent servir au Job si la campagne historique l'exige. +- [X] Repair Worker borné à la continuité de son acquisition live ; aucune recherche historique arbitraire. +- [X] `ksp-raw-transaction-lib` conservé uniquement comme lower-layer source-neutral commune ; il ne crée aucune collaboration Job/Worker. +- [X] Matrices provider/réseau/prix/preuve et sources EARLY conservées dans la synthèse réorganisée. +- [X] Correctif documentaire uniquement : `workspace.package.version` reste `0.3.9-pre.6`. + ## 7. Couloirs de fermeture ### `pre.007` — gate technique final @@ -259,4 +272,4 @@ Après la synthèse multi-source `pre.006`, l'état courant est : workspace.package.version = 0.3.9-pre.6 ``` -`pre.002` reste la tranche non-fix `0.3.9-pre.2`. Les correctifs de conformité/compilation portent successivement `0.3.9-pre.2.fix.1` puis `0.3.9-pre.2.fix.2` conformément à `VER-ID-007` et `VER-ID-010`. `pre.003` reprend ensuite la séquence prerelease normale avec `0.3.9-pre.3`; son gate opérateur est PASS et freeze Worker API. `pre.004` poursuit avec `0.3.9-pre.4` sans changement runtime, uniquement l'audit standard Solana/KSP et la création de l'owner durable d'acquisition. `pre.005` passe à `0.3.9-pre.5` et enrichit cet owner avec l'audit Helius/Yellowstone/providers/kbot3 sans modifier le runtime. `pre.006` passe à `0.3.9-pre.6` et ferme la synthèse exhaustive possibilités/support/preuve ainsi que les handoffs `0.3.10`/`0.3.12`, toujours sans changement runtime. L'état précédent `0.3.9-pre.1.fix.2` reste documenté dans `pre.001-fix.002`. +`pre.002` reste la tranche non-fix `0.3.9-pre.2`. Les correctifs de conformité/compilation portent successivement `0.3.9-pre.2.fix.1` puis `0.3.9-pre.2.fix.2` conformément à `VER-ID-007` et `VER-ID-010`. `pre.003` reprend ensuite la séquence prerelease normale avec `0.3.9-pre.3`; son gate opérateur est PASS et freeze Worker API. `pre.004` poursuit avec `0.3.9-pre.4` sans changement runtime, uniquement l'audit standard Solana/KSP et la création de l'owner durable d'acquisition. `pre.005` passe à `0.3.9-pre.5` et enrichit cet owner avec l'audit Helius/Yellowstone/providers/kbot3 sans modifier le runtime. `pre.006` passe à `0.3.9-pre.6` et ferme la synthèse exhaustive possibilités/support/preuve ainsi que les handoffs `0.3.10`/`0.3.12`, toujours sans changement runtime. `pre.006-fix.001` réécrit ensuite l'owner d'architecture comme synthèse Store-centrique et corrige la séparation Worker live / Job historique sans modifier Cargo. L'état précédent `0.3.9-pre.1.fix.2` reste documenté dans `pre.001-fix.002`.