Solanas Gulf Stream: Mehr Mempool, mehr Probleme

Praktische Erkenntnisse

• Der Begriff „Gulf Stream“ lässt sich grob als der Prozess definieren, der beginnt, sobald ein Node eine Transaktion im Netzwerk aufnimmt, und endet, wenn sie den Leader des aktuellen Slots erreicht und von der Fetch Stage der TPU (Transaction Processing Unit) empfangen wird.
• Solana hebt sich ab, weil es von Anfang an für den Betrieb ohne Mempool entwickelt wurde. Anders als traditionellere Blockchains, die Gossip-Protokolle nutzen, um Transaktionen breit im Netzwerk zu verteilen, leitet Solana alle Transaktionen für jeden Slot an einen vorab bestimmten führenden Validator weiter, den sogenannten Leader. Der Leader wechselt alle 4 Slots. Der Leader-Zeitplan ist allen aktiven Netzwerk-Nodes im Voraus bekannt und ermöglicht eine effiziente Weiterleitung von Transaktionen.
• Solana-Transaktionen müssen standardmäßig einen aktuellen Blockhash enthalten, den Entwickler einfach über einen API-Aufruf anfordern können. Ein aktueller Blockhash ist bis zu 150 Slots lang gültig, also ungefähr 1 Minute. Danach ist er veraltet und das Netzwerk verwirft Transaktionen, die auf ihn verweisen. So können unverarbeitete Transaktionen nicht im Netzwerk verbleiben. Aktuelle Blockhashes helfen außerdem bei der Deduplizierung von Transaktionen. Entwickler können zudem dauerhafte Nonces hinzufügen.
• Transaktionen in Gulf Stream werden codiert und über QUIC-Streams an den Leader gesendet. Die Einführung von QUIC Ende 2022 war ein bedeutendes Netzwerk-Upgrade und ersetzte die zuvor verwendeten UDP-Verbindungen. Hauptgrund für diese Änderung war, Spam besser aus dem Netzwerk filtern zu können. Der Wechsel zu QUIC ist jedoch nicht unumstritten, da Solana im gesamten Jahr 2024 ein beispielloses Aktivitätsniveau verzeichnete.
• Die Einführung von Stake-weighted Quality of Service (SWQoS) Anfang 2024 veränderte grundlegend, wie Transaktionen den Leader über Gulf Stream erreichen. Leader priorisieren nun Transaktionsnachrichten, die über andere Validatoren mit Stake weitergeleitet werden. Konkret sind 80 % der Kapazität eines Leaders (2.000 Verbindungen) für Peers mit Stake reserviert. Die verbleibenden 20 % (500 Verbindungen) stehen Transaktionsnachrichten von Nodes ohne Stake zur Verfügung.
• Derzeit sind mehr als 80 % des Stakes auf Solana bei Validatoren gebunden, die statt des ursprünglichen Agave-Clients den Jito-Solana-Client ausführen. Jito führt eine Blockspace-Auktion außerhalb des Protokolls ein. Das macht den Weg von Transaktionen zum Leader noch komplexer. Konkret fügt der Jito-Relayer eine 200 Millisekunden lange „Bremsschwelle“ hinzu, die den Fluss eingehender Transaktionsnachrichten verlangsamt. Dadurch haben Searcher genug Zeit, Bundles einzureichen.

Einführung

Der Begriff „Gulf Stream“ stammt aus einer Reihe einführender Blogbeiträge, die das Solana-Gründungsteam 2019 veröffentlichte. Darin gab es vielen innovativen Mechanismen von Solana Namen aus der Luftfahrt. In diesen Beiträgen wurde Gulf Stream als Solanas „Protokoll zur Weiterleitung von Transaktionen ohne Mempool“ definiert. Eine heutige Suche nach „Gulf Stream“ in der Solana-Codebasis liefert jedoch nur eine einzige unbedeutende Erwähnung.

Im breiteren Kontext des Lebenszyklus einer Solana-Transaktion lässt sich „Gulf Stream“ als der gesamte Prozess verstehen, der beginnt, sobald ein Netzwerk-Node – typischerweise ein RPC – eine Transaktion aufnimmt, und endet, wenn sie den Leader des aktuellen Slots erreicht, also von der „Fetch Stage“ der TPU aufgenommen wird. Man könnte Gulf Stream auch als Spiegelbild von Turbine verstehen, Solanas Mechanismus zur Blockverteilung: Über Gulf Stream erreichen Transaktionen den Leader, über Turbine verlassen verarbeitete Transaktionen den Leader.

