Cette semaine, nous allons rester sur un angle plus technique, mais accessible : comprendre ce que font réellement Sentinel et Lava.

Les deux projets sont parfois rangés dans de grandes catégories comme DePIN, infrastructure Web3 ou services décentralisés. Ces termes peuvent être utiles, mais ils deviennent vite trop larges. Chez Snow-Fall, nous préférons partir de ce que nous connaissons : les nœuds, les validateurs, les services réseau, les RPC, la disponibilité, les coûts d’infrastructure et les usages concrets.

Sentinel et Lava ne font pas la même chose. Sentinel travaille sur l’accès réseau, la bande passante et le dVPN. Lava travaille sur l’accès aux blockchains via les RPC et les API. Dans les deux cas, on parle d’une infrastructure que l’utilisateur final ne voit pas toujours, mais qui peut devenir indispensable lorsque l’on veut construire des services fiables.

Sentinel : plus qu’un VPN décentralisé

Un VPN classique repose généralement sur une entreprise qui opère ou loue des serveurs. L’utilisateur se connecte à l’un de ces serveurs, son trafic passe par ce point de sortie, et l’entreprise VPN devient l’intermédiaire principal entre l’utilisateur et Internet. Le modèle est simple, mais il déplace la confiance : au lieu de faire confiance uniquement à son fournisseur d’accès Internet, l’utilisateur fait aussi confiance à la société VPN.

Sentinel propose une approche différente avec un réseau dVPN. Au lieu de dépendre d’un fournisseur unique, le réseau s’appuie sur des nœuds opérés par différents participants. Ces nœuds fournissent de la bande passante, et l’utilisateur peut se connecter à l’un d’eux via une application dVPN.

La blockchain sert ici de couche de coordination. Elle permet d’enregistrer les nœuds, les comptes, les sessions et les paiements. Le but n’est pas de rendre Internet totalement anonyme ou magique, mais de construire une infrastructure VPN où le service ne dépend pas d’une seule entreprise qui contrôle tous les serveurs, les clés, les règles et la facturation.

Le point important, souvent oublié, est que Sentinel n’est pas seulement une application VPN. Le projet met surtout en avant une stack complète pour construire des applications dVPN en marque blanche. En clair, une équipe peut créer son propre service VPN, avec sa propre marque et sa propre interface, tout en utilisant l’infrastructure Sentinel en arrière-plan.

C’est cette partie qui rend le projet plus intéressant techniquement. Sentinel fournit les briques nécessaires : SDK, nœuds, gestion des sessions, protocoles de tunnel comme WireGuard ou V2Ray, logique de paiement, sélection des nœuds, plans d’abonnement et intégration possible avec différents moyens de paiement. L’équipe qui construit l’application ne doit pas forcément recréer tout le réseau VPN depuis zéro. Elle peut se concentrer sur le produit, l’expérience utilisateur, la distribution et le modèle commercial.

Comment fonctionne une session Sentinel

Le fonctionnement peut être résumé assez simplement.

Un utilisateur ouvre une application dVPN construite sur Sentinel. L’application cherche un nœud disponible selon certains critères : pays, prix, protocole, performance ou disponibilité. Une session est ensuite créée et enregistrée sur la blockchain. Le nœud vérifie cette session, puis fournit les informations nécessaires pour établir le tunnel VPN. Une fois le tunnel actif, le trafic passe directement entre l’utilisateur et le nœud choisi.

La différence avec une architecture VPN classique est importante. Dans le modèle Sentinel, le réseau de nœuds est distribué, les sessions sont autorisées on-chain, et l’application peut être développée par différentes équipes. Cela ouvre la porte à plusieurs types d’usages : applications grand public, VPN communautaires, offres spécialisées, services white-label, ou intégrations dans des produits existants.

C’est aussi ce qui rapproche Sentinel d’une logique DePIN. La ressource fournie n’est pas seulement un token ou une liquidité financière. La ressource fournie est de la bande passante, via des nœuds opérés par des participants indépendants.

Le vrai enjeu pour Sentinel

Le vrai enjeu de Sentinel n’est pas simplement de dire “nous sommes décentralisés”. Pour un VPN, l’utilisateur juge d’abord le service : est-ce rapide, stable, simple à installer, facile à payer, et suffisamment fiable pour une utilisation régulière ?

La partie white-label peut justement aider à répondre à ce problème. Si plusieurs équipes peuvent construire leurs propres applications au-dessus de Sentinel, le réseau n’est pas limité à une seule interface ou à une seule marque. Certaines applications peuvent viser le grand public, d’autres des communautés spécifiques, d’autres encore des usages plus professionnels.

Sentinel explore aussi un angle plus récent : l’accès VPN pour agents IA ou services automatisés. L’idée est qu’un agent puisse demander un accès, recevoir un prix, payer automatiquement et établir une connexion sans compte classique ni intervention humaine. Ce n’est probablement pas encore le cœur de l’usage actuel, mais c’est une piste intéressante, surtout si les agents automatisés deviennent de vrais consommateurs d’API, de réseaux et de services payés à l’usage.

Lava : le problème invisible des RPC

Lava traite un problème différent : l’accès aux blockchains.

Quand un wallet affiche un solde, il doit interroger une blockchain. Quand une dApp lit un smart contract, elle doit interroger une blockchain. Quand un bot surveille une transaction ou qu’un dashboard affiche des données, il doit aussi interroger une blockchain. Cette communication passe souvent par un endpoint RPC.

