Turbine: Block-Weiterleitung auf Solana

Worum geht es in diesem Artikel?

Datenverfügbarkeit ist für Blockchains entscheidend. Sie stellt sicher, dass Nodes jederzeit auf alle Informationen zugreifen können, die sie zur Validierung benötigen. So bleiben Integrität und Sicherheit des Netzwerks gewahrt. Eine hohe Datenverfügbarkeit bei gleichzeitig hoher Leistung zu gewährleisten, ist jedoch eine große Herausforderung – insbesondere, wenn Netzwerke skalieren.

Solana begegnet dieser Herausforderung mit einer einzigartigen Architektur, die eine kontinuierliche Erstellung und Weiterleitung von Blöcken ermöglicht. Möglich machen dies mehrere zentrale Innovationen wie die Auswahl des Leaders, Gulf Stream (macht einen Mempool überflüssig) und Turbine (Mechanismus zur Block-Weiterleitung).

Da Solana kontinuierlich arbeitet, ist ein effizientes System erforderlich, damit alle Validatoren zeitnah den neuesten Zustand erhalten. Bei einem einfachen Ansatz würde der Leader alle Blöcke direkt an jeden anderen Validator übertragen. Angesichts des hohen Durchsatzes von Solana würde diese Methode jedoch den Bandbreitenbedarf und andere Ressourcenanforderungen erheblich erhöhen und gleichzeitig die Dezentralisierung schwächen.

Bandbreite ist eine knappe Ressource. Turbine ist Solanas ausgeklügelte Lösung, um Informationen vom Leader eines bestimmten Blocks an den Rest des Netzwerks zu verteilen. Turbine wurde speziell entwickelt, um die Belastung durch ausgehenden Datenverkehr (das Versenden von Daten) vom Leader an das Netzwerk zu reduzieren.

In diesem Artikel sehen wir uns an, wie Turbine funktioniert und welche zentrale Rolle es bei der Einbindung von Transaktionen auf Solana spielt. Außerdem vergleichen wir Turbine mit anderen Lösungen für Datenverfügbarkeit und erörtern offene Forschungsfragen in diesem Bereich.

Was ist Turbine?

Turbine ist ein mehrschichtiger Mechanismus zur Block-Weiterleitung. Ein Solana-Cluster nutzt ihn, um Ledger-Einträge an alle Nodes zu übertragen. Die grundlegenden Ideen hinter Turbine beschäftigen die Forschung bereits seit vielen Jahren. Das zeigen diese 2004 veröffentlichte Arbeit und neuere Forschung.

Anders als traditionelle Blockchains, bei denen ein Block sequenziell oder per Flooding an alle Nodes gesendet wird, verfolgt Turbine einen strukturierteren Ansatz. Dadurch minimiert es den Kommunikationsaufwand und reduziert die Last einzelner Nodes. Vereinfacht gesagt zerlegt Turbine einen Block in kleinere Teile und verteilt sie über eine Hierarchie von Nodes. Eine einzelne Node muss dabei nicht mit jeder anderen Node verbunden sein, sondern nur mit einigen ausgewählten Nodes kommunizieren. Das wird mit wachsender Netzwerkgröße immer wichtiger, da herkömmliche Verteilungsmethoden wegen des enormen Kommunikationsvolumens nicht mehr praktikabel wären. Turbine sorgt daher für eine schnelle und effiziente Datenverteilung auf Solana. Wie schnell Blöcke weitergeleitet und verifiziert werden, ist entscheidend für Solanas hohen Durchsatz und die Netzwerksicherheit.

Darüber hinaus löst Turbine das Problem der Datenverfügbarkeit. Es stellt sicher, dass alle Nodes effizient auf die Daten zugreifen können, die sie zur Validierung von Transaktionen benötigen. Dafür ist keine enorme Bandbreite erforderlich, die in anderen Blockchain-Netzwerken häufig einen Engpass darstellt.

Turbine trägt wesentlich dazu bei, dass Solana große Transaktionsvolumen bewältigen und eine schlanke, effiziente Netzwerkstruktur aufrechterhalten kann. Dafür verringert es Bandbreitenengpässe und sorgt für eine schnelle Block-Weiterleitung. Dieses innovative Protokoll ist einer der Grundpfeiler, mit denen Solana sein Versprechen als schnelles, sicheres und skalierbares Netzwerk erfüllt.

