ERPC bringt den XDP-Fast-Path und zero-copy von Solana v4 für RPC-Nodes und Geyser-gRPC-Nodes in allen Regionen in Produktion — der in NY erbrachte Nachweis wird auf jede Region ausgeweitet und hebt sowohl die Stream-Zustellung als auch die RPC-State-Frische an

Die ELSOUL LABO B.V. (Hauptsitz: Amsterdam, Niederlande; CEO: Fumitake Kawasaki) und Validators DAO, die ERPC betreiben, freuen sich bekannt zu geben, dass ERPC den XDP-Fast-Path und AF_XDP zero-copy von Solana v4 (Agave 4.x) für die RPC-Nodes und Solana-Geyser-gRPC-Nodes in allen Regionen in Produktion gebracht hat. Damit wird die Optimierung, die zuerst an der Quelle des Geyser-gRPC der Region New York (NY) nachgewiesen wurde, auf die Produktionsinfrastruktur in jeder Region ausgeweitet.

Der XDP-Fast-Path und AF_XDP zero-copy sind Turbine-orientierte Optimierungen, die in Solana v4 (Agave 4.x) verfügbar wurden. Was die Startflags betrifft, so wurde in der Agave-4.1-Linie die Familie --experimental-retransmit-xdp-* als veraltet eingestuft und zu --xdp-interface / --xdp-cpu-cores / --xdp-zero-copy geordnet. Aufbauend auf diesem Turbine-orientierten XDP-Fast-Path und zero-copy hat ERPC diese Optimierung in Produktion nicht nur auf die Quell-Nodes, die das Geyser-gRPC tragen, sondern auch auf die RPC-Nodes angewendet. Sowohl RPC-Nodes als auch Geyser-gRPC-Nodes empfangen die Shreds, aus denen Blöcke bestehen, über Turbine. Indem XDP und zero-copy den Kernel-Overhead auf diesem Pfad der Shred-Propagierung und -Aufnahme reduzieren, verzeichnet das Geyser-gRPC eine geringere Latenz bei der Stream-Zustellung, während RPC eine verbesserte State-Frische und eine bessere Fähigkeit erhält, mit dem aktuellsten Zustand Schritt zu halten. Diese Änderung läuft bereits in Produktion in allen Regionen. Kundinnen und Kunden, die First-arrival-Performance priorisieren, können das RPC und Geyser-gRPC in allen Regionen sofort ausprobieren — über die stundenbasierte Abrechnung (pro Stunde) oder Crypto Pay (SOL / USDC / EURC).

ERPC-Website: https://erpc.global/de ERPC-Dashboard: https://dashboard.erpc.global/de

Auf Solana rotiert der für die Blockproduktion verantwortliche Leader in einem kurzen Zyklus, sodass sich der Ursprung der Kommunikation ständig bewegt. In dieser Struktur kommt es in der Praxis nicht darauf an, einem einzelnen festen Punkt nahe zu sein, sondern mit hoher Wahrscheinlichkeit dem Netzwerk nahe zu sein, in dem die wichtigen Nodes und Validatoren konzentriert sind — und das wirkt sich im realen Betrieb unmittelbar auf Latenz, Retransmissionsraten und Ausfallraten aus. Deshalb ist ERPC überzeugt, dass es sinnvoll ist, nicht nur eine einzelne Maschine schnell zu machen, sondern die Produktions-Nodes in jeder Region auf dasselbe Niveau zu heben.

Der Kern dieser Ausrollung liegt darin, dass das Ziel der Optimierung der „Pfad der Shred-Propagierung und -Aufnahme auf Turbine" ist. Sowohl bei RPC als auch bei Geyser-gRPC wird die letztendliche Geschwindigkeit davon getragen, „wie schnell ein Node einen Block greifen kann". XDP und zero-copy sind Optimierungen, die den Overhead genau dieser greifenden Stufe reduzieren — des Empfangs, des Retransmits und der Propagierung von Shreds über Turbine. Indem dies auf Produktions-Nodes in jeder Region angewendet wird, können Kundinnen und Kunden, gleichgültig welchen Verbindungspunkt welcher Region sie nutzen, Daten über einen optimierten Pfad empfangen.

