ERPC ergänzt gemeinsam genutzte Solana-Shreds- und Geyser-gRPC-Endpunkte um HTTPS — HTTPS oder HTTP, je nach Anwendungsfall

ERPC ergänzt gemeinsam genutzte Solana-Shreds- und Geyser-gRPC-Endpunkte um HTTPS — HTTPS oder HTTP, je nach Anwendungsfall

ERPC ergänzt gemeinsam genutzte Solana-Shreds- und Geyser-gRPC-Endpunkte um HTTPS — HTTPS oder HTTP, je nach Anwendungsfall
ELSOUL LABO B.V. (Hauptsitz: Amsterdam, Niederlande; geschäftsführender Direktor und CEO: Fumitake Kawasaki) und Validators DAO, die Betreiber von ERPC, haben die gemeinsam genutzten Endpunkte für Shreds gRPC und Geyser gRPC um HTTPS erweitert. Zusammen mit dem HTTP-Transport, den wir von Anfang an angeboten haben, können Sie nun zwischen HTTPS und HTTP wählen.
Betroffen sind Direct Shreds Connect und Direct Shreds Turbo auf der Shreds-gRPC-Seite sowie die Stufen Standard, Premium und Burst des Geteilten Geyser gRPC-Streams.
Sie können einen verschlüsselten, sicheren HTTPS-Endpunkt wählen oder einen HTTP-Endpunkt, bei dem keinerlei TLS-Verarbeitung anfällt. In gRPC-Terminologie ist Ersteres gRPC über TLS, Letzteres unverschlüsseltes (plaintext) HTTP/2. Damit deckt ERPC ein deutlich breiteres Spektrum an Anwendungsfällen ab — von Workloads, bei denen allein die Latenz zählt, bis zu Workloads, bei denen die Vertraulichkeit des Abonnierten an erster Stelle steht.
Der Hostname des Endpunkts bleibt unverändert. Nur Schema und Port unterscheiden sich: HTTPS nutzt Port 443, HTTP nutzt Port 80. Umschalten können Sie im ERPC Web Dashboard.

Neu ist HTTPS — bestehendes HTTP läuft unverändert weiter

Die gemeinsam genutzten Stream-Endpunkte von ERPC wurden bisher über HTTP bereitgestellt.
Hinzugekommen ist die HTTPS-Seite. Bestehende HTTP-Verbindungen bleiben in Spezifikation und Verhalten unverändert und können genau wie bisher weiter genutzt werden. Kunden, die bereits über HTTP verbunden sind, müssen nichts unternehmen.
Eine Abschaffung von HTTP ist nicht geplant. HTTP bleibt als Option für Workloads erhalten, bei denen die Latenz an erster Stelle steht.

HTTPS — verschlüsselte, sichere Verbindungen

Auf einem HTTPS-Endpunkt wird die gesamte Kommunikation zwischen Ihrem Client und ERPC mit TLS verschlüsselt.
Sowohl der Inhalt Ihrer Abonnement-Anfrage als auch die daraufhin zurückgelieferten Stream-Daten werden mit TLS verschlüsselt, sodass die Nutzdaten auf dem Weg normalerweise nicht gelesen werden können. Im ERPC Web Dashboard ist HTTPS der standardmäßig ausgewählte Transport.
Der TLS-Handshake fällt im Wesentlichen beim Verbindungsaufbau an. Die Ver- und Entschlüsselung der Stream-Daten läuft danach weiter, doch bei einem typischen, lange offen gehaltenen gRPC-Stream fallen die Handshake-Kosten nicht immer wieder neu an.

HTTP — die latenzarme Option ohne TLS-Verarbeitung

Auf einem HTTP-Endpunkt gibt es weder einen TLS-Handshake noch Ver- oder Entschlüsselungsarbeit.
Bei der Solana-Echtzeitverarbeitung wirkt sich jeder Verarbeitungsschritt auf dem Weg von der Datenentstehung bis zum Eintreffen in Ihrer Anwendung auf die Latenz aus. Da HTTP keine TLS-Ver- oder Entschlüsselung benötigt, eignet es sich für latenzkritische Workloads, bei denen die Verarbeitung auf dem Pfad so weit wie möglich reduziert werden soll.
Bei Konfigurationen, die Verbindungen häufig neu aufbauen, oder bei Konfigurationen, die keinerlei Overhead auf dem Pfad tolerieren, ist HTTP im Vorteil.

Wenn die Zusammenstellung eines Abonnement-Filters Bedeutung trägt

HTTP ist die latenzärmere Option, doch je nach Nutzung durch das Projekt wird dabei die Gruppe der angefragten Adressen auf dem Weg sichtbar — und für manche Projekte ist genau das ein Problem.
Die Daten auf der Blockchain sind für sich genommen öffentlich. Wird jedoch ihre Gruppierung sichtbar, kann sie eine Bedeutung tragen, die kein einzelner Eintrag für sich hatte.
Angenommen, ein Projekt möchte sämtliche Wallets seiner Kunden filtern und überwachen. Die Adressliste in dieser Abonnement-Anfrage kann für dieses Projekt selbst eine sensible Information sein. Selbst wenn jede einzelne Adresse öffentlich ist, kann das Wissen darüber, welche Adressgruppe als eine Einheit überwacht wird, Rückschlüsse auf den Kundenstamm des Projekts, seine Beobachtungsziele und seine geschäftlichen Interessen zulassen.
Genau hier hilft der HTTPS-Endpunkt. Im Gegenzug für die von TLS benötigte Ver- und Entschlüsselung werden die Nutzdaten sowohl Ihrer Abonnement-Anfrage als auch der Stream-Daten verschlüsselt.
Zuerst die Latenz oder zuerst die Vertraulichkeit des Abonnements? Diese Entscheidung fällt von Projekt zu Projekt unterschiedlich aus. ERPC überlässt sie nun Ihnen — passend zu Ihrem eigenen Anwendungsfall.

