Das Millisekundenrennen gewinnen: Shreds, LaserStream und der Vorsprung auf Solana

Was sind Shreds?

Shreds sind die grundlegende Einheit für die hochleistungsfähige Datenweiterleitung auf Solana und ermöglichen frühen Zugriff auf On-Chain-Statusänderungen.

Solana ist auf maximale Geschwindigkeit und maximalen Durchsatz ausgelegt. Deshalb kann das Netzwerk Blöcke nicht als eine einzige große Einheit übertragen. Stattdessen werden Blöcke in kleinere Pakete aufgeteilt, die als Shreds bezeichnet werden – die atomaren Einheiten der Datenweiterleitung auf Solana. 

Diese Shreds enthalten Teile der Transaktionsdaten, bevor sie zu einem Block zusammengesetzt werden. Jeder Shred ist ungefähr 1,2 KB groß und so optimiert, dass er in die Maximum Transmission Unit (MTU) standardmäßiger Netzwerkpakete passt. Das ermöglicht eine blitzschnelle Übertragung ohne Fragmentierung. 

Es gibt zwei Arten von Shreds:

Data Shreds

Data Shreds enthalten die zentralen Transaktionsdaten eines Blocks, aufgeteilt in Bestandteile mit fester Größe. Dazu gehören serialisierte Entry-Batches, also Gruppen von Transaktionen, denen zur effizienten Verarbeitung eine Anzahl vorangestellt ist.

Coding Shreds

Coding Shreds schaffen Redundanz durch Reed-Solomon-Erasure-Coding. Diese Vorwärtsfehlerkorrektur erzeugt Paritätsdaten, mit denen sich fehlende oder beschädigte Shreds rekonstruieren lassen. Coding Shreds werden zusammen mit Data Shreds in Forward Error Correction (FEC) Sets organisiert. Üblicherweise ist das Verhältnis ausgeglichen, etwa 32 Data Shreds zu 32 Coding Shreds, sodass bis zu 50 % Paketverlust toleriert werden können. Leader können dieses Verhältnis an die Netzwerkbedingungen anpassen, um eine hohe Zuverlässigkeit zu gewährleisten.

Wie werden Shreds auf Solana weitergeleitet?

Der Prozess beginnt damit, dass der Leader, also der aktuell für die Blockproduktion zuständige Validator, Transaktionen in Entries bündelt und serialisiert. Diese Entries werden dann in kleinere Segmente unterteilt oder geschreddert, die als Shreds bezeichnet werden. Der Leader signiert alle Shreds entweder mit einem Legacy-System, bei dem jeder Shred einzeln signiert wird, oder mit einem Merkle-basierten Verfahren, bei dem die Merkle-Root des gesamten FEC Sets signiert wird. Das ist in der Shred-Spezifikation von Solana definiert und gewährleistet Authentizität und Datenintegrität. 

Shreds werden mit Turbine an andere Validatoren gesendet, dem mehrschichtigen, Fanout-basierten Weiterleitungssystem von Solana. Bei Turbine überträgt der Leader Shreds an eine Root-Node, die sie in einer baumartigen Struktur an nachfolgende Schichten von Validatoren verteilt. Jede Schicht leitet sie mit einem Fanout von 200 Nodes pro Schicht an die nächste weiter. Je nach Anzahl aktiver Validatoren sind typischerweise 2 bis 3 Hops nötig. Diese Baumstruktur minimiert die Bandbreite und verteilt Transaktionen dennoch innerhalb von Millisekunden im gesamten Netzwerk.

Stake-gewichtetes Mischen priorisiert die Übertragung an Validatoren mit höherem Stake. Turbine sortiert Validatoren zunächst nach ihrem gehaltenen Stake, also ihrem Stake-Gewicht. Validatoren mit höherem Stake stehen weiter vorne in dieser Liste und landen nach einem deterministischen Mischen tendenziell in früheren Schichten des Baums, näher am Leader. Weniger Hops bedeuten daher eine geringere Latenz. Validatoren mit mehr Stake erhalten Shreds also früher.   

Hinweis: Turbine wird künftig durch Rotor ersetzt, sobald Alpenglow implementiert ist. Auch nach diesen Änderungen beeinflusst der Stake eines Validators weiterhin, an welche Peers Validatoren Daten übertragen.

