FAQ - Direct Shreds

Q. Meine Shreds- / getBlock-Ausgabe sieht plötzlich kaputt aus oder liefert -32015 — was hat sich geändert?

Solana Transaction v1 (SIMD-0385) ist am 15. September 2026 in Epoche 1035 auf dem Solana-Mainnet live gegangen. Das Wire-Layout einer v1-Transaktion beginnt mit dem Versionspräfix-Byte 0x81, die Signaturen folgen nach der Message, und ein Legacy-Längenpräfix gibt es nicht mehr.

Wenn Sie ShredStream-, Direct-Shreds- oder UDP-Forwarding-Entries selbst dekodieren, liest ein bincode- oder solana-entry-Decoder unter Version 4.2 dieses 0x81-Byte fälschlich als Signaturanzahl — das zeigt sich als EOF-Fehler, als Compact-Length-Overflow oder als Fehler "invalid message version". Geyser-gRPC-Nutzer, die Raw-Transaktionen mit Crates vor 4.2 deserialisieren, haben dasselbe Problem. RPC-Aufrufe von getBlock und getTransaction mit maxSupportedTransactionVersion: 0 liefern -32015 Transaction version (1) is not supported by the requesting client; getTransactionsForAddress im Modus full meldet denselben Fehler für jede betroffene Zeile. Sie sind nicht betroffen, wenn Sie bereits die geparsten JSON-Antworten von ERPC mit gesetzter Version 1 lesen.

Setzen Sie maxSupportedTransactionVersion im Options-Objekt auf 1 — im zweiten Parameter von getBlock und getTransaction sowie in den Options von getTransactionsForAddress:

json

{
  "maxSupportedTransactionVersion": 1
}

{
  "maxSupportedTransactionVersion": 1
}

Aktualisieren Sie das Solana Stream SDK auf 2.0.0: Rust solana-stream-sdk auf crates.io oder npm @validators-dao/solana-stream-sdk und @validators-dao/solana-shreds-client. Aktualisieren Sie @validators-dao/solana-entry-decoder separat auf 2.5.0. 1.4.0 und entry-decoder 2.4.0 unterstützen v1 nicht. Eigene Rust-Decoder sollten auf solana-entry 4.2.x umsteigen.

Q. In welchen Regionen liegen Ihre Knoten?

Aktuell betreiben wir Knoten in den folgenden Regionen:

Frankfurt (FRA)
Amsterdam (AMS)
London (LON)
Dublin (DUB)
New York (NY)
Chicago (CHI)
Salt Lake City (SLC)
Tokio (TY)
Singapur (SGP)
Sydney (SYD)

ERPC misst die tatsächliche Netzwerklatenz anhand realer Routing-Pfade und wählt automatisch die Region mit der niedrigsten Latenz, statt sich auf die Luftlinienentfernung zu verlassen. Dieser Ansatz verbessert nicht nur die Latenz für einzelne Nutzer, sondern steigert auch die Effizienz des gesamten Netzwerks und stärkt die globale Widerstandsfähigkeit von ERPC gegen potenzielle Angriffe.

Wenn Ihre Umgebung die optimale Region nicht automatisch auswählt, kontaktieren Sie uns bitte über das ERPC Web Dashboard.

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

Q. Die Latenz wird mit 9999 ms angezeigt, und es wird eine nicht optimale Region ausgewählt. Was soll ich tun?

Für die Regionsauswahl von Shreds sendet ERPC von den unten aufgeführten Proxy-Hosts ICMP-Latenzprüfungen an Ihre registrierte IP-Adresse. Lassen Sie eingehende ICMP-Echoanfragen von allen aufgeführten Quell-IP-Adressen zu. Werden sie durch eine Firewall (ufw, Cloud-Firewall, Sicherheitsgruppe usw.) blockiert, kann der Messwert 9999ms betragen und eine nicht optimale Region ausgewählt werden. Mehrere IP-Adressen in einer Region gehören zu separaten Prüfhosts; sie werden alle benötigt.

Region	ICMP-Quell-IP-Adressen
🇳🇱 Amsterdam	`82.21.43.35`
🇺🇸 New York	`151.243.244.162`
🇩🇪 Frankfurt	`151.241.178.73`
🇯🇵 Tokyo	`143.20.238.88`
🇸🇬 Singapore	`151.245.186.3`
🇬🇧 London	`151.241.65.10`

Far Point ausgewählt