Zunächst ist es hilfreich, RPC-Nodes (Remote Procedure Call) im Kontext von Solana zu definieren. Diese Nodes dienen als Gateways, über die du mit dem Netzwerk interagierst und Daten daraus liest. Sie vermitteln zwischen Nutzern und den Validatoren von Solana. RPCs führen dieselbe Software wie vollständige Validatoren aus, verwenden jedoch andere Einstellungen. So können sie Transaktionen präzise simulieren und eine aktuelle Ansicht des gegenwärtigen Zustands, der Bank, pflegen. RPC-Nodes haben jedoch keinen Stake und nehmen daher nicht am Konsens teil. Ohne Stake können sie weder abstimmen noch Blöcke erstellen. Das unterscheidet sich von vielen anderen Blockchains, bei denen Validatoren und RPC-Nodes üblicherweise identisch sind. Für Gulf Stream lässt sich die Rolle eines RPC so zusammenfassen: Er empfängt Transaktionen über HTTP, konvertiert sie für QUIC – dazu später mehr –, ermittelt anhand des Leader-Zeitplans die Adresse und Portinformationen des aktuellen Leaders und leitet die Transaktion an den aktuellen sowie die nächsten Leader weiter.

Seit dem Start des Netzwerks hat Gulf Stream mindestens zwei große Upgrades erhalten: QUIC und Stake-weighted QoS. Beide behandeln wir später in diesem Artikel ausführlich. Gulf Stream ist außerdem der Teil des Kernprotokolls, der in den vergangenen Jahren aufgrund des beispiellosen Netzwerkverkehrs von Solana wohl am stärksten belastet wurde. Zur Einordnung: Sobald ein Validator zum Leader wird, kann der eingehende Datenverkehr auf mehr als ein Gigabyte pro Sekunde steigen, da das gesamte Netzwerk Pakete an ihn sendet. Solch enorme eingehende Datenmengen zu verarbeiten, ist eine gewaltige technische Herausforderung.

Mehr Mempool, mehr Probleme

Die ursprüngliche Definition von Gulf Stream durch das Gründungsteam betont, dass es keinen Mempool gibt. Ein Mempool – wörtlich „Speicherpool“ – ist eine Menge von Transaktionen, die Nutzer eingereicht haben und die auf ihre Verarbeitung durch das Netzwerk warten. Während sie öffentlich einsehbar warten, sind diese Transaktionen üblicherweise weder verschlüsselt noch abgeschirmt. Sie werden über ein Gossip-Protokoll im gesamten Netzwerk verteilt. Je nach Netzwerk können signierte Transaktionen möglicherweise unbegrenzt im Mempool verbleiben, bis die Bedingungen für ihre Ausführung erfüllt sind. Das gilt besonders für Transaktionen, deren Transaktionsgebühr – der Preis pro Recheneinheit – deutlich unter den üblichen Marktpreisen liegt. In Extremfällen kann ihre Ausführung Tage oder Wochen dauern, wenn die Netzwerkbedingungen ihre Aufnahme in einen Block nicht begünstigen.

Ein solches Szenario ist auf Solana nicht möglich. Solana kennt nicht nur nativ keinen Mempool, sondern verlangt auch, dass jede Transaktionsnachricht einen aktuellen Blockhash enthält. Entwickler können aktuelle Blockhashes einfach über einen JSON RPC API-Aufruf der Methode getLatestBlockhash anfordern. Dieser Blockhash wird in die Transaktionsnachricht eingebettet und ist bis zu 150 Slots lang gültig. Das entspricht ungefähr 1 Minute, da jeder Slot eine Zielzeit von 400 Millisekunden hat. Nach 150 Slots ist der Blockhash veraltet und das Netzwerk verwirft Transaktionen, die auf ihn verweisen. Standardmäßig versuchen RPCs, Transaktionen alle 2 Sekunden weiterzuleiten. Sobald der aktuelle Blockhash jedoch abläuft, wird die Transaktion verworfen und garantiert nie onchain ausgeführt.

