ERPC veröffentlicht Solana Stream SDK v4.0.0 mit schnellerer UDP-Shreds-Verarbeitung und gRPC-Wiederverbindung

ERPC veröffentlicht Solana Stream SDK v4.0.0 mit schnellerer UDP-Shreds-Verarbeitung und gRPC-Wiederverbindung

ERPC veröffentlicht Solana Stream SDK v4.0.0 mit schnellerer UDP-Shreds-Verarbeitung und gRPC-Wiederverbindung
ELSOUL LABO B.V. und Validators DAO haben am 6. November 2026 Solana Stream SDK v4.0.0 offiziell veröffentlicht, ein Open-Source-SDK zur Verarbeitung von Solana-Streamingdaten. Lokale Benchmarks ergaben eine etwa 108-fach schnellere interne Verarbeitung von UDP-Shreds in Rust und einen etwa vierfachen Durchsatz der TypeScript-Event-Queue. Auch Geyser gRPC nimmt den Empfang von Aktualisierungen nach einem Verbindungsabbruch schneller wieder auf. Das SDK ist kostenlos nutzbar; Beispiele für Rust und TypeScript erleichtern Entwicklern den Einstieg.
Ob eine Anwendung von einer Datenübermittlung mit geringer Latenz profitiert, hängt auch davon ab, wie schnell sie eingehende Daten verarbeitet. Version 4.0.0 gestaltet die interne Verarbeitung nach dem Eintreffen der Daten effizienter und verbessert die Wiederherstellung der Verbindung nach Abbrüchen. Zusammen mit ERPC Shreds UDP Forwarding Premium können Entwickler sowohl den Übermittlungsweg als auch die Empfangsimplementierung ihrer Solana-Anwendungen verbessern.

Verbesserungen bei Verarbeitung und Wiederverbindung in drei Tests gemessen

Vergleich der internen Rust-UDP-Verarbeitung, der TypeScript-Event-Queue und der gRPC-Wiederverbindung in Solana Stream SDK v4.0.0
Im Rust-UDP-Empfangspfad beschleunigt v4 das Dekodieren von Datagrammen, das Einfügen in einen internen Puffer und das Deshredding, bei dem Daten aus Shreds rekonstruiert werden. Durch die Überarbeitung der Bereinigung interner Zustände und der Zeitabfragen, die zuvor für jedes Paket wiederholt wurden, sinkt der Verarbeitungsaufwand, während die Aufbewahrungsfristen der Daten erhalten bleiben. Im Vergleich sank die interne Verarbeitungszeit pro Datagramm von 94.236 ns auf 855–881 ns, was einer Beschleunigung um etwa den Faktor 108 entspricht.
Der Benchmark lief auf einem Mac mit einem Chip der Apple-M-Serie und verarbeitete pro Durchlauf 403.200 Datagramme aus 300 Slots. Verglichen werden die Medianwerte aus jeweils fünf Durchläufen. Die Messung umfasst den internen Pfad decode→insert→deshred. Sie schließt die Übermittlungszeit im Netzwerk und die anschließende Verarbeitung in der Anwendung des Nutzers aus. Ein geringerer Aufwand für die Rekonstruktion eingehender Shreds ermöglicht es Entwicklern, mehr Rechenressourcen für die Anwendungslogik einzusetzen.
Die TypeScript-Beispiele und Starter für Geyser gRPC verringern Wartezeiten, solange sich Ereignisse in der Queue befinden, sodass empfangene Daten effizienter abgerufen werden können. In einem reinen Queue-Test mit zwei Millionen Ereignissen unter Node.js 24 stieg der Durchsatz von 5,7–7,4 Millionen auf 24,8–29,4 Millionen Ereignisse pro Sekunde. Das entspricht einer Verbesserung um etwa den Faktor 4.
Für Geyser gRPC wurden der für die Wiederverbindung zuständige Client und das Intervall bis zum ersten erneuten Verbindungsversuch aktualisiert. In einem Test mit 20 absichtlich ausgelösten Verbindungsabbrüchen auf einem lokalen tonic-Server sank der Median der Zeitspanne zwischen den vor und nach dem jeweiligen Abbruch empfangenen Aktualisierungen von 552 ms mit dem 3.0-Runner auf 103 ms mit dem 4.0-Runner. Gemessen wird damit die Zeitspanne bis zur Wiederaufnahme der Aktualisierungen in der lokalen Testumgebung.
Diese drei Ergebnisse stammen aus unterschiedlichen Tests mit jeweils eigenem Messumfang und eigenen Bedingungen. Sie zeigen die Verbesserungen der internen Rust-Verarbeitung, der TypeScript-Event-Queue und der gRPC-Wiederverbindung. Details zur Implementierung und zu den Testbedingungen finden Sie in PR #129 unter den weiterführenden Links.

Alpenglow-Unterstützung beibehalten und Clients aktualisiert