Der Far Point von Shared Shreds ist eine Ausweichoption mit begrenzter Kapazität. Jeder Endpunkt unterstützt kundenübergreifend insgesamt bis zu 32 gleichzeitig weitergeleitete Streams—nicht 32 Plätze pro Kunde. Streaming ist am effektivsten, wenn der Subscriber in der Nähe des ausgewählten Shreds-Endpunkts ausgeführt wird; Streams über große Entfernungen binden gemeinsam genutzte Verbindungen, Flow-Control-Fenster und Egress-Kapazität länger. Damit die gemeinsam genutzte Umgebung reaktionsfähig bleibt, geben Sie alle aufgeführten Quell-IP-Adressen der regionalen ICMP-Probes frei und führen Sie die Regionsauswahl erneut aus. Für eine dauerhafte Nutzung empfiehlt sich ein ERPC VPS in der Nähe des ausgewählten Endpunkts. Wählen Sie für UDP Forwarding Standard bei der Ersteinrichtung eine verfügbare Region und konfigurieren Sie als Ziel eine gültige, nicht leere öffentliche IPv4-Adresse mit Port. Region und Ziel lassen sich später im Dashboard ändern. Ein Regionswechsel ändert die Quell-IP der Weiterleitung, daher muss die Firewall auf der Empfangsseite die neue Quell-IP der Weiterleitung zulassen.

ERPC VPS in der Nähe dieses Endpunkts verwenden · UDP Forwarding Standard konfigurieren Schnellstart für Direct Shreds lesen

Q. Ich habe meine IP freigegeben, kann mich aber immer noch nicht verbinden. Was soll ich prüfen?

ERPC gRPC- und Shreds-Endpoints verwenden einfaches HTTP auf Port 80, geschützt durch IP-Allowlisting. Sie verwenden kein HTTPS/TLS auf Port 443.

Wenn Sie ein Client-Beispiel eines anderen Anbieters kopieren, ist dort möglicherweise :443 oder HTTPS voreingestellt. Wenn Sie nur die Domain ersetzen, können Port- und TLS-Einstellungen unverändert bleiben – dann kommt keine Verbindung zustande.

Die untenstehenden Endpoints sind Beispiele. Ersetzen Sie sie durch Ihren eigenen im Dashboard angezeigten Endpoint. Verwenden Sie ihn im HTTP-Format, oder geben Sie Port 80 explizit an, wenn Ihr Client Host und Port verlangt:

Nicht gültig: shreds-fra6-1.erpc.global:443
Gültig: shreds-fra6-1.erpc.global:80
Gültiges URL-Format: http://shreds-fra6-1.erpc.global

Die Authentifizierung erfolgt über Ihre registrierte IP-Adresse. Fügen Sie für ERPC gRPC- oder Shreds-Endpoints keine x-token-, token- oder Authorization-Header hinzu, sofern dies nicht auf einer bestimmten Produktseite ausdrücklich angegeben ist.

Q. Ich habe bisher nur WebSocket oder Geyser gRPC (YellowStone) verwendet. Haben Sie Beispiele?

Ja. Mit SLV können Sie schnell damit beginnen, Shreds-Verbindungen zu testen und Anwendungen zu entwickeln.

Details finden Sie im folgenden Leitfaden:

Shreds-Schnellstartanleitung

Q. Kann ich zwei IP-Adressen registrieren?

Sie können einen Endpunkt pro Abonnement verwenden. Wenn Sie zwei IP-Adressen verwenden möchten, müssen Sie zwei separate Abonnements abschließen.

Q. Welche Region empfehlen Sie?

Es gibt keine einzelne Region, die dauerhaft die beste ist. Solana ist global, und die Leader-Rolle wechselt Slot für Slot zwischen den Validatoren. In Regionen mit mehr Validatoren und höherem Stake fallen Leader-Slots häufiger an, was dazu beitragen kann, dass Transaktionen schneller in einen Block aufgenommen werden. Der Nachteil: Auch der konkurrierende Traffic konzentriert sich dort, sodass eine weniger überlaufene Region je nach Strategie manchmal bessere Ergebnisse liefern kann.

Ein praktischer Ausgangspunkt: Wählen Sie eine Region mit hoher Validatordichte wie Frankfurt oder die US-Ostküste, wenn ein stetiges Angebot an Leader-Slots am wichtigsten ist, oder platzieren Sie sich in der Nähe eines bestimmten Ziel-Validators, wenn die Ausführung über den kürzesten Pfad Vorrang hat. Nutzen Sie Validators Solutions, um die öffentliche Verteilung des Solana-Netzwerks zu verstehen, und entscheiden Sie dann anhand der ERPC Leader Slot API und realer Messungen, ob eine Bereitstellung in einer Region, in zwei Regionen oder global sinnvoll ist.