Sehen wir uns nun genauer an, wie Turbine funktioniert und Blöcke im Solana-Netzwerk weiterleitet.

Wie leitet Turbine Blöcke weiter?

Bevor ein Block weitergeleitet, also an andere Validatoren im Netzwerk übertragen wird, erstellt und ordnet der Leader ihn anhand des eingehenden Transaktionsstroms. Sobald der Block erstellt ist, kann Turbine ihn an den Rest des Netzwerks senden. Dieser Prozess wird als Block-Weiterleitung bezeichnet. Anschließend tauschen Validatoren Abstimmungsnachrichten aus. Diese Nachrichten werden in die Blockdaten eingebettet, um den Commitment-Status „confirmed“ oder „finalized“ zu erreichen. Ein bestätigter Block hat eine qualifizierte Mehrheit der Ledger-Stimmen erhalten. Ein finalisierter Block wurde zusätzlich bestätigt und von mindestens 31 bestätigten Blöcken überbaut. Der Unterschied zwischen den Commitment-Status wird hier genauer erklärt. Diesen Teil des Konsensmechanismus behandeln wir in einem zukünftigen Beitrag.

Leader erstellen und schlagen vollständige Blöcke vor. Die eigentlichen Daten werden jedoch als Shreds (Teilblöcke) an andere Validatoren im Netzwerk gesendet. Shreds sind die atomaren Einheiten, die Validatoren untereinander austauschen.

Vereinfacht gesagt sendet Turbine Shreds an eine vorab festgelegte Gruppe von Validatoren. Diese leiten die Shreds anschließend an eine neue Gruppe von Validatoren weiter. Das folgende Diagramm zeigt den kontinuierlichen Prozess der Shred-Weiterleitung:

In diesem Beispiel ist Validator 1 der festgelegte Slot-Leader. Während seines Slots – Validatoren werden für vier aufeinanderfolgende Slots als Leader bestimmt – erstellt Validator 1 einen Block und schlägt ihn vor. Zunächst zerlegt Validator 1 den Block durch einen als Shredding bezeichneten Prozess in Unterblöcke, die sogenannten Shreds. Beim Shredding werden die Blockdaten in Daten-Shreds von der Größe einer Maximum Transmission Unit (MTU) aufgeteilt. Das ist die maximale Datenmenge, die eine Node an die nächste senden kann, ohne sie in kleinere Einheiten zu fragmentieren. Zusätzlich werden mithilfe der Reed-Solomon-Erasure-Codierung entsprechende Recovery-Shreds erzeugt. Dieses Verfahren unterstützt die Datenwiederherstellung und gewährleistet die Datenintegrität während der Übertragung. Beides ist entscheidend für die Sicherheit und Zuverlässigkeit des Netzwerks.

Dieser Shredding- und Weiterleitungsprozess verteilt Blockdaten schnell und effizient auf Solana und erhält dabei den hohen Durchsatz und die Netzwerksicherheit.

Erasure Coding

Bevor Shreds durch den Turbine Tree weitergeleitet werden, codiert sie das System mithilfe der Reed-Solomon-Erasure-Codierung, einem polynombasierten Verfahren zur Fehlererkennung und -korrektur. Erasure Coding dient dem Schutz von Daten. Die ursprünglichen Daten lassen sich dadurch auch dann wiederherstellen, wenn Teile während der Übertragung verloren gehen oder beschädigt werden. Die Reed-Solomon-Erasure-Codierung ist eine spezielle Form eines Forward-Error-Correction-Algorithmus (FEC).

Turbine basiert grundlegend auf einer Reihe von Paketweiterleitungen durch nachgelagerte Validatoren. Diese Validatoren könnten bösartig sein (gegnerische byzantinische Nodes) und absichtlich falsche Daten weiterleiten. Sie könnten aber auch unvollständige Daten empfangen, etwa durch Paketverluste im Netzwerk. Aufgrund der Baumstruktur für Weiterleitungen bei Turbine summieren sich netzwerkweite Paketverluste. Mit jedem Hop steigt die Wahrscheinlichkeit, dass ein Paket sein Ziel nicht erreicht.

Vereinfacht gesagt kann das Netzwerk beliebige 33 % der Pakete verlieren, ohne den Block zu verlieren, wenn der Leader 33 % der Blockpakete als Erasure Codes überträgt. Leader können diesen Wert, die FEC-Rate, anhand der Netzwerkbedingungen dynamisch anpassen. Dabei berücksichtigen sie Variablen wie die zuletzt beobachteten netzwerkweiten Paketverluste und die Tiefe des Baums.