Wie werden Shreds wieder zu Blöcken zusammengesetzt?

Sobald ein Validator Shreds empfängt, prüft er zunächst ihre Signaturen auf Authentizität. Anschließend rekonstruiert er mit Reed-Solomon-Erasure-Coding fehlende oder beschädigte Data Shreds aus den verfügbaren Coding Shreds im FEC Set. 

Die rekonstruierten Data Shreds werden danach wieder zusammengeführt. Ihre Payloads werden anhand der Shred-Indizes in der richtigen Reihenfolge verkettet, um die serialisierten Entry-Batches wiederherzustellen. 

Diese Batches werden anschließend in einzelne Transaktionen und Entries deserialisiert, die sich zu einem vollständigen Block zusammensetzen lassen.

Warum sind Shreds wichtig? 

Shreds sind wichtig, weil sie das Reaktionsfenster in einem Netzwerk verkürzen, in dem Timing entscheidend ist. 

Shreds sind entscheidend, um die Performance-Vorteile von Solana auszuschöpfen – besonders bei latenzkritischen Anwendungen wie Hochfrequenzhandel, Request-for-Quote-Desks (RFQ), Liquidations-Engines und Oracle-Aktualisierungen. 

Shreds bieten den frühesten Einblick in entstehende On-Chain-Ereignisse. Bei den meisten anderen Blockchains müssen Anwendungen dagegen warten, bis ein vollständiger Block produziert und bestätigt wurde. Das kann Verzögerungen von Hunderten Millisekunden bis zu mehreren Sekunden verursachen. 

Die Arbeit mit Raw Shreds kann umständlich sein. Der Empfänger muss ihre Authentizität prüfen, fehlende Data Shreds rekonstruieren, sie wieder zusammenführen und in Transaktionen und Entries deserialisieren. Abschließend muss er sie nach verwertbaren Ereignissen wie Swaps oder Account-Änderungen durchsuchen.

Wenn du den Latenzvorteil von Shreds nutzen möchtest, ohne diese Pipeline selbst zu entwickeln, führt Preprocessed Transactions die Shreds für dich zusammen und streamt die signierten Transaktionen über WebSocket bis zu 8 ms vor dem Commitment-Level processed.

Dieser „frühe Einblick“ in ausstehende Transaktionen und Account-Aktualisierungen bietet jedoch einen beispiellosen Vorteil und führt in Wettbewerbssituationen direkt zu höheren Erfolgsquoten.

Ein Liquidations-Bot, der Besicherungsquoten überwacht, könnte mit Shreds beispielsweise eine gefährdete Position deutlich vor Konkurrenten erkennen, die langsamere Methoden wie WebSockets nutzen. So gewinnt er die Liquidation. 

Auch Arbitrage-Händler, die Marktineffizienzen erkennen, und latenzarme DEX-Aggregatoren, die Preise stellen, profitieren von diesem Latenzvorteil, da Millisekunden über die Profitabilität entscheiden.

Die Hierarchie der Shred-Latenz

Wichtig ist, dass die Shred-Latenz nicht bei allen Quellen gleich ist.

Validatoren mit hohem Stake

Validatoren mit einem hohen Stake haben im Weiterleitungsbaum von Turbine höchste Priorität. Sie empfangen Shreds oft direkt vom Leader oder in früheren Fanout-Schichten und profitieren von Stake-Weighted Quality of Service (SWQoS).

Validatoren mit Stake

Validatoren mit einem moderaten Stake erleben aufgrund ihrer niedrigeren Priorität in der Weiterleitungswarteschlange mäßige Verzögerungen, da Shreds zusätzliche Hops durchlaufen müssen. Ihre Beteiligung am Konsens gewährleistet zuverlässigen Zugriff, allerdings kann die Latenz je nach Netzwerkposition und aktueller Stake-Verteilung leicht variieren. Verglichen mit Validatoren mit hohem Stake sind Validatoren mit niedrigem Stake für extrem wettbewerbsintensive, zeitkritische Vorgänge weniger geeignet.

Validatoren ohne Stake

Validatoren ohne Stake profitieren nicht von den Servicequalitätsvorteilen gestakter Nodes. Für das Streaming von Solana-Echtzeitdaten bei latenzkritischen Vorgängen sind sie ungeeignet. Im Fanout von Turbine erhalten sie Shreds zuletzt.

