🤖 NOUVEAU : « Quicknode » : un guide pratique sur l'IA 10 recettes éprouvées pour le codage en IA agents.
Voir les recettes     Certifié SOC 2 Type II · ISO 27001
Réponses>En savoir plus sur l'indexation et les données de la blockchain>RPC ou indexation : quelle est la différence ? RPC ou indexation : quelle est la différence ?
// Tags
RPC ou indexationQuand utiliser l'indexeur ?
En bref : le RPC et l’indexation sont deux approches fondamentalement différentes pour accéder aux données de la blockchain. Les points de terminaison RPC vous permettent d’interroger l’état actuel de la blockchain en temps réel, une requête à la fois. L'indexation extrait, transforme et stocke les données de la blockchain dans une base de données consultable, afin que votre application puisse effectuer des requêtes complexes sur l'historique des enregistrements. Le RPC revient à demander à un bibliothécaire de trouver un livre spécifique. L'indexation revient à créer un catalogue sur fiches pour l'ensemble de la bibliothèque. La plupart des applications de production ont besoin des deux.
L'explication simple
Toute application blockchain a besoin de données. Un portefeuille a besoin des soldes des comptes. Un tableau de bord DeFi a besoin des cours des tokens et de l'état des pools de liquidité. Une place de marché NFT a besoin des registres de propriété et de l'historique des transactions. Une plateforme d'analyse a besoin de métriques agrégées portant sur des milliers de contrats et des millions de transactions. La question est de savoir comment extraire ces données de la blockchain pour les intégrer à votre application.
Les points de terminaison RPC constituent l’interface native de la blockchain. Lorsque votre application envoie une requête JSON-RPC à un nœud, elle pose une question directe sur l’état actuel ou récent de la blockchain : quel est le solde actuel de ce portefeuille, que s’est-il passé lors de cette transaction spécifique, que contient le bloc numéro 20 000 000 ? Le nœud recherche la réponse et la renvoie. Le RPC est immédiat, précis et simple pour les recherches ponctuelles. Mais il présente une limite majeure : les méthodes RPC sont conçues pour récupérer des données spécifiques et connues, et non pour effectuer des recherches ou des agrégations sur l'ensemble de la chaîne. Il n'existe pas de méthode RPC permettant de « trouver toutes les transactions de ce portefeuille au cours des 30 derniers jours » ou de « m'afficher les 10 pools de liquidité les plus importants en termes de volume ».
L'indexation comble cette lacune en créant une base de données consultable à partir des données brutes de la blockchain. Un indexeur lit chaque bloc au fur et à mesure de sa production, décode les transactions et les journaux d'événements, transforme les données brutes en enregistrements structurés, puis écrit ces enregistrements dans une base de données dotée d'index appropriés. Une fois les données indexées, votre application peut les interroger à l'aide de SQL, de GraphQL ou de tout autre langage de requête pris en charge par votre base de données. Il devient alors possible d'effectuer des filtrages complexes, des agrégations, des tris, des jointures et des recherches en texte intégral.
Quand utiliser le RPC ?
Le RPC est le choix idéal lorsque votre application doit lire ou écrire des données spécifiques et connues en temps réel. Pour vérifier le solde ETH actuel d'un portefeuille, il suffit d'un seul appel « eth_getBalance ». Pour soumettre une transaction signée au mempool, il faut utiliser « eth_sendRawTransaction ». Pour lire la valeur renvoyée par la fonction view d'un smart contract, on utilise « eth_call ». Il s'agit là de requêtes ponctuelles où vous savez exactement ce que vous voulez et où la méthode RPC peut vous le renvoyer directement.
Le RPC est également la seule option disponible pour les opérations d'écriture. Il n'est pas possible de soumettre une transaction via un indexeur. Les indexeurs sont des systèmes en lecture seule qui traitent les données après leur validation sur la chaîne. Chaque fois que votre application doit envoyer une transaction, approuver un jeton, interagir avec un contrat intelligent ou diffuser une opération modifiant l'état, elle doit passer par une interface R endpoint.
La vérification de l'état en temps réel constitue un autre atout du RPC. Lorsqu'un protocole DeFi doit vérifier le ratio de garantie d'un utilisateur avant de procéder à une liquidation, ou lorsqu'un pont doit s'assurer qu'un dépôt a bien été confirmé, il interroge l'état actuel du nœud via le RPC. La réponse reflète le dernier bloc canonique, garantissant ainsi que les données sont aussi récentes que possible.
Le RPC présente toutefois des limites pour toute requête nécessitant de parcourir, filtrer ou agréger des données sur plusieurs blocs ou contrats. Une requête du type « Affiche-moi tous les transferts ERC-20 impliquant cette adresse » nécessite de parcourir chaque bloc et de vérifier chaque reçu de transaction, ce qui est mathématiquement irréalisable via le RPC seul. La requête « Quel est le volume total des transactions sur Uniswap V3 au cours des dernières 24 heures ? » nécessite de décoder et de totaliser les journaux d’événements provenant de milliers de blocs répartis sur des dizaines de contrats de pool. Il s’agit là de problèmes d’indexation.
Quand utiliser l'indexation ?
L'indexation est indispensable dès lors que votre application doit rechercher, filtrer, trier ou agréger des données de blockchain. Les outils de suivi de portefeuille qui affichent l'historique complet des transactions d'un utilisateur sur plusieurs jetons et chaînes s'appuient sur des données indexées. Les tableaux de bord analytiques qui présentent le volume des transactions, les tendances de la TVL, les modèles de consommation de gaz et les indicateurs des protocoles reposent entièrement sur des bases de données indexées. Les explorateurs de blocs tels qu'Etherscan indexent l'intégralité de la chaîne afin que les utilisateurs puissent rechercher n'importe quelle adresse, transaction ou contrat.
L’analyse historique constitue un autre cas d’utilisation clé de l’indexation. Si une é equipe chargée de la conformité doit retracer l’ flow des fonds à travers une série de portefeuilles sur une période de six mois, cela nécessite d’interroger des données de transactions indexées à l’aide de jointures et de filtres complexes. Si un cabinet d’études souhaite analyser les schémas d’extraction de MEV sur une année de blocs de la Ethereum , il a besoin d’un index complet des transactions, des traces et des journaux d’événements, la charge de calcul de ces requêtes étant prise en charge par une base de données, et non par un nœud de blockchain.
Les architectures orientées événements tirent également parti de l'indexation. Au lieu d'interroger les points de terminaison RPC pour détecter le déclenchement d'un événement spécifique lié à un contrat intelligent, un indexeur peut traiter en continu les nouveaux blocs et transmettre en temps réel les événements correspondants à votre application. Cette méthode est plus fiable que les abonnements WebSocket (qui peuvent se déconnecter et manquer des événements) et plus efficace que l'interrogation HTTP (qui gaspille des requêtes pour des réponses vides).
Utiliser les deux ensemble
La plupart des applications blockchain en production combinent l’utilisation du RPC et de l’indexation. L’expérience de lecture offerte à l’utilisateur repose généralement sur des données indexées : valeurs de portefeuille, historique des transactions, tableaux de bord analytiques, résultats de recherche. Lorsque l’utilisateur effectue une action (envoi d’une transaction, échange de jetons, création d’un NFT), l’application bascule vers le RPC pour soumettre la transaction au réseau et confirmer son intégration. Une fois la transaction confirmée, l’indexeur la récupère dans le nouveau bloc et met à jour la base de données, ce qui se répercute ensuite dans l’interface utilisateur.
Cette architecture assure une séparation claire des préoccupations. Le RPC gère les écritures en temps réel et les lectures ponctuelles. Les bases de données indexées prennent en charge les lectures complexes et les requêtes historiques. Il en résulte une application qui semble rapide et réactive pour les utilisateurs, tout en prenant en charge, en arrière-plan, des modèles d'accès aux données sophistiqués.
Quelle est la différence entre le RPC et l'indexation ?
En résumé, une interface RPC ( endpoint ) répond à des questions directes concernant un état actuel ou spécifique, tandis que l'indexation de la blockchain consiste à pré-traiter la chaîne pour la transformer en une base de données dans laquelle vous pouvez effectuer des recherches et des agrégations. Le tableau ci-dessous présente côte à côte les différences concrètes entre ces deux approches.
Aspect | RPC | Indexation |
|---|
Modèle d'accès | Une demande, une réponse | Rechercher, filtrer et regrouper |
Actualité des données | En temps réel, dernier bloc | Légère retard par rapport à l'extrémité de la chaîne |
Profondeur historique | Nécessite un nœud d'archivage | Stockées et consultables instantanément |
Prise en charge de l'écriture | Oui, la seule façon d'écrire | Non, en lecture seule |
Temps nécessaire à la mise en place | Low, appelle un endpoint | Higher : construire ou acheter un gazoduc |
Idéal pour | Lectures et transactions en temps réel | Analyses, historique et recherche |
Un indexeur est-il plus rapide que le RPC pour les requĂŞtes historiques ?
Type de requĂŞte | Le meilleur outil | Pourquoi ? |
|---|
Solde ou état actuel | RPC | En direct et en temps réel |
Enregistrer une transaction | RPC | Seul le RPC peut Ă©crire |
Historique des transactions du portefeuille | Indexeur | Recherche nécessaire sur plusieurs blocs |
Volume du protocole ou TVL | Indexeur | Il faut effectuer une agrégation dans le temps |
Événements en direct consacrés aux nouveaux blocs | RPC ou diffusion en continu | Notification push à faible latence |
Est-il possible de développer un indexeur de blockchain en s'appuyant sur RPC ?
Oui, et c'est le cas de presque tous les indexeurs. Un indexeur lit la chaîne via RPC ou un flux en continu, décode chaque bloc et écrit des lignes structurées dans sa propre base de données. La difficulté réside dans la gestion fiable des réorganisations, des nouvelles tentatives et des lacunes ; c'est pourquoi de nombreuses équipes utilisent un pipeline géré de streaming de données de blockchain plutôt que de développer elles-mêmes des boucles d'interrogation RPC.
L'indexation remplace-t-elle le RPC ?
Non. L'indexation et le RPC constituent des couches complémentaires de la pile d'infrastructure Web3. Le RPC reste le seul moyen d'envoyer des transactions et de lire l'état actuel, tandis que l'indexation permet d'assurer la recherche, l'historique et l'analyse. Les applications en production acheminent les écritures et les lectures en temps réel vers le RPC, et acheminent les lectures complexes vers un index.
Foire aux questions
Peut-on soumettre des transactions via un indexeur ?
Non. Les indexeurs sont des systèmes en lecture seule qui traitent les données une fois celles-ci validées sur la chaîne. Chaque soumission de transaction doit passer par une interface RPC endpoint.
Pourquoi le RPC est-il lent pour les requĂŞtes d'analyse ?
Le RPC renvoie une seule donnée connue par appel et ne permet ni de filtrer ni d'agréger les données sur l'ensemble de la chaîne. Répondre à une question d'analyse avec le RPC implique d'effectuer des milliers d'appels successifs et de combiner soi-même les résultats, ce qui est lent et coûteux.
Dans quelle mesure les données indexées sont-elles plus récentes que celles du RPC ?
Les données indexées présentent généralement un décalage de quelques secondes à quelques minutes par rapport à l'extrémité de la chaîne, selon l'indexeur utilisé. Le RPC reflète le dernier bloc canonique ; par conséquent, pour obtenir des données actualisées en moins d'une seconde, il faut toujours lire directement depuis un nœud.
Avez-vous besoin d'un nœud d'archivage pour l'indexation ?
Pour reconstituer l'historique lointain, vous avez besoin de données d'archive, provenant soit d'un nœud d'archive, soit d'un pipeline de reconstitution. Consultez la section « Nœud complet vs nœud d'archive » pour connaître la différence.
« The Graph » est-il un indexeur ou un fournisseur RPC ?
The Graph est un protocole d'indexation. Ses propres indexeurs lisent la chaîne via RPC et restituent le résultat traité sous forme de sous-graphes consultables. Il ne peut pas, à lui seul, soumettre de transactions ni fournir de données en temps réel en moins d'une seconde.
Comment « Quicknode » répond à ces deux besoins
Quicknode fournit l'infrastructure nécessaire aux deux volets de cette équation. L'API Core offre un accès RPC distribué à l'échelle mondiale et à faible latence sur plus de 80 chaînes, gérant les lectures en temps réel et les soumissions de transactions avec une disponibilité de 99,99 % et des temps de réponse 2,5 fois plus rapides que ceux de la concurrence. Les méthodes API améliorées réduisent le nombre d'appels RPC individuels nécessaires pour des opérations courantes telles que la consultation des soldes de jetons ou des collections de NFT.
Quicknode Streams comble le fossé entre le RPC et l'indexation en proposant un pipeline de données de type « push » qui transmet des données de blockchain brutes ou filtrées directement vers votre base de données, votre entrepôt de données ou votre webhook. Au lieu de développer et de maintenir une infrastructure de sondage RPC personnalisée pour alimenter votre indexeur, vous configurez un flux (« Stream ») et Quicknode se charge de l’extraction, du filtrage, de la livraison, de la correction des réorganisations et de la logique de réessai des données. Streams prend en charge à la fois le streaming en temps réel et le remplissage historique, ce qui vous permet d’alimenter votre index depuis sa création et de le maintenir à jour à l’aide d’un seul outil. Pour les équipes qui ont besoin de développer leur propre indexeur, Quicknode publie un guide étape par étape expliquant comment créer un indexeur de blockchain complet s'appuyant sur PostgreSQL à l'aide de Streams.
Pour en savoir plus
