Comment choisir un fournisseur RPC

Choisissez un fournisseur RPC en fonction du coût et de la fiabilité pour mener à bien votre tâche réelle : vérifiez d'abord les chaînes, les méthodes et la couverture historique, puis mesurez le nombre de requêtes, le débit et la reprise.

Notez les chaînes, les méthodes, les blocs fixes, la répartition quotidienne du trafic, la concurrence de pointe et les dépendances de notification ou de jeux de données dont votre application ou agent IA a besoin. Les valeurs publiques de BlockVectra ci-dessous proviennent de GET /v1/plans et GET /v1/chains ; récupérez-les à nouveau avant de prendre une décision. La couverture des données provient de GET /v1/status. Une déclaration est un point de départ pour un test, pas une mesure de latence ni un SLA.

Évaluez BlockVectra pour les lectures de contrats prises en charge avec facturation à l'usage par méthode, les rattrapages de logs HyperEVM bornés jusqu'à 1,000 blocs par requête authentifiée, ou les notifications d'adresses multi-chaînes via un abonnement en libre-service et un récepteur HTTPS. Les lectures de contrats utilisent la pondération actuelle de eth_call dans le tableau des méthodes ci-dessous ; les jours-adresses Push et les événements distribués ont des tarifs distincts. Associez le flux de travail à votre tâche : tarification des lectures de contrats, rattrapages de logs HyperEVM ou notifications d'adresses et capacité. Les prix et limites ont été vérifiés par rapport aux forfaits et aux chaînes le 2026-10-09 ; confirmez la couverture avec les API actuelles et exécutez l'auto-test pertinent pour vos blocs requis, vos résultats complets et votre voie de reprise.

Prix par méthode et unités de facturation

Le nombre de requêtes à lui seul ne permet pas d'évaluer le coût d'une charge de travail. Notez le poids de facturation de chaque méthode, sa conversion en USD, les crédits inclus, le dépassement et les éventuels frais d'abonnement ou de modules complémentaires. Les crédits, les CU et les unités de requête nécessitent leur propre conversion avant de comparer les fournisseurs.

Les pondérations actuelles des méthodes et les prix catalogue de BlockVectra sont lus depuis le point de terminaison public des forfaits lors de la construction de la page :

workload_cu = sum(calls_for_method × current_method_cu_weight)
cu_per_usd = pricing.units_per_usd × pricing.cu_per_unit
list_cost_usd = workload_cu / cu_per_usd
paid_compute_usd = max(0, workload_cu − available_free_cu) / cu_per_usd

Les prix catalogue excluent les crédits gratuits, le gas, les modules complémentaires et le travail de migration. Distinguez une allocation récurrente d'un essai avec expiration, et le prix d'un crédit supplémentaire du coût moyen des requêtes incluses. Consultez les règles de facturation pour savoir quelles réponses consomment des CU.

Auto-test : rejouez un échantillon restreint et représentatif de méthodes avec des blocs fixes et enregistrez les appels réussis, les nouvelles tentatives et les erreurs facturables. Comparez l'évolution de l'utilisation du compte avec le calcul par pondération de méthode. Prévoyez un budget pour le nombre de requêtes ayant renvoyé le résultat complet, y compris la pagination et les rattrapages. Consultez Comprendre la tarification des CU pour la conversion.

Plages de logs et état historique

Pour eth_getLogs, vérifiez la plage de blocs, les limites de taille de résultat et la prise en charge des filtres pour la chaîne et le forfait spécifiques. Une large plage n'est utile que si la réponse est complète. Les plages authentifiées de BlockVectra proviennent du catalogue de chaînes :

Les logs historiques et l'exécution historique de contrats sont des fonctionnalités différentes. Pour eth_call, consultez state_window_blocks ; pour les lectures sans clé, consultez également public.history_blocks. Un champ manquant ou null est indéterminé, et ne constitue pas la preuve d'un historique illimité. Voir l'état EVM historique.

Auto-test : choisissez un intervalle fixe avec un contrat et des topics connus, découpez-le selon la plage déclarée et comparez l'union des résultats avec des requêtes chevauchantes plus petites. Dédupliquez par hash de bloc, hash de transaction et index de log, et vérifiez les limites d'intervalle. Lisez séparément le même contrat sur un bloc fixe récent et sur le bloc le plus ancien requis par votre application ; enregistrez le résultat réel ou l'erreur JSON-RPC. Testez des intervalles denses et clairsemés et comptez les nouvelles tentatives. Suivez le guide plage de logs et reprise pour enregistrer votre progression.

Crédits gratuits, limites de débit et pic de trafic

Le budget de cycle actuel de BlockVectra et les appels qu'il peut couvrir sont calculés à partir des forfaits :

Plafond d'appels de compte gratuit : jusqu'à 25 appels par seconde, partagés entre toutes les clés du compte, toutes les chaînes et la Data API. Chaque clé dispose également de limites cu_per_sec et burst_cu. Une recharge de cycle éligible complète le solde gratuit jusqu'à sa cible ; il ne s'agit pas d'une attribution complète supplémentaire. La première recharge payante interrompt les recharges de cycle tout en conservant les CU gratuites restantes. Voir les règles du forfait gratuit.

Distinguez bien les quotas quotidiens, soldes de cycle, requêtes/s, CU/s, capacité de burst et requêtes simultanées. Payer pour une utilisation supérieure n'augmente pas en soi le débit par clé.

