Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.3.15-pre.009

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-14 11:38:55 +02:00
parent d3eea1aa12
commit 11105fac28
26 changed files with 1194 additions and 293 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md -->
<!-- version: 15 -->
<!-- version: 16 -->
# Acquisition et alimentation `RawTransaction`
@@ -164,7 +164,7 @@ Le caller ne lui fournit pas une signature, un `program_id`, une plage historiqu
Deux entrées publiques coexistent : `start` conserve la fondation sans source productive, tandis que `start_with_runtime_resources` lance la collection de ressources live validée. Les cinq familles productives matérialisées sont :
```text
Yellowstone Transaction / TransactionStatus / Block
Yellowstone Transaction / TransactionStatus
Standard WS logsSubscribe
Helius transactionSubscribe
-> signaux transactionnels source-neutral
@@ -172,6 +172,12 @@ Helius transactionSubscribe
-> HTTP getTransaction observed
-> Common RAW
Yellowstone Block (mode de reconciliation caller-selected)
-> trigger slot temps réel
-> HTTP getBlock observed Full/Base64
-> toutes les transactions Legacy|V0|V1 du bloc
-> Common RAW
Standard WS blockSubscribe Full/Base64 Legacy|V0|V1
HTTP live block polling getSlot -> getBlocksWithLimit -> getBlock observed
-> qualification RAW directe Legacy|V0|V1
@@ -297,7 +303,7 @@ HTTP getBlock full/base64 Legacy/V0/V1
provider stream compatible full transaction après parité prouvée
```
Dans le Worker V1 actuel, Yellowstone reste volontairement traité comme signal puis hydraté par HTTP `getTransaction` afin de conserver un seul chemin de canonicalisation productif pour cette famille. Les voies directes effectivement matérialisées dans le Worker sont Standard Block et HTTP Block Polling.
Le Worker conserve le mode Yellowstone transaction/status + `getTransaction` pour les compositions qui le demandent, mais la route Desk Mainnet utilise désormais Yellowstone Block comme trigger et `getBlock` comme chemin de reconciliation. Cela réduit le chemin nominal d'environ une requête HTTP par transaction à une requête par bloc tout en réutilisant la canonicalisation block déjà qualifiée. La projection protobuf Yellowstone -> RAW directe reste non revendiquée tant que la parité complète du meta n'est pas prouvée. Les voies RAW-directes existantes restent Standard Block et HTTP Block Polling.
Chemin logique :