Betroffen sind die gemeinsam genutzten Endpunkte

Die HTTPS-Unterstützung umfasst die folgenden gemeinsam genutzten Endpunkte:
  • Direct Shreds Connect
  • Direct Shreds Turbo
  • Geteilter Geyser gRPC-Stream — Standard
  • Geteilter Geyser gRPC-Stream — Premium
  • Geteilter Geyser gRPC-Stream — Burst
HTTPS ist auf den gemeinsam genutzten Stream-Endpunkten in allen Regionen aktiviert, und die bestehenden HTTP-Endpunkte bleiben unverändert erhalten. Auch die in Shreds Bundle und ERPC Bundle enthaltenen gemeinsam genutzten Endpunkte können HTTPS nutzen.
Dedizierte Endpunkte sind von dieser Änderung nicht betroffen. Dedizierter Geyser gRPC und die dedizierten Shreds-Produkte behalten ihre bisherige Verbindungsmethode unverändert bei.

Umschalten im Dashboard — die Allowlist der IPs bleibt dieselbe

Den Transport schalten Sie in der Endpunktanzeige im ERPC Web Dashboard um.
Wechseln Sie zwischen HTTPS und HTTP; die Endpunkt-URL für den gewählten Transport wird angezeigt. Übernehmen Sie die URL genau so, wie sie angezeigt wird, in die Konfiguration Ihres Clients.
Beide Transportarten verwenden dieselbe Allowlist der registrierten IPs. Die Authentifizierung basiert weiterhin auf Ihrer registrierten IP-Adresse. Für den Wechsel zu HTTPS müssen Sie daher keine IPs neu registrieren, und es kommt weder ein Token noch ein Authorization-Header hinzu.

Nach dem Ende von Jito ShredStream laufen die gemeinsam genutzten Shreds-Produkte von ERPC weiter

Jito ShredStream stellt den Dienst am 5. September 2026 ein. Die gemeinsam genutzten Shreds-Produkte von ERPC laufen dagegen darüber hinaus weiter.
Direct Shreds Connect und Direct Shreds Turbo — beide von dieser HTTPS-Einführung erfasst — sowie die Shreds Bundle Multi-IP-Tarife und der in ERPC Bundle enthaltene Direct Shreds Connect bleiben alle auch nach dem 5. September verfügbar.
Zur Klarstellung: Das am 21. August 2026 angekündigte Dienstende zum 5. September betrifft die dedizierten Shredstream-Produkte und Stream Bundle. Die gemeinsam genutzten Shreds-Produkte sind davon nicht erfasst. Die Migrationsberatung für Kunden mit dedizierten Tarifen führen wir wie bisher individuell fort.
Wenn Sie gerade prüfen, wie Ihr Projekt Shreds empfängt, ist dies ein guter Zeitpunkt, sich die Optionen anzusehen. Wir freuen uns, wenn Sie sie ausprobieren.

Im Stundentarif testen, ab einer Stunde

Die gemeinsam genutzten Endpunkte von ERPC sind ab einer Stunde verfügbar und werden stündlich abgerechnet.
Ohne sich auf einen Monatstarif festzulegen, können Sie HTTPS und HTTP mit Ihrer echten Workload testen und selbst sehen, wie sich Latenz und Vertraulichkeit in Ihrer eigenen Umgebung zueinander verhalten.
Beginnen Sie mit einer kurzen Evaluierung und wählen Sie Ihren Tarif anschließend auf Basis Ihrer Messungen.

Erneuertes Produkt für UDP Forwarding kommt in Kürze

Für UDP Forwarding, das den Zustellweg für Shreds selbst vereinfacht, kommt in Kürze ein erneuertes Produkt.
Das Ziel ist eine Produktreihe, in der Sie die zum jeweiligen Zweck passende Zustellmethode wählen können: UDP für Workloads, bei denen niedrige Latenz über allem steht, und Shreds gRPC für Stream-Abonnements über die bestehende gRPC-Schnittstelle.
Unterstützte Regionen, Preise, detaillierte Spezifikationen und das offizielle Veröffentlichungsdatum werden bekanntgegeben, sobald sie feststehen.

Infrastruktur, die Sie passend zum Anwendungsfall wählen

ERPC bewertet die Leistung der Solana-Infrastruktur nicht allein anhand von Serverspezifikationen. Nähe zur Datenquelle, Netzwerkpfad, Hardware, Betriebssystem und Kernel sowie die endgültige Zustellmethode zum Nutzer werden gemeinsam als eine einzige latenzarme Infrastruktur gestaltet.
Diese HTTPS-Einführung erweitert die Auswahl innerhalb dieser endgültigen Zustellmethode. Es gibt nicht die eine schnellste Option, die für jedes Projekt richtig wäre; wie stark Latenz und Vertraulichkeit jeweils gewichtet werden, hängt von der Natur des Produkts ab.
Bei Fragen kontaktieren Sie uns bitte über den Support-Chat im ERPC Web Dashboard.