XDP (eXpress Data Path) ist eine Technologie des Linux-Kernels, die hochperformantem Netzwerkcode erlaubt, einen Großteil des üblichen Pfades der Paketverarbeitung des Kernels zu umgehen. Indem es Datenkopien und Kontextwechsel reduziert, verarbeitet es Pakete mit weit geringerem Overhead als der Standard-Netzwerkstack.

In Agave (dem Solana-Validator-Client) wird XDP auf Turbine angewendet, das Protokoll, das Blöcke zwischen Validator-Nodes propagiert. Empfangene Shreds werden von einem eBPF-Programm verarbeitet, das nahe der Netzwerkkarte (NIC) angebracht ist, und über AF_XDP in Puffer im User-Space abgebildet. Wird der zero-copy-Modus verwendet, werden empfangene Daten direkt vom Kernel an den User-Space übergeben, ohne kopiert zu werden. Auch ausgehende Shreds nutzen den AF_XDP-Sendepfad, um Kopien und System-Call-Overhead auf dem Hot-Path zu reduzieren.

Anza führte XDP für Turbine in der Agave-3.x-Linie (ab v3.0.9) ein und übertrug es in das Fundament von Solana v4 (Agave 4.x). Die Startflags wurden über aufeinanderfolgende Releases geordnet: In der Agave-4.1-Linie wurde die Familie --experimental-retransmit-xdp-* als veraltet eingestuft und zu --xdp-interface / --xdp-cpu-cores / --xdp-zero-copy geordnet. Laut Anzas Setup-Leitfaden können große Validatoren mit XDP über Turbines Fanout an 150.000 ausgehende Pakete pro Sekunde herankommen.

Anza Agave XDP Setup Guide: https://www.anza.xyz/blog/agave-xdp-setup-guide

Geyser-gRPC ist der Pfad, um Account-, Slot-, Block- und Transaktionsaktualisierungen als Stream statt durch Polling zu empfangen. Hier verbindet sich ein Unterschied von einer Millisekunde unmittelbar mit dem Erfassen von Ausführungschancen und mit der wahrgenommenen Front-End-Geschwindigkeit. Die Geyser-Latenz wird letztlich davon getragen, „wie schnell die Quelle einen Block greifen kann".

XDP und zero-copy sind genau die Optimierungen, die den Overhead dieses quellseitigen Pfades der Shred-Propagierung und -Aufnahme reduzieren. Da die Quelle Shreds schneller empfangen und propagieren kann, kann sie Blöcke zu einem früheren Zeitpunkt beobachten und rekonstruieren, was die Latenz verkürzt, bis diese Aktualisierungen die Kundinnen und Kunden über den Geyser-gRPC-Stream erreichen. In der Region New York (NY), wo wir dies zuerst angewendet haben, haben wir durch Open-Source-Messung bestätigt, dass diese Optimierung in der Tail-Region der Zustellungslatenz wirksam ist. Wir haben dieselbe Optimierung nun auf die Geyser-gRPC-Nodes in jeder Region ausgeweitet.

Neu an dieser Ausrollung ist, dass wir diese Optimierung auch auf RPC-Nodes angewendet haben. Auch RPC-Nodes empfangen die Shreds, aus denen Blöcke bestehen, über Turbine und aktualisieren ihr eigenes Ledger und ihren State. Wenn XDP und zero-copy den Overhead dieser Turbine-basierten Shred-Aufnahme und -Propagierung reduzieren, können RPC-Nodes neuere Blöcke früher aufnehmen.