12
docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md -->
<!-- version: 12 -->
<!-- version: 13 -->
# Plan v0.3.15 — Raw Transaction Ingest Desk
@@ -238,7 +238,7 @@ Le frontend reçoit uniquement la projection sûre de ce modèle. Les ressources
| Route V1 | Network | Required capability | Optional capability | Config evidence | Worker resource | Composable aujourd’hui ? | Missing contract | Live-testable ? |
|-------------------------------|------------------|----------------------------------------------------------------|-------------------------------------------------|---------------------------------|-----------------------------------------------|-----------------------------------------------------------------------------------|------------------------------------------------|--------------------------------------|
| `yellowstone-hydrated` | réseau du profil | Yellowstone gRPC Subscribe + HTTP `getTransaction` même réseau | scan HTTP repair si rôle compatible | gRPC + HTTP role | `RawTransactionIngestYellowstoneSource` | oui sur profil complet et secrets résolus | aucun contrat essentiel | provider-gated selon profil |
| `yellowstone-hydrated` | réseau du profil | Yellowstone gRPC Block Subscribe + HTTP `getBlock` même réseau | reconciliation HTTP bloc multi-provider | gRPC + HTTP role | `RawTransactionIngestYellowstoneSource` | oui sur profil complet et secrets résolus | aucun contrat essentiel | provider-gated selon profil |
| `standard-logs-hydrated` | réseau du profil | WS Solana standard `logsSubscribe` + HTTP `getTransaction` | scan HTTP repair si rôle compatible | `Logs` + HTTP role | `RawTransactionIngestStandardLogsSource` | oui côté Config sur profils déclarant `Logs` ; enforcement Worker en `pre.004` | enforcement Worker minimal | oui, notamment Devnet keyless |
| `standard-block-direct` | réseau du profil | WS Solana standard `blockSubscribe` explicitement déclaré | aucune hydration obligatoire | WS capability `Block` | `RawTransactionIngestStandardBlockSource` | oui sur les profils publics standard qui déclarent explicitement `Block` | enforcement Worker minimal + endpoint qualifié | seulement endpoint prouvé compatible |
| `helius-transaction-hydrated` | réseau du profil | WS Helius `transactionSubscribe` + HTTP `getTransaction` | scan HTTP repair si rôle compatible | `HeliusTransaction` + HTTP role | `RawTransactionIngestHeliusTransactionSource` | oui côté Config sur `helius_*` si secret résolu ; enforcement Worker en `pre.004` | enforcement Worker minimal | provider-gated Helius |
@@ -795,15 +795,17 @@ Le slot reste occupé pendant le drain terminal et la fermeture Store ; aucun se
Le test live Mainnet a montré que `yellowstone-hydrated` ouvrait bien le gRPC PublicNode mais reconstruisait son pool `getTransaction` à partir du Transport de base `mainnet_public`, donc `api.mainnet.solana.com`. Le fix impose que le gRPC Yellowstone et son hydration HTTP proviennent du même composant `transport.yellowstone`. Le profil `publicnode_mainnet` utilise désormais `https://solana-rpc.publicnode.com` pour son endpoint HTTP et n'hérite plus de la limite locale Solana-public `5 req/s`; la concurrence reste bornée et les `429` continuent à déclencher le cooldown Transport.
Ce fix ne prétend pas rendre viable le firehose Mainnet complet par hydration unitaire. La suppression de l'hydration systématique quand Yellowstone porte déjà le matériau transactionnel, le pool HTTP multi-provider, le multi-route, la déduplication cross-route et le repair HTTP par bloc sont explicitement déplacés vers `pre.009`.
Ce fix ne prétend pas rendre viable le firehose Mainnet complet par hydration unitaire. `pre.009` remplace finalement ce chemin nominal par Yellowstone Block -> `getBlock` multi-provider : l'hydratation `getTransaction` systématique disparaît de la route Desk, tandis que la projection protobuf -> RAW directe reste différée jusqu'à preuve de parité canonique complète.
Budget cible : une tranche runtime mono-route.
### `pre.009` — optimisation Mainnet, multi-route et Store partagé
Permettre plusieurs routes simultanées avec un Worker indépendant par route, un même Store partagé lorsque le réseau est strictement identique et une isolation des faults entre routes. La tranche doit également traiter le goulet observé sur Mainnet : privilégier un chemin Yellowstone direct lorsque le matériau RAW peut être reconstruit sans `getTransaction`, réserver HTTP à la réparation/hydration réellement nécessaire, et introduire un pool HTTP multi-provider dont les quotas, health, cooldown et capabilities restent endpoint-owned.
Matérialiser plusieurs routes simultanées avec **un Worker indépendant par route**, un même `Arc<Store>` partagé uniquement lorsque le réseau est strictement identique, Stop ciblé et isolation des faults. Le premier Start same-network ouvre/valide Store ; les suivants le réutilisent ; la dernière route terminale seule ferme Store. Aucun gap, frontier ou handle Worker n'est partagé entre routes.
Le Store conserve l'idempotence `(network, signature)` et les observations/provenances permettent à plusieurs routes de confirmer la même transaction sans créer une seconde entité RAW. Le repair HTTP doit privilégier le niveau bloc lorsqu'il permet de récupérer plusieurs transactions par requête.
Pour Mainnet, remplacer le chemin Yellowstone nominal `transaction -> getTransaction` par `Yellowstone Block -> getBlock Full/Base64`. L'abonnement Block sert de trigger temps réel sans transporter le payload transactionnel ; la reconciliation HTTP récupère toutes les transactions du bloc en une requête, avec retry borné/interruptible afin d'absorber le décalage court entre disponibilité gRPC et HTTP. Cette tranche ne revendique pas encore une canonicalisation protobuf -> RAW directe.
Le profil `publicnode_mainnet` expose un pool HTTP de même rôle contenant PublicNode et Solana public. Les limites, health, cooldown et concurrence restent endpoint-owned et `HttpTransportPool` conserve son routage/fallback. Store assure toujours l'idempotence `(network, signature)` et conserve les observations/provenances distinctes lorsque plusieurs routes voient la même transaction.
Budget cible : une tranche runtime/throughput Mainnet + multi-route.