Betrachten wir zur Vereinfachung eine Shred-Gruppe mit einer FEC-Rate von 4:4.

Die Daten-Shreds sind Teilblöcke des ursprünglichen, vom Leader erstellten Blocks. Die Recovery-Shreds sind dagegen die mit Reed-Solomon erzeugten, Erasure-codierten Blöcke.

Blöcke auf Solana verwenden üblicherweise eine FEC-Rate von 32:32. Damit können 32 von 64 Paketen verloren gehen, ohne dass sie erneut übertragen werden müssen. Laut der Solana-Dokumentation gelten dabei die folgenden konservativen Netzwerkannahmen:

• Paketverlustrate von 15 %
• 50.000 TPS erzeugen 6.400 Shreds pro Sekunde

Eine FEC-Rate von 32:32 ergibt eine Erfolgsrate von ~99 % für Blöcke. Leader können die FEC-Rate zudem nach eigenem Ermessen erhöhen, um die Wahrscheinlichkeit einer erfolgreichen Blockübertragung zu steigern.

Turbine verwendet derzeit UDP zur Block-Weiterleitung und erreicht damit erhebliche Latenzvorteile. Laut einem Validator-Betreiber dauert die Übertragung von 6 MB plus Erasure-Coding-Daten von us-east-1 nach eu-north-1 mit UDP 100 ms, mit TCP dagegen 900 ms.

Turbine Tree

Ein Turbine Tree ist eine strukturierte Netzwerktopologie, mit der Solana Shreds, also codierte Blockdaten, effizient unter Validatoren verteilt. Sobald Shreds korrekt in ihre jeweiligen Shred-Gruppen codiert wurden, können sie über den Turbine Tree verteilt werden. Dadurch erhalten andere Validatoren im Netzwerk den neuesten Zustand.

Jede Shred-Gruppe wird in einem Netzwerkpaket an eine spezielle Root-Node gesendet. Diese bestimmt, welche Validatoren zur ersten Ebene gehören, also einen Hop entfernt sind. Anschließend werden die folgenden Schritte ausgeführt:

1. Listenerstellung: Die Root-Node fasst alle aktiven Validatoren in einer Liste zusammen und sortiert sie anschließend nach ihrem jeweiligen Stake im Netzwerk. Validatoren mit höherem Stake-Gewicht erhalten Shreds bevorzugt. Dadurch können sie schneller mit eigenen Abstimmungsnachrichten zum Konsens beitragen.
2. Mischen der Liste: Diese Liste wird anschließend deterministisch gemischt. So entsteht für jeden Shred ein „Turbine Tree“ aus den Validator-Nodes. Als Seed dienen Slot-Leader-ID, Slot, Shred-Index und Shred-Typ. Zur Laufzeit wird für jede Shred-Gruppe ein neuer Baum erzeugt. Das reduziert potenzielle Sicherheitsrisiken einer statischen Baumstruktur.
3. Bildung der Ebenen: Anschließend werden die Nodes von oben nach unten in Ebenen aufgeteilt. Die Aufteilung basiert auf dem Wert DATA_PLANE_FANOUT, der Breite und Tiefe des Turbine Tree bestimmt. Dieser Wert beeinflusst, wie schnell Shreds im Netzwerk weitergeleitet werden können. Der aktuelle Wert für DATA_PLANE_FANOUT beträgt 200. Daher sind die meisten Validatoren nur zwei bis drei Hops entfernt (Leader -> Root -> L1 -> L2).

Da der Turbine Tree allen bekannt ist, weiß jeder Validator genau, an welche Stelle er den jeweiligen Shred weiterleiten muss. Beim aktuellen Wert von 200 für DATA_PLANE_FANOUT hat der Turbine Tree üblicherweise zwei oder drei Hops, abhängig von der Anzahl aktiver Validatoren.

Nodes können außerdem auf Gossip und Reparatur zurückgreifen, wenn sie nicht genügend Shreds erhalten oder die Verlustrate die FEC-Rate überschreitet. In der aktuellen Implementierung sendet eine Node, der genügend Shreds zur Rekonstruktion des Blocks fehlen, eine Anfrage zur erneuten Übertragung an den Leader. Bei deterministischem Turbine kann jede Node, die den vollständigen Block erhalten hat, die benötigten Reparatur-Shreds an die anfragende Node senden. Dadurch wird die Datenübertragung weiter in jene Bereiche des Baums verlagert, die Daten anfordern.