Für Kundinnen und Kunden, die RPC nutzen, geht es dabei nicht darum, dass alle RPC-Methoden gleichmäßig schneller werden, sondern es zeigt sich als die Frische des States, den der Node hält. Wenn Sie den jüngsten Slot oder Block oder den aktuellsten Zustand eines Accounts abfragen, verbindet sich die Tatsache, dass die bereits vom Node aufgenommene Information neuer ist, unmittelbar mit der Frische der Daten in der Antwort. Darüber hinaus übersetzt sich geringerer Overhead auf dem Pfad der Propagierung und Aufnahme in Reserven für den Node, um Aktualisierungen unter hoher Last zu verarbeiten, ohne sie fallen zu lassen. Dieselbe Optimierung wie bei der Stream-Zustellung des Geyser-gRPC wirkt auch als Fundament, das die Frische der Daten trägt, die RPC zurückgibt — das ist der Grund, weshalb wir den Geltungsbereich dieses Mal auf RPC-Nodes ausgeweitet haben.

ERPC hat die RPC-Nodes und Geyser-gRPC-Nodes in allen Regionen auf Solana v4 (Agave 4.x) migriert und den Turbine-orientierten XDP-Fast-Path und AF_XDP zero-copy in Produktion gebracht. Aufbauend auf dem in der Agave-4.1-Linie geordneten Startflag-Schema --xdp-interface / --xdp-cpu-cores / --xdp-zero-copy aktivieren wir es entsprechend der Konfiguration jeder Region.

Die Aktivierung von XDP erfordert ein fortgeschrittenes und fehleranfälliges Tuning: einen aktuellen Kernel, eine XDP-fähige NIC, die richtigen systemd-Capabilities für den Validator-Prozess, korrekte Startflags und eine angemessene Pinnung der CPU-Kerne. Dies nicht auf einen einzelnen Node, sondern auf Produktions-Nodes in jeder Region auszurollen — und dabei die jeweils unterschiedliche NIC-, Kernel- und Netzwerkkonfiguration jeder Region zu verifizieren — erhöht die operative Schwierigkeit weiter. ERPC wendet das operative Know-how, das aus dem Betrieb von Validatoren an der Spitze des Netzwerks gewachsen ist, direkt auf den Aufbau und Betrieb der Quell-Nodes und RPC-Nodes in jeder Region an.

Und das operative Know-how für diese Optimierung ist als Rezept im Open-Source-Solana-Betriebstool SLV konsolidiert. SLV stellt alles bereit, von der Aktivierung von XDP (über Konfigurationsvariablen wie xdp_enabled / xdp_zero_copy) bis zur Messung der Zustellungslatenz (slv check geyserbench), in einer Form, die jeder durch Gespräche mit einem KI-Agenten oder über die CLI reproduzieren kann. Die Optimierung, die ERPC in allen Regionen erreicht hat, ist kein einmaliger Trick für eine einzelne Maschine, sondern steht auf einem reproduzierbaren operativen Rezept.

SLV GitHub: https://github.com/validatorsDAO/slv

Wie groß der Unterschied ist, den diese Optimierung bewirkt, variiert je nach Verbindungsursprung, Route, Tageszeit und Leader-Verteilung. Genau deshalb legt ERPC Wert darauf, die Zustellungsqualität nicht durch subjektive Behauptungen oder Werbetexte zu zeigen, sondern durch eine Messung, die jeder mit derselben Methode überprüfen kann. Was Kundinnen und Kunden überprüfen können, ist nicht eine feste Zahl, sondern die Messmethode selbst.

Für das Geyser-gRPC ist das Benchmark-Tooling von ERPC Open Source. Für First-arrival-Vergleiche können Sie slv check geyserbench --kind grpc verwenden, und für Konnektivitäts- und Latenzprüfungen eines einzelnen Endpunkts slv check grpc, wobei Sie unter Bedingungen vergleichen, die Ihrer eigenen Workload nahekommen. Auch für RPC ist der zuverlässigste Ansatz, die Frische der zurückgegebenen Daten und das Verhalten der Antworten von Ihrem eigenen Verbindungspunkt aus zu messen und zu beobachten, mit den Anfragen, die Ihr eigener Bot oder Ihre eigene Anwendung tatsächlich sendet.

