FAQ - Solana Shreds
Q. Ma sortie Shreds / getBlock semble soudain cassée ou renvoie -32015 — qu'est-ce qui a changé?
Solana Transaction v1 (SIMD-0385) est entré en vigueur sur le mainnet Solana le 15 septembre 2026, à l'epoch 1035. Le format wire d'une transaction v1 commence par l'octet de préfixe de version
0x81, les signatures viennent après le message, et il n'y a plus de préfixe de longueur legacy.Si vous décodez vous-même les entries ShredStream ou UDP Forwarding, un décodeur
bincode ou solana-entry antérieur à la version 4.2 interprète cet octet 0x81 comme un nombre de signatures, ce qui se manifeste par une erreur EOF, un dépassement de compact-length ou une erreur "invalid message version". Les utilisateurs Geyser gRPC qui désérialisent des transactions brutes avec des crates antérieures à 4.2 rencontrent le même problème. Les appels RPC getBlock et getTransaction avec maxSupportedTransactionVersion: 0 renvoient -32015 Transaction version (1) is not supported by the requesting client ; getTransactionsForAddress en mode full signale la même erreur sur chaque ligne concernée. Vous n'êtes pas concerné si vous lisez déjà les réponses JSON parsées d'ERPC avec la version 1 activée.Définissez
maxSupportedTransactionVersion à 1 dans l'objet d'options — le second paramètre de getBlock et getTransaction, ainsi que dans les options de getTransactionsForAddress :json
Mettez à jour le Solana Stream SDK vers
2.0.0 : solana-stream-sdk en Rust sur crates.io, ou @validators-dao/solana-stream-sdk et @validators-dao/solana-shreds-client sur npm. Mettez à jour @validators-dao/solana-entry-decoder séparément vers 2.5.0. 1.4.0 et entry-decoder 2.4.0 ne prennent pas en charge v1. Vos propres décodeurs Rust devraient passer à solana-entry 4.2.x.- Guide de migration
- Notes de version du SDK 2.0.0
- Dépôt du Solana Stream SDK
- SIMD-0385 : Transaction v1 — la proposition
- Upgrade de Solana : Larger Transaction Sizes
- Documentation RPC de Solana : getBlock
- Documentation RPC de Solana : getTransaction
- Documentation ERPC : démarrage rapide de ShredStream
- Documentation ERPC : démarrage rapide de Geyser gRPC
- Documentation ERPC : RPC
Q. Dans quelles régions se trouvent vos nœuds?
Nous opérons actuellement des nœuds dans les régions suivantes:
- Francfort (FRA)
- Amsterdam (AMS)
- Londres (LON)
- Dublin (DUB)
- New York (NY)
- Chicago (CHI)
- Salt Lake City (SLC)
- Tokyo (TY)
- Singapour (SGP)
- Sydney (SYD)
ERPC mesure la latence réelle du réseau à partir des chemins de routage effectifs et sélectionne automatiquement la région offrant la latence la plus faible, plutôt que de se fier à la distance à vol d'oiseau. Cette approche améliore non seulement la latence pour chaque utilisateur, mais aussi l'efficacité globale du réseau, et renforce la résilience mondiale d'ERPC face aux attaques potentielles.
Si votre environnement ne sélectionne pas automatiquement la région optimale, veuillez nous contacter via l'ERPC Web Dashboard.
ERPC Web Dashboard: https://dashboard.erpc.global/fr
Q. La latence affiche 9999 ms et une région non optimale est sélectionnée. Que dois-je faire ?
Pour la sélection de région de Shreds, ERPC envoie des sondes de latence ICMP à votre adresse IP enregistrée depuis les hôtes proxy répertoriés ci-dessous. Autorisez les requêtes d’écho ICMP entrantes provenant de chaque adresse IP source répertoriée. Si elles sont bloquées par un pare-feu (ufw, pare-feu cloud, groupe de sécurité, etc.), la mesure peut atteindre
9999ms et une région non optimale peut être sélectionnée. Plusieurs adresses IP dans une même région correspondent à des hôtes de sonde distincts ; elles sont toutes requises.Far Point sélectionné
Le Far Point de Shared Shreds est une solution de repli à capacité limitée. Chaque endpoint prend en charge jusqu’à 32 flux simultanés transmis par proxy, tous clients confondus—et non 32 places par client. Le streaming est le plus efficace lorsque l’abonné s’exécute à proximité de l’endpoint Shreds sélectionné ; les flux longue distance mobilisent plus longtemps les connexions partagées, les fenêtres de contrôle de flux et la capacité de sortie. Pour contribuer à préserver la réactivité de l’environnement partagé, autorisez toutes les adresses IP sources des sondes ICMP régionales indiquées, puis relancez la sélection de région. Pour une utilisation continue, envisagez un ERPC VPS proche de l’endpoint sélectionné. UDP Forwarding est disponible en Standard et en Premium. Dans les deux cas, vous choisissez la région d’UDP Forwarding dans l’ERPC Web Dashboard et recevez les Raw Shreds en UDP à l’adresse IPv4 publique et au port que vous configurez.
Utiliser un ERPC VPS près de cet endpoint · Comparer les options d’UDP Forwarding
Lire le guide de démarrage rapide de Solana Shreds
Q. J'ai autorisé mon IP, mais je n'arrive toujours pas à me connecter. Que dois-je vérifier ?
Utilisez l’endpoint HTTPS chiffré sélectionné dans le dashboard. HTTPS utilise le port 443 ; HTTP sur le port 80 reste l’option non chiffrée à faible latence.
Les deux transports utilisent la même allowlist d’IP enregistrées. Utilisez l’endpoint sélectionné dans le dashboard : HTTPS sur 443 ou HTTP sur 80.
- Endpoint HTTPS : utilisez l’endpoint sélectionné dans le dashboard sur le port 443.
- Endpoint HTTP : utilisez l’endpoint sélectionné dans le dashboard sur le port 80.
- Utilisez l’URL affichée dans le dashboard avec
https://ouhttp://.
L'authentification se fait par votre adresse IP enregistrée. N'ajoutez pas d'en-têtes
x-token, token ou Authorization sauf indication explicite sur une page produit spécifique.Q. Je n'ai utilisé que WebSocket ou Geyser gRPC (YellowStone) jusqu'ici. Avez-vous des exemples ?
Oui. Vous pouvez rapidement commencer à tester les connexions Shreds et le développement d'applications en utilisant SLV.
Veuillez consulter le guide suivant pour plus de détails:
Q. Puis-je enregistrer deux adresses IP?
Vous pouvez utiliser un endpoint par abonnement. Si vous souhaitez utiliser deux adresses IP, vous devez souscrire deux abonnements distincts.
Q. Quelle région recommandez-vous?
Il n'existe pas de région qui soit la meilleure en permanence. Solana est un réseau mondial, et le rôle de leader passe d'un validateur à l'autre selon le planning des leaders. Les régions avec davantage de validateurs et un stake plus élevé obtiennent plus souvent des slots leaders, ce qui peut aider les transactions à être confirmées plus vite. En contrepartie, le trafic concurrent s'y concentre aussi; une région moins saturée peut donc parfois donner de meilleurs résultats selon votre stratégie.
Comme point de départ, choisissez une région dense en validateurs, comme Francfort ou la côte Est des États-Unis, lorsque la disponibilité régulière de slots leaders compte le plus. Placez-vous plutôt près d'un validateur cible précis lorsque l'exécution par le chemin le plus court est prioritaire. Utilisez Validators Solutions pour comprendre la distribution publique du réseau Solana, puis l'ERPC Leader Slot API et des mesures réelles pour décider si un déploiement mono-région, bi-région ou global est approprié.
Q. J'ai besoin d'une latence d'environ 400 ms ou moins.
Pour atteindre une latence d'environ 400 ms ou moins, tenez compte de ces points essentiels:
-
Compréhension réaliste des valeurs du ping: Les valeurs de ping indiquent des conditions idéales et ne reflètent pas la latence réelle des communications en streaming, qui est généralement de l'ordre de cinq fois la latence du ping. Par exemple, un ping de 100 ms entre continents se traduit en pratique par environ 500 ms de latence. Ainsi, des infrastructures doivent être mises en place dans la même région pour atteindre ~400 ms de latence.
- Références typiques de ping:
- Même réseau: ~0,1 ms
- Interconnexion réseau privée (PNI): ~0,2 ms
- Même centre de données: ~0,3 ms
- Même ville: ~1 ms
- Pays voisin: ~5–10 ms
- Intercontinental: ~100–300 ms
- Références typiques de ping:
-
Éviter le piège de la latence moyenne: Les validateurs de Solana sont dispersés géographiquement à l'échelle mondiale, et le planning des leaders change de façon aléatoire à chaque époque. Il n'est pas réaliste de s'appuyer sur la latence moyenne pour atteindre ~400 ms. Au lieu de cela, vous devriez suivre précisément les plannings des validateurs dans votre région spécifique pour identifier les slots avec la latence la plus basse. Pour obtenir une latence minimale de façon constante, il faut une infrastructure dans toutes les régions concernées. Dans la même région, l'acquisition de données peut se faire en dizaines de millisecondes, la transmission étant possible en quelques millisecondes seulement.
-
Suivi du planning des leaders: Surveillez le planning des validateurs leaders de votre région avec l'ERPC Leader Slot API (
getLeaderSlots). Elle renvoie le planning des prochains leaders, le poids de stake de l'époque en cours, la géolocalisation estimée des validateurs et des valeurs de ping de référence, pour que vous puissiez identifier les slots offrant la latence la plus faible et les cibler avant qu'ils n'arrivent. Les données publiques de type carte et les API RPC natives sont utiles pour obtenir une vue d'ensemble du réseau, mais elles ne sont pas assez précises pour le timing d'exécution. La Leader Slot API comble cette lacune avec la granularité nécessaire pour le routage et les décisions de trading.
Données du réseau Solana: Validators Solutions
Q. Comment puis-je réaliser le trading zero-block (zero-slot)?
Réussir le trading zero-block (zero-slot) nécessite des stratégies plus sophistiquées, comme suit:
-
Identification des zones d'opportunité: Les validateurs Solana sont répartis dans le monde entier, et il est physiquement impossible d'obtenir une latence optimale sur chaque slot. Par conséquent, surveillez les plannings des validateurs leaders dans la région où se trouve votre infrastructure et identifiez les zones d'opportunité les plus favorables. Le déploiement d'infrastructures dans plusieurs régions peut également être avantageux. Par exemple, Francfort est une région clé en raison de sa forte densité de validateurs, ce qui entraîne une sélection plus fréquente des leaders et de meilleures opportunités de trading.Utilisez l'ERPC Leader Slot API (
getLeaderSlots) pour consulter le planning des prochains leaders, le poids de stake de l'époque en cours, des données de géolocalisation estimée des validateurs et des valeurs de ping de référence, avec une précision bien supérieure à celle des sources de données publiques de type carte ou des API RPC natives. Vous pouvez ainsi cartographier les zones d'opportunité avant l'arrivée des slots et exécuter des trades à latence quasi nulle. -
Mise en œuvre des nœuds dédiés: Si vous avez du mal à rivaliser, envisagez de déployer des nœuds dédiés. Les nœuds partagés subissent la latence générée par le trafic d'autres utilisateurs et ne sont donc pas recommandés. De plus, placer votre nœud dédié dans le même réseau que votre application réduit considérablement la latence du réseau et optimise les performances.
Q. Puis-je utiliser un endpoint spécifique?
Pour maintenir un environnement à faible latence, notre système sélectionne automatiquement le nœud disponible le plus proche. Si vous souhaitez utiliser un endpoint spécifique, nous vous recommandons de louer un serveur situé au plus près de cet endpoint.
Q. Pourquoi les endpoints dédiés sont-ils plus rapides?
Les endpoints partagés sont utilisés par plusieurs clients qui se partagent les mêmes ressources. Lorsque le trafic augmente, de la latence a tendance à apparaître. Les ressources serveur ont des limites physiques, et la quantité de travail qu'elles peuvent traiter est finie. Lorsque trop de requêtes arrivent en même temps, elles doivent être traitées l'une après l'autre, ce qui ralentit les temps de réponse.
Même si nous prenons diverses mesures pour optimiser les performances, y compris sur les endpoints partagés, avec un endpoint dédié vous êtes l'unique utilisateur de la ressource. Vous n'êtes donc aucunement affecté par les autres utilisateurs, ce qui garantit des réponses toujours stables et rapides.
Les endpoints dédiés offrent aussi des options de communication sans TLS, comme HTTP. En évitant le handshake TLS (environ 20 ms), la communication devient encore plus rapide qu'en HTTPS.
Q. Mon prix augmentera-t-il après mon abonnement?
Tant que votre abonnement reste actif, le prix obtenu à l'inscription reste appliqué. Les environnements capables d'encaisser les charges temps réel de Solana sont rares à l'échelle mondiale, et nous prévoyons de relever progressivement les prix à mesure que la demande en matériel et en réseau augmente. Les configurations haut de gamme et les régions très demandées partent le plus vite; sécuriser le prix actuel est donc le choix le plus rentable à long terme.
Q. Je veux payer en crypto
Les paiements en crypto sont disponibles depuis l'ERPC Web Dashboard lorsque le pays de votre adresse de facturation enregistrée fait partie des pays membres de l'UE. Si toutes les cartes de paiement enregistrées sur votre compte ont été émises hors de l'UE, les paiements en crypto ne sont pas disponibles. Vous pouvez utiliser SOL, USDC ou EURC pour acheter des ERPC Credits.
Utilisez ces ERPC Credits pour activer ou continuer les plans ERPC. Ouvrez le dashboard, choisissez le paiement crypto, effectuez le transfert depuis votre wallet, puis le dashboard vérifiera la transaction et créditera votre compte.
Pays pris en charge : Allemagne, Autriche, Belgique, Bulgarie, Chypre, Croatie, Danemark, Espagne, Estonie, Finlande, France, Grèce, Hongrie, Irlande, Italie, Lettonie, Lituanie, Luxembourg, Malte, Pays-Bas, Pologne, Portugal, Roumanie, Slovaquie, Slovénie, Suède, Tchéquie.
Pour les pays qui ne figurent pas dans cette liste, veuillez payer par carte bancaire.
Q. Pourquoi ShredStream n'inclut-il pas toutes les transactions?
Par conception, Shreds n'inclut pas toutes les transactions de la blockchain Solana. Le suivi de toutes les transactions nécessiterait le déploiement de nombreux proxys à l'échelle mondiale et la réception de Shreds en provenance de chaque validateur, ce qui n'est pas pratique.
Généralement, les utilisateurs fonctionnent avec un sous-ensemble des données disponibles, car cette approche est suffisante pour la plupart des applications du monde réel. Si votre cas d'utilisation exige une couverture complète des données sans perte, Shreds pourrait ne pas être approprié.
Pour les scénarios nécessitant une surveillance plus complète, Geyser gRPC offre une fiabilité plus élevée que Shreds. Cependant, pour obtenir une couverture de 100 % des données de la blockchain Solana, il faut toujours déployer de nombreux serveurs edge, ce qui n'est peut-être pas réaliste dans la pratique.
Geyser gRPC offre une fiabilité supérieure à 99 %, nettement plus élevée que celle de Shreds, un fait confirmé par de nombreux utilisateurs, y compris nous. Shreds offre toutefois généralement une fiabilité supérieure à 90 %.
Même s'ils ne capturent pas toutes les transactions, leur principal avantage est de récupérer la plupart des transactions plus rapidement que Geyser gRPC.
Pour une compréhension plus approfondie, nous vous recommandons d'explorer les protocoles Turbine et Gulf Stream de Solana:
- Gulf Stream: le protocole de transfert de transactions sans mempool de Solana
- Turbine — le protocole de propagation des blocs de Solana résout le trilemme de la scalabilité
Q. Je veux le meilleur environnement possible.
UDP Forwarding est disponible en Standard et en Premium. Les deux livrent les Shreds à votre récepteur depuis la région de votre choix. Avec Standard, ERPC les transfère depuis un nœud situé dans cette région, de sorte qu’ils vous parviennent depuis une seule IP source. Avec Premium, le réseau maillé transmet, pour chaque Shred, la copie qui lui parvient en premier. Dans les deux cas, choisissez votre région dans l’ERPC Web Dashboard et configurez l’adresse IPv4 publique et le port qui doivent recevoir les Raw Shreds.
Veuillez nous contacter via l'ERPC Web Dashboard pour plus de détails.
Q. Qu'en est-il de la latence?
La latence varie selon la méthode de mesure et votre environnement d'utilisation spécifique. Plutôt que de se concentrer sur des valeurs numériques exactes, il est crucial de s'assurer que la latence répond à vos besoins opérationnels réels.
Nous fournissons des outils simples en TypeScript et Rust pour mesurer la latence.
Q. Ce RPC (gRPC, Shreds) est-il plus rapide que les autres?
Nous concevons chaque niveau d'offre pour la vitesse, et nous sommes heureux d'être comparés côte à côte avec n'importe quel autre fournisseur. Les résultats peuvent varier selon la région, selon que vous utilisez un endpoint partagé ou dédié, selon le protocole (WebSockets, gRPC ou Shreds) et selon le langage de programmation de votre client.
Si notre service vous semble plus lent, indiquez-nous via l'ERPC Web Dashboard les conditions précises et les concurrents auxquels vous l'avez comparé. Nous en identifierons la cause et améliorerons encore la vitesse.
Q. Quel plan est le plus rapide?
En général, notre plan le plus haut de gamme offre les meilleures performances grâce à des CPU plus puissants, davantage de mémoire et des configurations matérielles plus robustes.
Nous proposons aussi des solutions personnalisées si vous avez besoin de serveurs encore plus puissants, mais nos plans standard sont conçus pour offrir un rapport prix/performance optimal.
Nous sommes convaincus d'offrir des performances de classe mondiale à chaque niveau de prix. Si vous trouvez un fournisseur plus rapide dans la même gamme de prix, merci de nous le signaler afin que nous puissions analyser la situation et apporter des améliorations.
Q. J'ai une latence élevée. Pourquoi?
La latence augmente significativement avec la distance jusqu'à l'endpoint. Nous vous recommandons d'accéder depuis un serveur situé au plus près de l'endpoint fourni. Les environnements les plus rapides sont disponibles via nos serveurs bare metal et nos services VPS.
Q. Quel est le plus rapide: WebSockets, gRPC ou Shreds?
Sur la base des commentaires des clients, l'ordre de performance est le suivant:
Shreds > gRPC > WebSockets
Si votre expérience diffère, veuillez nous en informer.
Q. La latence ne correspond pas à mes attentes.
La performance varie considérablement selon le langage de programmation utilisé. En général, l'ordre de performance est le suivant:
Rust > Go > TypeScript (JavaScript) > Python
Pour des comparaisons détaillées, voir:
Nous recommandons vivement Rust pour obtenir les meilleures performances.