Je früher du dich im Baum befindest, desto mehr Zeit hast du zu reagieren, bevor der Rest des Netzwerks aufholt. 

Globale Schwankungen 

Wichtig ist: Turbine ist standortunabhängig. Die globale Weiterleitung kann die Latenzschwankungen verstärken, da physische Entfernung und Netzwerkbedingungen zusätzlich zu den Hops von Turbine Verzögerungen verursachen. 

Shreds, die beispielsweise zwischen Regionen übertragen werden, etwa von einem Leader in den USA an Validatoren im asiatisch-pazifischen Raum, können sich durch interkontinentales Routing, erneute Paketübertragungen oder sogar Peering-Probleme verzögern. Das gilt selbst für Validatoren mit hohem Stake in den frühen Schichten von Turbine.

Diese geografische Verteilung eröffnet Optimierungsmöglichkeiten. Ein einzelner Validator mit hohem Stake kann lokal hervorragend abschneiden, global aber zurückfallen, wenn er nicht optimal positioniert ist. Ein verteiltes Shred-Netzwerk könnte dieses Problem mindern, indem es die schnellstmöglichen Shreds aus verschiedenen Quellen aggregiert. Das würde die Schwankungen reduzieren und gleichbleibende Empfangsgeschwindigkeiten ermöglichen. Ein solches System könnte einen Validator mit Top-Stake in globalen Szenarien konstant übertreffen.

Für Entwickler latenzkritischer Systeme ist der zuverlässige Zugriff auf Shreds aus optimierten Quellen unerlässlich, um wettbewerbsfähig zu bleiben. Dafür ist jedoch eine robuste Infrastruktur nötig, die Wiederherstellung, Verifizierung und globale Verteilung effektiv bewältigt. Außerdem nutzen die meisten beliebten Tools für Echtzeit-Datenstreaming auf Solana derzeit keine Shreds.

Datenstreaming auf Solana

Entwickler, die Echtzeitdaten auf Solana streamen möchten, haben mehrere Optionen. Jede bringt eigene Kompromisse bei Latenz, Zuverlässigkeit und Komplexität mit sich:

Webhooks

Webhooks ermöglichen ereignisgesteuerte Aktualisierungen und senden Daten an deine Anwendung, sobald sich ein bestimmter Account oder ein bestimmtes Programm ändert. Sie lassen sich einfach programmatisch integrieren und sogar ohne Code direkt im Helius Dashboard einrichten. Entwickler können menschenlesbare, geparste Daten für bestimmte Transaktionstypen und Raw-Transaktions-Payloads streamen. Sie können diese Aktualisierungen sogar direkt als formatierte Nachricht an einen bestimmten Discord-Kanal senden.

Webhooks sind äußerst zuverlässig und werden von vielen bekannten Unternehmen auf Solana eingesetzt. Sie senden Benachrichtigungen jedoch erst, nachdem eine Transaktion bestätigt wurde. Dadurch können Webhooks den Daten auf Shred-Ebene um Hunderte Millisekunden hinterherhinken. Für latenzkritische Vorgänge wie Hochfrequenzhandel oder Liquidationen sind sie deshalb zu langsam.

Standard-WebSockets

Die JSON RPC API von Solana unterstützt WebSocket-Abonnements wie accountSubscribe für Account-Änderungen, logSubscribe für Transaktionsprotokolle und programSubscribe für Programmereignisse. WebSockets halten eine dauerhafte Verbindung zwischen einem Client und einem RPC-Anbieter aufrecht und streamen Aktualisierungen, sobald Transaktionen und Account-Änderungen verarbeitet wurden. WebSockets sind bidirektional und eignen sich zur Echtzeitüberwachung bestimmter Accounts oder Ereignisse, während sie den Aufwand durch Polling reduzieren.

Wie Webhooks liefern WebSockets Daten jedoch erst nach dem Zusammensetzen der Shreds, also auf den Commitment-Levels processed, confirmed oder finalized. Je nach Commitment-Level verursacht das eine zusätzliche Latenz von 400 ms bis 30 s. 