Entscheidungen auf der Grundlage von Zahlen treffen zu können, die Sie selbst gemessen haben, statt auf Behauptungen eines Anbieters, ist der Ausgangspunkt für Kundinnen und Kunden, die First-arrival-Performance priorisieren. Die Schritte von der Installation von SLV bis zur Ausführung der Messung sind im SLV-Getting-Started-Leitfaden veröffentlicht.

SLV-Website: https://slv.dev/de SLV Getting Started: https://slv.dev/de/doc/general/getting-started/ Solana Geyser gRPC Geschwindigkeitsvergleich: https://erpc.global/de/doc/geyser-grpc/speed-comparison/

Der Latenzvorteil von ERPC kommt nicht allein aus der Software-Optimierung. Indem ERPC Quell-Nodes, empfangende Endpunkte und verarbeitende Nodes in Premium-Rechenzentren platziert, in denen Solana-Validatoren dicht konzentriert sind, unterdrückt ERPC distanzbedingte Latenz bereits in der Designphase.

ELSOUL LABO betreibt als Teil der ERPC-Plattform ein Solana-spezifisches Rechenzentrum unter einer eigenen ASN (AS200261), die von RIPE NCC zugewiesen wurde. Software-Optimierungen wie das heutige XDP und zero-copy entfalten ihre maximale Wirkung erst auf der Grundlage dieses physischen und netzwerktechnischen Nähe-Designs. Erst wenn sowohl die Nähe auf Designebene als auch die Software-Optimierung auf Node-Seite vorhanden sind, werden First-arrival-Performance, niedriglatente Streaming-Qualität und frische RPC-Antworten verwirklicht.

Diese Ausrollung in allen Regionen reiht sich in die Linie der Infrastrukturstärkung ein, die ERPC kontinuierlich verfolgt hat. Sie ist die Optimierung der neuesten Generation, im Anschluss an das regionsübergreifende Geyser-gRPC-Infrastruktur-Upgrade im Dezember 2025, die groß angelegte Stärkung der Region Frankfurt (FRA) im Januar 2026 und die frühere Anwendung von XDP und zero-copy in der Region New York (NY) im Juni 2026. Die in NY nachgewiesene Optimierung wurde nun — mit RPC-Nodes in ihrem Geltungsbereich erweitert — auf die Produktionsinfrastruktur in jeder Region ausgeweitet.

Statt steigender Nachfrage mit Limits oder Drosselung zu begegnen, fängt ERPC sie konsequent ab, indem die Infrastruktur selbst gestärkt wird. Wir spiegeln die Optimierungen der neuesten Generation weiterhin in unsere Produktionsinfrastruktur, während wir kompatible NICs, Kernel und Netzwerkkonfigurationen wiederholt verifizieren. Das RPC und Geyser-gRPC von ERPC werden sich weiterentwickeln.

Das RPC und Geyser-gRPC von ERPC können über den stundenbasierten Abrechnungsplan ab einer einzigen Stunde ausprobiert werden. Dies ermöglicht eine risikoarme Verifizierungsschleife: nur für eine Stunde einen Vertrag abschließen, innerhalb dieser Stunde das tatsächliche Verhalten bestätigen, wie es vom Verbindungspunkt Ihres eigenen Bots oder Ihrer eigenen Anwendung aus zu sehen ist, und auf Basis der Ergebnisse über den Wechsel zu einem Monats- oder Jahresplan entscheiden. Die oben beschriebenen Messungen mit slv check können innerhalb dieser einstündigen Testphase unverändert ausgeführt werden.

