Auf Solana, einem Bereich, der Tausende von Transaktionen pro Sekunde generiert, wird dein Bot schnell in einem Meer von Datenrauschen ertrinken, wenn du versuchst, alle Kontenaktualisierungen im gesamten Netzwerk zu überwachen. Bandbreitenbeschränkungen der RPC-Knoten, CPU-Entlastung und Netzwerkverzögerungen können Arbitragemöglichkeiten sofort zunichte machen.

Effiziente Sucher hören niemals „blind“ zu. Sie verwenden eine Strategie, die als „Bestandsgetriebenes Monitoring“ bekannt ist: Zuerst wird ein globaler Index für den gesamten Netzwerkliquiditätspool offline erstellt, um wertvolle „Arbitrage-Kandidaten-Pools“ herauszufiltern, gefolgt von präzisen Abonnements.

Dieser Artikel analysiert, wie man ein solches hochleistungsfähiges Inventory-System aufbaut.

1. Kernkonzept: Den Kampfplatz verkleinern, den Siegpunkt fixieren

1.1 Warum ein Inventory aufbauen?

Auf Solana gibt es DEXs (dezentrale Börsen), wie Raydium und Orca, die Zehntausende von Liquiditäts-Pools haben. Für Arbitrage-Strategien bieten jedoch nur solche Paare, die in mehreren Protokollen gleichzeitig vorhanden sind (z. B. SOL/USDC, die sowohl in Raydium als auch in Orca einen Pool haben), einen atomaren Arbitrage-Raum.

Die Aufgabe des Inventars besteht darin:

  • Cold-Start-Aggregation: Abrufen der vollständigen Pool-Liste von den verschiedenen DEX-APIs.

  • Schnittmengen-Berechnung: Finden der überlappenden Token-Paare.

  • Whitelist-Filterung: Entfernen von toten Pools und Pools mit geringer Liquidität, um eine "Überwachungs-Whitelist" zu erstellen.

1.2 Inventar-getriebener vs. Vollständig-getriebener Ansatz

  • Vollständig-getriebener Ansatz: Abonnieren aller Logs, Gelegenheiten finden und dann in einer Tabelle nachschlagen. Vorteil: Umfangreiche Abdeckung. Nachteil: Sehr hohe Latenz und hoher Overhead durch verarbeitete redundante Daten.

  • Inventar-getriebener Ansatz: Nur Aktualisierungen von Konten in der Whitelist abonnieren. Vorteil: Extrem schnelle Reaktion und Einsparung von RPC-Ressourcen. Der bevorzugte Ansatz für Hochfrequenz-Arbitrage.

2. Technische Architektur: Hochparallele Zustandsmaschine, unterstützt durch Rust

Im Rust-Ausführungs-Engine ist das Inventory-Modul als hochparallele, threadsichere Singleton-Klasse konzipiert, die von mehreren Strategie-Modulen gemeinsam genutzt wird.

2.1 Wichtige Datenstrukturen: DashMap und Arc

Da die Datenverarbeitung auf Solana mehrfach parallel erfolgt, muss das Inventory extrem hohe Lese- und Schreibfrequenzen bewältigen:

  • DashMap: Eine Hochleistungs-Hash-Tabelle für mehrfache Threads. Im Gegensatz zu standardmäßigen HashMap + Mutex wird die Sperrgranularität auf Shard-Ebene verfeinert, um globale Sperrkonflikte bei häufigen Status-Updates zu vermeiden.

  • Arc (Atomic Reference Counted): Wird verwendet, um die Speicheradresse des Inventory sicher zwischen verschiedenen Tokio-Aufgaben (wie Überwachungs-Aufgaben, Preis-Aufgaben, Ausführungs-Aufgaben) zu teilen und einen null-Kopie-Datenzugriff zu ermöglichen.

2.2 Index-Schicht-Logik

Das System verwaltet zwei Ebenen von Indizes:

  1. Globaler Pool-Index: Speichert die Zuordnung von Pool-Adressen zu Token-Metadaten (Mint, Dezimalstellen, Vault).

  2. Arbitrage-Paar-Zuordnung: Speichert die "kandidierenden Arbitrage-Paare". Zum Beispiel: Bei Eingabe der Mint-Adresse von SOL wird sofort die zugehörige Information über den Pool in Raydium A und Orca B zurückgegeben.

3. Algorithmus-Implementierung: Schnelle Schnittmenge in O(N+M)

