Solana-Datenströme und Protokolle verstehen (Shreds, gRPC, WS, UDP)
Wenn Sie Ihre Solana-Anwendung oder Trading-Strategie schneller machen möchten, sollten Sie zunächst nicht den Code oder die Serverspezifikationen betrachten.
Ausgangspunkt sind zwei grundlegende Fragen.
Ausgangspunkt sind zwei grundlegende Fragen.
Erstens: Wie weit sind Sie von den Solana-Validatoren entfernt, die für Sie relevant sind?
In welcher Region läuft Ihre Anwendung tatsächlich, und wie viele Millisekunden braucht es, um einen Validator von dort zu erreichen? Diese Distanz ist die Grundlage für alles. Wenn der Abstand falsch ist, wird keine Software- oder Hardware-Optimierung die Leistung freischalten, die möglich sein sollte.
In welcher Region läuft Ihre Anwendung tatsächlich, und wie viele Millisekunden braucht es, um einen Validator von dort zu erreichen? Diese Distanz ist die Grundlage für alles. Wenn der Abstand falsch ist, wird keine Software- oder Hardware-Optimierung die Leistung freischalten, die möglich sein sollte.
Zweitens: Wo befindet sich der Leader-Validator zu einem bestimmten Zeitpunkt?
Wenn Frankfurt der Leader ist, werden Knoten in der Nähe von Frankfurt strukturell begünstigt. Wenn Tokio der Leader ist, werden Knoten in der Nähe von Tokio bevorzugt. Solana-Leader rotieren weltweit von Slot zu Slot. Solange diese Eigenschaft besteht, wird es bei einem Single-Region-Setup immer Zeitfenster geben, in denen es physisch benachteiligt ist.
Wenn Frankfurt der Leader ist, werden Knoten in der Nähe von Frankfurt strukturell begünstigt. Wenn Tokio der Leader ist, werden Knoten in der Nähe von Tokio bevorzugt. Solana-Leader rotieren weltweit von Slot zu Slot. Solange diese Eigenschaft besteht, wird es bei einem Single-Region-Setup immer Zeitfenster geben, in denen es physisch benachteiligt ist.
In der Praxis bedeutet dies, dass eine realistische Strategie mehrere Regionen umfassen muss.
Indem Sie die Infrastruktur an mehreren Standorten wie Frankfurt, Amsterdam, New York, Chicago, Tokio und Singapur platzieren, können Sie die Kette aus einer Region beobachten, die zu jedem Zeitpunkt in der Nähe des aktuellen oder kommenden Leaders liegt.
Indem Sie die Infrastruktur an mehreren Standorten wie Frankfurt, Amsterdam, New York, Chicago, Tokio und Singapur platzieren, können Sie die Kette aus einer Region beobachten, die zu jedem Zeitpunkt in der Nähe des aktuellen oder kommenden Leaders liegt.
Nachdem der physische und zeitliche Kontext geklärt ist, können wir über Solanas Datenströme sprechen. Dieser Artikel konzentriert sich auf drei, denen Entwickler häufig begegnen:
- WebSocket (WS)
- Geyser gRPC
- Shredstream (UDP Shreds)
Wir betrachten, zu welchem Zeitpunkt jeder Datenstrom die Daten sieht, welche Transporteigenschaften er hat und wofür er sich tatsächlich eignet.
Ziel ist nicht, etwas zu wählen, nur weil „der Name schnell klingt“, sondern zu verstehen, wie Solana selbst funktioniert und wie sich die zugrunde liegenden Protokolle verhalten, und diese Erkenntnisse dann konkret mit App-Performance und UX zu verknüpfen.
Ziel ist nicht, etwas zu wählen, nur weil „der Name schnell klingt“, sondern zu verstehen, wie Solana selbst funktioniert und wie sich die zugrunde liegenden Protokolle verhalten, und diese Erkenntnisse dann konkret mit App-Performance und UX zu verknüpfen.
Zeitliche Unterschiede im Datenfluss von Solana
Zunächst muss man verstehen, wann verschiedene Datenarten in Solanas interner Pipeline tatsächlich erscheinen.
Grob gesagt gibt es drei Stufen, die für die Betrachtung der Performance hilfreich sind.
Grob gesagt gibt es drei Stufen, die für die Betrachtung der Performance hilfreich sind.
Die erste Stufe sind Shreds.
Validatoren tauschen Shreds über UDP aus, um Blöcke zu erstellen. Dabei werden Daten übertragen, die noch nicht vollständig zu einem Block zusammengesetzt wurden. Wenn Sie diese Phase anzapfen können, sehen Sie Änderungen an der Chain zum frühestmöglichen Zeitpunkt. Der Nachteil ist, dass Sie bei UDP Paketverluste und nicht sortierte Ankünfte einkalkulieren und Ihr System entsprechend gestalten müssen.
Validatoren tauschen Shreds über UDP aus, um Blöcke zu erstellen. Dabei werden Daten übertragen, die noch nicht vollständig zu einem Block zusammengesetzt wurden. Wenn Sie diese Phase anzapfen können, sehen Sie Änderungen an der Chain zum frühestmöglichen Zeitpunkt. Der Nachteil ist, dass Sie bei UDP Paketverluste und nicht sortierte Ankünfte einkalkulieren und Ihr System entsprechend gestalten müssen.
Die zweite Stufe ist Geyser gRPC.
Nachdem ein Validator Shreds empfangen und einen Block erstellt und bestätigt hat, kann er die Ergebnisse über Geyser-Plugins strukturiert bereitstellen. Daraus entstehen Geyser-gRPC-Streams: Sie liefern Ereignisse wie Blöcke, Logs und Kontoaktualisierungen. Das geschieht eine Stufe später als bei Shreds, aber die Daten sind bereits organisiert und daher für Anwendungen wesentlich leichter zu verarbeiten.
Nachdem ein Validator Shreds empfangen und einen Block erstellt und bestätigt hat, kann er die Ergebnisse über Geyser-Plugins strukturiert bereitstellen. Daraus entstehen Geyser-gRPC-Streams: Sie liefern Ereignisse wie Blöcke, Logs und Kontoaktualisierungen. Das geschieht eine Stufe später als bei Shreds, aber die Daten sind bereits organisiert und daher für Anwendungen wesentlich leichter zu verarbeiten.
Die dritte Stufe sind HTTP-RPC und WebSocket.
Sobald die Daten Geyser und weitere interne Verarbeitung durchlaufen haben und in die internen Speicher des Knotens geschrieben wurden, sind sie über JSON-RPC und WebSocket-Benachrichtigungen verfügbar. Methoden wie getBalance, getProgramAccounts und Log-Abonnements lesen aus diesem gespeicherten Zustand. Zeitlich liegt diese Stufe hinter den Geyser-Benachrichtigungen und bildet die oberste „öffentliche“ API-Schicht, die die meisten Anwendungen zuerst sehen.
Sobald die Daten Geyser und weitere interne Verarbeitung durchlaufen haben und in die internen Speicher des Knotens geschrieben wurden, sind sie über JSON-RPC und WebSocket-Benachrichtigungen verfügbar. Methoden wie getBalance, getProgramAccounts und Log-Abonnements lesen aus diesem gespeicherten Zustand. Zeitlich liegt diese Stufe hinter den Geyser-Benachrichtigungen und bildet die oberste „öffentliche“ API-Schicht, die die meisten Anwendungen zuerst sehen.
Zusammengefasst:
- Shreds sind Rohdaten sehr nah an dem Moment der Ausbreitung.
- Geyser gRPC liefert strukturierte Daten an dem Punkt, an dem Blöcke bestätigt werden.
- RPC und WebSocket stellen gespeicherte Daten als APIs bereit, die nachträglich abgefragt werden.
Welche Phase Sie beobachten, bestimmt, wie früh Sie Änderungen an der Kette erkennen können. Dieser Zeitunterschied allein schafft bereits eine signifikante Leistungslücke.
Transporteigenschaften: UDP, gRPC, WebSocket und TLS
Timing ist eine Achse. Die zweite Achse ist, wie die Daten tatsächlich transportiert werden.
Shreds verwenden UDP.
UDP hat kleine Header und erfordert keinen Verbindungsaufbau. Es garantiert weder erneute Übertragung noch Reihenfolge, minimiert dafür aber die Latenz. Für Shreds, die redundant zwischen vielen Validatoren verbreitet werden, sind diese Einfachheit und Geschwindigkeit genau richtig.
UDP hat kleine Header und erfordert keinen Verbindungsaufbau. Es garantiert weder erneute Übertragung noch Reihenfolge, minimiert dafür aber die Latenz. Für Shreds, die redundant zwischen vielen Validatoren verbreitet werden, sind diese Einfachheit und Geschwindigkeit genau richtig.
Geyser gRPC läuft über TCP mit einem binären Protokoll.
Streaming-RPC, Header-Komprimierung und binäre Kodierung ermöglichen eine effizientere Übertragung als bei typischem HTTP+JSON. Das eignet sich gut, um strukturierte Ereignisse kontinuierlich in Backends, Überwachungssystemen und Analyse-Pipelines zu verarbeiten.
Streaming-RPC, Header-Komprimierung und binäre Kodierung ermöglichen eine effizientere Übertragung als bei typischem HTTP+JSON. Das eignet sich gut, um strukturierte Ereignisse kontinuierlich in Backends, Überwachungssystemen und Analyse-Pipelines zu verarbeiten.
WebSocket sitzt in der Regel auf TCP plus TLS und verwendet JSON-Payloads.
Der Hauptvorteil ist, dass Browser und Standard-Webstacks es direkt verwenden können, weshalb es in dApps und leichten Bots weit verbreitet ist. Der Nachteil ist, dass Text-JSON geparst werden muss und Header sowie Verschlüsselung zusätzlichen Overhead verursachen. Von den drei Verfahren ist dies in der Regel das aufwendigste.
Der Hauptvorteil ist, dass Browser und Standard-Webstacks es direkt verwenden können, weshalb es in dApps und leichten Bots weit verbreitet ist. Der Nachteil ist, dass Text-JSON geparst werden muss und Header sowie Verschlüsselung zusätzlichen Overhead verursachen. Von den drei Verfahren ist dies in der Regel das aufwendigste.
Darüber hinaus fügt TLS selbst eine weitere Kostenschicht hinzu.
Bei https, wss oder gRPC-TLS muss jede Verbindung einen Handshake ausführen sowie Nutzdaten ver- und entschlüsseln. Für allgemeine Web-Apps ist dies in der Regel akzeptabel und kaum wahrnehmbar. Für Strategien, bei denen Dutzende Millisekunden für UX oder PnL wichtig sind, ist der Overhead spürbar.
Bei https, wss oder gRPC-TLS muss jede Verbindung einen Handshake ausführen sowie Nutzdaten ver- und entschlüsseln. Für allgemeine Web-Apps ist dies in der Regel akzeptabel und kaum wahrnehmbar. Für Strategien, bei denen Dutzende Millisekunden für UX oder PnL wichtig sind, ist der Overhead spürbar.
Wichtig ist:
- der Zeitpunkt, zu dem Sie Daten sehen (Shreds / Geyser / RPC)
- die Art, wie Sie sie transportieren (UDP / gRPC / WebSocket / TLS)
Diese beiden Aspekte sind voneinander getrennt, beeinflussen aber beide Ihre endgültige Latenz und UX erheblich.
Geschwindigkeit im Kontext: Zeitpunkt und Transport
Mit diesen Grundlagen können Sie Geschwindigkeit konkreter beurteilen.
Aus Sicht des Zeitpunkts:
- Shreds sehen die früheste Phase.
- Geyser gRPC kommt als nächstes.
- RPC / WebSocket kommt zuletzt.
Aus Sicht des Verkehrs:
- UDP ist am schlanksten und schnellsten.
- gRPC über TCP folgt mit effizientem binärem Streaming.
- WebSocket mit JSON und TLS ist in der Regel am aufwendigsten.
Wenn man dieselbe Region, Hardware und denselben Netzwerkpfad zugrunde legt, ergibt sich folgende technische Geschwindigkeitsreihenfolge:
- UDP (Shreds)
- gRPC (Geyser)
- WebSocket (JSON-RPC Benachrichtigungen)
Natürlich betrachtet dies die Geschwindigkeit isoliert. In realen Systemen können Sie nicht nur auf Latenz schauen. Sie müssen auch Zuverlässigkeit, Korrektheitsanforderungen, Entwicklungskosten und die Komplexität berücksichtigen, die Ihr Team tatsächlich bewältigen kann.
Zuverlässigkeit und Entwicklungskosten: Warum in der Praxis WS > gRPC > UDP gilt
In vielen realen Projekten ist die Reihenfolge, in der Datenströme eingeführt werden, fast das Gegenteil der technischen Geschwindigkeitsrangfolge:
- Zuerst WebSocket
- Dann Geyser gRPC
- Schließlich Shreds / UDP
Das ist kein Zufall.
Shreds (UDP) sind am schnellsten, erfordern aber von Anfang an ein Design für fehlende und ungeordnete Daten.
Sie können nicht davon ausgehen, dass jedes Paket ankommt oder alle Daten perfekt geordnet sind. Ihre Logik muss Lücken behandeln, die Daten bei Bedarf mit anderen Streams abgleichen und Störungen tolerieren. Der Vorteil ist minimale Latenz, während Implementierung und Betrieb deutlich anspruchsvoller werden.
Sie können nicht davon ausgehen, dass jedes Paket ankommt oder alle Daten perfekt geordnet sind. Ihre Logik muss Lücken behandeln, die Daten bei Bedarf mit anderen Streams abgleichen und Störungen tolerieren. Der Vorteil ist minimale Latenz, während Implementierung und Betrieb deutlich anspruchsvoller werden.
Geyser gRPC liefert Daten, die im Knoten bereits bestätigt und strukturiert wurden.
Das macht die Daten wesentlich leichter verarbeitbar. Ereignisgesteuerte Backends, Alarmsysteme, On-Chain-Analysen und Indexer können auf Geyser aufbauen und dabei Geschwindigkeit, Zuverlässigkeit und Entwicklungsaufwand ausbalancieren. Für viele Teams ist dies der natürliche zweite Schritt, sobald reine WebSocket-Setups an ihre Grenzen stoßen.
Das macht die Daten wesentlich leichter verarbeitbar. Ereignisgesteuerte Backends, Alarmsysteme, On-Chain-Analysen und Indexer können auf Geyser aufbauen und dabei Geschwindigkeit, Zuverlässigkeit und Entwicklungsaufwand ausbalancieren. Für viele Teams ist dies der natürliche zweite Schritt, sobald reine WebSocket-Setups an ihre Grenzen stoßen.
Der Hauptvorteil von WebSocket ist die direkte Unterstützung durch Browser und normale Web-Infrastruktur.
dApp-Frontends und leichte Dienste können vorhandene Tools und Bibliotheken verwenden, und die entsprechenden Codemuster sind weit verbreitet. Für die erste Produktversion ist WebSocket oft der praktischste Ausgangspunkt, insbesondere wenn das Problem der Entfernung zu den Validatoren bereits gelöst ist.
dApp-Frontends und leichte Dienste können vorhandene Tools und Bibliotheken verwenden, und die entsprechenden Codemuster sind weit verbreitet. Für die erste Produktversion ist WebSocket oft der praktischste Ausgangspunkt, insbesondere wenn das Problem der Entfernung zu den Validatoren bereits gelöst ist.
Theoretisch lautet die Geschwindigkeitsreihenfolge UDP > gRPC > WS.
In der Praxis ist die Einführungsreihenfolge in der Regel WS > gRPC > UDP.
Sie müssen beide Achsen im Auge behalten und anhand Ihrer aktuellen Phase und Ziele wählen, statt einem abstrakten „schnellsten“ Label nachzujagen.
In der Praxis ist die Einführungsreihenfolge in der Regel WS > gRPC > UDP.
Sie müssen beide Achsen im Auge behalten und anhand Ihrer aktuellen Phase und Ziele wählen, statt einem abstrakten „schnellsten“ Label nachzujagen.
Wie Shreds und Geyser gRPC zusammenarbeiten
Sobald Sie über grundlegende Geschwindigkeitsoptimierung hinausgehen und es auf Dutzende Millisekunden ankommt, stellt sich die Schlüsselfrage, wie sich Shreds und Geyser gRPC kombinieren lassen.
Shreds dienen dazu, Änderungen zuerst zu erkennen.
Wenn Sie Shreds in der Nähe des aktuellen Leaders empfangen, können Sie Änderungen auf der Chain Dutzende bis Hunderte Millisekunden früher erkennen als jemand, der nur Geyser oder RPC beobachtet. Für Strategien, bei denen diese Lücke direkt in PnL übergeht, ist dies sehr wichtig. Der Kompromiss besteht darin, dass Sie Rauschen akzeptieren und Ihr System dafür auslegen müssen.
Wenn Sie Shreds in der Nähe des aktuellen Leaders empfangen, können Sie Änderungen auf der Chain Dutzende bis Hunderte Millisekunden früher erkennen als jemand, der nur Geyser oder RPC beobachtet. Für Strategien, bei denen diese Lücke direkt in PnL übergeht, ist dies sehr wichtig. Der Kompromiss besteht darin, dass Sie Rauschen akzeptieren und Ihr System dafür auslegen müssen.
Geyser gRPC dient der korrekten Bestätigung und Einordnung.
Zum Zeitpunkt der Blockbestätigung sendet Geyser Protokolle, Kontoänderungen und andere strukturierte Ereignisse aus. Sie können diese in Ihre Strategielogik, Risikokontrollen, Indexer und Überwachungssysteme einfügen. Es ist langsamer als Shreds, aber die Daten sind konsistent und viel einfacher zu verstehen.
Zum Zeitpunkt der Blockbestätigung sendet Geyser Protokolle, Kontoänderungen und andere strukturierte Ereignisse aus. Sie können diese in Ihre Strategielogik, Risikokontrollen, Indexer und Überwachungssysteme einfügen. Es ist langsamer als Shreds, aber die Daten sind konsistent und viel einfacher zu verstehen.
Ein gemeinsames Muster im Feld ist:
- Verwenden Sie Shreds, um Chancen zu erkennen und Kandidatentransaktionen so schnell wie möglich zusammenzustellen.
- Verwenden Sie gleichzeitig Geyser gRPC, um Blöcke und Logs zu überprüfen und Ihre Kernlogik sowie Überwachung zu steuern.
Diese Trennung ermöglicht es Ihnen, die Latenz zu reduzieren und Ihre Entscheidungsfindung zugleich auf stabile, verifizierbare Daten zu stützen.
TLS, gemeinsam genutzte Endpunkte und dedizierte Knoten
Bisher haben wir angenommen, dass der zugrunde liegende Knoten und das Netzwerk gleich sind. In Wirklichkeit gibt es einen weiteren großen strukturellen Unterschied: ob Sie einen gemeinsamen Endpunkt oder einen dedizierten Knoten verwenden.
Ein gemeinsamer Endpunkt wird gleichzeitig von vielen Nutzern verwendet.
Er ist über das öffentliche Internet erreichbar, und der Datenverkehr läuft durch eine Sicherheitsgrenze. Verschlüsselung ist obligatorisch; TLS lässt sich nicht einfach deaktivieren. Die Kosten für Verschlüsselung, Entschlüsselung und Handshakes sind bei normaler dApp-Nutzung völlig akzeptabel, machen sich aber bemerkbar, wenn in einem HFT-Kontext jede Millisekunde zählt.
Er ist über das öffentliche Internet erreichbar, und der Datenverkehr läuft durch eine Sicherheitsgrenze. Verschlüsselung ist obligatorisch; TLS lässt sich nicht einfach deaktivieren. Die Kosten für Verschlüsselung, Entschlüsselung und Handshakes sind bei normaler dApp-Nutzung völlig akzeptabel, machen sich aber bemerkbar, wenn in einem HFT-Kontext jede Millisekunde zählt.
Ein dedizierter Knoten ist für einen einzigen Nutzer reserviert.
Da Sie den Zugriff per IP-Adresse einschränken und die Umgebung isolieren können, haben Sie die Möglichkeit, TLS zu deaktivieren und einfaches HTTP oder unverschlüsseltes gRPC zu verwenden. Außerdem teilen Sie CPU, Speicher, Festplatten-I/O und Netzwerkbandbreite nicht mit anderen Kunden, sodass die Latenz nicht schwankt, weil jemand anderes auf derselben Maschine eine hohe Last erzeugt.
Da Sie den Zugriff per IP-Adresse einschränken und die Umgebung isolieren können, haben Sie die Möglichkeit, TLS zu deaktivieren und einfaches HTTP oder unverschlüsseltes gRPC zu verwenden. Außerdem teilen Sie CPU, Speicher, Festplatten-I/O und Netzwerkbandbreite nicht mit anderen Kunden, sodass die Latenz nicht schwankt, weil jemand anderes auf derselben Maschine eine hohe Last erzeugt.
Wenn Sie Shreds, Geyser gRPC und RPC auf dedizierten Knoten betreiben, arbeiten alle diese Datenströme in einer von anderen Nutzern und TLS-Overhead isolierten Umgebung.
Diese Kombination ermöglicht es dedizierten Setups, Latenzbereiche zu erreichen, die gemeinsam genutzte Endpunkte konstruktionsbedingt selbst mit derselben Hardware nicht erreichen können.
Diese Kombination ermöglicht es dedizierten Setups, Latenzbereiche zu erreichen, die gemeinsam genutzte Endpunkte konstruktionsbedingt selbst mit derselben Hardware nicht erreichen können.
Gemeinsam genutzte Knoten bieten vielen Nutzern solide Leistung.
Dedizierte Knoten existieren, um die Grenzen zu drücken, wenn Sie wirklich den schnellsten Weg benötigen.
Dedizierte Knoten existieren, um die Grenzen zu drücken, wenn Sie wirklich den schnellsten Weg benötigen.
Multi-Region und dedizierte Shreds (UDP-Weiterleitung)
Wenn wir zu Entfernung und Leader-Position zurückkehren: Solange Solanas Leader rund um den Globus wechseln, kann ein Setup in nur einer Region nicht überall und jederzeit am schnellsten sein.
Hier kommen Multi-Region-Shred-Setups ins Spiel.
Dedizierte Shreds (Premium Shreds, Standard Shreds, Metal Shreds, Limited Editions und ähnliche Produktlinien) kombinieren:
- die schnellstmögliche UDP-Übertragung von Shreds
- Dedizierte Server mit minimalem Jitter
Durch die Bereitstellung von dedizierten Shreds in mehreren Regionen wie Frankfurt, Amsterdam, New York, Chicago, Tokio und Singapur erhalten Sie Shreds in der Nähe des Leaders, unabhängig davon, welche Region derzeit bevorzugt ist.
Ein gängiges Muster ist, gleichzeitig mehrere Shred-Feeds aus verschiedenen Regionen zu abonnieren und nur den zuerst eintreffenden Feed zu verwenden.
Dies reduziert die Auswirkungen der Langstreckenlatenz und regionaler Überlastung und ermöglicht es Ihnen, sich praktisch einem Zustand „immer nahe am Leader“ anzunähern.
Dies reduziert die Auswirkungen der Langstreckenlatenz und regionaler Überlastung und ermöglicht es Ihnen, sich praktisch einem Zustand „immer nahe am Leader“ anzunähern.
Um dedizierte Shreds in mehreren Regionen zugänglicher zu machen, bietet ERPC Rabattcoupons für die Multi-Region-Nutzung:
- 2 Regionen: 5 % Rabatt
- 3 Regionen: 8 % Rabatt
- 5 Regionen: 10 % Rabatt
- Alle Regionen: 15 % Rabatt
Dies erleichtert Setups, in denen Sie die besten Shred-Tarife (z. B. Premium oder Metal) in den wettbewerbsfähigsten Regionen einsetzen und in unterstützenden Regionen kostengünstigere Optionen nutzen, während Sie dennoch eine breite Abdeckung erreichen.
Shared-Shredstream-Bundles: ein breiterer Einstieg in Shreds
Bevor Sie überall vollständig auf dedizierte Shreds setzen, kann ein Shared-Shredstream-Setup in mehreren Regionen ein sehr praktischer Zwischenschritt sein.
Shared-Shredstream-Bundles ermöglichen es Ihnen, unter einem einzigen Tarif gemeinsam genutzte Shreds aus mehreren Regionen zu beziehen.
Intern nimmt Shared Shredstream die Daten aus der Shred-Schicht (UDP) und liefert sie über gRPC. Die Quelle sind weiterhin Shreds: Sie sehen die Informationen also eine Stufe früher als bei Geyser gRPC und profitieren zugleich vom komfortablen gRPC-Streaming.
Intern nimmt Shared Shredstream die Daten aus der Shred-Schicht (UDP) und liefert sie über gRPC. Die Quelle sind weiterhin Shreds: Sie sehen die Informationen also eine Stufe früher als bei Geyser gRPC und profitieren zugleich vom komfortablen gRPC-Streaming.
Die Schichten ordnen sich wie folgt:
- Dedizierte Shreds über UDP-Forwarding liegen am nächsten an der ursprünglichen Verbreitung und sind am schnellsten.
- Shared Shredstream ist ein aus Shreds abgeleiteter gRPC-Stream und liegt direkt darüber.
- Geyser gRPC kommt danach, zum Block-Bestätigungszeitpunkt.
Shared-Shredstream-Bundles umfassen IP-Whitelisting, 10 Verbindungen und automatisches Routing zum nächstgelegenen Edge. So bleiben die Kosten angemessen, während Sie aus Shreds abgeleitete Daten gleichzeitig in Regionen wie Asien, Nordamerika und Europa nutzen können.
Anstatt direkt in jeder Region dedizierte Shreds einzusetzen, können Sie:
- mit einem Shared-Shredstream-Bundle starten, um praktische Erfahrungen mit Shreds-basierten Daten zu sammeln.
- Logs und Leistungsdaten nutzen, um zu verstehen, wo es den größten Unterschied macht.
- besonders wichtige Regionen auf dedizierte Shreds migrieren, sobald Sie Belege und einen klaren Geschäftsfall haben.
Praktische Schritte nach Entwicklungsphase
Wenn man alles zusammenführt, ist es hilfreich, in Entwicklungsphasen zu denken.
In Phase 1 wählen Sie die richtige Region und Entfernung und bauen Ihre dApp oder Ihren Bot mit RPC und WebSocket.
Die richtige Region und Netzwerkplatzierung bringen oft schon vor dem Einsatz von Shreds oder gRPC deutliche UX-Verbesserungen. Für den Produktstart ist WebSocket eine sehr vernünftige Wahl, insbesondere im Frontend.
Die richtige Region und Netzwerkplatzierung bringen oft schon vor dem Einsatz von Shreds oder gRPC deutliche UX-Verbesserungen. Für den Produktstart ist WebSocket eine sehr vernünftige Wahl, insbesondere im Frontend.
In Phase 2 ergänzen Sie Geyser-gRPC-Unterstützung, um Backends, Überwachung und Analysen zu stärken.
Mit Geyser gRPC können Sie Block-, Log- und Kontoereignisse effizient verarbeiten und darauf robuste Indexer, Alarmsysteme und externe APIs aufbauen. Es bietet ein gutes Gleichgewicht aus Geschwindigkeit, Zuverlässigkeit und Entwicklungskosten und ist für viele Teams ein natürlicher „zweiter Schritt“.
Mit Geyser gRPC können Sie Block-, Log- und Kontoereignisse effizient verarbeiten und darauf robuste Indexer, Alarmsysteme und externe APIs aufbauen. Es bietet ein gutes Gleichgewicht aus Geschwindigkeit, Zuverlässigkeit und Entwicklungskosten und ist für viele Teams ein natürlicher „zweiter Schritt“.
In Phase 3 führen Sie Shreds und UDP-Forwarding dort ein, wo Latenzunterschiede PnL oder UX direkt beeinflussen.
Durch dedizierte Shreds in mehreren Regionen und Multi-Region-Rabatte können Sie die für HFT-, MEV- und 0-Slot-Strategien erforderliche Latenz erreichen, ohne alles auf einmal von Grund auf neu entwerfen zu müssen.
Durch dedizierte Shreds in mehreren Regionen und Multi-Region-Rabatte können Sie die für HFT-, MEV- und 0-Slot-Strategien erforderliche Latenz erreichen, ohne alles auf einmal von Grund auf neu entwerfen zu müssen.
Der entscheidende Punkt ist nicht: „UDP ist theoretisch am schnellsten, also verwenden Sie überall nur UDP.“
Entscheidend ist, Ihre Entwicklungsphase und Wirtschaftlichkeit zu betrachten und dann zu bestimmen, wo und wann Investitionen in Shreds und dedizierte Infrastruktur tatsächlich einen Unterschied machen.
Entscheidend ist, Ihre Entwicklungsphase und Wirtschaftlichkeit zu betrachten und dann zu bestimmen, wo und wann Investitionen in Shreds und dedizierte Infrastruktur tatsächlich einen Unterschied machen.
ERPC-Bundles und VPS als Grundlage
Die ERPC-Bundle-Pläne sind darauf ausgelegt, Ihnen eine vollständige Grundlage zu bieten:
- RPC (HTTP / WebSocket)
- Geyser gRPC
- Shared Shredstream gRPC
alle unter einer einzigen Struktur.
Sie können RPC und WebSocket weiterhin als wichtigste Produktionsschnittstellen verwenden und gleichzeitig Geyser gRPC und Shredstream im selben Netzwerk testen.
Da alles auf einer einheitlichen Infrastruktur läuft, können Sie Verhalten und Leistung direkt vergleichen und Entscheidungen auf Grundlage tatsächlicher Messungen statt bloßer Annahmen treffen.
Da alles auf einer einheitlichen Infrastruktur läuft, können Sie Verhalten und Leistung direkt vergleichen und Entscheidungen auf Grundlage tatsächlicher Messungen statt bloßer Annahmen treffen.
Darüber hinaus können Sie dies mit VPS-Produktlinien im selben ERPC-Netzwerk kombinieren, etwa EPYC VPS und Premium Ryzen VPS.
Damit können Sie an einem Ort Folgendes optimieren:
- Distanz zu Solana-Validatoren
- Auswahl der Datenströme (WS, gRPC, Shreds)
- Hardware-Leistung
Ein praktischer Ansatz besteht darin, zunächst die richtigen Regionen sowie die ERPC-Bundle-plus-VPS-Grundlage zu sichern und dann schnellere Schichten (Geyser, Shared Shreds, dedizierte Shreds) einzusetzen, wenn sich Ihre Anforderungen ändern und die wirtschaftlichen Rahmenbedingungen weiterentwickeln.
Fazit: Solana-Performance durch Zeitpunkt, Transport und Entfernung
Die Performance und UX einer Solana-Anwendung ergeben sich aus einer Kombination mehrerer Faktoren:
- Wo sich Ihre Server befinden
- Wie nah Sie in jedem Zeitfenster am Leader sind
- Zu welchem Zeitpunkt Sie On-Chain-Daten erhalten
- Welchen Transport und welches Protokoll Sie verwenden
- Wie Ihre Anwendungslogik darauf reagiert
Distanz und Leader-Position bilden die Basis. Darüber hinaus haben Sie:
- Shreds für die früheste Phase
- Geyser gRPC für bestätigte, strukturierte Daten
- RPC / WebSocket zum Zugriff auf gespeicherten Zustand über APIs
Und auf der Transportseite haben Sie:
- UDP
- gRPC über TCP
- WebSocket über TCP mit JSON und TLS
Die alleinige Auswahl eines Streams oder Protokolls nach Namen oder Marketing reicht nicht aus.
Der Punkt ist, eine Struktur auszuwählen, die Ihrem Anwendungsfall entlang dieser drei Achsen entspricht: Timing, Transporteigenschaften und Abstand zu den relevanten Validatoren.
Der Punkt ist, eine Struktur auszuwählen, die Ihrem Anwendungsfall entlang dieser drei Achsen entspricht: Timing, Transporteigenschaften und Abstand zu den relevanten Validatoren.
ERPC und Validators DAO bieten ein Solana-orientiertes Netzwerk, RPC-, gRPC- und Shredstream-Dienste, VPS-Produktlinien sowie Multi-Region-Rabatte für dedizierte Shreds. So können Sie diese Strukturen zu realistischen Kosten aufbauen und sie mit wachsenden Anforderungen weiterentwickeln.
Wenn Sie über Datenstromdesign, die Optimierung der Netzwerkentfernung oder Kombinationen aus dedizierten Shreds, Shared-Shredstream-Bundles, Bundles und VPS sprechen möchten, können Sie uns gerne über den Validators-DAO-Discord kontaktieren.
- ERPC: https://erpc.global/de
- SLV: https://slv.dev/de
- Epics DAO: https://epics.dev/de
- Validators DAO Discord: https://discord.gg/C7ZQSr CkYR