Sobald Ihre Konfiguration und Nutzung klar werden, bleiben Sie beim Wechsel zu einem Monats- oder Jahresplan auf demselben Dashboard und bei derselben Endpunktqualität.

ERPC-Dashboard: https://dashboard.erpc.global/de

ERPC bietet Crypto Pay für den Kauf von ERPC-Credits und für die Bezahlung seiner Pläne an, und es wird auch für den stundenbasierten Abrechnungsplan unterstützt. Sie können SOL oder die Stablecoins USDC / EURC als Zahlungsasset wählen. EURC kann direkt gesendet werden, während USDC oder SOL über Orca zu EURC getauscht wird und der Transfer innerhalb desselben Ablaufs abgeschlossen wird.

Für Teams, die auf Solana entwickeln und betreiben, ist die Möglichkeit, Infrastrukturkosten in einer Weise zu handhaben, die ihrem bestehenden, wallet-basierten Ablauf der Mittelverwaltung nahekommt, eine praktische Verbesserung, die die Hürde zum Start der Verifizierung senkt. Auch die oben beschriebene Verifizierung über die stundenbasierte Abrechnung lässt sich direkt aus den Assets in Ihrer Solana-Wallet heraus starten.

ERPC ermöglicht es Ihnen, Solana RPC, WebSocket, Solana Geyser gRPC, Solana Shredstream, Direct UDP Stream (Raw Shreds), VPS, Bare-Metal-Server, dediziertes RPC, SWQoS, eine Pyth-fähige Price API sowie Jet Analytics & Indexed RPC auf einer einzigen Plattform zu kombinieren.

Das ERPC-Dashboard unterstützt 16 Sprachen und lässt Sie Planauswahl, Regionsauswahl, Bestandsprüfungen, das Hinzufügen zum Warenkorb, Credit-Aufladungen, Checkout, das Einsehen von API-Schlüsseln und Endpunkten, die Prüfung der Nutzung und das Erstellen von Support-Tickets handhaben — alles vom selben Bildschirm aus.

Hinter ERPC steht die Forschung und Entwicklung Solana-spezifischer Infrastruktur, die ELSOUL LABO kontinuierlich verfolgt. ELSOUL LABO wurde seit 2022 fünf Jahre in Folge im Rahmen von WBSO genehmigt, dem staatlichen F&E-Förderprogramm der Niederlande. Es setzt die F&E zu Solana-RPC-Infrastruktur, Validator-Betrieb, Echtzeit-Datenzustellung sowie KI-Agenten-gestütztem Betrieb und Entwicklung fort, und diese Ergebnisse spiegeln sich in Diensten wider, darunter ERPC, SLV, SLV AI und das Solana-spezifische Rechenzentrum AS200261.

Auch die heutige Unterstützung von Solana v4 / XDP / zero-copy in allen Regionen hat aus dem Betrieb von Validatoren an der Spitze des Netzwerks Gestalt angenommen. ERPC wird weiterhin niedriglatente Infrastruktur nahe am Solana-Netzwerk bereitstellen und deren Qualität durch eine Messung belegen, die jeder mit derselben Methode überprüfen kann.

Zu optimalen regionalen Konfigurationen einschließlich des RPC und Geyser-gRPC in allen Regionen, zur Auswahl zwischen eigenständigen gRPC-Plänen und gRPC-Bundle-Plänen, zur Wahl zwischen stundenbasierter, monatlicher und jährlicher Abrechnung sowie zum Migrationsdesign von einer bestehenden Konfiguration bieten wir individuelle Beratung auf dem offiziellen Discord von Validators DAO an.

ERPC-Dashboard: https://dashboard.erpc.global/de ERPC-Website: https://erpc.global/de Validators DAO Offizieller Discord: https://discord.gg/C7ZQSrCkYR

Wir danken allen unseren Nutzerinnen und Nutzern aufrichtig für ihre fortwährende Nutzung von ERPC.