trade-doc/3700x.md

3700X jako drugi bare metal dla Drift perps

Ten dokument opisuje sensowną rolę drugiego hosta:

• AMD Ryzen 7 3700X
• 128 GB RAM
• 2 x 1 TB NVMe
• 1 Gbps

W tym układzie zakładamy, że:

• host 9950X robi tylko Agave + Yellowstone Geyser,
• host 3700X robi consumer + processing + lekka/umiarkowana baza,
• komunikacja między hostami idzie po prywatnej sieci (private VLAN albo później wg0).

Cel

Rozdzielić role:

• 9950X: ingest danych z Solany, bez ciężkiej obróbki
• 3700X: odbiór streamu, dekodowanie Drift, budowa DLOB, zapis pochodnych danych, API i worker-y

To zmniejsza ryzyko, że:

• baza danych,
• parser,
• albo batch/worker

zwiększą lag walidatora.

Co uruchamiać na 3700X

Tak:

• Yellowstone gRPC consumer
• parser Drift
• cache stanu w RAM
• worker-y realtime
• Redis / NATS / lekka kolejka
• Postgres o umiarkowanej skali
• read-only API / query layer
• monitoring

Nie:

• agave-validator
• ciężkie historyczne archiwum raw streamu
• duży ClickHouse na start
• wszystko naraz bez limitów retencji

Układ usług

Przepływ:

1. 9950X uruchamia Agave + Geyser plugin
2. 3700X łączy się po prywatnym adresie do gRPC
3. consumer odbiera tylko potrzebny scope Drift
4. parser buduje lokalny stan
5. do DB trafiają tylko dane pochodne i potrzebne eventy

Model:

• host A = producer
• host B = consumer + processing

Dyski

Najprostszy podział:

• nvme0:
  • system
  • Docker
  • binarki
  • cache buildów
• nvme1:
  • dane consumera
  • Postgres
  • logi aplikacyjne
  • kolejki / spool

Filesystem:

• ext4 na obu dyskach

Minimalny scope Yellowstone pod Drift perps

Na start nie streamuj całej Solany. Dla Drift perps minimalny sensowny zakres to:

• slots
• transactions tylko dla programu Drift
• accounts dla kont Drift potrzebnych do stanu rynku i userów

Konta i strumienie

Na start streamuj:

• State
• PerpMarketAccount dla wybranych rynków
• SpotMarketAccount potrzebne do collateral / quote
• UserAccount

Powód:

• Drift trzyma zlecenia i pozycje w UserAccount
• lokalny DLOB buduje się właśnie z UserAccount
• PerpMarketAccount daje stan rynku
• SpotMarketAccount jest potrzebny dla cross-margin

Filtry v1

Najrozsądniejsza wersja startowa:

• slots: włączone
• transactions:
  • account_include = [Drift Program ID]
  • bez vote tx
• accounts:
  • exact accounts dla State i marketów
  • UserAccount dla programu Drift

Jeśli interesują Cię tylko wybrane rynki, np. SOL-PERP, BTC-PERP, ETH-PERP, to:

• odbierasz UserAccount,
• po dekodzie odrzucasz userów bez pozycji i bez orderów na tych rynkach

To jest bezpieczniejsze operacyjnie niż próba zbyt agresywnego filtrowania przed dekodem.

Co liczyć po stronie consumera

W RAM trzymaj:

• cache UserAccount
• cache PerpMarketAccount
• cache SpotMarketAccount
• ostatni slot

Z tego licz:

• lokalny DLOB
• best bid / ask
• depth
• zmiany pozycji
• fills
• liquidations
• funding / mark / oracle impact

Do DB zapisuj:

• eventy biznesowe
• snapshoty pochodne
• agregaty

Nie zapisuj na start całego raw streamu 1:1.

Co daje taki układ

• mniejszy wpływ processingu na lag walidatora
• bezpieczny transport po prywatnej sieci
• prostsza diagnostyka
• możliwość restartu parsera bez ruszania noda
• łatwiejsze skalowanie w przyszłości

Ograniczenia 3700X

Ten host jest dobry jako:

• consumer node
• processing node
• umiarkowana DB

To nie jest idealny host pod:

• bardzo ciężki ClickHouse
• duże historyczne archiwum
• wiele ciężkich pipeline'ów naraz

Najbardziej ograniczą Cię:

• 1 Gbps
• pojemność 2 x 1 TB
• RAM przy większej retencji i większej liczbie workerów

Rekomendacja startowa

Na 3700X uruchom:

• Yellowstone consumer
• Drift parser
• Redis
• Postgres
• lekkie API

Na 9950X zostaw tylko:

• Agave
• Geyser

Najpierw uruchom zakres dla 2-3 rynków perp i dopiero potem rozszerzaj.

Powiązane dokumenty

• doc/rpc/software-placement.md
• doc/rpc/geyser-dlob.md
• doc/dlob-services.md