945 lines
55 KiB
Markdown
945 lines
55 KiB
Markdown
<!-- file: docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md -->
|
||
<!-- version: 11 -->
|
||
|
||
# Acquisition et alimentation `RawTransaction`
|
||
|
||
## 1. Rôle du document
|
||
|
||
Ce document est l'owner durable de l'architecture d'alimentation des `RawTransaction` de KSP.
|
||
|
||
Il ne suit pas l'ordre chronologique des audits `pre.004` / `pre.005`. Il synthétise directement le modèle cible :
|
||
|
||
```text
|
||
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
|
||
```
|
||
|
||
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.
|
||
|
||
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é.
|
||
|
||
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.
|
||
|
||
## 2. Centre du modèle : Store et `RawTransaction`
|
||
|
||
### 2.1 Vérité RAW durable
|
||
|
||
L'identité canonique reste :
|
||
|
||
```text
|
||
RawTransaction identity = (network, signature)
|
||
```
|
||
|
||
Le contenu canonique doit être indépendant de la source d'acquisition :
|
||
|
||
```text
|
||
même identité + même contenu canonique
|
||
-> idempotence
|
||
|
||
même identité + contenu canonique divergent
|
||
-> conflit explicite
|
||
-> jamais first-provider-wins silencieux
|
||
```
|
||
|
||
La provenance d'acquisition n'est pas l'identité de la transaction. Elle appartient aux observations associées.
|
||
|
||
### 2.2 Observations et provenance
|
||
|
||
Une même transaction peut être acquise plusieurs fois :
|
||
|
||
```text
|
||
PublicNode Yellowstone
|
||
Helius WSS
|
||
HTTP getTransaction
|
||
blockSubscribe
|
||
archive provider
|
||
...
|
||
```
|
||
|
||
Ces acquisitions peuvent converger vers un seul `RawTransaction` et plusieurs `RawTransactionObservation` distinctes lorsque leurs clés d'observation sont différentes et utiles.
|
||
|
||
La provenance sûre peut conserver notamment :
|
||
|
||
```text
|
||
provider
|
||
protocole
|
||
méthode
|
||
origin logique
|
||
endpoint logique
|
||
commitment
|
||
filter id
|
||
capture session id
|
||
timestamps
|
||
hash/taille du payload source
|
||
```
|
||
|
||
Aucune URL secrète, clé API ou payload sensible ne doit traverser ce contrat durable.
|
||
|
||
### 2.3 Complétude avant persistence
|
||
|
||
Une source n'est autorisée à produire directement un `RawTransaction` que si elle permet de reconstruire le payload canonique complet attendu par Store.
|
||
|
||
Un signal incomplet reste un matériau de discovery/hydration :
|
||
|
||
```text
|
||
signature seule
|
||
logs
|
||
transaction status
|
||
transaction body sans execution meta
|
||
shreds
|
||
slot/block meta
|
||
```
|
||
|
||
Il doit être complété avant la persistence RAW canonique.
|
||
|
||
## 3. Deux producteurs indépendants
|
||
|
||
### 3.1 Job Backfill : historique paramétré et borné
|
||
|
||
`ksp-job-backfill-lib` a pour rôle de **récupérer un historique demandé**.
|
||
|
||
Une campagne reçoit des paramètres métier explicites, par exemple :
|
||
|
||
```text
|
||
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/base64, legacy-v0 | bloc + transactions | oui, parité RAW v1 prouvée | oui, direct pour le sous-ensemble qualifié | non sans mécanisme de replay historique | méthode standard instable ; capability validator-dependent |
|
||
| Helius `transactionSubscribe` full/base64 | transaction + meta + signature/index | non sans hydration | oui, signal riche puis hydration HTTP | non comme source historique | absence de blockTime/version dans l’enveloppe qualifiée |
|
||
| 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/base64 legacy-v0 qualifié
|
||
provider stream compatible full transaction après parité prouvée
|
||
```
|
||
|
||
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` | HTTP/WS standard multi-provider, PublicNode Yellowstone gRPC, Helius HTTP/WSS | Helius gRPC payant, QuickNode, Alchemy, Chainstack, Shyft, Triton, dRPC, GetBlock | identité KSP canonique ; `mainnet-beta` = alias legacy/externe |
|
||
| `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_block_observed
|
||
get_slot
|
||
get_first_available_block
|
||
minimum_ledger_slot
|
||
```
|
||
|
||
`get_block_observed` conserve désormais la provenance sûre provider/endpoint du winner réel d’un pool HTTP, symétriquement à `get_transaction_observed`. La projection d’une transaction full issue d’un bloc vers le matériau RAW commun reste volontairement hors de Transport : l’adapter productif appartient au producer (Worker/Job) afin de ne créer aucun edge `Transport -> ksp-raw-transaction-lib`.
|
||
|
||
### 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.
|
||
|
||
La qualification `pre.005` ferme deux cas distincts : `blockSubscribe` standard en `full/base64` avec `maxSupportedTransactionVersion = 0` produit, sur fixture identique, les mêmes bytes/hash RAW v1 que `getBlock`; Helius `transactionSubscribe` full/base64 conserve l’identité, le slot, le transaction wire, la meta et l’index mais ne transporte pas `blockTime` ni `version` dans l’enveloppe qualifiée. Helius reste donc un signal live riche à hydrater par HTTP avant persistence RAW directe.
|
||
|
||
### 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
|
||
```
|
||
|
||
Aucun backend physique ne doit entrer dans le Worker ou le Job.
|
||
|
||
### 12.5 Config
|
||
|
||
Config reste seul propriétaire :
|
||
|
||
```text
|
||
réseau
|
||
endpoints
|
||
provider/protocole
|
||
secrets
|
||
activation des sources
|
||
capabilities déclarées
|
||
priorités/composition
|
||
```
|
||
|
||
Les prix/tiers d'audit ne doivent pas devenir une politique runtime.
|
||
|
||
`mainnet` est l'identité réseau durable KSP. `mainnet-beta` reste uniquement un alias de compatibilité/historique ou un libellé externe lorsqu'un provider/API l'emploie. Depuis `0.3.9-pre.006-fix.003`, les profils Config/Store/Transport Mainnet engagés utilisent `mainnet` comme identité logique, et les exemples/tests associés ont été normalisés. Les endpoints publics Solana engagés suivent également la nomenclature Mainnet courante (`https://api.mainnet.solana.com` et `wss://api.mainnet.solana.com`). Aucune migration de données D1 n'est exigée : les données RAW Mainnet encore expérimentales peuvent être droppées/recréées si elles portent l'ancienne identité.
|
||
|
||
## 13. Normalisation RAW commune sans couplage Job/Worker
|
||
|
||
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.
|
||
|
||
Le handoff retient la crate source-neutral commune désormais matérialisée :
|
||
|
||
```text
|
||
ksp-raw-transaction-lib
|
||
```
|
||
|
||
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é.
|
||
|
||
Responsabilités prévues :
|
||
|
||
```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 ----> ksp-store-api
|
||
ksp-worker-raw-transaction-ingest-lib ---> ksp-raw-transaction-lib ----> ksp-store-api
|
||
|
||
ksp-job-backfill-lib --------------------> ksp-store-lib
|
||
ksp-worker-raw-transaction-ingest-lib ---> ksp-store-lib
|
||
ksp-job-backfill-lib --------------------> ksp-onchain-transport-lib
|
||
ksp-worker-raw-transaction-ingest-lib ---> ksp-onchain-transport-lib
|
||
|
||
aucun edge Job <-> Worker
|
||
aucun edge Transport <-> ksp-raw-transaction-lib
|
||
```
|
||
|
||
La migration doit préserver exactement les golden bytes/hash RAW v1 déjà prouvés. Aucun RAW v2 n'est justifié.
|
||
|
||
### 13.1 Transaction wire Legacy/V0/V1
|
||
|
||
`pre.006` matérialise dans `ksp-raw-transaction-lib` un modèle wire Solana source-neutral, indépendant de Transport et des crates runtime Solana. Il sérialise exactement les formes Legacy, V0 et V1 puis expose aussi la représentation Base64.
|
||
|
||
Pour V1, le contrat suit SIMD-0385 tel qu'audité le 7 septembre 2026 :
|
||
|
||
```text
|
||
0x81
|
||
LegacyHeader
|
||
TransactionConfigMask u32 LE
|
||
LifetimeSpecifier [32]
|
||
NumInstructions u8
|
||
NumAddresses u8
|
||
Addresses
|
||
ConfigValues
|
||
InstructionHeaders
|
||
InstructionPayloads
|
||
Signatures terminales
|
||
```
|
||
|
||
Les limites common verrouillées sont : transaction `<= 4096` octets, `<= 12` signatures, `<= 64` adresses, `<= 64` instructions, indexes bornés, aucune ALT en V1 et aucune donnée après les signatures. La présence de `Message.config` Yellowstone distingue V1 ; `versioned=true` sans config reste V0, et `versioned=false` sans config reste Legacy.
|
||
|
||
L'extracteur de signature Base64 common reconnaît désormais V1 au premier octet `0x81` et parcourt structurellement le message jusqu'aux signatures terminales au lieu d'appliquer le short-vector signatures-first de Legacy/V0.
|
||
|
||
Le format V1 est encore documenté upstream comme pre-release/feature-gated ; KSP implémente donc la capacité de lecture/canonicalisation sans déclarer son activation sur un cluster particulier.
|
||
|
||
### 13.2 Qualification Yellowstone `pre.006`
|
||
|
||
Un canari cross-layer test-only dans Backfill monte un serveur Geyser local, ouvre le vrai `YellowstoneGrpcChannel::open_standard_subscribe`, reçoit successivement une update `Transaction` V1 et une update `Block` contenant la même transaction, puis projette les DTO Transport vers le modèle wire common uniquement dans le test.
|
||
|
||
Le gate prouve :
|
||
|
||
```text
|
||
Transaction update -> slot/index + transaction wire V1 exact
|
||
Block update -> slot/index + même transaction wire V1 exact + block_time
|
||
Transport -> aucun edge production vers ksp-raw-transaction-lib
|
||
Backfill -> tonic/yellowstone-grpc-proto strictement dev-only
|
||
```
|
||
|
||
Il ne qualifie pas un RAW-direct complet Yellowstone : une update `Transaction` ne porte pas `block_time`, et la représentation protobuf Yellowstone de la meta n'est pas démontrée byte-identical avec la projection JSON HTTP servant au RAW v1 actuel. La décision `TR-C4` reste donc conservative :
|
||
|
||
```text
|
||
Yellowstone Transaction/Block -> signal structuré + transaction wire fidèle
|
||
RAW v1 complet -> hydration HTTP avant persistence
|
||
```
|
||
|
||
Aucun adapter productif n'est ajouté en `pre.006`. Conformément à `TR-C2`, l'adapter `Transport DTO -> common` demeure réservé au Worker concret, désormais ouvert en `0.3.11`.
|
||
|
||
## 14. Handoff Worker live `0.3.11` à `0.3.14`
|
||
|
||
### 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/base64 legacy-v0 direct qualifié
|
||
Helius transactionSubscribe full/base64 + HTTP hydration
|
||
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` | fermé : `get_block_observed` symétrique de `get_transaction_observed` | provenance exacte en pool HTTP |
|
||
| `TR-C` | projection source-neutral des transactions full WS/Yellowstone ; Helius via hydration | é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.16` : 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 + observed getBlock + preuves cross-source
|
||
0.3.11 P0 : Worker foundation/runtime + persistence déterministe
|
||
0.3.12 P0 : Yellowstone transactions/blocks/status + hydration + replay continuity
|
||
0.3.13 P0 : WS logs + hydration, blockSubscribe, Helius transactionSubscribe, HTTP live polling
|
||
0.3.13 P1 : multi-source convergence, dedup, provenance, content conflict, backpressure
|
||
0.3.14 P0 : continuity repair complet + hardening + smokes gratuits accessibles
|
||
0.3.14 P2 : EARLY adapters accessibles seulement si prouvés
|
||
0.3.16 P0 : block scan historique
|
||
0.3.16 P0 : replay Yellowstone borné
|
||
0.3.16 P1 : provider history/archive
|
||
0.3.16 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** et revalidées pour Transaction V1 le **7 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 |
|
||
| getBlocksWithLimit | https://solana.com/docs/rpc/http/getblockswithlimit |
|
||
| getBlock | https://solana.com/docs/rpc/http/getblock |
|
||
| getSlot | https://solana.com/docs/rpc/http/getslot |
|
||
| getFirstAvailableBlock | https://solana.com/docs/rpc/http/getfirstavailableblock |
|
||
| minimumLedgerSlot | https://solana.com/docs/rpc/http/minimumledgerslot |
|
||
| logsSubscribe | https://solana.com/docs/rpc/websocket/logssubscribe |
|
||
| signatureSubscribe | https://solana.com/docs/rpc/websocket/signaturesubscribe |
|
||
| blockSubscribe | https://solana.com/docs/rpc/websocket/blocksubscribe |
|
||
| slotSubscribe | https://solana.com/docs/rpc/websocket/slotsubscribe |
|
||
| slotsUpdatesSubscribe | https://solana.com/docs/rpc/websocket/slotsupdatessubscribe |
|
||
|
||
### 18.2 Yellowstone et providers
|
||
|
||
| Source | URL |
|
||
|----------------------------------|--------------------------------------------------------------------------------------------------------------|
|
||
| Yellowstone proto | https://github.com/rpcpool/yellowstone-grpc/blob/master/yellowstone-grpc-proto/proto/geyser.proto |
|
||
| Yellowstone storage proto | https://github.com/rpcpool/yellowstone-grpc/blob/master/yellowstone-grpc-proto/proto/solana-storage.proto |
|
||
| SIMD-0385 Transaction V1 | https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md |
|
||
| Transaction V1 examples | https://github.com/solana-foundation/transaction-v1-examples |
|
||
| 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 |
|
||
|
||
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
|
||
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 canonique ; mainnet-beta alias legacy/externe
|
||
RAW canonicalisation = lower-layer commune, sans edge Job <-> Worker
|
||
Transaction V1 = wire source-neutral Legacy/V0/V1 dans common ; activation cluster non supposée
|
||
Yellowstone pre.006 = transaction wire V1 qualifié ; RAW complet via hydration HTTP
|
||
TR-C2 = adapter productif Transport DTO -> common réservé au Worker concret
|
||
0.3.10 = common RAW + preuves cross-source
|
||
0.3.11 à 0.3.14 = Worker live multi-source par responsabilités bornées
|
||
0.3.16 = Job Backfill multi-stratégie historique
|
||
```
|
||
|
||
`0.3.9` n'implémente aucune nouvelle stratégie d'acquisition. Il ferme l'architecture et l'inventaire nécessaires aux releases suivantes.
|