FAQ - Geyser gRPC Stream

V. In welke regio's bevinden zich uw nodes?

We beheren momenteel nodes in de volgende regio's:

Frankfurt (FRA)
Amsterdam (AMS)
London (LON)
New York (NY)
Chicago (CHI)
Tokyo (TY)
Singapore (SGP)
Sydney (SYD)

ERPC meet de werkelijke netwerklatentie op basis van echte routeringspaden en selecteert automatisch de regio met de laagste latentie in plaats van te vertrouwen op hemelsbreed afstand. Deze aanpak verbetert niet alleen de latentie voor individuele gebruikers, maar verhoogt ook de algehele netwerkefficiency en versterkt ERPC's wereldwijde weerbaarheid tegen potentiele aanvallen.

Als uw omgeving niet automatisch de optimale regio selecteert, neem dan contact met ons op via het ERPC Web Dashboard. In de meeste gevallen wordt dit probleem veroorzaakt door firewallinstellingen die pingreacties van het endpoint blokkeren.

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

V. Latentie toont 9999ms en er wordt een niet-optimale regio geselecteerd. Wat moet ik doen?

Wanneer u uw IP registreert, pingen we het vanaf elke gRPC load balancer om de dichtstbijzijnde regio te bepalen. Als ICMP-antwoorden worden geblokkeerd door uw firewall (ufw, cloud-firewalls, beveiligingsgroepen, enz.), kan de meting 9999ms worden, waardoor de optimale nabijgelegen regio mogelijk niet wordt geselecteerd. Zet de onderstaande load balancer-IP's op de allowlist zodat de dichtstbijzijnde regio automatisch wordt gekozen.

Region	Domain	IP Address
🇳🇱 Amsterdam	grpc-ams1.erpc.global	84.32.103.245
🇳🇱 Amsterdam	grpc-ams1.erpc.global	84.32.64.77
🇺🇸 New York	grpc-ny6-1.erpc.global	64.130.37.222
🇩🇪 Frankfurt	grpc-fra1-1.erpc.global	185.191.118.149
🇩🇪 Frankfurt	grpc-fra1-1.erpc.global	185.191.118.177
🇩🇪 Frankfurt	grpc-fra1-1.erpc.global	185.191.118.206
🇬🇧 London	grpc-lon6-1.erpc.global	67.209.52.250
🇯🇵 Tokyo	grpc-tokyo-6.erpc.global	198.13.133.88
🇸🇬 Singapore	grpc-sgp6-1.erpc.global	202.8.11.52
🇦🇺 Sydney	grpc-syd-1.erpc.global	82.26.116.36
🛰️ Far Point	grpc-far-point.erpc.global	63.254.162.14

Q. Ik heb mijn IP toegestaan, maar kan nog steeds niet verbinden. Wat moet ik controleren?

ERPC gRPC- en Shreds-endpoints gebruiken plain HTTP op poort 80, beschermd door IP-allowlisting. Ze gebruiken geen HTTPS/TLS op poort 443.

Als u een clientvoorbeeld van een andere provider kopieert, kan dat standaard :443 of HTTPS gebruiken. Alleen het domein vervangen kan de poort- en TLS-instellingen ongemoeid laten, waardoor de verbinding niet werkt.

De onderstaande endpoints zijn voorbeelden. Vervang ze door uw eigen endpoint dat in het dashboard wordt weergegeven. Gebruik het in HTTP-vorm, of geef poort 80 expliciet op als uw client host en poort vereist:

Reguliere gRPC

Niet geldig: grpc-fra1-1.erpc.global:443
Geldig: grpc-fra1-1.erpc.global:80
Geldige URL-vorm: http://grpc-fra1-1.erpc.global

Burst gRPC

Niet geldig: grpc-fra1-burst.erpc.global:443
Geldig: grpc-fra1-burst.erpc.global:80
Geldige URL-vorm: http://grpc-fra1-burst.erpc.global

Authenticatie gebeurt op basis van uw geregistreerde IP-adres. Voeg geen x-token-, token- of Authorization-headers toe voor ERPC gRPC- of Shreds-endpoints, tenzij een specifieke productpagina dit expliciet vermeldt.

V. Wat is Geyser gRPC Burst?

Geyser gRPC Burst is de gedeelde gRPC-tier met lage latentie van ERPC voor latentiegevoelige Solana-streamworkloads. Het biedt dezelfde Yellowstone/Geyser gRPC-interface als de reguliere gRPC-service, inclusief account-, transactie-, slot- en block-subscriptions, terwijl het Burst-specifieke regionale infrastructuur gebruikt.

Burst draait momenteel in Frankfurt, Amsterdam, New York, Tokyo en Singapore. Het systeem selecteert de best beschikbare Burst-regio voor uw geregistreerde IP op basis van echte latentiemetingen.