Der Kern der Erstellung einer Arbitrage-Whitelist ist das 'Berechnen des Durchschnitts'.

  1. Scan von Protokoll A (Raydium): Alle Pools werden in einer temporären Hash-Tabelle gespeichert, mit Token_A → Pool_Address.

  2. Scan von Protokoll B (Orca): Durchlaufe die Liste der Pools und wenn das gleiche Token_A in der Hash-Tabelle von Protokoll A gefunden wird, liegt ein potenzieller Arbitrage-Chance vor.

  3. Erstellung der Watchlist: Füge die adressierten Pools gleichzeitig in die "Überwachungsliste (Watchlist)" ein.

Zeitkomplexität: Kann mit nur zwei linearen Durchläufen abgeschlossen werden. Selbst bei Zehntausenden von Pools wird die Cold-Start-Phase innerhalb von Millisekunden abgeschlossen.

4. Leistungs-Optimierungspunkte: Geschwindigkeit aus ingenieurtechnischen Details herausholen

4.1 API-Cache und Fehlertoleranz

Die offiziellen APIs von Protokollen wie Raydium sind oft nicht stabil genug. Wir haben in unserer ingenieurtechnischen Implementierung eine lokale persistente Cache-Funktion integriert.

  • Beim Cold-Start wird zunächst die lokale pools_cache.json gelesen.

  • Hintergrund-Asynchronanfrage an die API zur Aktualisierung des Cache.

  • Dies stellt sicher, dass der Roboter auch unter extremen Netzwerkbedingungen sofort wieder arbeiten kann.

4.2 Abonnementschranken und Fragmentierung

Die meisten RPC-Knoten beschränken die Anzahl der accountSubscribe-Anfragen pro Verbindung (z. B. 50–100).
Das Inventory sortiert die Watchlist automatisch nach der 'Pool-Heißheit' (Transaktionsvolumen/TVL) und abonniert zunächst die Top-N-Pools mit dem höchsten Gewinnpotenzial oder verteilt die Abonnements über mehrere RPC-Knoten durch Lastverteilung.

5. Algorithmus-Prototyp-Demonstration (Python-Logik-Implementierung)

Obwohl wir in der Produktion Rust verwenden, lässt sich die zugrundeliegende Logik anhand des folgenden Python-Beispiels klar darstellen:

from dataclasses import dataclass
from typing import Dict, List, Set

@dataclass(frozen=True)
class PoolMetadata:
address: str
token_mint: str

def build_arbitrage_radar(ray_pools: List[PoolMetadata], orca_pools: List[PoolMetadata]):
# 1. Raydium-Index erstellen (Token → Pool)
ray_index = {p.token_mint: p.address for p in ray_pools}

arbitrage_watchlist = []

# 2. Scan von Orca zur Suche nach Schnittmengen
for o_pool in orca_pools:
if o_pool.token_mint in ray_index:
# Übereinstimmung gefunden: Dieses Token hat Liquidität in beiden DEXs
arbitrage_watchlist.append({
"token": o_pool.token_mint,
"raydium_pool": ray_index[o_pool.token_mint],
"orca_pool": o_pool.address
})

return arbitrage_watchlist

# Mock-Daten zur Demonstration
ray_list = [PoolMetadata("RAY_SOL_POOL", "SOL_MINT"), PoolMetadata("RAY_BONK_POOL", "BONK_MINT")]
orca_list = [PoolMetadata("ORCA_SOL_POOL", "SOL_MINT"), PoolMetadata("ORCA_WIF_POOL", "WIF_MINT")]

watchlist = build_arbitrage_radar(ray_list, orca_list)
print(f"[*] Gefunden {len(watchlist)} potenzielle Arbitrage-Pfade")
Im Ergebnis wird der Pfad für SOL enthalten sein, da beide DEXs einen SOL-Pool haben.

6. Zusammenfassung: Der Radar ist aktiviert

Das Inventory-Modul ist das 'Sieb' des gesamten MEV-Systems, das alle Netzwerk-Rauschen filtert und nur diejenigen Ziele übrig lässt, die mit Gewinnpotential glänzen.

  • Ohne Inventory: Dein Roboter verarbeitet tausende von ungültigen Nachrichten ziellos.

  • Mit Inventory: Dein Roboter konzentriert sich nur auf die wenigen, häufig wechselnden Pools und ist jederzeit bereit, abzudrücken.

Nächster Schritt – Ankündigung

Mit der Whitelist ist der nächste Schritt, wie man diese Konten in Echtzeit erfasst. In einem nächsten Artikel werden wir das Scout-Modul vorstellen und erklären, wie über gRPC/WebSocket-Protokolle eine sub-millisekundenschnelle Transaktionsüberwachung und Datenanalyse erreicht wird.

Dieser Artikel wurde von Levi.eth verfasst und konzentriert sich auf hochleistungsfähige Ingenieurpraktiken im Solana-Ökosystem.