Q. Ich brauche eine Latenz von mindestens ~400 ms oder besser.

Um eine Latenz innerhalb von etwa 400 ms zu erreichen, sollten Sie diese wesentlichen Punkte berücksichtigen:

Realistisches Verständnis von Ping-Werten: Ping-Werte geben ideale Bedingungen wieder und spiegeln nicht die tatsächliche Latenz bei Streaming-Kommunikation wider, die typischerweise etwa das Fünffache der Ping-Latenz beträgt. Ein Ping von 100 ms zwischen Kontinenten führt beispielsweise realistisch betrachtet zu etwa 500 ms Latenz. Um ~400 ms Latenz zu erreichen, muss die Infrastruktur daher in derselben Region aufgebaut werden.
- Typische Ping-Referenzwerte:
  - Gleiches Netzwerk: ~0,1 ms
  - Private Network Interconnect (PNI): ~0,2 ms
  - Gleiches Rechenzentrum: ~0,3 ms
  - Gleiche Stadt: ~1 ms
  - Nachbarland: ~5–10 ms
  - Interkontinental: ~100–300 ms
Die Durchschnittslatenz-Falle vermeiden: Solana-Validatoren sind geografisch über die ganze Welt verteilt, und der Leader-Schedule ändert sich mit jeder Epoche zufällig. Sich auf die durchschnittliche Latenz zu verlassen, um ~400 ms zu erreichen, ist nicht praktikabel. Verfolgen Sie stattdessen die Schedules der Validatoren in Ihrer jeweiligen Region genau, um die Slots mit der niedrigsten Latenz zu identifizieren. Um durchgängig minimale Latenz zu erreichen, ist Infrastruktur in allen relevanten Regionen erforderlich. Innerhalb derselben Region kann die Datenerfassung innerhalb einiger Dutzend Millisekunden erfolgen, und die Übertragung ist in nur wenigen Millisekunden möglich.
Den Leader-Schedule verfolgen: Beobachten Sie den Leader-Schedule der Validatoren für Ihre Region mit der ERPC Leader Slot API (getLeaderSlots). Die API liefert den anstehenden Leader-Schedule, die Stake-Gewichtung für die aktuelle Epoche, geschätzte Standorte der Validatoren und Referenz-Ping-Werte, sodass Sie die Slots mit der niedrigsten Latenz als Ziel bestimmen können, bevor sie an der Reihe sind. Öffentliche Daten im Kartenstil und native RPC-APIs eignen sich für einen breiten Überblick über das Netzwerk, sind für das Timing der Ausführung aber nicht präzise genug. Die Leader Slot API schließt diese Lücke mit der Granularität, die für Routing- und Trading-Entscheidungen nötig ist.
- Dokumentation zur ERPC Leader Slot API
- ERPC Web Dashboard

Validators Solutions - Solana-Netzwerkdaten

Solana-Netzwerkdaten: Validators Solutions

Q. Wie kann ich Zero-Block-Trading (Zero-Slot-Trading) erreichen?

Für erfolgreiches Zero-Block-Trading (Zero-Slot-Trading) sind ausgefeiltere Strategien nötig:

Opportunity Zones identifizieren: Solana-Validatoren sind weltweit verteilt, und es ist physikalisch unmöglich, für jeden Slot eine optimale Latenz zu erreichen. Beobachten Sie daher die Leader-Schedules der Validatoren in der Region, in der sich Ihre Infrastruktur befindet, und identifizieren Sie die günstigsten Opportunity Zones. Auch eine Verteilung der Infrastruktur auf mehrere Regionen kann von Vorteil sein. Frankfurt etwa ist dank seiner hohen Validatordichte eine Schlüsselregion: Leader werden dort häufiger ausgewählt, was mehr Trading-Möglichkeiten eröffnet.

Nutzen Sie die ERPC Leader Slot API (getLeaderSlots), um den anstehenden Leader-Schedule, die Stake-Gewichtung für die aktuelle Epoche, geschätzte Standortdaten der Validatoren und Referenz-Ping-Werte mit weitaus höherer Präzision abzurufen als über öffentliche Datenquellen im Kartenstil oder native RPC-APIs. So können Sie Opportunity Zones ermitteln, bevor die Slots an der Reihe sind, und Trades mit nahezu null Latenz ausführen.
- Dokumentation zur ERPC Leader Slot API
- ERPC Web Dashboard
Dedizierte Knoten einsetzen: Wenn Sie Schwierigkeiten haben, im Wettbewerb mitzuhalten, sollten Sie dedizierte Knoten in Betracht ziehen. Geteilte Knoten sind durch den Traffic anderer Nutzer von Latenz betroffen und werden daher nicht empfohlen. Wenn Sie Ihren dedizierten Knoten zudem im selben Netzwerk wie Ihre Anwendung platzieren, sinkt die Netzwerklatenz erheblich und die Performance wird optimiert.