V. Welke IP's moet ik toestaan voor Burst gRPC?

Burst-routing meet de latency vanaf de hierboven genoemde reguliere gRPC-loadbalancer-IP's en koppelt daarna de dichtstbijzijnde ondersteunde regio aan een Burst-endpoint. Sta deze reguliere gRPC-pingbron-IP's toe voor latencyselectie en sta ook de onderstaande Burst-loadbalancer-IP's toe zodat uw client verbinding kan maken met het geselecteerde Burst-endpoint.

Region	Burst Domain	IP Address
🇩🇪 Frankfurt	grpc-fra1-burst.erpc.global	64.130.41.234
🇳🇱 Amsterdam	grpc-ams1-burst.erpc.global	64.130.55.180
🇺🇸 New York	grpc-ny6-burst.erpc.global	64.130.59.217
🇯🇵 Tokyo	grpc-tokyo-burst.erpc.global	208.91.107.247
🇸🇬 Singapore	grpc-singapore-burst.erpc.global	67.209.55.15

Als ICMP-antwoorden vanaf de reguliere gRPC-loadbalancer-IP's worden geblokkeerd, kan het dashboard 9999ms tonen en kan Burst terugvallen op een niet-optimale regio. Het blokkeren van de Burst-IP's beïnvloedt de verbinding met het geselecteerde Burst-endpoint.

V. Is Burst hetzelfde als Direct Shreds of ShredStream?

Nee. Burst is volledige Yellowstone/Geyser gRPC over de standaard gRPC-interface. Het is geschikt wanneer u block-, slot-, transactie- of account-streams van een gRPC-client nodig heeft.

Direct Shreds / ShredStream is een afzonderlijk, op UDP gebaseerd product voor ruwe shred-data en kan de voorkeur hebben wanneer het vroegst mogelijke pre-block datapad de prioriteit is. De twee producten bedienen verschillende interfaces en workloads.

V. Ik heb alleen WebSocket gebruikt. Kan ik gRPC gebruiken? Heeft u voorbeelden?

Ja. U kunt snel testen en beginnen met ontwikkelen met gRPC met behulp van SLV.

Voor een gedeeld endpoint dat u zonder token kunt testen, voert u uit:

bash

slv check grpc --endpoint <YOUR_ENDPOINT> --token none

slv check grpc --endpoint <YOUR_ENDPOINT> --token none

Bekijk onze gRPC Snelstart Handleiding voor details.

V. Kan ik twee IP-adressen registreren?

U kunt een endpoint per abonnement gebruiken. Als u twee IP-adressen wilt gebruiken, moet u twee afzonderlijke abonnementen afsluiten.

V. Zijn er filterbeperkingen?

Nee, er zijn geen beperkingen op filters.

V. Welke regio raden jullie aan?

Er is geen enkele permanent beste regio. Solana is wereldwijd, en de leader validator verandert elke slot. Regio's met meer validators en meer stake krijgen vaker leader slots, wat transacties sneller kan laten landen. De keerzijde is dat concurrerend verkeer zich daar ook concentreert, waardoor een minder drukke regio soms beter kan werken afhankelijk van uw strategie.

Kies als praktisch startpunt een validator-dichte regio zoals Frankfurt of de Amerikaanse oostkust wanneer een stabiele aanvoer van leader slots het belangrijkst is, of plaats uw infrastructuur dicht bij een specifieke target validator wanneer het kortste pad de prioriteit is. Gebruik Validators Solutions om de publieke Solana-netwerkverdeling te begrijpen, en gebruik daarna de ERPC Leader Slot API en echte metingen om te beslissen of single-region, dual-region of wereldwijde deployment passend is.

V. Ik heb een latentie van minimaal ~400ms of beter nodig.

Om latentie binnen ongeveer 400ms te bereiken, overweeg deze essentiele punten:

Realistisch begrip van pingwaarden: Pingwaarden geven ideale omstandigheden aan en weerspiegelen niet de werkelijke latentie in streamingcommunicatie, die doorgaans ongeveer 5 keer de pinglatentie bedraagt. Bijvoorbeeld, een ping van 100ms over continenten resulteert realistisch gezien in ongeveer 500ms latentie. Daarom moet infrastructuur in dezelfde regio worden opgezet om ~400ms latentie te bereiken.
- Typische pingwaarde-referentie:
  - Hetzelfde netwerk: ~0,1ms
  - Private Network Interconnect (PNI): ~0,2ms
  - Hetzelfde datacenter: ~0,3ms
  - Dezelfde stad: ~1ms
  - Buurland: ~5–10ms
  - Intercontinentaal: ~100–300ms