Die Unterstützung für Alpenglow wurde mit v3.0.0 eingeführt. Version 4.0.0 behält die Unterscheidung zwischen Block-Markern für Block-Header-, Block-Footer- und Parent-Updates und den Entries bei, die Transaktionen enthalten. Anwendungen können Informationen zur Blockstruktur getrennt von den zu verarbeitenden Entries behandeln.
Version 4.0.0 aktualisiert die Clients auf Agave 4.4.1 und Yellowstone gRPC 17.x. Bei der Wiederverbindung kann ein Disconnected-Ereignis Informationen zur Identifikation teilweise empfangener Daten sowie die Position für die Wiederaufnahme melden. Damit erhalten Anwendungen die Informationen, die sie für eine eigene Behandlung erneut übermittelter Duplikate und nur teilweise empfangener Daten benötigen.
Bei der Migration von v3 auf v4 bleiben die Geyser-protobuf-Definitionen erhalten, während die Wiederverbindungsereignisse und die in Rust verwendeten Solana-Nachrichten- und Transaktionstypen aktualisiert werden. Der veröffentlichte Migrationsleitfaden beschreibt die Änderungen an Ereignishandlern und Abhängigkeitsversionen.

Rust für UDP, Rust und TypeScript für gRPC

Das veröffentlichte Rust-Paket solana-stream-sdk und das TypeScript-Paket @validators-dao/solana-stream-sdk sind beide in v4.0.0 verfügbar. Die unterstützten Sprachen je Verbindungstyp sind nachfolgend aufgeführt.
VerbindungstypUnterstützte Sprachen
Shreds UDPRust
Geyser gRPCRust und TypeScript
Shreds gRPCRust und TypeScript
Verwenden Sie den Rust-Client, um Shreds über UDP zu empfangen. Das Rust-UDP-Beispiel und der Starter nutzen das veröffentlichte SDK v4.0.0 und ermöglichen es, den Datenempfang, die Rekonstruktion von Daten aus Shreds und die Erkennung von Instruktionen eines zu überwachenden Programms auszuprobieren. Passen Sie das überwachte Programm und die Verarbeitung nach der Erkennung an, um daraus einen Ausgangspunkt für Ihre eigene Anwendung zu machen.
Für die Entwicklung mit TypeScript stehen Geyser gRPC und Shreds gRPC zur Verfügung. Die Verbesserungen der Event-Queue in dieser Version sind in den Geyser-gRPC-Beispielen und -Startern enthalten. Wählen Sie die veröffentlichte Implementierung, die zu Ihrer Sprache und Übermittlungsart passt.

Shreds UDP Forwarding Premium nutzen

ERPC Shreds UDP Forwarding Premium verbindet mehrere Nodes innerhalb jeder Region zu einem Mesh und leitet von jedem Shred die Kopie weiter, die das Mesh zuerst empfängt. Sowohl die Ankunftszeit über den Übermittlungsweg als auch die anschließende Rekonstruktionszeit im SDK beeinflussen, wie schnell empfangene Daten nutzbar werden. Die Verbesserungen des Rust-UDP-Empfangs lassen sich auf der Empfängerseite auf die von Premium gelieferten Daten anwenden.
Beim Vergleich in Frankfurt am 30. Oktober 2026 wurden Standard und Premium 120 Sekunden lang gleichzeitig auf demselben Rechner mit derselben Uhr aufgezeichnet. Aus der pcap-Aufzeichnung wurden UDP-Payloads mit identischem Inhalt einander zugeordnet. Bei 98 % dieser übereinstimmenden Datenmenge traf Premium zuerst ein; der Median des Ankunftsunterschieds betrug 1,78 ms. Von den bei Standard beobachteten Payloads wurden 93,9 % auch bei Premium beobachtet.
Vergleich der zuerst eintreffenden Daten von Shreds UDP Forwarding Premium und Standard unter gleichen Bedingungen in Frankfurt
Die Premium-Grafik zeigt Unterschiede in der Ankunftszeit zwischen den Übermittlungswegen, während die SDK-Grafik die interne Verarbeitung auf der Empfängerseite und die Wiederherstellung der Verbindung darstellt. Wenn Sie in einer tatsächlichen Anwendung sowohl die Paketankunft als auch den Zeitpunkt der Erkennung einer relevanten Instruktion aufzeichnen, können Sie prüfen, wie viel des Übermittlungsvorsprungs im Verarbeitungsergebnis erhalten bleibt.

Mit Stundenabrechnung und Beispielen in der eigenen Umgebung vergleichen

Shreds UDP Forwarding Premium ist mit Stundenabrechnung für 1,39 € pro Stunde verfügbar. Sie können den Dienst über das Dashboard starten und den Empfang mit dem Rust-UDP-Starter überprüfen. Wenn Region, Empfangsserver und Anwendungsworkload gleich bleiben, lassen sich Unterschiede bei den Ankunftszeiten getrennt von der Verarbeitungszeit nach dem Empfang bewerten.
Registrieren Sie zunächst Ihre öffentliche IPv4-Adresse und den UDP-Port im Dashboard und erlauben Sie eingehenden Datenverkehr von den aufgeführten Quellen. Nachdem Sie den Paketempfang und die Datenrekonstruktion mit dem Rust-UDP-Starter geprüft haben, beziehen Sie die zu überwachenden Programme und die tatsächliche Verarbeitung Ihrer Anwendung in die Bewertung ein. Kombinieren Sie die Beispiele mit dem Übermittlungsdienst, um die Zeit vom Empfang bis zur Erkennung in Ihrer eigenen Umgebung zu messen.