docs: add rpc/dlob/candles notes
This commit is contained in:
109
doc/drift-data-bez-solana-rpc.md
Normal file
109
doc/drift-data-bez-solana-rpc.md
Normal file
@@ -0,0 +1,109 @@
|
||||
# Drift / Solana: czy mamy dostęp do danych bez Solana RPC?
|
||||
|
||||
Pytanie ma dwa znaczenia — rozdzielmy je jasno:
|
||||
|
||||
1) **bez własnego (bare metal) RPC** — czyli nie utrzymujemy swojego `solana-validator --rpc`, ale korzystamy z dostawcy RPC albo zewnętrznych serwisów,
|
||||
2) **bez żadnego RPC w ogóle** — czyli nikt w naszym systemie nie pyta Solany o stan on‑chain.
|
||||
|
||||
TL;DR:
|
||||
- **Bez własnego RPC**: tak, da się na start (hosted RPC +/lub serwisy zewnętrzne).
|
||||
- **Bez żadnego RPC**: tylko częściowo (dane “rynkowe” można brać z zewnętrznego DLOB), ale **stan konta/pozycji/fille/funding** i tak pochodzi z chaina, więc ktoś musi mieć RPC.
|
||||
|
||||
---
|
||||
|
||||
## Co z Twojego “speca” da się mieć bez własnego RPC?
|
||||
|
||||
Poniżej mapowanie kategorii danych (z Twojego opisu A–F) na źródła:
|
||||
|
||||
### B) Prices / microstructure (oracle/mark/BBO, “close now”)
|
||||
|
||||
**Da się bez własnego RPC**:
|
||||
- Tak. W naszym stacku te dane mogą pochodzić z pipeline DLOB (`dlob_*_latest`) i ticków (`drift_ticks`), które są już w DB i dostępne przez Hasurę / `trade-api`.
|
||||
|
||||
**Da się bez żadnego RPC w naszej infra** (czyli “my nie łączymy się do RPC”):
|
||||
- Częściowo tak, jeśli polegamy na zewnętrznym źródle L2/BBO (np. `https://dlob.drift.trade`) — ale to źródło i tak jest zasilane przez czyjeś RPC.
|
||||
|
||||
### A) Position snapshot (pozycja: base, entry, side)
|
||||
|
||||
**Bez własnego RPC**:
|
||||
- Tak, jeśli mamy **jakikolwiek** komponent (executor/collector) korzystający z hosted RPC (Helius/QuickNode/itp.) i zapisujący snapshot pozycji do DB.
|
||||
|
||||
**Bez żadnego RPC**:
|
||||
- Praktycznie nie (pozycja jest stanem konta on‑chain). Wyjątek: jeśli Twój executor/bot sam utrzymuje lokalny stan i zapisuje go do DB — ale po restarcie i tak potrzebujesz reconcile z chaina (czyli RPC).
|
||||
|
||||
### C) Account risk (margin/liquidation/health)
|
||||
|
||||
**Bez własnego RPC**:
|
||||
- Tak, jeśli collector liczy to na backendzie z danych Drift (przez hosted RPC) i zapisuje do TS (`contract_metrics_ts` / analogicznie).
|
||||
|
||||
**Bez żadnego RPC**:
|
||||
- Nie, bo margin/liq zależy od stanu konta i parametrów rynku on‑chain.
|
||||
|
||||
### D) Fills / trades (realized PnL + fees + slippage)
|
||||
|
||||
**Bez własnego RPC**:
|
||||
- Tak, jeśli:
|
||||
- executor składa zlecenia i loguje fille do `bot_events` (to już mamy jako koncept), albo
|
||||
- collector subskrybuje eventy transakcji / kont przez hosted RPC i zapisuje fille do DB.
|
||||
|
||||
**Bez żadnego RPC**:
|
||||
- Tylko jeśli fille są już zapisane w DB (np. przez bota). Na bieżąco — ktoś musi je wyciągać z chaina.
|
||||
|
||||
### E) Funding / payments
|
||||
|
||||
**Bez własnego RPC**:
|
||||
- Tak, ale ktoś musi pobierać funding rate / funding payment (hosted RPC lub inny feed) i zapisywać do DB.
|
||||
|
||||
**Bez żadnego RPC**:
|
||||
- Jak wyżej: tylko z historii zapisanej w DB; na żywo potrzebujesz źródła z chaina.
|
||||
|
||||
### F) Order lifecycle costs (cancel/replace/tx)
|
||||
|
||||
**Bez własnego RPC**:
|
||||
- Tak, jeśli executor:
|
||||
- loguje akcje (create/cancel/replace) i ich koszty (`tx_fee_usd`, priority fee) do `bot_events`, albo
|
||||
- collector wyciąga metryki tx z RPC i mapuje do orderów.
|
||||
|
||||
**Bez żadnego RPC**:
|
||||
- Tylko retrospektywnie (jeśli już w DB).
|
||||
|
||||
---
|
||||
|
||||
## Co to znaczy praktycznie dla architektury “backend liczy, UI tylko wyświetla”?
|
||||
|
||||
UI/Visualizer **może działać bez bezpośredniego kontaktu z RPC** (łączy się do `trade-api` + Hasura).
|
||||
|
||||
Natomiast backend “compute” (k3s) ma dwie opcje zasilania:
|
||||
|
||||
1) **Hosted RPC** (na start)
|
||||
- pro: szybciej, taniej, mniej ops,
|
||||
- con: limit subskrypcji/WS, możliwe rwania, vendor lock‑in.
|
||||
|
||||
2) **Własny RPC + Geyser/Yellowstone** (docelowo)
|
||||
- pro: kontrola, stabilność na większej skali, streaming “pro”,
|
||||
- con: koszt i ops (dyski/IO, tuning, monitoring).
|
||||
|
||||
W obu przypadkach “backend liczy” działa tak samo — różni się tylko źródło surowych danych.
|
||||
|
||||
---
|
||||
|
||||
## Co już mamy w DB “bez RPC w UI”
|
||||
|
||||
Z obecnego pipeline (VPS/k3s) mamy “rynkowe” dane pod BBO/slippage:
|
||||
- `dlob_l2_latest`, `dlob_stats_latest`, `dlob_slippage_latest`, `dlob_depth_bps_latest` (+ TS przez `*_ts`)
|
||||
- `drift_ticks` (ticki/ceny)
|
||||
|
||||
To wystarcza do:
|
||||
- estymat wejścia/wyjścia (“close now”),
|
||||
- wykresów spread/slippage/depth,
|
||||
- części SIM (model slippage/fee) **bez** znajomości pełnego stanu konta.
|
||||
|
||||
Do pełnego `contract_metrics_ts` (PnL + risk) brakuje nam jeszcze stałego feedu:
|
||||
- pozycji konta + margin/liq,
|
||||
- filli i funding (albo z chaina, albo z logów executora).
|
||||
|
||||
## Zobacz też
|
||||
|
||||
- “Kanoniczna” architektura w pełni self-hosted (RPC + DLOB): `doc/rpc-dlob-kanoniczna-architektura.md`
|
||||
- Runbook: bare metal RPC + Geyser/Yellowstone gRPC: `doc/solana-rpc-geyser-setup.md`
|
||||
- Mapa dokumentów o RPC/DLOB/metrykach: `doc/solana-rpc.md`
|
||||
Reference in New Issue
Block a user