De l'interface frontale à la base de données : comment EthStorage permet aux DApp de parvenir à une décentralisation véritablement fiable ?
TechFlow SélectionTechFlow Sélection
De l'interface frontale à la base de données : comment EthStorage permet aux DApp de parvenir à une décentralisation véritablement fiable ?
Comment héberger le frontend, le backend et les données d'une DApp sur Ethereum ? EthStorage propose deux grandes solutions.
Dédié à des analyses Web3 approfondiesRédaction : Équipe EthStorage
Résumé
-
Une application décentralisée est composée de plusieurs parties, mais actuellement seul le cœur logique (backend) s'exécute sur Ethereum. Les autres composants, comme le code frontend, sont encore déployés en dehors d'Ethereum, accompagnés de nombreuses données non enregistrées sur la blockchain. Ainsi, la majorité des DApps ne peuvent pas pleinement bénéficier de la sécurité d'Ethereum et sont loin d'atteindre l'état idéal souhaité.
-
Les raisons principales de ce problème sont deux : premièrement, Ethereum ne fournit pas aux développeurs de normes ni d'outils adaptés pour le frontend ; deuxièmement, le coût du stockage sur chaîne est trop élevé.
-
Pour proposer une norme de frontend décentralisé, l'équipe EthStorage a conçu le protocole d'accès web3://, offrant un ensemble complet de standards et outils permettant aux développeurs de déployer et accéder au code frontend – voire à un système de fichiers similaire – via des contrats intelligents. Ce protocole est désormais une norme officielle d'Ethereum.
-
Pour réduire le coût du stockage des données sur Ethereum, l'équipe EthStorage a développé le protocole de stockage en couche 2 appelé EthStorage, qui exploite PoRA (Proof of Random Access) et les preuves à divulgation nulle (zero-knowledge proofs), garantissant la sécurité de la couche 1 tout en réduisant considérablement les coûts de stockage.
Remerciements : Nous remercions Faust de Geek Web3, Zhixiong Pan de ChainFeeds, Bruce de LXDAO, ainsi que Qi Zhou et Lun Deng d’EthStorage pour leurs retours sur cet article.
Contexte et problèmes des DApps décentralisées
La vision d'Ethereum est de devenir un « ordinateur mondial », où toutes les applications construites hériteraient de sa sécurité. Une fois déployée, une application fonctionnerait éternellement sur Ethereum sans pouvoir être censurée ou manipulée par un tiers.
Mais les DApps actuelles atteignent-elles cet objectif ? Pour répondre clairement à cette question, nous devons déconstruire une DApp afin d'identifier ses différents composants et analyser leur degré de confiance minimale, puis en tirer une conclusion finale.
En général, une DApp décentralisée comprend une interface frontend, un serveur backend et une base de données. Lorsqu’un utilisateur accède à l’interface frontend, celle-ci charge son contenu via un navigateur et un service de noms de domaine. Plus précisément :
-
Frontend et service de noms de domaine : La plupart ne sont pas déployés ni accessibles via des contrats intelligents. Les propriétés offertes par la blockchain – résistance aux pannes ponctuelles, immuabilité du code, anti-censure, gouvernance communautaire – ne se retrouvent donc pas dans cette partie.
-
Backend : Partiellement implémenté via des contrats intelligents, certaines tâches intensives en calcul ne pouvant pas être entièrement exécutées sur chaîne.
-
Base de données : Partiellement gérée par des contrats intelligents, mais en raison du coût très élevé du stockage sur chaîne, les DApps utilisent souvent des solutions hors chaîne lorsque le volume de données est important.
D’après cette analyse, on constate que seuls certains composants des DApps actuelles bénéficient de la protection d'Ethereum grâce aux contrats intelligents. Le système Ethereum est encore loin de réaliser la vision initiale d’un « ordinateur mondial décentralisé ».
À la fin de l'année 2023, Vitalik a publié un article très discuté intitulé « Make Ethereum Cypherpunk Again », dans lequel il revient sur l’évolution d'Ethereum et appelle la communauté à revenir aux principes cypherpunk. Il y expose les valeurs fondamentales que la communauté Ethereum – et plus largement Web3 – devrait défendre, notamment :
Une application décentralisée devrait réduire autant que possible sa dépendance à tout acteur centralisé, de sorte qu'elle continue de fonctionner même si ses développeurs principaux disparaissent définitivement.
On voit donc que Vitalik partage des attentes similaires concernant la manière dont doivent être construites les DApps. Dans la suite, nous analyserons en détail les problèmes rencontrés par chaque composant d'une DApp décentralisée et explorerons les pistes d'amélioration.
Frontend et service de noms de domaine
Parmi les composants d'une DApp décentralisée, le frontend et le service de nommage sont ceux qui présentent le plus haut degré de centralisation. Actuellement, la quasi-totalité des dApps utilisent des serveurs centralisés pour leur frontend. Les équipes projet peuvent modifier le code à tout moment sans passer par une gouvernance communautaire ni respecter de temporisation (time-lock). La sécurité de cette partie est donc bien inférieure à celle des contrats intelligents déployés sur Ethereum.
Un pirate peut compromettre le serveur et altérer le code frontend, entraînant des pertes d'actifs pour les utilisateurs. Ce type d'incident s'est répété pendant le DeFi Summer. On doit alors se poser la question : pourquoi le frontend ne pourrait-il pas être déployé sur Ethereum comme le backend, avec des modifications soumises à la gouvernance et à un time-lock ?
Imaginez aussi que l'équipe Uniswap décide un jour de ne plus payer l'hébergement de son serveur frontend ni de renouveler son nom de domaine. Comment les utilisateurs et fournisseurs de liquidités (LP) pourraient-ils continuer à utiliser Uniswap ?
La grande majorité des utilisateurs ne savent pas interagir directement avec les contrats intelligents en contournant le frontend. Bien qu'Uniswap ait expérimenté l'upload de son frontend sur IPFS, IPFS et Ethereum sont des réseaux distincts, avec des niveaux de fiabilité et de confiance minimale très différents. Soulignons également que l’accès au contenu sur IPFS est lent, et la plupart des utilisateurs interagissent encore avec le frontend d'Uniswap hébergé sur des serveurs centralisés.
De plus, le frontend d'Uniswap étant géré par Uniswap Labs, ils ont ajouté des filtres sur la liste des tokens pour se conformer à la réglementation, ce qui contraste fortement avec les contrats intelligents déployés sur Ethereum, que personne ne peut modifier arbitrairement. Ainsi, les tokens filtrés au niveau du frontend restent accessibles au niveau du contrat. Cela illustre parfaitement l’importance de mettre le code sur chaîne pour résister à la censure.
Serveur backend
L'EVM offrant un environnement d'exécution Turing-complet, la plupart de la logique backend peut s’exécuter sur Ethereum. On peut donc dire que les applications basées sur des contrats intelligents héritent pleinement de la sécurité d'Ethereum. Toutefois, pour des raisons de coût, les tâches intensives en calcul ne peuvent pas être exécutées directement sur chaîne.
Pour résoudre ce problème, les approches explorées consistent principalement à utiliser des méthodes ZK ou OP : le calcul est effectué hors chaîne, tandis que la chaîne Ethereum valide uniquement le résultat final, permettant ainsi une extension à la couche calcul. Certains projets liés à l'IA poussent cette approche à l’extrême, cherchant à associer des modèles d’intelligence artificielle extrêmement gourmands en calcul à la blockchain – une tendance à surveiller attentivement.
Base de données
Concernant la base de données, l'EVM prend nativement en charge le stockage clé-valeur (KV), suffisant pour de nombreux cas d’usage. Mais le problème central reste : le coût du stockage sur chaîne est excessivement élevé.
À quel point est-il élevé ? Avec un prix du gaz à 10 Gwei, stocker 1 Go de données sur chaîne coûterait plus de 6 200 ETH, soit plus de 20 millions de dollars ! Le coût du stockage devient donc le principal obstacle à la décentralisation de la base de données.
On pourrait envisager une solution similaire à l’extension du calcul : stocker les données hors chaîne tout en vérifiant leur existence sur chaîne. Nous développerons plus loin cette approche.
Après avoir analysé les composants d’une DApp, il apparaît clairement que seule une DApp dont tous les composants sont sécurisés et à confiance minimale peut véritablement être qualifiée de décentralisée. En tant que plateforme d’exécution et d’hébergement des dApps, Ethereum doit fournir aux développeurs des solutions adaptées pour favoriser un écosystème conforme à sa vision initiale.
Solutions à confiance minimale pour les DApps
Pour permettre aux DApps d'être entièrement déployées et accessibles via Ethereum, l'équipe EthStorage propose deux solutions :
-
Protocole d'accès web3:// : Résout le problème du déploiement et de l'accès au code frontend via des contrats intelligents, voire à un système de fichiers similaire.
-
Protocole de stockage en couche 2 EthStorage : Réduit drastiquement les coûts de stockage tout en préservant la sécurité d'Ethereum.
Protocole d'accès web3://
Le protocole web3:// peut être vu comme la version décentralisée de http://. Alors que les URL HTTP spécifient une adresse IP ou un nom de domaine pour accéder à des ressources centralisées, les URL web3 spécifient une adresse de contrat intelligent ou un nom ENS pour accéder aux ressources stockées dessus.
Nous pouvons ainsi déployer l'intégralité du frontend d'un site web dans un contrat intelligent et y accéder via web3:// ! Comparons les deux approches :
web3:// est désormais une norme officielle d'Ethereum (ERC-4804). Pour en savoir plus, rendez-vous sur son site officiel. Afin de faciliter la gestion des fichiers dans les contrats intelligents, nous avons proposé l'ERC-5018, qui simule une interface de système de fichiers au sein d’un contrat intelligent. Grâce à ethfs-cli, il devient possible de charger un dossier contenant le code frontend compilé vers un contrat intelligent et d'y accéder via web3://.
Si vous êtes intéressés, suivez notre tutoriel pour déployer et accéder à votre première DApp décentralisée.
Grâce au protocole web3://, le frontend d'une dApp acquiert enfin la propriété « Code is law ». Pour les développeurs, une fois déployé, ce frontend s'exécutera éternellement. Imaginez si Uniswap Labs avait aussi déployé son frontend sur Ethereum : même s'ils voulaient imposer des restrictions ou de la censure au niveau du frontend, cela ne pourrait empêcher personne d'utiliser la version déployée sur Ethereum.
Bien sûr, après avoir résolu la faisabilité technique, nous avons conscience que le coût du stockage massif sur chaîne reste prohibitif. C’est pourquoi nous avons développé le protocole EthStorage en couche 2, réduisant fortement les coûts tout en conservant la sécurité d'Ethereum.
Protocole de stockage en couche 2 EthStorage
Le protocole EthStorage repose sur un contrat intelligent déployé sur Ethereum et des nœuds de stockage situés dans un réseau en couche 2. Le contrat intelligent assure le stockage clé-valeur, tandis que les nœuds en couche 2 stockent physiquement les données.
Les utilisateurs téléchargent les données via les BLOBs d'EIP-4844 sur Ethereum. Le contrat intelligent EthStorage n'enregistre que le hachage des données du BLOB, réduisant efficacement les coûts de stockage.
Parallèlement, les nœuds de stockage en couche 2 téléchargent les données BLOB sur leur disque local, puis génèrent une preuve de stockage via PoRA (Proof of Random Access) et des preuves ZK, qu’ils soumettent au contrat sur Ethereum pour validation. Ce dernier utilise le hachage BLOB précédemment enregistré pour vérifier que la preuve ZK correspond bien aux données, confirmant ainsi que les nœuds en couche 2 stockent effectivement les données.
Le processus détaillé est le suivant :
Pour les développeurs, les interfaces de lecture et écriture des données sont extrêmement simples :
Les développeurs peuvent utiliser directement les interfaces du contrat EthStorage pour lire et écrire de grands volumes de données, avec un coût d'écriture environ mille fois inférieur au stockage direct sur chaîne. Ainsi, EthStorage permet non seulement le déploiement du frontend sur chaîne, mais offre aussi une solution économique pour des opérations de base de données clé-valeur à grande échelle.
Actuellement, EthStorage a obtenu une subvention officielle d'Ethereum et a déjà déployé un réseau test public sur Sepolia. Toute la communauté est invitée à participer.
Conclusion et perspectives
Les composants essentiels de la plupart des DApps – comme le frontend et la base de données – ne sont pas déployés sur Ethereum, privant ces applications de la sécurité de la chaîne. Elles ne peuvent donc pas, dans leur ensemble, s’exécuter éternellement, résister à la censure ou être gérées de façon décentralisée.
Face à ce constat, EthStorage propose deux solutions : le protocole d'accès web3:// pour déployer et accéder au frontend via des contrats intelligents, et le protocole de stockage en couche 2 EthStorage pour résoudre le problème du coût élevé du stockage.
Pour concrétiser la vision originelle d'Ethereum, nous pensons qu’il va évoluer vers un serveur Web décentralisé, où toutes les applications décentralisées déployeront l’intégralité de leurs composants – code backend, frontend et données – sur Ethereum. Une fois déployés, le code s’exécutera éternellement et les données resteront accessibles indéfiniment, donnant naissance à de véritables DApps inarrêtables (Unstoppable Dapps).
La phase de test public d’EthStorage lance actuellement sa deuxième campagne incitative. Les membres de la communauté intéressés peuvent suivre le Guide pour déployer et accéder à leur premier Unstoppable Dapp !
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@EthStorage