Q. Kann ich einen bestimmten Endpunkt verwenden?

Um eine Umgebung mit niedriger Latenz aufrechtzuerhalten, wählt unser System automatisch den nächstgelegenen verfügbaren Knoten aus. Wenn Sie einen bestimmten Endpunkt nutzen möchten, empfehlen wir, einen Server zu mieten, der möglichst nah an diesem Endpunkt steht.

Q. Warum sind dedizierte Endpunkte schneller?

Geteilte Endpunkte werden von mehreren Kunden genutzt, die sich dieselben Ressourcen teilen. Mit zunehmendem Traffic steigt tendenziell die Latenz. Server-Ressourcen haben physische Grenzen, und die Arbeitslast, die sie bewältigen können, ist endlich. Wenn zu viele Anfragen gleichzeitig eintreffen, müssen sie nacheinander verarbeitet werden, was zu längeren Antwortzeiten führt.

Obwohl wir verschiedene Maßnahmen ergreifen, um die Leistung auch auf geteilten Endpunkten zu optimieren, sind Sie bei dedizierten Endpunkten der einzige Nutzer der Ressource. Andere Nutzer haben also keinerlei Einfluss auf Sie, was durchgängig stabile und schnelle Antworten sicherstellt.

Darüber hinaus bieten dedizierte Endpunkte Kommunikationsoptionen ohne TLS, etwa HTTP. Da der TLS-Handshake (etwa 20 ms) entfällt, ist die Kommunikation noch schneller als über HTTPS.

Q. Wird der Verkaufspreis erhöht, nachdem ich abonniert habe?

Solange Ihr Abonnement aktiv bleibt, gilt weiterhin der Verkaufspreis, den Sie sich bei der Anmeldung gesichert haben. Umgebungen, die Solanas Echtzeit-Workload standhalten, sind weltweit knapp, und wir planen, die Listenpreise im Einklang mit der wachsenden Nachfrage nach Hardware und Netzwerk schrittweise anzuheben. Höher spezifizierte Konfigurationen und stark nachgefragte Regionen sind am schnellsten ausverkauft; sich den aktuellen Aktionspreis zu sichern, ist daher langfristig die kosteneffizienteste Wahl.

Q. Ich möchte mit Krypto bezahlen

Krypto-Zahlungen sind im ERPC Web Dashboard verfügbar, wenn das Land Ihrer registrierten Rechnungsadresse eines der EU-Mitgliedsländer ist. Sie können mit SOL, USDC oder EURC ERPC Credits kaufen.

Mit diesen ERPC Credits können Sie ERPC-Pläne starten oder fortsetzen. Öffnen Sie das Dashboard, wählen Sie die Krypto-Zahlung, senden Sie die Zahlung aus Ihrer Wallet, und das Dashboard prüft die Transaktion und schreibt die Credits Ihrem Konto gut.

Unterstützte Länder: Belgien, Bulgarien, Dänemark, Deutschland, Estland, Finnland, Frankreich, Griechenland, Irland, Italien, Kroatien, Lettland, Litauen, Luxemburg, Malta, Niederlande, Österreich, Polen, Portugal, Rumänien, Schweden, Slowakei, Slowenien, Spanien, Tschechien, Ungarn, Zypern.

Für Länder, die nicht auf der Liste stehen, zahlen Sie bitte per Kreditkarte.

ERPC Web Dashboard

Q. Warum enthält ShredStream nicht alle Transaktionen?

Shreds enthalten konstruktionsbedingt nicht jede Transaktion auf der Solana-Blockchain. Um alle Transaktionen zu überwachen, müsste man weltweit zahlreiche Proxys bereitstellen und Shreds von jedem Validator empfangen, was nicht praktikabel ist.

In der Regel arbeiten Nutzer mit einer Teilmenge der verfügbaren Daten, da dieser Ansatz für die meisten realen Anwendungen ausreicht. Wenn Ihr Anwendungsfall eine vollständige Datenabdeckung ohne jeglichen Verlust erfordert, sind Shreds möglicherweise nicht geeignet.

