Comment fonctionne l'infrastructure Web3 ?

L'explication simple

Une application web traditionnelle présente une architecture simple : un utilisateur ouvre un navigateur, celui-ci charge une interface utilisateur à partir d'un serveur web, l'interface communique avec une API backend, et le backend lit et écrit dans une base de données. L'entreprise qui exploite l'application contrôle toutes les couches : les serveurs, la base de données, l'API et les règles déterminant qui peut accéder à quoi.

Une application Web3 remplace la base de données centralisée par une blockchain. Mais les blockchains ne sont pas des bases de données. Il n'est pas possible d'y exécuter des requêtes SQL. Il n'est pas possible de s'y connecter à l'aide d'un pilote de base de données standard. Il n'est pas possible d'y écrire des données en appelant une API avec une clé secrète. Interagir avec une blockchain nécessite une pile d'infrastructure fondamentalement différente, et la compréhension de cette pile constitue la première étape pour développer des dapps de qualité opérationnelle.

La différence fondamentale réside dans le modèle de transaction. Dans une application traditionnelle, le backend écrit dans la base de données en utilisant ses propres identifiants. Dans une application Web3, c’est l’utilisateur qui écrit sur la blockchain en signant les transactions avec sa propre clé privée, via son propre portefeuille. L’application facilite ce processus, mais n’a jamais d’accès direct en écriture à l’état on-chain de l’utilisateur. Ce passage de données contrôlées par le serveur à des données contrôlées par l’utilisateur est ce qui rend le Web3 « décentralisé », et c’est également ce qui rend l’infrastructure plus complexe.

×

Quicknode

□

En quoi l'infrastructure du Web3 diffère-t-elle de celle du Web2 ?

La meilleure façon de comprendre l'infrastructure du Web3 est de la comparer à la pile Web2 que la plupart des développeurs connaissent déjà. Les données sont stockées à un autre endroit, et le processus de lecture et d'écriture s'adapte en conséquence.

Comme il n'est pas possible d'interroger une chaîne de blocs comme on le ferait avec une base de données, la plupart des lectures s'effectuent via une interface RPC ( endpoint ) pour les recherches simples, et via l'indexation de la chaîne de blocs pour les requêtes complexes et structurées.

L'architecture d'une dapp

Une dapp de production type se compose de plusieurs couches, chacune remplissant une fonction distincte.
Le frontend correspond à l’interface utilisateur, généralement une application web développée avec React, Next.js ou des frameworks similaires. Le frontend gère le rendu, les saisies de l'utilisateur et l'interaction avec le portefeuille. Il se connecte au portefeuille de l'utilisateur (MetaMask, Phantom, etc.) via une API de fournisseur (comme ethers.js ou wagmi) qui permet à la dapp de demander des adresses de portefeuille, d'afficher les soldes et de solliciter des signatures de transactions.

Le portefeuille constitue à la fois l'identité et le mécanisme d'authentification de l'utilisateur. Au lieu de se connecter avec un nom d'utilisateur et un mot de passe, les utilisateurs Web3 connectent leur portefeuille. Le portefeuille fournit l'adresse publique de l'utilisateur (son identité) et lui permet de signer des transactions (son autorisation). Lorsque la dapp doit enregistrer des données sur la blockchain (envoyer des tokens, interagir avec un contrat intelligent, frapper un NFT), elle construit une transaction, l'envoie au portefeuille pour signature, puis le portefeuille diffuse la transaction signée sur le réseau.

Les points de terminaison RPC constituent la passerelle entre la dApp et la blockchain. Chaque opération de lecture (vérification d'un solde, consultation de l'état d'un contrat intelligent, récupération d'un reçu de transaction) et chaque opération d'écriture (envoi d'une transaction signée) passe par un endpoint RPC. L'endpoint se connecte à un nœud de la blockchain qui traite la requête et renvoie le résultat. Le choix du fournisseur RPC a un impact direct sur la vitesse, la fiabilité et l'exactitude des données de votre application.

Le backend (facultatif mais courant en environnement de production) gère la logique hors chaîne qui n'a pas sa place sur la blockchain : gestion des sessions utilisateur, agrégation d'API, mise en cache, analyse de données, traitement des webhooks et intégration avec des services traditionnels. De nombreuses dapps utilisent également un backend pour gérer l'envoi de transactions côté serveur pour les opérations qui ne nécessitent pas la signature du portefeuille de l'utilisateur (comme les opérations administratives ou les méta-transactions sans gas).

