169 lines
8.7 KiB
Markdown
169 lines
8.7 KiB
Markdown
# 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).
|