trade/trade-doc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0d3d11002607faa2b3400bed6297cca505924686
trade-doc/rpc/README.md

8.7 KiB
Raw Blame History

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).