De valkuil van gemiddelde latentie vermijden: Solana validators zijn wereldwijd geografisch verspreid en het leaderschema verandert willekeurig bij elke epoch. Vertrouwen op gemiddelde latentie om ~400ms te bereiken is niet praktisch. In plaats daarvan moet u validatorschema's in uw specifieke regio nauwkeurig volgen om slots met de laagste latentie te identificeren. Om consequent minimale latentie te bereiken, is infrastructuur in alle relevante regio's vereist. Binnen dezelfde regio kan gegevensverzameling in tientallen milliseconden plaatsvinden, met transmissie in slechts enkele milliseconden.
Het leaderschema volgen: Monitor continu het leader validator-schema voor uw regio met behulp van de ERPC Leader Slot API (getLeaderSlots). Het biedt realtime gegevens over aankomende leaders, stake weight, validator-geolocaties en referentie-pingwaarden, waardoor u optimale handelsslots met minimale latentie nauwkeurig kunt identificeren. Publieke kaartgegevens en native RPC API's zijn nuttig voor een breed netwerkoverzicht, maar ze zijn niet nauwkeurig genoeg voor uitvoeringstiming. De Leader Slot API vult die leemte met de granulariteit die nodig is voor routerings- en handelsbeslissingen.
- ERPC Leader Slot API-documentatie
- ERPC Web Dashboard

Validators Solutions - Solana-netwerkdata

Solana-netwerkdata: Validators Solutions

V. Hoe kan ik zero-block (zero-slot) trading bereiken?

Succesvol zero-block (zero-slot) trading bereiken vereist meer geavanceerde strategieen, als volgt:

Kansenzones identificeren: Solana validators zijn wereldwijd verspreid en het is fysiek onmogelijk om optimale latentie voor elke slot te bereiken. Monitor daarom validator-leaderschema's in de regio waar uw infrastructuur zich bevindt en identificeer de gunstigste kansenzones. Het implementeren van infrastructuur in meerdere regio's kan ook voordelig zijn. Frankfurt is bijvoorbeeld een belangrijke regio vanwege de hoge validatordichtheid, wat resulteert in frequentere leaderselectie en meer handelsmogelijkheden.

Gebruik de ERPC Leader Slot API (getLeaderSlots) om realtime leaderschema's, stake weight, validator-geolocatiegegevens en referentie-pingwaarden te verkrijgen met veel grotere precisie dan publieke kaartgegevens of native RPC API's. Hiermee kunt u kansenzones nauwkeuriger voorspellen en bijna-nul-latentie trades uitvoeren.
- ERPC Leader Slot API-documentatie
- ERPC Web Dashboard
Dedicated nodes implementeren: Als u moeite heeft om te concurreren, overweeg dan dedicated nodes te implementeren. Gedeelde nodes ervaren latentie door verkeer van andere gebruikers en worden daarom niet aanbevolen. Bovendien vermindert het plaatsen van uw dedicated node binnen hetzelfde netwerk als uw applicatie de netwerklatentie aanzienlijk en optimaliseert het de prestaties.

V. Kan ik een specifiek endpoint gebruiken?

Om een omgeving met lage latentie te handhaven, selecteert ons systeem automatisch de dichtstbijzijnde beschikbare node. Als u een specifiek endpoint wilt gebruiken, raden we aan een server te huren die het dichtst bij dat endpoint staat.

V. Ik krijg een 401-fout. Waarom?

Om een omgeving met lage latentie te handhaven, implementeren we IP-beperkingen. Als u geen abonnement heeft of uw IP niet is geregistreerd, ontvangt u een 401-fout.

Controleer of uw geregistreerde IP overeenkomt met uw huidige toegangs-IP.

V. Ik krijg een 429-fout. Waarom?

U heeft de verbindingslimiet van uw plan bereikt.

Als u deze fout tegenkomt, overweeg dan uw plan te upgraden. Als u meer verbindingen nodig heeft dan ons premium plan biedt, is een dedicated gRPC-node geschikter.

V. Waarom zijn dedicated endpoints sneller?

Gedeelde endpoints worden door meerdere klanten gebruikt die dezelfde resources delen. Naarmate het verkeer toeneemt, treedt latentie op. Serverresources hebben fysieke limieten en de hoeveelheid werk die ze aankunnen is eindig. Wanneer te veel verzoeken tegelijkertijd binnenkomen, moeten ze sequentieel worden verwerkt, wat resulteert in tragere responstijden.

Hoewel we diverse maatregelen nemen om prestaties te optimaliseren, zelfs bij gedeelde endpoints, bent u bij dedicated endpoints de enige gebruiker van de resource. Dit betekent dat u volledig onbeinvloed bent door andere gebruikers, wat consistent stabiele en snelle reacties garandeert.

Bovendien bieden dedicated endpoints communicatieopties zonder TLS, zoals HTTP. Door de TLS-handshake (ongeveer 20ms) over te slaan, wordt communicatie nog sneller vergeleken met HTTPS.