Les indexeurs transforment les données brutes de la blockchain en bases de données consultables. La blockchain elle-même ne prend pas en charge les requêtes complexes. Il est impossible de lui demander « affiche-moi tous les NFT détenus par cette adresse » ou « quel est le volume total des transactions effectuées aujourd’hui sur ce DEX » à l’aide des méthodes RPC standard. Les indexeurs (tels que The Graph ou les pipelines personnalisés créés avec Quicknode Streams ) traitent chaque bloc, décodent les transactions et les événements, puis stockent les résultats dans une base de données prenant en charge les requêtes SQL ou GraphQL. Ces données indexées permettent d’afficher les portefeuilles, l’historique des transactions, les tableaux de bord analytiques et les fonctionnalités de recherche.

Les contrats intelligents constituent la logique « on-chain » de l'application. Ils définissent les règles régissant les transferts de jetons, les opérations DeFi, la création de NFT, les votes de gouvernance et tout autre comportement programmable sur la blockchain. Les contrats intelligents sont déployés une seule fois et s'exécutent de manière déterministe chaque fois qu'ils sont appelés. Ils constituent la « logique backend » qui réside sur la blockchain plutôt que sur le serveur d'une entreprise.

×

Quicknode

□

Quels sont les éléments essentiels de l'infrastructure Web3 ?

Bien que les architectures varient, la plupart des dapps en production s'appuient sur le même ensemble de composants de base. Le tableau ci-dessous présente chaque couche, son rôle et un exemple courant.

Les couches évolutives, telles qu’un réseau de couche 2, les contrats intelligents qui contiennent votre logique et un pipeline en temps réel comme Streams s’intègrent tous à cette même architecture.

Données de lecture et données d'écriture

Les chemins de lecture et d'écriture dans une dapp sont fondamentalement différents.