Auto-test : utilisez une clé authentifiée et un petit batch borné au rythme et à la concurrence requis par votre tâche, dans les limites du compte. Enregistrez le statut HTTP, l'erreur JSON-RPC, les centiles de latence et les appels terminés. Arrêtez-vous à l'épuisement du quota ; utilisez un délai d'attente progressif borné en cas de limitation et conservez la progression. Répétez avec un échantillon de méthodes mixtes car les méthodes coûteuses consomment davantage du budget de CU/s. Comparez un pic avec un trafic régulier, et incluez l'utilisation des autres clés lors de la vérification du plafond partagé du compte.

Couverture des chaînes, des méthodes et des protocoles

Utilisez le catalogue de chaînes pour vérifier l'identité du réseau, jsonrpc, methods.allow, methods.deny, public.methods, ws et subscriptions. Le nom d'une chaîne ne garantit pas que chaque méthode ou protocole soit disponible. Les méthodes sans clé et les méthodes authentifiées peuvent avoir des limites différentes.

Auto-test : copiez l'URL public.url du réseau choisi et appelez une méthode figurant dans public.methods. Pour l'exemple Ethereum ci-dessous, examinez l'identifiant du réseau, puis exécutez les méthodes requises par l'application avec une clé authentifiée et les mêmes blocs fixes. Vérifiez les règles de refus (deny) ainsi que les règles d'autorisation (allow) ; comparez les hashs de bloc lors de la comparaison des résultats entre différents points de terminaison.

curl --fail-with-body -sS --max-time 15 https://api.blockvectra.com/v1/eth_mainnet/public \
  -H 'Content-Type: application/json' \
  -H 'User-Agent: curl BlockVectraQA/1' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

Ceci vérifie une méthode publique, et non la couverture d'archive ou la capacité authentifiée. Si votre application a besoin de sockets, testez l'abonnement requis, la déconnexion et la reprise sur un réseau déclarant la prise en charge de ws. Voir les abonnements WebSocket.

Distribution push et données indexées

Pour les notifications d'adresses, examinez la déclaration push de la chaîne et ses paramètres de confirmation. BlockVectra peut surveiller le même ensemble d'adresses sur l'ensemble des chaînes prises en charge dans un seul abonnement avec un seul récepteur HTTPS ; vérifiez la capacité en libre-service et pour entreprises par rapport à votre nombre d'adresses. Pour les requêtes Data API, examinez les jeux de données et la plage indexée dans GET /v1/status. Les enregistrements indexés n'impliquent pas l'exécution historique arbitraire de contrats. L'interrogation RPC, les messages WebSocket, les événements Push distribués et les jours-adresses surveillés utilisent des compteurs de facturation différents ; calculez chaque flux de travail nécessaire à partir des pondérations applicables dans les forfaits.

Auto-test : pour le Push, utilisez un récepteur HTTPS sous votre contrôle, vérifiez les signatures et testez la gestion des doublons, les nouvelles tentatives et le rejeu à l'aide d'un événement provenant d'une adresse que vous contrôlez. Pour la Data API, interrogez une transaction ou un transfert indexé connu, comparez son hash de bloc avec le RPC, épuisez la pagination et enregistrez le curseur avant de reprendre. Consignez les lacunes de couverture et le nombre d'événements ou d'appels facturés. Utilisez Webhook Push, Webhook versus WebSocket et la référence de la Data API pour la voie de reprise appropriée.

Authentification et accès des agents

Vérifiez si votre client peut fournir une clé en toute sécurité, découvrir une documentation lisible par machine, créer un compte et récupérer des erreurs. Le RPC BlockVectra accepte une clé dans le chemin à POST /v1/{chain}/{api_key} ou un en-tête x-api-key à POST /v1/{chain}. La Data API utilise x-api-key. Conservez les clés dans les environnements de serveur et hors des bundles de navigateur, des logs et des messages de chat.

Les développeurs et les agents IA bénéficient des mêmes tarifs et limites. L'inscription programmatique documente la création de compte basée sur un portefeuille, et le guide des agents fournit la documentation et les points d'entrée MCP. Les agents peuvent approvisionner le solde d'utilisation du compte avec des stablecoins via le flux de recharge documenté, sans abonnement RPC mensuel. Les réseaux de recharge, tokens et montants minimaux proviennent de GET /v1/topup/status.

Auto-test : demandez au client prévu de découvrir la chaîne et la méthode, de lire la documentation, de charger une clé depuis son environnement et d'exécuter une requête authentifiée bornée. Examinez à la fois le statut HTTP et l'erreur JSON-RPC (error). Vérifiez une réponse de clé manquante sans consigner les identifiants. Vérifiez que le client enregistre sa progression en cas de solde insuffisant, lit le réseau et le token de recharge activés, et suit le flux de recharge documenté ; les étapes de création de compte et de paiement doivent utiliser des comptes que vous contrôlez. Ne considérez pas une connexion au MCP de documentation comme une preuve que l'agent peut exécuter un appel RPC authentifié.

Consigner la décision

Conservez une courte fiche de résultats : source et date d'échantillonnage ; chaîne et méthode ; hash de bloc fixe ; exhaustivité du résultat ; total des appels et nouvelles tentatives ; quota disponible ; coût de la tâche payante ; latence et limitation de débit ; lacunes d'historique et de protocole ; étapes de reprise ; effort de migration. Si la charge de travail nécessite une assistance contractuelle ou un SLA, obtenez les conditions applicables séparément de ces tests d'API.

Une fois votre charge de travail définie, comparez avec des fournisseurs spécifiques :

• Comparer avec des fournisseurs spécifiques : tarification du calcul et plages de logs.
• Comparer avec des fournisseurs spécifiques : facturation des essais et abonnements.
• Comparer avec des fournisseurs spécifiques : coûts des requêtes HTTPS.
• Comparer avec des fournisseurs spécifiques : budgets quotidiens et de cycle.
• Comparer avec des fournisseurs spécifiques : requêtes incluses et dépassement.