--- title: "FAQ - Solana RPC endpoints ERPC" description: "Réponses sur les endpoints RPC Solana ERPC, la création d'un endpoint Solana, WebSocket, régions, latence et erreurs." canonical: "https://erpc.global/fr/faq/rpc/general/" locale: "fr" --- # FAQ - Solana RPC endpoints ERPC Les questions sur la facturation, le forfait Gratuit, le paiement et les erreurs 401 ou 429 se trouvent dans [Comment démarrer](https://erpc.global/fr/faq/how-to-start/general/). Les questions sur la distance, la vitesse et les régions se trouvent dans [Latence et régions](https://erpc.global/fr/faq/latency/general/). ## Q. Qu'est-ce qu'un endpoint Solana RPC et comment en obtenir un avec ERPC? Un endpoint Solana RPC est l'URL qu'utilise votre application, votre bot de trading, votre wallet ou votre système d'analyse pour envoyer des requêtes JSON-RPC à Solana et recevoir les données de la chaîne. Avec ERPC, vous obtenez un endpoint Solana géré qui prend en charge l'accès HTTP et WebSocket via le même réseau mondial de proxys. Pour commencer, créez ou ouvrez votre compte ERPC dans l'[ERPC Web Dashboard](https://dashboard.erpc.global/fr), copiez votre API key et ajoutez-la au paramètre `api-key` de l'URL de l'endpoint: ```text https://edge.erpc.global?api-key= ``` Utilisez le même format d'API key pour les abonnements WebSocket: ```text wss://edge.erpc.global?api-key= ``` ## Q. Puis-je utiliser WebSocket? Oui, WebSocket est pris en charge sur le même endpoint, ce qui permet de recevoir efficacement des mises à jour de données en temps réel. ## 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) - New York (NY) - Tokyo (TY) - Singapour (SGP) Les endpoints RPC d'ERPC s'appuient sur Cloudflare et son réseau mondial de plus de 300 serveurs edge. Les requêtes sont automatiquement acheminées vers l'edge Cloudflare le plus proche, puis transmises au nœud ERPC optimal afin d'emprunter le chemin réseau le plus court possible et de maintenir une latence faible partout dans le monde. Cette architecture élimine l'impact de la distance géographique et des routages complexes, et offre une connectivité toujours optimisée aux nœuds Solana, avec une stabilité et des performances maximales. ERPC Web Dashboard: [ERPC Web Dashboard](https://dashboard.erpc.global/fr) ## Q. Pourquoi des blocs ou transactions Solana plus anciens sont-ils manquants, ou pourquoi vois-je -32011? À l'exception de `getTransactionsForAddress`, une requête sans `history=true` est traitée à partir de la plage récente que détient chaque nœud ; les blocs ou transactions plus anciens peuvent donc renvoyer l'erreur `This request needs history access. Add history=true to the endpoint URL.` (code `-32011`), `null` ou un résultat vide, selon la méthode. Ajoutez `history=true` à l'URL `https://edge.erpc.global` d'une requête HTTP pour les demander. Envoyez l'API key dans l'URL : ```text https://edge.erpc.global?api-key=&history=true ``` Ou envoyez-la dans l'en-tête `Authorization: Bearer ` et conservez `history=true` dans l'URL : ```text https://edge.erpc.global?history=true ``` Une recherche de blocs ou de transactions plus anciens peut prendre beaucoup plus de temps qu'une requête ordinaire, parfois plusieurs secondes. History Access est une option distincte qui sépare ces recherches des requêtes ordinaires, afin que celles-ci restent rapides. À l'exception de `getTransactionsForAddress` en mode `"full"`, chaque appel traité par History Access coûte 640 tokens de plus que le prix habituel de sa méthode. Les allocations gratuites, y compris celles du forfait Free, ont une limite pour History Access. Le forfait Free est limité à une requête avec History Access toutes les 10 secondes. Sans `history=true`, `getTransactionsForAddress` avec `transactionDetails` défini sur `"full"` renvoie la même erreur `-32011`, quel que soit l'âge des données ; la documentation ERPC en donne le prix. [Documentation ERPC : RPC](https://erpc.global/fr/doc/rpc/general/) ## 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 { "maxSupportedTransactionVersion": 1 } ``` 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](https://github.com/ValidatorsDAO/solana-stream/blob/main/docs/transaction-v1.md) - [Notes de version du SDK 2.0.0](https://github.com/ValidatorsDAO/solana-stream/releases/tag/v2.0.0) - [Dépôt du Solana Stream SDK](https://github.com/ValidatorsDAO/solana-stream) - [SIMD-0385 : Transaction v1 — la proposition](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md) - [Upgrade de Solana : Larger Transaction Sizes](https://solana.com/upgrades/larger-transaction-sizes) - [Documentation RPC de Solana : getBlock](https://solana.com/docs/rpc/http/getblock) - [Documentation RPC de Solana : getTransaction](https://solana.com/docs/rpc/http/gettransaction) - [Documentation ERPC : démarrage rapide de ShredStream](https://erpc.global/fr/doc/shredstream/quickstart/) - [Documentation ERPC : démarrage rapide de Geyser gRPC](https://erpc.global/fr/doc/geyser-grpc/quickstart/) - [Documentation ERPC : RPC](https://erpc.global/fr/doc/rpc/general/) ## Q. Quelles méthodes Unlimited Endpoint prend-il en charge ? Les Unlimited Endpoints sont conçus pour les appels Solana RPC standard à faible latence. Les méthodes prises en charge sont : - `getSlot` - `getBlockHeight` - `getLatestBlockhash` - `getBalance` - `getAccountInfo` - `getMultipleAccounts` - `getTransaction` - `sendTransaction` - `simulateTransaction` - `getSignatureStatuses` - `getRecentPrioritizationFees` - `getHealth` - `getVersion` - `getEpochInfo` - `getBlock` Pour les autres méthodes, utilisez `https://edge.erpc.global?api-key=`. ## Q. Les transactions sur mon nœud dédié ont un faible taux de succès Les taux de réussite et la vitesse des transactions sont considérablement affectés par un mécanisme appelé QoS (Quality of Service). Nous proposons une QoS spécifique pour les nœuds dédiés. Pour plus de détails, veuillez consulter les pages ci-dessous ou nous contacter via notre ERPC Web Dashboard. - [QoS pour les nœuds dédiés (ERPC)](https://erpc.global/fr/staked-connection/) - [Un guide de la Quality of Service pondérée par le stake sur Solana](https://solana.com/developers/guides/advanced/stake-weighted-qos) ## Q. Comment puis-je obtenir la latence la plus faible possible? La configuration idéale pour la latence minimale est un nœud RPC dédié combiné avec nos [serveurs bare metal](https://erpc.global/fr/baremetal/). Les deux partagent le même réseau, ce qui permet une communication privée à distance zéro avec des pings d'environ 0,1 ms. Veuillez nous contacter via l'ERPC Web Dashboard pour plus de détails. [ERPC Web Dashboard](https://dashboard.erpc.global/fr)