Vergleich der Block-Weiterleitung bei Solana und Ethereum

Die Block-Weiterleitung funktioniert auf Solana anders als auf Ethereum. Hier sind einige grundlegende Unterschiede:

• Solanas ideale Bandbreitenanforderungen (>1 Gbit/s) sind deutlich höher als die von Ethereum (geth empfiehlt >25 Mbit/s). Dieser höhere Bandbreitenbedarf entsteht durch Solanas größere Blöcke und kürzere Blockzeiten. Solanas Architektur kann die gesamte Bandbreite effektiv nutzen, um die Datenübertragung zu beschleunigen und die Latenz zu reduzieren. Die Bandbreite erreicht zwar Spitzen von bis zu 1 Gbit/s, wird aber nicht dauerhaft in dieser Höhe genutzt. Solanas Architektur ermöglicht gezielt solche Bedarfsspitzen.
• Solana verwendet Turbine zur Weiterleitung von Blockdaten, während Ethereum ein standardmäßiges Gossip-Protokoll nutzt. Auf Ethereum werden Blockdaten unkompliziert weitergeleitet: Jede Node kommuniziert mit jeder anderen Full Node im Netzwerk. Sobald ein neuer Block vorliegt, verifizieren ihn die Clients, indem sie ihn an ihre Peers senden und die darin enthaltenen Transaktionen bestätigen. Dieser Mechanismus eignet sich für Ethereum, weil die Blöcke kleiner und die Blockzeiten länger als bei Solana sind. Auch Ethereum-L2-Rollup-Daten folgen dem Gossip-Protokoll, ausgenommen Validiums. Die Blockdaten werden dabei im Feld „calldata“ von Ethereum-L1-Blöcken gespeichert.
• Ethereum verwendet TCP über das DevP2P-Protokoll zur Block-Weiterleitung, Solana dagegen UDP (wobei Teile der Community einen Wechsel zu QUIC unterstützen). Zwischen UDP und QUIC sind einige Kompromisse zu beachten:
• Da UDP unidirektional arbeitet, erzielt es eine geringere Latenz als QUIC, das QUIC-Streams voraussetzt. Derzeit wird darüber diskutiert, unidirektionale Streams in QUIC zu implementieren.
• Befürworter von QUIC argumentieren, dass sich zwar ein eigener Kontrollfluss über UDP umsetzen lässt, dies jedoch erheblichen Entwicklungsaufwand erfordert. QUIC reduziert diesen Aufwand, weil es solche Funktionen nativ unterstützt. Das Endziel ist dasselbe, doch die aktuelle Obergrenze für die Leistung von QUIC bei Latenz, Durchsatz und weiteren Faktoren entspricht dem aktuellen Stand von reinem UDP.

Diese Unterschiede verdeutlichen die besonderen Architekturentscheidungen von Solana und Ethereum. Sie prägen jeweils Leistung, Skalierbarkeit und Robustheit des Netzwerks. Eine ausführlichere Analyse von TCP, UDP und QUIC findest du in unserem Artikel über Solana und QUIC.

Zukünftige Forschungsfragen

Block-Weiterleitung und Datenverfügbarkeit bleiben offene Forschungsfelder, in denen zahlreiche Teams eigene Ansätze entwickeln. Die Kennzahlen können sich zwar weiterentwickeln, dennoch möchten wir einen Überblick über die verschiedenen Ansätze und ihre jeweiligen Kompromisse geben:

• Einige Diskussionen befassen sich mit der Einordnung von Turbine als Mechanismus für „Datenverfügbarkeit“ (DA). Turbine dient insofern als Mechanismus für Datenverfügbarkeit, als die vollständigen Blockdaten veröffentlicht und von allen anderen Validatoren auf Solana heruntergeladen werden. Turbine unterstützt jedoch kein Data Availability Sampling (DAS). Diese Funktion hilft Light Nodes, den Zustand mit geringeren Hardwareanforderungen zu verifizieren. Teams wie Celestia entwickeln aktiv daran. Wie Turbine verwendet auch DAS Erasure Codes, allerdings ausdrücklich zur Erkennung und Verhinderung von Data-Withholding-Angriffen.
• Für L2s auf Basis der Solana Virtual Machine (SVM) wie Eclipse verliert Turbine an Bedeutung, da es keine Gruppe von Validatoren gibt, die Daten untereinander austauscht. Bei Eclipse werden Blockdaten zur Gewährleistung der Datenverfügbarkeit auf Celestia veröffentlicht. Dadurch können externe Beobachter Fraud Proofs ausführen, um die korrekte Ausführung und korrekte Zustandsübergänge sicherzustellen. Eclipse wird eine der ersten Implementierungen der SVM außerhalb des Solana-Netzwerks selbst sein. Pyth hat die SVM außerdem für sein eigenes Oracle-Netzwerk namens „Pythnet“ geforkt und betreibt damit effektiv eine eigene Sidechain.
• Auf Solana übernehmen Full Nodes die Block-Weiterleitung und sind gleichzeitig an anderen Teilen des integrierten Blockchain-Stacks beteiligt, etwa an der Transaktionsreihenfolge und am Konsens. Welche quantitativen Kennzahlen würde Turbine erreichen, wenn es als modulare Komponente auf spezialisierter Hardware betrieben würde?
• Turbine priorisiert Nodes mit höherem Stake-Gewicht, damit sie Blockdaten zuerst erhalten. Führt das mit der Zeit zu einer stärkeren Zentralisierung von MEV?
• Wie schneiden verschiedene Ansätze zur Datenverfügbarkeit wie EigenDA – ein horizontal skalierbarer einzelner Unicast-Relayer – und Celestia mit Data Availability Sampling im Produktivbetrieb gegenüber Turbine ab, wenn es um Rohdurchsatz und Vertrauensminimierung geht?
• Firedancer soll die Datenweiterleitung weiter steigern und ist für eine stabile Bandbreitenverbindung mit 10 Gbit/s optimiert. Wie bewähren sich die Optimierungen auf Systemebene rund um Turbine im Produktivbetrieb auf Hardware für Privatanwender und auf professioneller Hardware?
• Derzeit sind alle Nodes auf Solana Full Nodes. Implementierungen für Light Clients befinden sich noch in der Entwicklung. Sreeram Kannan von EigenLayer hat kürzlich eine Implementierung von DAS-S auf Turbine beschrieben. Wird es eine DAS-Version für Turbine geben? Lassen sich Light Clients mit DAS implementieren, die einen hohen Datendurchsatz bewahren und trotz wesentlich geringerer Ressourcenanforderungen die Vertrauensminimierung gewährleisten?

Fazit

Glückwunsch! In diesem Artikel haben wir Turbine und seine Funktionsweise im breiteren Kontext der Transaktionseinbindung auf Solana untersucht. Wir haben Turbine mit anderen Lösungen für Datenverfügbarkeit verglichen und verschiedene offene Forschungsfelder in diesem Bereich erörtert. Solanas Turbine-Protokoll zeigt, wie konsequent das Netzwerk hohen Durchsatz und geringe Latenz verfolgt. Dafür nutzt es eine strukturierte Netzwerktopologie, um Blockdaten effizient unter Validatoren zu verteilen.

Die Suche nach Möglichkeiten, die Datenverfügbarkeit zu verbessern und die Block-Weiterleitung effizienter zu gestalten, treibt Innovationen in der gesamten Blockchain-Community voran. Ein Vergleich der Mechanismen zur Block-Weiterleitung bei Solana und Ethereum verdeutlicht ihre jeweiligen Stärken und Kompromisse. Zugleich regt er eine vertiefte Diskussion darüber an, wie neue Blockchain-Lösungen wie EigenDA, Celestia und Firedancer dieses Ökosystem künftig prägen könnten.

Eine vollständige Lösung für effiziente Datenweiterleitung und Datenverfügbarkeit liegt noch in weiter Ferne. Solanas Ansatz und das konsequente Ziel, die Netzwerkleistung zu optimieren, ohne Sicherheit und Vertrauensminimierung zu beeinträchtigen, sind jedoch sehr willkommen.

Vielen Dank an @dubbel06 und @jon_charb für die Durchsicht und die Kommentare.

Zusätzliche Ressourcen und weiterführende Literatur

• Block-Weiterleitung mit Turbine
• Erasure Coding verstehen
• Ethereum-Blöcke
• Pyth-Perseus-Netzwerk-Upgrade
• Einführung in EigenDA: Hyperskalierbare Datenverfügbarkeit für Rollups
• Firedancer