ERPC verbessert Solana-Netzwerkinfrastruktur grundlegend – hochleistungsfähige Rust-Proxy-Plattform in allen Regionen für Shared RPC, Geyser gRPC und ShredStream ausgerollt, Zero-Downtime-Updates erreicht
ERPC, betrieben von ELSOUL LABO B.V. (Hauptsitz: Amsterdam, Niederlande; CEO: Fumitake Kawasaki) und Validators DAO, hat ein umfassendes Upgrade seiner Solana-Netzwerkinfrastruktur abgeschlossen.
Dieses Upgrade wurde bereits auf alle Regionen und alle von ERPC bereitgestellten gemeinsamen Endpunkte (Solana RPC, Geyser gRPC und Shredstream) angewendet. Wir haben als integriertes System die Infrastrukturverhaltensweisen aktualisiert, die reale Ergebnisse direkt beeinflussen können, darunter Verbindungsaufbau, TLS-Verarbeitung, Cache-Control, HTTP/1.1- und HTTP/2-Transport, Verhalten langlebiger Verbindungen sowie Metriken für Beobachtung und Fehlerbehebung.
Neben der Beibehaltung der alltäglichen Reaktionsfähigkeit als Grundlage haben wir das zugrunde liegende Netzwerkverhalten neu organisiert, damit es in Szenarien mit tendenziell schlechteren Ergebnissen weniger anfällig für Verzerrungen und Instabilität ist – etwa bei Volatilität unter Spitzenlast, Instabilität im Dauerbetrieb sowie Kaskaden durch Trennungen und Wiederverbindungen. Dadurch ist die Umgebung besser darauf ausgerichtet, Leistung und Stabilität im praktischen Solana-Betrieb aufrechtzuerhalten.
Außerdem haben wir auf eine Betriebsarchitektur umgestellt, mit der Änderungen der Netzwerkkonfiguration und Plattform-Upgrades vollständig ohne Ausfallzeit angewendet werden können. Preise, Spezifikationen, Authentifizierung und Rate-Limits ändern sich nicht; bestehende ERPC-Kunden erhalten die Vorteile des Upgrades ohne zusätzliche Einrichtung oder betriebliche Anpassungen.
Hintergrund
Im praktischen Solana-Betrieb sind durchschnittliche Antwortzeit und Latenz im Normalbetrieb wichtige Grundlagen. Gleichzeitig gibt es Szenarien, in denen das Verhalten der zugrunde liegenden Netzwerkinfrastruktur selbst die Ergebnisse bestimmt – etwa bei konzentrierter Last, langlebigen Verbindungen sowie in Phasen mit Trennungen und Wiederverbindungen.
Gemeinsame Endpunkte müssen insbesondere sowohl Transaktionsspitzen in kurzen Zeitfenstern als auch dauerhaft aktive Verbindungen über WebSocket und gRPC bewältigen. Unter diesen Bedingungen wirken sich Infrastrukturverhalten wie Verbindungsaufbau, TLS-Handshake, Transport, Cache-Verarbeitung und die Wiederherstellung aus dem Leerlauf direkt auf Nutzererfahrung und Ausführungsergebnisse aus.
Auch bei einer ausdrücklich als Grundlage gesetzten durchschnittlichen Reaktionsfähigkeit können verschiedene Faktoren während Spitzenlasten oder im Dauerbetrieb über reale Ergebnisse entscheiden. Deshalb müssen praktische Abläufe Alltagstauglichkeit und Kontinuität in fehleranfälligen Szenarien gleichzeitig sicherstellen.
ERPC hat seine eigene hochleistungsfähige Rust-Proxy-Plattform als Grundlage der Solana-Kommunikation entwickelt und betrieben. Dabei wird ein Ansatz in allen Regionen beibehalten und die Plattform kontinuierlich weiterentwickelt. Dieses Upgrade betrachtet betrieblich beobachtete Probleme als ein zusammenhängendes System – vom Verbindungsaufbau bis zum Dauerbetrieb – und ordnet die gesamte Netzwerkgrundlage entsprechend neu.
Was sich für ERPC-Kunden ändert
Mit diesem Update erleben ERPC-Kunden zunächst ein stabileres Verhalten beim Verbindungsaufbau. Während der Verbindungsherstellung einschließlich TLS treten seltener widersprüchliche Bedingungen und unnötige Wiederholungen auf, sodass Transaktionen und Streams zuverlässiger in die Verarbeitung gelangen.
Anschließend haben wir Infrastrukturverhalten neu geordnet, das bei Spitzenlast zu Volatilität führen kann. Durch die Kombination aus früher Filterung unnötiger Verbindungen und gleichzeitigen Verbesserungen an HTTP/1.1- und HTTP/2-Transport, Timeout-Konsistenz, Zustand der Verbindungspools, Cache-Verhalten bei Konkurrenz sowie Beobachtungs- und Fehlerbehebungsmetriken verhindern wir verzerrtes Verhalten auch bei konzentrierter Last besser.
Bei langlebigen WebSocket- und gRPC-Streams sowie dauerhaft aktiven Monitoring-Workloads hat sich die Verbindungskontinuität verbessert. Die Häufigkeit von Trennungs-, Wiederverbindungs- und Resynchronisationsereignissen sowie die Wahrscheinlichkeit, dass diese Ereignisse die Ergebnisse kaskadenartig beeinflussen, wurde reduziert, sodass sich Abläufe leichter auf einen dauerhaften Betrieb auslegen lassen.
Verbesserungen an Cache-Control und Transportverhalten verringern außerdem unnötige erneute Abrufe und verschwendete Verarbeitung bei Überlastung. Bandbreite und Verarbeitungsreserven bleiben eher nutzbar und stabil; erweiterte Metriken und Beobachtbarkeit verkürzen die Zeit für Ursachenanalyse und Wiederherstellung.
Durch die Aktivierung von Konfigurationsänderungen und Plattform-Upgrades ohne Ausfallzeit haben wir zudem Betriebsbedingungen geschaffen, unter denen sich Leistung, Stabilität und die Gesamtqualität der Plattform häufiger verbessern lassen. Die Möglichkeit, die Plattform ohne Unterbrechung weiterzuentwickeln, stärkt die Kontinuität für Kunden.
Details der Verbesserungen
Dieses Upgrade wird nicht als Release mit bestimmten Feature-Namen oder Versionsnummern präsentiert. Stattdessen zerlegt es die Szenarien, die reale Solana-Ergebnisse bestimmen können, in die folgenden Schichten: Verbindungsaufbau, TLS, die L4/HTTP-Grenze, H1/H2-Transport, Cache, Beobachtbarkeit, Fehlerverhalten und langfristige betriebliche Voraussetzungen. Die Plattform wurde aktualisiert, damit diese Schichten widerspruchsfrei zusammenspielen.
Im Folgenden erläutern wir die Verbesserungen und ihren Beitrag zu Kundenerfahrung und Betriebsergebnissen.
Verbesserungen bei Verbindungsaufbau und TLS-Verarbeitung
Wir haben den TLS-Kontext erweitert, der während der Verbindungsherstellung verarbeitet wird, und die Struktur so aktualisiert, dass der erforderliche Zustand erhalten und angemessen angewendet werden kann. Dadurch treten beim Verbindungsaufbau seltener widersprüchliche Bedingungen und unnötige Wiederholungen auf.
Auch die TLS-Verarbeitung einschließlich Zertifikats- und Hostnamenprüfung wurde neu organisiert. Sicherheitsanforderungen können erfüllt werden, während Bedingungen reduziert werden, unter denen Handshake-Fehler oder uneinheitliche Verarbeitung zu Verlusten beim Start und dadurch zu Auswirkungen auf Ergebnisse führen. Dies ist nicht nur eine Sicherheitsverbesserung, sondern stabilisiert das Verhalten vom Verbindungsbeginn bis zum Eintritt in die Verarbeitung von Solana-Workloads.
Wir haben außerdem Mechanismen gestärkt, die TLS-nahes Verhalten leichter beobachtbar und analysierbar machen. Wenn der Verbindungsaufbau die Ergebnisse maßgeblich bestimmt, sind schnelle Reproduktion, Ursachenfindung und Umsetzung von Korrekturen entscheidend für die Qualität der Nutzererfahrung.
Reserven durch frühe Filterung unnötiger Verbindungen sichern
Wir haben einen Mechanismus eingeführt, der TCP-Verbindungen frühzeitig filtert. Dadurch belasten unzulässige oder unnötige Verbindungen den legitimen Datenverkehr weniger. Bei gemeinsamen Endpunkten können Verbindungsanfragen durch externe Faktoren oder vorübergehende Verschiebungen sprunghaft ansteigen.
Die Filterung in einer frühen Phase trägt dazu bei, dass legitime Verbindungen beim Start seltener ins Stocken geraten und während Spitzenlast mehr Reserven verfügbar bleiben. Dadurch wird verzerrtes Verhalten bei konzentrierter Last unwahrscheinlicher und eine stabile Latenzverteilung begünstigt.
Verbindungsmodell durch Neuordnung der L4/HTTP-Grenze klären
Netzwerkinfrastruktur endet nicht bei HTTP. Verbindungsaufbau und Kontinuität hängen von L4-Bedingungen ab, und Schwankungen auf dieser Ebene wirken sich auf die Erfahrung mit höheren Protokollen aus.
In diesem Update haben wir die Verarbeitung von L4-Streams abstrahiert und die Struktur neu geordnet, sodass das Verbindungsmodell expliziter verarbeitet werden kann. Damit kann die Plattform leichter konsistentes Verhalten beibehalten, wenn Verbindungen weiter anwachsen, Client-Implementierungen variieren und langlebige Abläufe Zustandsübergänge verursachen.
Auch das Wiederholungsverhalten wurde neu geordnet, um Muster zu reduzieren, bei denen kurzfristige Schwankungen auf die Nutzererfahrung übergreifen. Praktische Stabilität hängt weniger von der Beseitigung einzelner Fehler als von der Vermeidung von Fehlerkaskaden ab.
Verbesserungen bei HTTP/1.1-, HTTP/2-Transport und Dauerbetrieb
Wir haben Messungen ergänzt, mit denen das über HTTP/1.1 und HTTP/2 übertragene Datenvolumen einheitlich verfolgt werden kann. So lässt sich leichter erkennen, wo in der Transportpipeline Verzögerungen oder Engpässe auftreten; Fehlerbehebung und Umsetzungsgeschwindigkeit von Korrekturen werden verbessert.
Außerdem wurde das Timeout-Verhalten beim Schreiben von HTTP/2-Body-Daten neu geordnet, damit bei konzentrierter Last oder langlebigem Streaming weniger unnatürliche Verzögerungen und Hänger auftreten. Im Dauerbetrieb zählt nicht nur Spitzenleistung unter idealen Bedingungen, sondern die Vermeidung eines Zusammenbruchs bei Zustandsübergängen.
Idle-Timeouts und die Verarbeitung der Verbindungspools wurden ebenfalls überprüft, um Instabilitätsfaktoren zu entfernen, die sich im Dauerbetrieb ansammeln können. Auf der HTTP/1.1-Seite haben wir das sichere Beenden von Verbindungen mit unvollständigen Anfragen neu organisiert und damit Schwankungsquellen bei Ressourcenverbrauch und Verhalten reduziert.
Verbesserungen bei Cache-Control und Betriebsqualität
Wir haben die Nachverfolgung verbessert, warum ein Asset nicht gecacht wird, und damit die Erklärbarkeit des Cache-Verhaltens erhöht. Entscheidend ist in der Praxis nicht nur, ob Caching vorhanden ist, sondern unter welchen Bedingungen es angewendet wird oder ausfällt.
Sperrverhalten, Umgang mit veralteten Daten und Revalidierung wurden neu organisiert, sodass sich eine Verschlechterung bei Konkurrenz unter Spitzenlast seltener kaskadenartig ausbreitet. Außerdem wurden Eviction-Kontrollen für wachsende Cache-Bestände sowie Teilinhaltsverhalten einschließlich Range-Anfragen verfeinert, wodurch unnötige erneute Abrufe und Latenz unter realen Workloads reduziert werden.
Diese Verbesserungen verringern Fälle, in denen das Cache-Verhalten zum Ausreißer wird, sodass Kunden ihre Abläufe seltener um Unsicherheiten auf Infrastrukturebene herum planen müssen.
Verbesserungen bei Fehlerverhalten, Logging und Beobachtbarkeit
Fehlerverhalten und Logging wurden neu organisiert, damit bei auftretenden Problemen leichter verständlich ist, was passiert ist. Muster, bei denen nachgelagerte Fehler auf Cache- und Transportverhalten übergreifen und die Erfahrung verschlechtern, wurden reduziert; der betroffene Bereich lässt sich leichter eingrenzen.
Verbesserungen bei Beobachtbarkeit und Fehlerbehebung sollen nicht „null Vorfälle“ versprechen, sondern die Zeit bis zur Wiederherstellung bei Vorfällen verkürzen. Das reduziert Risiken bei Spitzenlast und im Dauerbetrieb.
Abhängigkeitsaktualisierungen und Sicherheitskorrekturen für den langfristigen Betrieb
Wir haben Abhängigkeitsaktualisierungen und Sicherheitskorrekturen integriert, um die Voraussetzungen für einen langfristigen Plattformbetrieb zu erhalten. Dazu gehören Aktualisierungen der minimal unterstützten Rust-Version (MSRV) und die Ausrichtung der CI, wodurch die Grundlage für die kontinuierliche Weiterentwicklung gestärkt wird.
Sicher aktualisieren zu können, ist selbst eine Voraussetzung für langfristige Qualität.
Übergang zu einem Betrieb ohne Ausfallzeit
Bisher konnten bei Änderungen der Netzwerkkonfiguration oder Plattform-Upgrades kurze Ausfallzeiten auftreten. Mit diesem Update sind wir auf eine Architektur umgestiegen, in der solche Vorgänge vollständig ohne Ausfallzeit angewendet werden können.
Gemeinsame Endpunkte haben dauerhaft aktive Verbindungen und fortlaufende Abläufe, bei denen das Timing entscheidend ist. Selbst kurze Ausfälle können Trennungen, Wiederverbindungen und Resynchronisationskaskaden auslösen, deren Kosten sich auf die Ergebnisse auswirken. Updates ohne Ausfallzeit verringern diese Wahrscheinlichkeit und verhindern, dass langlebige Abläufe fragmentiert werden.
ERPC verfügt nun zugleich über betriebliche Voraussetzungen, mit denen beobachtete Probleme schnell in Verbesserungen einfließen können. Eine höhere Iterationsfrequenz erlaubt es uns, Volatilität und Randfallverhalten im Produktionsbetrieb kontinuierlich zu reduzieren.
Auswirkungen nach Dienst
Solana RPC (HTTP / WebSocket)
Verbesserungen bei Verbindungsaufbau, TLS, Cache-Control und Transport wirken sich sowohl auf Datenabrufe als auch auf die Übermittlung von Transaktionen aus. Die Alltagstauglichkeit bleibt erhalten, während Faktoren reduziert werden, die Ergebnisse bei Spitzenlast verzerren können; zugleich werden Bedingungen für den Erhalt von Reserven bei Überlastung gestärkt.
Geyser gRPC
Für langlebiges Streaming hat sich die Verbindungskontinuität verbessert. HTTP/2-Transport, Timeout-Konsistenz, Zustand der Verbindungspools und erweiterte Transportmessungen wirken zusammen, um die Wahrscheinlichkeit zu reduzieren, dass Kosten von Wiederverbindungen und Resynchronisationen die Ergebnisse beeinflussen.
Shredstream (Direct Shreds)
Durch Verbesserungen bei Verbindungsverwaltung und -aufbau für die kontinuierliche Übertragung sind die Bedingungen stabiler, sodass fehlende Daten oder Latenz bei Überlastung weniger wahrscheinlich werden. Eine stabile Kontinuität für Erkennung und Weiterverfolgung lässt sich leichter aufrechterhalten.
Verbindung von Forschung und Entwicklung mit dem Produktionsbetrieb
Die verteilte Systemgrundlage, zu der ERPC gehört, wurde im Rahmen des niederländischen WBSO-Programms als Forschungs- und Entwicklungsprojekt anerkannt. Dadurch können im Betrieb beobachtete Probleme als Forschungsgegenstände aufgenommen und durch Verifikation und Iteration verbessert werden.
Dieses Update der Netzwerkgrundlage ist eine solche Iteration, die auf alle Regionen angewendet wurde und sich in praktischer Leistung und Stabilität widerspiegelt. Die Verbindung von Betrieb und Forschung und Entwicklung ist Voraussetzung dafür, Beobachtungen aus der Produktion kontinuierlich mit dem nächsten Update zu verknüpfen, statt bei einer einmaligen Verbesserung stehenzubleiben.
Bei ERPC fließen tatsächliche Nutzungsmuster, Lastschwankungen und Fehlerverhalten in wiederholte Verifikations- und Verbesserungszyklen ein, die die Qualität der Netzwerkgrundlage schrittweise erhöhen. Dieses Update wurde im Rahmen dieses integrierten Forschungs-, Entwicklungs- und Produktionsmodells umgesetzt.
Informationen für Kunden
Dieses Update wurde bereits auf alle Regionen und alle gemeinsamen Endpunkte angewendet. Bestehende ERPC-Kunden müssen ihre Konfiguration oder ihren Betrieb nicht ändern. Preise, Spezifikationen, Authentifizierung und Rate-Limits bleiben unverändert.
Da gemeinsame Endpunkte gleichzeitig kurze Spitzen und langlebige Verbindungen bewältigen müssen, wurden die Bedingungen so neu geordnet, dass gemischte Workloads seltener zu verzerrtem Verhalten führen. Auch während Konfigurationsänderungen oder Plattform-Updates im Betrieb werden Änderungen ohne Ausfallzeit angewendet; Kunden müssen daher keine Verbindungsfragmentierung oder eine planmäßige Resynchronisation einplanen.
Bei Fragen zu Architektur, workload-spezifischer Optimierung oder betrieblichem Feedback wenden Sie sich bitte über den offiziellen Validators-DAO-Discord an uns.
Durch die kontinuierliche Überführung von Produktionsbeobachtungen und Feedback in Verbesserungen hat ERPC die Qualität seiner Grundlage schrittweise erhöht. Wir werden weiterhin Verbesserungen ohne Ausfallzeit umsetzen und Netzwerkinfrastruktur bereitstellen, die reale Solana-Ergebnisse unterstützt.
Offizieller Validators DAO Discord: https://discord.gg/C7ZQSr CkYR
Offizielle ERPC-Website: https://erpc.global/de
Offizielle ERPC-Website: https://erpc.global/de