12
docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md -->
<!-- version: 13 -->
<!-- version: 14 -->
# Validation v0.3.15 — Raw Transaction Ingest Desk
@@ -174,7 +174,7 @@ Plusieurs Workers peuvent recevoir le même `Arc<Store>` ; leurs lifecycle/gaps/
| Route V1 | Network | Required capability | Optional capability | Config evidence | Worker resource | Composable aujourd’hui ? | Missing contract | Live-testable ? |
|-------------------------------|------------------|----------------------------------------------------------------|-------------------------------------------------|-----------------------|-----------------------------------------------|---------------------------------------------------------|--------------------------------------------------|-----------------------------------------------|
| `yellowstone-hydrated` | réseau du profil | Yellowstone gRPC Subscribe + HTTP `getTransaction` même réseau | scan HTTP repair si rôle compatible | gRPC + HTTP role | `RawTransactionIngestYellowstoneSource` | oui sur profil complet et secrets résolus | aucun contrat essentiel | provider-gated selon profil |
| `yellowstone-hydrated` | réseau du profil | Yellowstone gRPC Block Subscribe + HTTP `getBlock` même réseau | reconciliation HTTP bloc multi-provider | gRPC + HTTP role | `RawTransactionIngestYellowstoneSource` | oui sur profil complet et secrets résolus | aucun contrat essentiel | provider-gated selon profil |
| `standard-logs-hydrated` | réseau du profil | WS Solana standard `logsSubscribe` + HTTP `getTransaction` | scan HTTP repair si rôle compatible | WS + HTTP role | `RawTransactionIngestStandardLogsSource` | non prouvable strictement avant capability WS explicite | Transport + Config + enforcement Worker minimaux | oui, notamment Devnet keyless après extension |
| `standard-block-direct` | réseau du profil | WS Solana standard `blockSubscribe` explicitement déclaré | aucune hydration obligatoire | WS capability Block | `RawTransactionIngestStandardBlockSource` | non prouvable aujourd’hui | Transport + Config + enforcement Worker minimaux | seulement endpoint prouvé compatible |
| `helius-transaction-hydrated` | réseau du profil | WS Helius `transactionSubscribe` + HTTP `getTransaction` | scan HTTP repair si rôle compatible | Helius WS + HTTP role | `RawTransactionIngestHeliusTransactionSource` | non dans les profils committed actuels | Config data/composite + capability WS explicite | provider-gated Helius |
@@ -419,11 +419,15 @@ Le parcours live `pre.008-fix.003` prouve que le channel Yellowstone PublicNode
Le fix corrige la composition : `prepare_yellowstone` prend désormais son role/pool HTTP dans le même `ResolvedTransportConfig` optionnel qui fournit le gRPC. Le profil `publicnode_mainnet` expose `publicnode_solana_mainnet_rpc` sur `https://solana-rpc.publicnode.com`, provider `publicnode`, sans recopier la limite locale `5 req/s` du profil Solana-public. La concurrence locale reste bornée à 8 et le cooldown Transport sur `429` reste actif.
Non-claim : ce changement réduit une erreur de composition mais ne garantit pas qu'une hydration HTTP unitaire puisse suivre le firehose Mainnet. L'optimisation structurelle Yellowstone direct + pool HTTP multi-provider + repair bloc est reportée à `pre.009`.
Non-claim : ce changement réduit une erreur de composition mais ne garantit pas qu'une hydration HTTP unitaire puisse suivre le firehose Mainnet. `pre.009` choisit finalement Yellowstone Block -> `getBlock` multi-provider comme optimisation sûre ; la projection protobuf -> RAW directe reste non revendiquée.
### `pre.009` — optimisation Mainnet et runtime multi-route
Un Worker par route, même Store si réseau identique, isolation des faults, chemin Yellowstone direct lorsque possible, pool HTTP multi-provider et repair par bloc pour éviter que `getTransaction` unitaire soit le chemin nominal du temps réel.
La tranche matérialise un Worker indépendant par route, Stop ciblé, Store partagé uniquement sur identité réseau exacte et fermeture Store par la dernière route. Les faults restent route-local et aucune TargetCoverage/gap/frontier n'est partagée entre Workers.
La route Yellowstone bascule sur un filtre Block sans transactions embarquées puis reconcile le slot par `getBlock` Full/Base64. Le Worker distingue explicitement son ancien mode transaction-hydration du mode block-reconciliation ; ce dernier n'entre plus dans la registry d'hydration `getTransaction`. La récupération bloc est interruptible par Stop et retente de façon bornée lorsque le bloc n'est pas encore visible ou qu'un endpoint du pool échoue.
Le profil `publicnode_mainnet` contient deux endpoints HTTP de même rôle : PublicNode et Solana public repair. La validation doit prouver que Config conserve leurs limites séparées et que la route exige désormais `getBlock`, pas `getTransaction`. Le direct protobuf -> RAW n'est pas revendiqué.
### `pre.010` — monitoring