Für Szenarien, die eine umfassendere Überwachung erfordern, bietet Geyser gRPC eine höhere Zuverlässigkeit als Shreds. Eine Datenabdeckung von 100% auf der Solana-Blockchain erfordert jedoch nach wie vor die Bereitstellung zahlreicher Edge-Server, was in der Praxis möglicherweise nicht realistisch ist.

Geyser gRPC bietet eine Zuverlässigkeit von über 99% und damit deutlich mehr als Shreds – das haben viele Nutzer bestätigt, darunter auch wir selbst. Shreds bieten dagegen typischerweise eine Zuverlässigkeit von über 90%.

Auch wenn sie nicht jede Transaktion erfassen, liegt ihr entscheidender Vorteil darin, dass sie die meisten Transaktionen schneller abrufen können als Geyser gRPC.

Für ein tieferes Verständnis empfehlen wir, sich mit Solanas Protokollen Turbine und Gulf Stream zu befassen:

Q. Ich will die bestmögliche Umgebung.

Wählen Sie für UDP Forwarding Standard bei der Ersteinrichtung eine verfügbare Region und konfigurieren Sie als Ziel eine gültige, nicht leere öffentliche IPv4-Adresse mit Port. Region und Ziel lassen sich später im Dashboard ändern. Ein Regionswechsel ändert die Quell-IP der Weiterleitung, daher muss die Firewall auf der Empfangsseite die neue Quell-IP der Weiterleitung zulassen.

Für weitere Details kontaktieren Sie uns bitte über das ERPC Web Dashboard.

ERPC Web Dashboard

🔗 ERPC Web Dashboard

Q. Wie ist die Latenz?

Die Latenz variiert je nach Messmethode und spezifischer Nutzungsumgebung. Statt sich auf exakte Zahlenwerte zu konzentrieren, ist es entscheidend sicherzustellen, dass die Latenz Ihren tatsächlichen betrieblichen Anforderungen entspricht.

Wir bieten einfach zu bedienende Werkzeuge in TypeScript und Rust zur Messung der Latenz.

Q. Ist dieser RPC (gRPC, Shreds) schneller als andere?

Wir legen jede Preisstufe auf Geschwindigkeit aus und freuen uns, wenn das im direkten Vergleich mit jedem anderen Anbieter gemessen wird. Die Ergebnisse hängen von der Region, von der Wahl zwischen geteiltem und dediziertem Endpunkt, vom verwendeten Protokoll (WebSockets, gRPC oder Shreds) und von der Programmiersprache Ihres Clients ab.

Wenn Ihnen unser Dienst langsamer erscheint, nennen Sie uns bitte über das ERPC Web Dashboard die konkreten Bedingungen und die Wettbewerber, mit denen Sie ihn verglichen haben. Wir ermitteln die Ursache und verbessern die Geschwindigkeit weiter.

ERPC Web Dashboard

Q. Welcher Plan bietet die schnellste Leistung?

In der Regel bietet unser Plan der höchsten Stufe dank leistungsstärkerer CPUs, größerer Speicherkapazitäten und robuster Hardwarekonfigurationen die schnellste Leistung.

Wenn Sie noch leistungsfähigere Server benötigen, bieten wir auch maßgeschneiderte Lösungen an; unsere Standardpläne sind jedoch auf ein optimales Preis-Leistungs-Verhältnis ausgelegt.

Wir sind zuversichtlich, auf jedem Preisniveau Weltklasse-Performance zu bieten. Wenn Sie im gleichen Preissegment einen schnelleren Anbieter finden, teilen Sie es uns bitte mit, damit wir der Sache nachgehen und Verbesserungen vornehmen können.

Q. Ich habe eine hohe Latenz. Warum?

Die Latenz nimmt mit der Entfernung zum Endpunkt deutlich zu. Wir empfehlen, von einem Server aus zuzugreifen, der sich näher am bereitgestellten Endpunkt befindet. Die schnellsten Umgebungen stehen über unsere Bare-Metal-Server und VPS-Services zur Verfügung.

Q. Was ist am schnellsten: WebSockets, gRPC oder Shreds?

Laut Kundenfeedback ergibt sich folgende Rangfolge der Leistung:

Shreds > gRPC > WebSockets

Wenn Ihre Erfahrungen davon abweichen, lassen Sie es uns bitte wissen.

Q. Latenz ist nicht das, was ich erwartet habe.

Die Leistung variiert je nach verwendeter Programmiersprache deutlich. Im Allgemeinen ergibt sich folgende Rangfolge:

Rust > Go > TypeScript (JavaScript) > Python

Detaillierte Vergleiche finden Sie hier:

Geschwindigkeitsvergleich von Programmiersprachen

Für höchste Leistung empfehlen wir dringend Rust.