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 :