WebSockets gelten außerdem als instabiler Verbindungstyp. Verbindungen können aus vielen Gründen abbrechen und erfordern eine eigene Wiederholungslogik. Ohne ergänzendes Polling können Verbindungsabbrüche zu dauerhaftem Datenverlust führen, was die Zuverlässigkeit in Echtzeit beeinträchtigt. 

Enhanced WebSockets

Enhanced WebSockets verbessern Standard-WebSockets deutlich und bieten mehrere Performance-Optimierungen sowie erweiterte Filterfunktionen. Insbesondere besseres Event-Parsing und weniger Rauschen machen sie entwicklerfreundlicher für den Produktionseinsatz.

Enhanced WebSockets können die Latenz gegenüber Standard-WebSockets reduzieren und eignen sich hervorragend für allgemeine Streaming-Anwendungen. Beim Streaming von Pump-AMM-Daten mit Enhanced WebSockets zeigt sich beispielsweise ein deutlicher Performance-Unterschied gegenüber Standard-WebSockets und Webhooks. 

Grundsätzlich liefern Enhanced WebSockets Daten jedoch weiterhin erst nach dem Zusammensetzen der Shreds. Das begrenzt erneut ihren Nutzen für Anwendungen, bei denen jede Millisekunde zählt. Außerdem bieten sie trotz ihrer Erweiterungen keine automatische Wiedergabe und kein Failover. Lücken musst du daher manuell behandeln. 

Yellowstone gRPC

Yellowstone gRPC ist ein Streaming-Protokoll mit niedriger Latenz zwischen Validator und Client, das Zugriff auf Daten auf Shred-Ebene bieten kann. Dadurch ist es deutlich schneller als WebSockets und Webhooks, weil es Aktualisierungen für das jeweilige Commitment-Level schneller liefern kann. 

Yellowstone bietet bidirektionales Streaming mit sofortigem Erstellen und Beenden von Abonnements sowie erweiterte Filterfunktionen. Damit kannst du genau steuern, welche Daten du bei bestimmten Transaktions-, Account- oder Programmaktualisierungen erhältst.

Yellowstone eignet sich ideal für Nutzer, die keine Ratenlimits, keine Credits und garantiert isolierte Hardware für benutzerdefinierte Node-Konfigurationen wünschen. Es gibt jedoch mehrere erhebliche Nachteile:

1. Infrastrukturaufwand

Du benötigst deine eigene dedizierte Node, um das Potenzial von Yellowstone gRPC voll auszuschöpfen. Dafür brauchst du Zugriff auf Hardware, die richtige Konfiguration, eine kontinuierliche Verwaltung dieser Hardware und spezialisiertes Wissen, um hardwarebezogene Probleme zu beheben.

2. Latenzschwankungen

Nur weil Yellowstone gRPC Daten auf Shred-Ebene liefern kann, geschieht das nicht automatisch auf optimale Weise. Die Latenz hängt von deinem Anbieter ab und davon, ob deine dedizierte Node mit Shred-optimierten Quellen gekoppelt ist, also mit Validatoren mit hohem Stake. Bei einer Kopplung mit Validatoren mit normalem bis niedrigem Stake landen diese nicht konstant in der ersten Turbine-Schicht. Bei vielen Shreds bleibst du daher weiter hinten in der Übertragungskette.

3. Ausfallrisiken

Wenn du dich auf eine einzige dedizierte Node verlässt, entsteht ein Single Point of Failure. Das Problem verschärft sich dadurch, dass Yellowstone gRPC keine nativen Wiedergabefunktionen bietet.

4. Ressourcenbedarf

Wenn du eine dedizierte Node während des Datenstreamings über Yellowstone mit intensiven RPC-Aufrufen überlastest, kann sich ihre Performance verschlechtern. 

Für viele Teams war Yellowstone gRPC lange der bevorzugte Streaming-Service für Echtzeitdaten auf Solana. Er ist schnell und eignet sich für fortgeschrittene Nutzer. Ohne eine Flotte dedizierter Nodes auf der ganzen Welt lässt sich eine konsistente, globale Abdeckung mit niedriger Latenz jedoch nur schwer betreiben.

LaserStream

LaserStream verbindet die Geschwindigkeit der Datenerfassung auf Shred-Ebene mit der Zuverlässigkeit und Reichweite eines global verteilten Service – ohne die Kosten und den Betriebsaufwand mehrerer dedizierter Nodes. 