La lecture des données est relativement simple. Le front-end (ou le back-end) envoie une requête RPC à un nœud pour demander des données spécifiques : un solde, l’état d’un contrat, le contenu d’un bloc. Le nœud recherche la réponse et la renvoie. Pour les lectures simples, cet aller-retour prend quelques dizaines de millisecondes avec un bon fournisseur. Pour les besoins en données complexes (comme « affiche-moi l'historique complet des transactions de ce portefeuille pour tous les tokens »), la dapp interroge la base de données d’un indexeur plutôt que la blockchain directement, car l’indexeur a déjà effectué le gros du travail de traitement et de structuration des données.

L'écriture de données est plus complexe. L'utilisateur lance une action (comme l'échange de jetons). La dapp construit une transaction en précisant le contrat intelligent à appeler, la fonction à exécuter et les paramètres à transmettre. La dapp estime le coût du gaz et le présente à l'utilisateur. Ce dernier vérifie et approuve la transaction dans son portefeuille, qui la signe avec sa clé privée. La transaction signée est soumise au réseau via une interface RPC ( endpoint). La transaction entre dans le mempool et attend qu’un validateur l’intègre dans un bloc. Une fois intégrée, la transaction est confirmée. La dapp détecte la confirmation (soit par interrogation, soit via un abonnement WebSocket) et met à jour l’interface utilisateur pour refléter le nouvel état.

Ce processus d'écriture en plusieurs étapes, qui implique le portefeuille de l'utilisateur, l'estimation du gas, la propagation dans le mempool, l'inclusion par les validateurs et la détection de la confirmation, explique pourquoi les opérations d'écriture Web3 semblent plus lentes que le simple clic sur un bouton dans une application traditionnelle. C'est également la raison pour laquelle une infrastructure RPC fiable et à faible latence est essentielle : chaque étape, de l'estimation du gas à la soumission de la transaction en passant par la détection de la confirmation, transite par l'endpoint RPC.

×

Quicknode

□

Réalité multi-chaînes

Les dapps modernes fonctionnent rarement sur une seule chaîne. Un protocole DeFi peut être déployé sur Ethereum ,mainnet, Arbitrum, Base, Optimism et Polygon. Une place de marché NFT peut prendre en charge Ethereum, Solana et plusieurs L2. Une application de portefeuille doit afficher les soldes et permettre d'effectuer des transactions sur des dizaines de chaînes simultanément.

Cette réalité multi-chaînes multiplie les besoins en infrastructure. Chaque chaîne nécessite ses propres points de terminaison RPC, son propre pipeline d’indexation et une compréhension spécifique de ses particularités (modèles de finalité différents, mécanismes de « gas » différents, formats de transaction différents). Gérer cette complexité sur 5, 10 ou plus de 80 chaînes représente un défi technique de taille que la plupart des équipes relèvent en faisant appel à un fournisseur d’infrastructure plutôt qu’en exploitant leurs propres nœuds pour chaque chaîne.

Faut-il faire tourner son propre nœud pour développer une dapp ?

Dans la plupart des cas, non. Vous pouvez déployer une dapp de production en utilisant un fournisseur RPC géré sans jamais avoir à exploiter de nœud. L’exploitation de votre propre nœud vous offre un contrôle et une confidentialité maximaux, mais cela implique également de mettre en place du matériel, de synchroniser les chaînes, de gérer les mises à jour et les hard forks, et de surveiller la disponibilité 24 heures sur 24, pour chaque chaîne que vous prenez en charge. C’est pourquoi, face au dilemme « construire ou acheter », les équipes qui souhaitent se concentrer sur le produit plutôt que sur les opérations optent généralement pour un fournisseur. Si vous souhaitez toutefois disposer d’un contrôle total, notre présentation sur l’exploitation de votre propre nœud vous aide à évaluer les coûts et les avantages.

Comment « Quicknode » alimente l'infrastructure Web3

Quicknode fournit l'infrastructure de base dont dépendent les dapps. L'API Core offre des points de terminaison RPC de niveau production sur plus de 80 réseaux blockchain à partir d'une plateforme unique, avec des nœuds répartis dans le monde entier, une disponibilité de 99,99 % et des temps de réponse 2,5 fois plus rapides que ceux de la concurrence. Les développeurs peuvent ainsi prendre en charge plusieurs chaînes sans avoir à gérer une infrastructure de nœuds distincte pour chacune d'entre elles.

Quicknode Streams Remplace l'infrastructure d'indexation personnalisée par un pipeline de données de type « push » qui transmet les données filtrées de la blockchain directement à votre base de données ou à votre entrepôt, avec une livraison garantie et une gestion automatique des réorganisations. Au lieu de créer et de maintenir des scripts d'interrogation pour chaque chaîne, vous configurez un « Stream » et « Quicknode » se charge de l'extraction, du filtrage, de la livraison et de la cohérence des données.

Pour l'écosystème DApp au sens large, Quicknode propose des passerelles IPFS et des fonctionnalités de « pinning » pour le stockage décentralisé, des modules complémentaires Marketplace pour des API enrichies (soldes de jetons, données NFT, analyses DeFi), ainsi que la plateforme Quicknode SDK permettant une intégration simplifiée en JavaScript et TypeScript. Ensemble, ces outils constituent une plateforme d'infrastructure complète pour le développement, la mise à l'échelle et l'exploitation d'applications Web3 en production.

Foire aux questions

Quelle est la différence entre un « RPC endpoint » et un « indexer » ?

Une endpoint RPC répond à des questions directes concernant l'état actuel de la chaîne, telles que le solde ou une transaction spécifique. Un indexeur traite l'historique complet pour l'intégrer dans une base de données, ce qui vous permet d'effectuer des requêtes complexes, comme l'historique complet des transactions d'un portefeuille, que le RPC seul ne peut pas traiter efficacement.

Une dapp peut-elle fonctionner sans backend ?

Oui. De nombreuses dapps fonctionnent entièrement côté client : l'interface utilisateur communique directement avec les points de terminaison RPC et le portefeuille de l'utilisateur. Un backend est facultatif et est ajouté pour les tâches hors chaîne telles que la mise en cache, l'analyse de données et les transactions sans frais de gaz.

Comment un utilisateur s'authentifie-t-il dans une application Web3 ?

Les utilisateurs connectent un portefeuille au lieu de créer un compte. L'adresse du portefeuille fait office d'identité, et la signature d'un message ou d'une transaction prouve qu'ils ont le contrôle de cette adresse, remplaçant ainsi les noms d'utilisateur et les mots de passe.

Pourquoi la plupart des équipes font-elles appel à un fournisseur d'infrastructure ?

Pour prendre en charge de nombreuses chaînes de manière fiable, il faut exploiter et maintenir des nœuds, des indexeurs et des solutions de stockage pour chacune d'entre elles. Un fournisseur regroupe tout cela au sein d'une plateforme unique, dont la mise en place est plus rapide et l'exploitation moins coûteuse que si l'on devait la développer en interne.

L'infrastructure Web3 est-elle entièrement décentralisée ?

C'est en partie vrai, et en partie faux. Les chaînes de blocs et les contrats intelligents sont décentralisés, mais les services associés, tels que les fournisseurs RPC et les interfaces utilisateur, fonctionnent souvent sur des plateformes cloud centralisées. Les flux de données en temps réel, comme la diffusion de données de blockchain, proviennent généralement eux aussi de fournisseurs gérés.

Pour en savoir plus

Qu'est-ce que l'indexation blockchain ? - Quicknode Glossaire
Qu'est-ce qu'un portefeuille crypto ? - Quicknode Glossaire
Qu'est-ce qu'un RPC endpoint? - Quicknode Glossaire
La pile d'infrastructure Web3 - Quicknode Glossaire
Quelle est l'infrastructure RPC la plus rapide ? - Quicknode Core-api
Premiers pas avec Streams - Quicknode Documentation
Introduction aux produits Quicknode