Mit dem aktuellen Blockhash lassen sich außerdem doppelte Transaktionen erkennen und entfernen. Andere Netzwerke erreichen dies durch die vorgeschriebene Einbindung einer Nonce, also einer nur einmal verwendeten Zahl. Entwickler können Solana-Transaktionen in bestimmten Nischenszenarien zwar dauerhafte Nonces hinzufügen, doch eine standardmäßige Solana-Transaktion muss keine Nonce enthalten.

Solanas Gulf-Stream-System ist möglich, weil alle aktiven Nodes den Leader-Zeitplan stets im Voraus kennen. Nodes aktualisieren ihre Leader-Zeitpläne jedes Mal, wenn die Slot-Höhe die Grenze einer Epoche überschreitet, also ungefähr alle 2 Tage. Der Leader-Zeitplan für eine Epoche wird aus dem Ledger-Zustand zu Beginn der vorherigen Epoche berechnet. Der algorithmische Prozess dafür sieht wie folgt aus:

• Verwende regelmäßig die Tick-Höhe des Proof of History (PoH), also einen monoton steigenden Zähler, als Seed für einen stabilen pseudozufälligen Algorithmus.
• Ermittle auf dieser Höhe aus der Bank alle Accounts mit Stake und Leader-Identitäten, die innerhalb einer vom Cluster konfigurierten Anzahl von Ticks abgestimmt haben. Diese Stichprobe heißt aktive Menge.
• Sortiere die aktive Menge nach Stake-Gewicht.
• Wähle mithilfe eines zufälligen Seeds Nodes nach ihrem Stake-Gewicht aus, um eine Stake-gewichtete Reihenfolge zu erstellen.
• Diese Reihenfolge wird nach einer vom Cluster konfigurierten Anzahl von Ticks gültig.

Quelle: Offizielle Solana-Dokumentation

Die Gewichtung nach Stake sorgt dafür, dass vertrauenswürdige Nodes mit höherem Stake häufiger als Leader ausgewählt werden. Nodes mit geringerem Stake werden dagegen seltener oder gar nicht ausgewählt. 

‍Die Stake-gewichtete Zuweisung von Ressourcen ist ein wiederkehrendes Prinzip im gesamten Kernprotokoll von Solana. Dazu gehören Voting-Belohnungen, Turbine-Bäume, Leader-Zeitpläne und das Gossip-Netzwerk*. Selbst Gulf Stream nutzt eine Stake-Gewichtung, wie wir später in diesem Artikel erläutern.

Ein Hinweis zu QUIC

Das erste große Upgrade für Gulf Stream erfolgte Ende 2022  mit der Einführung des Netzwerkprotokolls QUIC, über das Transaktionsnachrichten an den Leader übertragen werden. Auslöser waren Netzwerkausfälle durch DDoS-Angriffe und Spam-Transaktionen, die die Chain während NFT-Mints überfluteten. Nachdem QUIC mit Version 1.13.4 vollständig in Mainnet-Beta integriert worden war, verbesserte sich die Stabilität des Netzwerks.

Zuvor hatte Solana das Netzwerkprotokoll UDP (User Datagram Protocol) verwendet, um Transaktionen von RPC-Nodes an den aktuellen Leader zu senden. UDP ist schnell und effizient, arbeitet aber verbindungslos und bietet weder Flusskontrolle noch Empfangsbestätigungen. Daher gibt es keine wirksame Möglichkeit, missbräuchliches Verhalten zu verhindern oder einzudämmen. Um den Netzwerkverkehr kontrollieren zu können, wurde das Protokoll des Validators für die Annahme von Transaktionen – also die Fetch Stage der TPU – mit QUIC neu implementiert.

QUIC wurde ursprünglich 2012 von Google entwickelt und soll die Vorteile von TCP und UDP verbinden. Es ermöglicht eine schnelle, asynchrone Kommunikation ähnlich wie UDP, bietet aber zugleich die sicheren Sitzungen und fortschrittlichen Strategien zur Flusskontrolle von TCP. Dadurch lassen sich einzelne Traffic-Quellen begrenzen, sodass sich das Netzwerk auf die Verarbeitung legitimer Transaktionen konzentrieren kann. QUIC unterstützt außerdem separate Streams. Wird eine Transaktion verworfen, blockiert sie daher nicht die übrigen. Google war die treibende Kraft hinter der Verbreitung von QUIC im Web2. Verbindungen zu Google-Servern werden mit QUIC aufgebaut. Daher basieren viele Apps unter dem Dach von Google auf QUIC, darunter Hangouts, Gmail und YouTube. Nebenbei bemerkt: QUIC ist kein Akronym, sondern der eigentliche Name des Protokolls. 

