docs(snapshot): sync workspace documentation
This commit is contained in:
168
rpc/README.md
Normal file
168
rpc/README.md
Normal file
@@ -0,0 +1,168 @@
|
||||
# Baremetal RPC + VPS + Vast (Drift / DLOB / boty)
|
||||
|
||||
Ten folder zbiera w jednym miejscu ustalenia dot. topologii:
|
||||
|
||||
- **Bare metal**: prywatny Solana RPC (opcjonalnie z Geyser/Yellowstone dla feedów realtime).
|
||||
- **VPS**: “app/trading box” (k3s) z DLOB, statystykami, API i executorem transakcji.
|
||||
- **Vast (GPU, min 5090)**: trening transformera + ewentualnie inference, ale **bez sekretów**.
|
||||
|
||||
Dokumenty powiązane:
|
||||
|
||||
- `doc/dlob-services.md` — jak działają serwisy DLOB na VPS (k3s) i przepływ danych.
|
||||
- `doc/bots.md` — architektura botów (data plane / execution plane / model plane).
|
||||
- `doc/rpc/bot-executor-api.md` — minimalne endpointy i auth dla control plane / executora.
|
||||
- `doc/rpc/baremetal-monitoring.md` — jakie metryki zbieramy na RPC boxie i jak to wdrażamy (IaC).
|
||||
- `doc/rpc/baremetal-iac.md` — jak utrzymywać `mevnode-baremetal` jako IaC z runnera na VPS.
|
||||
|
||||
## Założenia (najważniejsze)
|
||||
|
||||
1) **RPC box ma być “lean”**: na bare metalu uruchamiamy tylko Solana RPC + minimum infrastruktury (VPN, firewall, monitoring).
|
||||
|
||||
2) **Drift/DLOB i reszta “biznesu” na VPS**: tam są publishery DLOB, Redis, warstwa persistence do Postgresa, DB, API, UI i executor.
|
||||
|
||||
3) **Vast = model plane**: trening (i ewentualnie inference) robimy na GPU, ale Vast **nigdy nie dostaje kluczy** ani tokenów do środków.
|
||||
|
||||
4) **Start od 2 marketów**: na początek ograniczamy DLOB do małej listy rynków, np. `PERP_MARKETS_TO_LOAD=0,75` (indeksy marketów PERP).
|
||||
|
||||
## Topologia (skrót)
|
||||
|
||||
```
|
||||
(public)
|
||||
┌────────────────────────────────────────────────────┐
|
||||
│ Internet / UI │
|
||||
│ trade-frontend + GraphQL (Hasura) + control-plane │
|
||||
└───────────────▲────────────────────────────────────┘
|
||||
│
|
||||
│ HTTPS (auth), brak “sign & send”
|
||||
│
|
||||
┌──────────────────┴───────────────────────────────────────────────────┐
|
||||
│ VPS (k3s / trade-staging) │
|
||||
│ │
|
||||
│ Data plane: │
|
||||
│ - dlob-publisher-hot/all → dlob-redis │
|
||||
│ - hot/all writers → Postgres → Hasura (GraphQL/WS) │
|
||||
│ │
|
||||
│ Execution plane: │
|
||||
│ - bot-executor (jedyny komponent z kluczami, podpisuje transakcje) │
|
||||
│ - trade-api (tokeny, admin ops, pomocnicze endpointy) │
|
||||
│ │
|
||||
│ Monitoring: Prometheus/Grafana/Alertmanager │
|
||||
└──────────────────▲───────────────────────────────────────────────────┘
|
||||
│ WireGuard (private)
|
||||
│ RPC/WS + opcjonalnie gRPC (Geyser)
|
||||
┌──────────────────┴───────────────────────────────────────────────────┐
|
||||
│ Bare metal (RPC box) │
|
||||
│ - agave/solana-validator jako prywatny RPC (bez publicznego dostępu) │
|
||||
│ - (opcjonalnie) Geyser/Yellowstone gRPC plugin │
|
||||
│ - wireguard + firewall + chrony + eksportery │
|
||||
└──────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
(public, outbound)
|
||||
┌──────────────────────────────────────────────────────────────────────┐
|
||||
│ Vast (GPU, min 5090) │
|
||||
│ - trening transformera na zebranych danych │
|
||||
│ - ewentualnie inference endpoint │
|
||||
│ - brak sekretów (brak kluczy, brak tokenów do środków) │
|
||||
└──────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Bare metal: co instalować i dlaczego
|
||||
|
||||
Minimalny zestaw (zgodnie z regułą “keep it lean”):
|
||||
|
||||
- **Solana RPC node** (validator w trybie RPC/non-voting).
|
||||
- **WireGuard**: RPC dostępny tylko prywatnie (VPS + admin).
|
||||
- **Firewall**: zablokowane porty RPC/WS na publicznym interfejsie; allow tylko na interfejsie WG.
|
||||
- **Chrony**: stabilny czas.
|
||||
- **Monitoring**:
|
||||
- `node_exporter` (CPU/RAM/dysk/iowait/sieć),
|
||||
- `solana-exporter` lub równoważny probe health przez RPC.
|
||||
- **Higiena dysk/logów**: rotacja logów, limity journald, monitoring NVMe.
|
||||
|
||||
Opcjonalnie (kolejny poziom “pro”):
|
||||
|
||||
- **Geyser / Yellowstone gRPC**: realtime stream kont/tx/slotów (mniejsze opóźnienia niż polling).
|
||||
|
||||
### Geyser + Drift DLOB (praktycznie)
|
||||
|
||||
Jeśli uruchamiasz Yellowstone gRPC na RPC boxie, to na VPS możesz przełączyć `dlob-publisher`
|
||||
na feed gRPC (zamiast Solana WS), a jednocześnie dalej trzymać prywatny dostęp po WireGuard.
|
||||
|
||||
- RPC HTTP (JSON-RPC): `ENDPOINT=http://<rpc_wg_ip>:8899`
|
||||
- RPC WS (pubsub): `WS_ENDPOINT=ws://<rpc_wg_ip>:8900`
|
||||
- Yellowstone gRPC: `GRPC_ENDPOINT=http://<rpc_wg_ip>:10000` (+ `TOKEN`, jeśli włączasz auth)
|
||||
|
||||
Konfiguracja DLOB (VPS) w praktyce (skrót):
|
||||
|
||||
- `PERP_MARKETS_TO_LOAD=0,75` (start od 2 marketów)
|
||||
- `USE_ORDER_SUBSCRIBER=true`
|
||||
- `USE_GRPC=true` + `GRPC_ENDPOINT` + `TOKEN` + `GRPC_CLIENT=yellowstone`
|
||||
- (opcjonalnie) `DISABLE_GPA_REFRESH=true` żeby ograniczyć polling
|
||||
|
||||
Więcej: `doc/rpc/geyser-dlob.md`.
|
||||
|
||||
Uwaga o 192 GB RAM:
|
||||
|
||||
- Na mainnet łatwo “dobić” pamięć jeśli włączysz ciężkie indeksy kont / rozbudowane API / wielu klientów.
|
||||
- Dlatego tym bardziej trzymamy RPC jako **prywatny** (mała liczba klientów: DLOB + executor + admin) i przenosimy obliczenia na VPS.
|
||||
|
||||
## VPS (k3s): co działa i jak jest używane
|
||||
|
||||
W `trade-staging` (k3s) mamy dwa krytyczne “plany”:
|
||||
|
||||
### Data plane (market data + statsy)
|
||||
|
||||
Opis szczegółowy: `doc/dlob-services.md`.
|
||||
|
||||
- `dlob-publisher-hot` i `dlob-publisher-all`: budują DLOB “off your RPC” i publikują snapshoty do Redis.
|
||||
- Na start ogranicz rynki hot-setu przez `PERP_MARKETS_TO_LOAD`.
|
||||
- `dlob-redis`: szybki cache dla publisherów i writerów.
|
||||
- `dlob-hot-redis-to-postgres-raw-writer`, `dlob-hot-postgres-to-postgres-derived-writer`, `dlob-all-redis-to-postgres-derived-writer`:
|
||||
- zapisują raw `hot` i derived `hot/all` do Postgresa,
|
||||
- Hasura wystawia te dane jako GraphQL + subscriptions.
|
||||
|
||||
### Execution plane (transakcje na Drift)
|
||||
|
||||
Opis szczegółowy: `doc/bots.md` (separation of concerns + kill switch).
|
||||
|
||||
- **`bot-executor`**:
|
||||
- jedyny komponent z kluczami (seed/keypair),
|
||||
- wykonuje `place/modify/cancel/close` + limity ryzyka + kill switch,
|
||||
- komunikuje się z DB (config/desired state + event log).
|
||||
|
||||
### Jak wystawić API na zewnątrz (propozycja)
|
||||
|
||||
Kluczowa zasada:
|
||||
|
||||
- **Nie wystawiamy publicznie “sign & send tx”**.
|
||||
|
||||
Wystawiamy tylko control plane:
|
||||
|
||||
- ustawianie `bot_config` (desired state / kill switch),
|
||||
- odczyt `bot_state` / `bot_events`,
|
||||
- market data / statsy przez Hasurę (GraphQL) i/lub własne read-only endpointy.
|
||||
|
||||
Warstwa dostępu (rekomendacja):
|
||||
|
||||
- Sieć: WireGuard / allowlist IP.
|
||||
- Aplikacja: tokeny + scopes.
|
||||
- (opcjonalnie) mTLS/HMAC między serwisami.
|
||||
|
||||
Executor czyta “desired state” z DB i sam podpisuje transakcje w klastrze.
|
||||
|
||||
## IaC (Git) dla bare metalu
|
||||
|
||||
Konfigurację RPC boxa (Solana RPC + Geyser + WireGuard + firewall + exporters) warto trzymać w Git
|
||||
i wdrażać z VPS (np. Ansible po WireGuard).
|
||||
|
||||
Starter (szkielet): `infra/baremetal-solana-rpc/`.
|
||||
|
||||
## Vast (GPU): jak to wpinamy
|
||||
|
||||
Model plane wg `doc/bots.md`:
|
||||
|
||||
- VPS zbiera dane (features, statsy, candles, eventy) i składa dataset.
|
||||
- Trening transformera na Vast (min 5090).
|
||||
- Artefakty modelu wracają na VPS (lub inference zostaje na Vast), ale:
|
||||
- **Vast nie dostaje kluczy**,
|
||||
- VPS podejmuje decyzję o wykonaniu i podpisuje transakcje (executor).
|
||||
Reference in New Issue
Block a user