LaserStream erreicht das durch:

• Erfassung aus mehreren Quellen: LaserStream erfasst die Shreds mit der niedrigsten Latenz und ist der Konkurrenz weltweit konstant voraus.
• Globale Abdeckung: LaserStream ist in mehreren Regionen weltweit verfügbar. Entwickler können so den Endpunkt verwenden, der ihrer Infrastruktur am nächsten liegt. Für Redundanz betreibt jede Region mehrere Server mit automatischem Failover.
• Keine Lücken: Mit der historischen Wiedergabe von LaserStream können Entwickler aktuelle Blockchain-Daten aus einem Zeitraum von bis zu 48 Stunden in der Vergangenheit erneut abrufen. Das hilft bei Verbindungsabbrüchen und gewährleistet Datenkontinuität. 
• Entwicklerfreundliche Nutzung: LaserStream ist ein direkter Ersatz für Yellowstone gRPC – keine Migrationen, keine neue Syntax, keine Kopfschmerzen.

Kurz gesagt ist LaserStream eine skalierbare, latenzarme und fehlertolerante Verbesserung gegenüber Yellowstone gRPC und WebSockets. Der Service stellt On-Chain-Ereignisse konstant bereit, sobald sie im Netzwerk auftreten. Du brauchst dafür weder Stake in Millionenhöhe noch musst du selbst Hochleistungsinfrastruktur betreiben. 

LaserStream ist der einfachste Weg, die Leistung von Shreds für Datenstreaming mit extrem niedriger Latenz auf Solana zu nutzen.

Clients und Performance

LaserStream bietet Clients für Go, Rust und JavaScript/TypeScript. Diese Clients übernehmen bei Verbindungsabbrüchen die automatische Wiedergabe, indem sie kontinuierlich nachverfolgen, welcher Slot gestreamt wurde. Wird die Verbindung aus irgendeinem Grund unterbrochen, stellt der Client sie automatisch wieder her und setzt das Streaming beim zuletzt verarbeiteten Slot fort.

Der JavaScript-Client von LaserStream ist besonders interessant, weil er native Rust-Bindings verwendet. Dadurch erreicht der Client einen Durchsatz von 1,3 GB/s. Das ist eine 40-fache Verbesserung gegenüber dem aktuellen JavaScript-Client von Yellowstone gRPC, der maximal 30 MB/s erreicht. 

Mit der weiteren Skalierung von Solana wird der JavaScript-Client von Yellowstone gRPC kaum Schritt halten können. Die Performance-Reserven des JavaScript-Clients von LaserStream sorgen dafür, dass deine Anwendung bei steigender Nachfrage sicher mit dem Netzwerk skalieren kann. 

Erfolge in der Praxis

DFlow, ein DEX-Aggregator mit niedriger Latenz, hat LaserStream kürzlich integriert, um seine Preis-Engine mit Daten zu versorgen. Ausschlaggebend waren die globale Skalierbarkeit ohne Sorgen um dedizierte Nodes und die eingesparte Entwicklungskapazität, die das Team stattdessen für Routing und Geschäftslogik einsetzen kann. 

Seit der Integration hat DFlow Berichten zufolge mehr als acht Stunden wiederkehrenden Entwicklungsaufwand eingespart, 100 % Verfügbarkeit mit unterbrechungsfreiem Datenstreaming aufrechterhalten und die Geschwindigkeit der Preisstellung durch schnellere Transaktionsbestätigungen verbessert. 

Schnelleres Streaming – schon heute.

Millisekunden sind nicht nur Latenz – sie sind Chancen. Mit LaserStream hältst du nicht nur mit dem Netzwerk Schritt. Du bleibst ihm voraus. 

Du brauchst Daten in unter einer Sekunde für Trading, Liquidationen oder Oracles? Nutze LaserStream und greife auf die schnellsten verfügbaren Solana-Daten zu. 

Wenn du als Power-User an der Übertragung von Raw Shreds interessiert bist, kannst du alternativ über das folgende Formular Kontakt mit uns aufnehmen.

Weitere Ressourcen

• LaserStream
• Shred-Modul von Agave
• Shred-Spezifikation von Solana