Allerdings lässt sich über die Wirksamkeit der QUIC-Implementierung auf Solana streiten. Bei starkem Netzwerkverkehr können Validatoren von QUIC-Handshakes überlastet werden. QUIC war keine Universallösung für Überlastungsprobleme auf Netzwerkebene, wie manche ursprünglich gehofft hatten. Außerhalb der Solana-Implementierung ist QUIC in der Blockchain-Branche bislang kaum verbreitet. Einige Mitglieder der Validator-Community von Solana kritisieren das Protokoll offen und halten die Einführung von QUIC für eine Fehlentscheidung.

Stake-Weighted Quality of Service (SWQoS)

Anfang 2024 wurde Stake-weighted Quality of Service (SWQoS) als Mechanismus gegen Spam und zur Erhöhung der Sybil-Resistenz eingeführt. Mit diesem System können Leader Transaktionsnachrichten priorisieren, die über Validatoren mit Stake geroutet werden. Validatoren mit höherem Stake erhalten proportional mehr Kapazität, um Pakete mit Transaktionsnachrichten an den Leader zu übertragen. Das schwächt Sybil-Angriffe von Nodes ohne oder mit geringem Stake im gesamten Netzwerk wirksam ab. Diese Segmentierung ist möglich, weil sich IP-Adressen über QUIC verifizieren lassen. Validatoren können dadurch den Datenverkehr bestimmter Verbindungen priorisieren und begrenzen. 

Mit SWQoS können Validatoren ihre Stake-gewichtete Kapazität an RPC-Nodes vermieten. Im Gegenzug erhalten RPC-Nodes mehr Bandbreite und erreichen damit höhere Aufnahmeraten für Transaktionen in Blöcken. 80 % der Kapazität eines Leaders (2.000 Verbindungen) sind für Stake-weighted QoS reserviert. Die verbleibenden 20 % (500 Verbindungen) stehen Transaktionsnachrichten von anderen Nodes zur Verfügung. Diese Zuweisungsstrategie ähnelt Vorrangspuren auf einer Autobahn, auf denen Fahrer eine Maut zahlen, um den Stau zu umgehen.

Derzeit sind mindestens 0,04 % des gesamten Stakes erforderlich, um als Peer mit Stake zu gelten. Zum Zeitpunkt der Veröffentlichung beträgt der gesamte Stake 384 Millionen SOL. Damit liegt die Mindestanforderung bei 15.360 SOL.‍

SWQoS hat das Solana-Ökosystem erheblich beeinflusst. Es hat die Anforderungen für die Weiterleitung von Transaktionen an den Leader erhöht und Spam-Angriffe weniger wirksam gemacht. Die Änderung motiviert Anwendungen mit hohem Datenverkehr dazu, ihren Betrieb vertikal zu integrieren. Indem Anwendungen eigene Validator-Nodes betreiben, sichern sie sich bevorzugten Zugang zum Leader und verbessern so ihre Fähigkeit, Transaktionen zu verarbeiten. Bei Helius sind wir stolz darauf, gemessen am Stake einen der führenden Validatoren im Netzwerk zu betreiben. So können wir eine höhere Aufnahme von Transaktionen gewährleisten. In unserem ausführlichen Staking-Leitfaden erfährst du hier mehr über das Staking mit uns.

Die Jito-Bremsschwelle

Dieser Artikel wäre unvollständig, wenn wir Jito nicht erwähnen würden. Zum Zeitpunkt der Veröffentlichung nutzen mehr als 80 % des Netzwerk-Stakes den Jito-Validator-Client. Dieser macht den üblichen Weg von Transaktionen zum Leader noch komplexer. Der Jito-Solana-Validator-Client (GitHub) ist ein Fork des Agave-Clients (GitHub), der ursprünglich der Client von Solana Labs war. Er führt eine Blockspace-Auktion außerhalb des Protokolls ein und ermöglicht Validatoren zusätzliche wirtschaftliche Anreize in Form von Trinkgeldern.

