110 lines
4.6 KiB
Markdown
110 lines
4.6 KiB
Markdown
# 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`
|