Un RPC, pour simplifier, est un point d’accès qui permet à une application de poser des questions à une blockchain ou de lui envoyer des instructions. Sans RPC fiable, une application blockchain devient rapidement inutilisable. L’interface peut être parfaite, mais si les données n’arrivent pas, si les requêtes échouent ou si les transactions ne partent pas, l’utilisateur verra seulement une application qui ne fonctionne pas.

Le problème est que beaucoup d’applications dépendent encore de quelques fournisseurs RPC centralisés ou semi-centralisés. C’est pratique, mais cela crée des points de faiblesse. Si le fournisseur ralentit, tombe ou limite certains accès, l’application en dépend directement.

Lava cherche à résoudre ce problème en coordonnant un réseau de fournisseurs RPC. D’un côté, il y a les providers : opérateurs d’infrastructure qui font tourner des nœuds et servent les données. De l’autre, il y a les consumers : wallets, dApps, développeurs, exchanges, dashboards ou services automatisés qui ont besoin de ces données.

Comment Lava organise l’accès aux données

Le modèle de Lava repose sur deux couches.

La première est la blockchain Lava, construite avec le Cosmos SDK. Elle sert à enregistrer les providers, gérer le staking, organiser les incitations et régler les paiements ou récompenses.

La seconde est le protocole hors chaîne. Les requêtes RPC ne passent pas toutes directement par la blockchain, ce qui serait trop lent et inefficace. Les consumers récupèrent une liste de providers disponibles, puis envoient leurs requêtes directement aux providers en peer-to-peer. La blockchain sert plutôt de couche de coordination, de sélection, de preuve et de règlement économique.

Ce point est important. Lava n’essaie pas de mettre chaque requête RPC on-chain. Le protocole utilise la blockchain pour coordonner les acteurs, mais les données circulent directement entre ceux qui les demandent et ceux qui les fournissent. Cela permet de garder une architecture plus efficace.

La sélection des providers peut prendre en compte plusieurs critères : qualité de service, latence, disponibilité, exactitude des réponses, géolocalisation ou stake. Le but est d’envoyer les requêtes vers les fournisseurs les plus fiables, plutôt que de laisser chaque application choisir manuellement un seul fournisseur RPC et dépendre de lui.

Pourquoi Lava devient important

Plus il existe de blockchains, de rollups, de dApps et de services automatisés, plus le besoin en RPC augmente. Les grandes chaînes attirent généralement de bons fournisseurs d’infrastructure. Les plus petites chaînes, ou les nouveaux réseaux, ont souvent plus de mal à obtenir des RPC fiables dès le lancement.

C’est là que Lava peut apporter quelque chose. Une chaîne peut créer ou financer des pools d’incitation pour attirer des providers. Les providers sont rémunérés selon leur contribution et leur qualité de service. Les développeurs, eux, obtiennent un accès plus simple et plus fiable à la blockchain.

Lava commence par les RPC, mais l’architecture peut théoriquement aller plus loin : indexing, subgraphs, APIs spécialisées ou autres services de données. C’est cette modularité qui rend le projet intéressant du point de vue infrastructure. Le RPC est le premier cas d’usage, mais la logique générale est celle d’un marché coordonné pour l’accès aux données blockchain.

Sentinel et Lava : deux ressources différentes

Sentinel et Lava ne doivent pas être mélangés. Sentinel fournit une infrastructure autour de la bande passante et du VPN. Lava fournit une infrastructure autour des données blockchain et des RPC.

La ressource Sentinel, c’est l’accès réseau.
La ressource Lava, c’est l’accès aux données blockchain.

Dans les deux cas, le projet essaie de transformer une ressource technique en service distribué. Sentinel le fait avec des nœuds dVPN. Lava le fait avec des providers RPC.

C’est aussi pour cela que ces projets nous intéressent chez Snow-Fall. Nous ne les regardons pas seulement comme des tokens à staker, mais comme des réseaux techniques à comprendre. Un réseau dVPN doit transporter du trafic. Un réseau RPC doit servir des requêtes. Dans les deux cas, l’usage réel est plus important que le discours marketing.

Une petite partie de l’écosystème Snow-Fall

Cette lecture ne couvre pas tout le DePIN ni toute l’infrastructure décentralisée. Elle part uniquement d’une partie de l’écosystème que nous suivons.

Dans ce cadre, on peut aussi citer Akash pour le calcul, Flux pour le cloud distribué, Althea pour la connectivité, KYVE et Band pour la donnée, ou encore TAO / Hippius pour le stockage, les machines virtuelles et certaines briques liées à Bittensor. Mais ces projets ne sont pas le centre de cet article.

Le sujet principal reste Sentinel et Lava, parce qu’ils permettent d’expliquer deux couches très concrètes : comment accéder à Internet de manière plus distribuée, et comment accéder aux blockchains de manière plus fiable.

Conclusion

Sentinel et Lava sont intéressants parce qu’ils permettent de parler d’infrastructure sans rester dans le vague.

Sentinel montre comment un réseau dVPN peut être construit autour de nœuds indépendants, d’applications white-label, de sessions on-chain, de paiements intégrables et de bande passante distribuée. Lava montre comment un réseau RPC peut coordonner des providers et des consumers pour rendre l’accès aux blockchains plus fiable, plus modulaire et moins dépendant de quelques points centraux.

Ces deux projets ne garantissent pas à eux seuls le succès de la narrative DePIN ou infrastructure Web3. Mais ils donnent des cas concrets à analyser. Ils permettent de regarder ce qui se passe sous le capot : les nœuds, les requêtes, les tunnels, les providers, les consumers, les paiements et la qualité de service.

Pour un opérateur comme Snow-Fall, c’est probablement là que l’analyse devient la plus intéressante. Pas seulement dans le prix du token, mais dans la capacité du réseau à fournir un service réel.