Eine umfassende Untersuchung des Jito-Clients würde den Rahmen dieses Artikels sprengen. Daher beschränken wir unsere Analyse darauf, wie der Jito-Client den Fluss normaler Transaktionen durch Gulf Stream beeinflusst. Transaktionen können zwei Wege nehmen: Sie fließen von einem RPC zu einem gekoppelten Validator und dann weiter zum aktuellen Leader – der Stake-gewichtete Weg. Oder sie werden direkt an den Leader weitergeleitet – der Weg über eine offene Verbindung. Führt der Leader in einem dieser Szenarien den Jito-Solana-Client aus, werden die Transaktionen zunächst an den Jito-Relayer (GitHub) gesendet. Diese Open-Source-Software dient als Proxy-Router für Transaktionen. 

Andere Netzwerk-Nodes kennen den Jito-Relayer nicht. Sie senden Transaktionen einfach an die Adresse und Portkonfiguration, die der Leader über das Gossip-Netzwerk als seinen ingress_socket veröffentlicht hat. Der Relayer verzögert Transaktionen um 200 Millisekunden, bevor er sie an den Leader weiterleitet. Diese „Bremsschwelle“ verlangsamt den Fluss eingehender Transaktionsnachrichten und ermöglicht effiziente Auktionen in diskreten Zeitintervallen. Nach 200 Millisekunden gibt der Relayer die Transaktionen unabhängig vom Auktionsergebnis optimistisch frei.

Jito betrieb zuvor einen kanonischen Mempool-Service außerhalb des Protokolls, der inzwischen eingestellt wurde. Wenn ein Jito-Solana-Validator der Leader ist, können Searcher weiterhin Gruppen atomar ausgeführter Transaktionen einreichen, sogenannte Bundles. Diese eignen sich für andere Arten von MEV-Transaktionen, die nicht vom Mempool abhängen, etwa Arbitrage-Transaktionen und Liquidationen.

Weitere Informationen findest du in unserem Helius-Blogartikel hier, der eine Einführung in Solana MEV bietet.

Fazit

In diesem Artikel haben wir verschiedene Aspekte von Solanas Gulf Stream untersucht, darunter das Netzwerkprotokoll QUIC, Stake-weighted QoS und die Jito-Validator-Konfiguration. Wir haben Gulf Stream mit der traditionelleren Mempool-Architektur verglichen und die Vorteile des Solana-Ansatzes aufgezeigt: höhere Effizienz und geringere Latenz. 

Gulf Stream wird sich zweifellos weiterentwickeln. Das Solana-Protokoll und sein breiteres Ökosystem machen schnelle Fortschritte. Bedeutende Upgrades sind bereits absehbar. Solana-Mitgründer Anatoly Yakovenko setzt sich beispielsweise nachdrücklich für mehrere gleichzeitig aktive Leader ein. Mehrere gleichzeitig aktive Leader würden mehreren Nodes weltweit ermöglichen, Nutzertransaktionen gleichzeitig zu sequenzieren. Das würde die Latenz verringern und im ungünstigsten Fall einen vollständigen globalen Roundtrip überflüssig machen, bevor eine Transaktion zur Blockchain hinzugefügt wird.

Solana bleibt nicht stehen. Das gesamte Protokoll einschließlich Gulf Stream hat eine spannende Zukunft vor sich. Entwickler sollten daher mit vielen weiteren Updates und Optimierungen rechnen.

Wenn du bis hierhin gelesen hast: Vielen Dank! Tritt unserer Community auf Discord bei, folge uns auf X oder abonniere unten unsere Mailingliste.‍

Vielen Dank an Jacob Creech und 0xIchigo für die Prüfung früherer Versionen dieses Artikels.‍

Weitere Ressourcen

• Gulf Stream: Solanas Protokoll zur Weiterleitung von Transaktionen ohne Mempool
• QUIC, ein multiplexierter Transport über UDP
• Ein umfassender Leitfaden zu HTTP/3 und QUIC
• Sammlung von Links zu SWQoS
• Ein Leitfaden zu Stake-weighted Quality of Service auf Solana
• Schulungsmaterial für Solana-Validatoren – Stake Weighted QoS
• Dokumentation zum Jito Relayer
• Asynchrone Ausführung, Endgame-Architektur

‍