V. Wordt de actieprijs verhoogd nadat ik me abonneer?

Zolang uw abonnement actief blijft, blijft de actieprijs die u bij inschrijving hebt vastgelegd van kracht. Omgevingen die Solana's real-time workload aankunnen zijn wereldwijd schaars, en we zijn van plan de lijstprijzen stapsgewijs te verhogen naarmate hardware- en netwerkvraag groeit. Configuraties met hogere specs en regio's met veel vraag raken het snelst uitverkocht, dus de huidige promotieprijs vastleggen is op lange termijn meestal de meest kostenefficiente keuze.

V. Ik wil betalen met crypto

Crypto-betalingen zijn nu beschikbaar via het ERPC Web Dashboard. U kunt SOL, USDC of EURC gebruiken om ERPC Credits te kopen.

Gebruik die ERPC Credits om ERPC-plannen te activeren of voort te zetten. Open het dashboard, kies crypto payment, verstuur de betaling vanuit uw wallet, en het dashboard verifieert de transactie en voegt de credits toe aan uw account.

ERPC Web Dashboard

V. Hoe kan ik de laagst mogelijke latentie bereiken?

We raden sterk aan een dedicated gRPC-node te combineren met onze Bare-Metal server.

Beide delen hetzelfde netwerk, wat prive communicatie op nulafstand mogelijk maakt zonder over het internet te hoeven gaan. Deze setup bereikt extreem lage latentie, doorgaans rond 0,1ms ping.

Neem contact met ons op via het ERPC Web Dashboard voor meer details.

ERPC Web Dashboard

🔗 ERPC Web Dashboard

V. Hoe is de latentie?

Latentie varieert afhankelijk van de meetmethode en uw specifieke gebruiksomgeving. In plaats van te focussen op exacte numerieke waarden, is het cruciaal om ervoor te zorgen dat de latentie voldoet aan uw werkelijke operationele vereisten.

We bieden gratis proefperiodes voor al onze plannen, zodat u de prestaties direct in uw eigen omgeving kunt testen. Daarnaast bieden we gebruiksvriendelijke tools in TypeScript en Rust voor het meten van latentie. Maak gerust gebruik van deze tools naast uw gratis proefperiode.

V. Is deze RPC (gRPC, Shreds) sneller dan anderen?

We moedigen u aan onze gratis proefperiode te proberen en de prestaties te vergelijken met andere services. Als u onze service trager vindt, laat het ons dan weten via het ERPC Web Dashboard met de specifieke omstandigheden en concurrenten waarmee u heeft vergeleken. We zullen de oorzaak identificeren en de snelheid verder verbeteren.

We werken continu aan het verbeteren van latentie op basis van klantfeedback. Als u het snelste mogelijke endpoint zoekt, deel dan gedetailleerde informatie met ons. Het verstrekken van specifieke metrics en vergelijkingsomstandigheden met concurrenten stelt ons in staat superieure prestaties te leveren. Deze feedbackgedreven aanpak heeft ons consequent in staat gesteld onze services te verbeteren.

ERPC Web Dashboard

V. Welk plan biedt de snelste prestaties?

Over het algemeen biedt ons plan op het hoogste niveau de snelste prestaties dankzij superieure CPU's, hogere geheugencapaciteiten en robuuste hardwareconfiguraties.

We bieden ook maatwerkoplossingen als u nog krachtigere servers nodig heeft, maar onze standaardplannen zijn ontworpen om optimale prijs-prestatieverhoudingen te leveren.

We zijn ervan overtuigd dat we prestaties van wereldklasse bieden op elk prijsniveau. Als u een snellere provider vindt binnen hetzelfde prijsbereik, laat het ons weten zodat we kunnen onderzoeken en verbeteringen kunnen aanbrengen.

V. Ik ervaar hoge latentie. Wat kan ik doen?

Latentie hangt sterk af van uw nabijheid tot het endpoint. We raden aan om toegang te krijgen vanaf een server dicht bij het aangeboden endpoint. De snelste verbindingen worden bereikt met onze Bare-Metal server en VPS-service.

V. Wat is het snelst: WebSockets, gRPC of Shreds?

Feedback van onze klanten rangschikt de snelheid consistent als volgt:

Shreds > gRPC > WebSockets

Deel uw ervaring als u andere resultaten waarneemt.

V. De latentie is niet wat ik verwachtte.

Prestaties varieren afhankelijk van de gebruikte programmeertaal. Over het algemeen rangschikt de snelheid van talen als volgt:

Rust > Go > TypeScript (JavaScript) > Python

Voor gedetailleerde vergelijkingen, zie:

Snelheidsvergelijking programmeertalen

Voor maximale prestaties raden we sterk aan Rust te gebruiken.