- Rubrique
57k Popularité
18k Popularité
5k Popularité
3k Popularité
4k Popularité
29k Popularité
16k Popularité
22k Popularité
12k Popularité
2k Popularité
- Épingler
57k Popularité
18k Popularité
5k Popularité
3k Popularité
4k Popularité
29k Popularité
16k Popularité
22k Popularité
12k Popularité
2k Popularité
Helios : implémentation d'un light client Ethereum pour un accès sans confiance aux données off-chain
Client léger Ethereum Helios : accès aux données off-chain sans confiance
Le 8 novembre, une célèbre société de capital-risque a lancé le client léger Ethereum Helios. Ce client, développé en langage Rust, vise à fournir un accès à Ethereum entièrement sans confiance.
Un des grands avantages de la technologie blockchain est qu'elle ne nécessite pas de faire confiance à un tiers. Grâce à la blockchain, les utilisateurs peuvent contrôler eux-mêmes leur richesse et leurs données. Les blockchains comme Ethereum ont en effet réalisé cette promesse dans la plupart des cas : nos actifs nous appartiennent véritablement.
Cependant, pour des raisons de commodité, nous avons également fait quelques compromis. L'un d'eux est l'utilisation de serveurs RPC (appel de procédure à distance) centralisés. Les utilisateurs accèdent généralement à Ethereum via des fournisseurs centralisés. Ces entreprises exécutent des nœuds haute performance sur des serveurs cloud, aidant les utilisateurs à obtenir facilement des données off-chain. Lorsque le portefeuille interroge le solde des jetons ou vérifie si les transactions en attente ont été incluses, ces services de fournisseurs centralisés sont presque toujours utilisés.
Le problème actuel du système est que les utilisateurs doivent faire confiance à ces fournisseurs, sans pouvoir vérifier l'exactitude des résultats des requêtes.
Helios est un client léger Ethereum basé sur Rust, capable de fournir un accès Ethereum entièrement sans confiance. Il utilise le protocole client léger mis en œuvre après la transition d'Ethereum vers PoS, permettant de convertir les données provenant de fournisseurs RPC centralisés non fiables en RPC local sécurisé et vérifiable. En combinant avec RPC centralisé, Helios peut vérifier l'authenticité des données sans avoir besoin d'exécuter un nœud complet.
La difficulté de concilier commodité et décentralisation est un point de douleur universellement présent. Ce nouveau type de client (ouvert au développement public) peut synchroniser en environ deux secondes, sans nécessiter d'espace de stockage, permettant aux utilisateurs d'accéder en toute sécurité aux données off-chain via n'importe quel appareil (y compris les smartphones et les plug-ins de navigateur). Alors, quels sont les risques potentiels liés à la dépendance aux infrastructures centralisées ? Cet article explorera en détail ces risques, présentera le design de Helios et fournira quelques conseils pour aider les développeurs à contribuer à la base de code.
Risques potentiels des infrastructures centralisées : menaces théoriques dans l'écosystème Ethereum
Dans l'écosystème Ethereum, il existe une menace théorique latente. Elle ne cherche pas de cibles dans la mémoire des transactions (Mempool), mais elle tend des pièges en imitant l'infrastructure centralisée sur laquelle nous comptons. Les utilisateurs qui tombent dans ce piège n'ont rien fait de mal : ils accèdent simplement à un DEX familier comme d'habitude, configurent un glissement raisonnable et effectuent des échanges de tokens... Leur opération ne pose aucun problème, mais ils peuvent être confrontés à un nouveau type d'attaque sandwich, qui est un piège soigneusement placé à l'entrée de l'écosystème Ethereum - le fournisseur RPC.
Avant de détailler, voyons d'abord comment le DEX traite les transactions. Lorsque les utilisateurs échangent des tokens, ils fournissent plusieurs paramètres au contrat intelligent : le token à échanger, le montant de l'échange, et, le plus crucial, le nombre minimum de tokens que l'utilisateur est prêt à accepter. Ce dernier paramètre détermine le "rendement minimum" que l'échange doit atteindre, sinon la transaction sera annulée. Cela est souvent appelé "slippage", car cela limite effectivement la fluctuation maximale des prix qui pourrait se produire entre l'envoi de la transaction au mempool et son inclusion dans un bloc. Si le slippage est réglé trop bas, l'utilisateur pourrait ne recevoir qu'un nombre réduit de tokens. Cette situation peut également entraîner des attaques par sandwich, où un attaquant pourrait intercaler la transaction de l'utilisateur entre deux transactions malveillantes. Ces transactions feront monter le prix au comptant, forçant l'utilisateur à conclure à un prix désavantageux. Ensuite, l'attaquant vendra immédiatement les tokens pour réaliser un petit profit.
Tant que le paramètre de production minimum est réglé dans une plage raisonnable, l'utilisateur ne sera pas affecté par les attaques sandwich. Mais que se passe-t-il si le fournisseur RPC ne fournit pas de cotations précises pour le contrat intelligent DEX ? Dans ce cas, l'utilisateur pourrait être induit en erreur et signer une transaction d'échange avec un paramètre de production minimum trop bas. Pire encore, l'utilisateur pourrait envoyer la transaction directement à un fournisseur RPC malveillant. Le fournisseur peut choisir de ne pas diffuser cette transaction dans la mémoire publique (où de nombreux robots rivalisent pour mener des attaques sandwich), mais plutôt de la conserver en privé et d'envoyer directement le paquet de transaction ciblé à une plateforme spécifique afin d'en tirer profit.
La cause fondamentale de cette attaque réside dans la confiance accordée aux autres pour aider à obtenir l'état de la blockchain. Pour remédier à ce problème, les utilisateurs expérimentés choisissent souvent de faire fonctionner leur propre nœud Ethereum. Cela nécessite un investissement considérable en temps et en ressources, au moins un appareil en ligne en permanence, plusieurs centaines de Go d'espace de stockage, et environ une journée pour se synchroniser depuis le début. Bien que ce processus ait été simplifié par rapport à avant, certaines équipes s'efforcent d'aider les utilisateurs à faire fonctionner des nœuds avec du matériel peu coûteux (comme un Raspberry Pi avec un disque dur externe). Mais même si les exigences sont considérablement réduites, faire fonctionner un nœud reste une tâche ardue pour la plupart des utilisateurs, en particulier pour ceux qui utilisent des appareils mobiles.
Il est important de noter que bien que les attaques de fournisseurs RPC centralisés soient tout à fait possibles, elles ne sont pour l'instant qu'un risque théorique et n'ont pas encore eu lieu dans la pratique. Bien que les antécédents des fournisseurs principaux soient dignes de confiance, il est toujours recommandé de faire des recherches approfondies avant d'ajouter des fournisseurs RPC inconnus à votre portefeuille.
Introduction à Helios : accès à Ethereum totalement sans confiance
Le protocole de light client lancé par Ethereum ouvre des possibilités passionnantes pour des interactions rapides avec la blockchain et la vérification des points de terminaison RPC avec des exigences matérielles minimales. Un mois après la fusion, plusieurs light clients indépendants sont apparus successivement, adoptant différentes approches, mais visant tous le même objectif : un accès efficace sans confiance, sans avoir à utiliser de nœuds complets.
Helios est un client léger Ethereum qui peut synchroniser en environ deux secondes, sans nécessiter d'espace de stockage, et offre un accès Ethereum totalement sans confiance. Comme tous les clients Ethereum, Helios est composé d'une couche d'exécution et d'une couche de consensus. Mais contrairement à la plupart des autres clients, Helios combine ces deux couches de manière étroite, permettant à l'utilisateur d'installer et d'exécuter un seul logiciel.
Son fonctionnement est le suivant : la couche de consensus Helios utilise un hachage de bloc de la chaîne de balises connu et se connecte à un RPC non fiable pour synchroniser de manière vérifiable le bloc actuel. La couche d'exécution Helios combine ces blocs de chaîne de balises vérifiés avec des RPC d'exécution non fiables pour vérifier diverses informations concernant l'état on-chain, telles que les soldes de compte, le stockage de contrats, les reçus de transactions et les résultats des appels de contrats intelligents. Ces composants travaillent ensemble pour fournir aux utilisateurs un RPC totalement sans confiance, sans avoir besoin d'exécuter un nœud complet.
couche de consensus
Le light client de la couche de consensus suit les spécifications du light client de la chaîne de balises et utilise le comité de synchronisation de la chaîne de balises (introduit dans le hard fork Altair avant la fusion). Le comité de synchronisation est un sous-ensemble de 512 validateurs choisis au hasard, avec une durée de service d'environ 27 heures.
Les validateurs signent tous les en-têtes de blocs de la chaîne de balises qu'ils voient après être entrés dans le comité de synchronisation. Si plus des deux tiers des membres du comité signent un en-tête de bloc, il est très probable que ce bloc se trouve dans la chaîne de balises conforme. Si Helios comprend la composition actuelle du comité de synchronisation, il peut suivre la tête de chaîne avec une grande certitude en interrogeant un RPC non fiable pour les signatures récentes du comité de synchronisation.
Grâce à l'agrégation des signatures BLS, une seule requête suffit pour valider le nouvel en-tête de bloc. Tant que la signature est valide et que plus des deux tiers des membres du comité ont signé, il est garanti que le bloc a été inclus dans la chaîne (bien sûr, il peut également être réorganisé en dehors de la chaîne, et le suivi de la finalité du bloc peut fournir une garantie plus forte).
Mais il manque manifestement un élément dans cette stratégie : comment trouver le comité de synchronisation actuel. Il faut d'abord obtenir une racine de confiance appelée point de contrôle de faible subjectivité. C'est simplement un ancien hash de bloc qui peut garantir qu'il a été intégré à la chaîne à un moment donné dans le passé. Concernant le temps exact d'existence du point de contrôle, il y a quelques calculs mathématiques intéressants derrière : l'analyse du pire scénario montre environ deux semaines, tandis qu'une estimation plus réaliste indique plusieurs mois.
Si le point de contrôle est trop ancien, il existe théoriquement une attaque pouvant tromper les nœuds en les incitant à suivre une chaîne erronée. À ce stade, obtenir un point de contrôle de faible subjectivité dépasse les capacités du protocole. La solution de Helios est de fournir un point de contrôle initial, codé en dur dans le code source (facilement contournable), qui sauvegarde localement le dernier hachage de bloc final afin de servir de point de contrôle lors de la synchronisation des nœuds.
Grâce à l'opération de hachage, les blocs de la chaîne de balise peuvent facilement générer un hachage de bloc de balise unique. Cela permet de consulter facilement le bloc de balise complet auprès des nœuds, puis de prouver la validité du contenu du bloc en effectuant une opération de hachage et en comparant avec le hachage de bloc connu. Helios utilise cette caractéristique pour obtenir et vérifier certains champs dans les blocs de points de contrôle de subjectivité faible, y compris deux champs cruciaux : le comité de synchronisation actuel et le prochain comité de synchronisation. Le plus important est que le client léger peut utiliser ce mécanisme pour vérifier rapidement l'historique de la chaîne de blocs.
Une fois que nous avons un point de contrôle de faible subjectivité, nous pouvons obtenir et vérifier le comité de synchronisation actuel et le suivant. Si le chef de chaîne actuel et le point de contrôle se trouvent dans le même cycle de comité de synchronisation, nous pouvons immédiatement commencer à utiliser le chef de comité de synchronisation signé pour vérifier les nouveaux blocs. Si notre point de contrôle est en retard de plusieurs comités de synchronisation, nous pouvons :
Utiliser le prochain comité de synchronisation après le point de contrôle pour obtenir et vérifier les blocs qui généreront un comité de synchronisation dans le futur.
Utilisez ce nouveau bloc pour obtenir le prochain comité de synchronisation.
Si le point de contrôle est encore derrière, retournez à l'étape 1.
Grâce à ce processus, nous pouvons rapidement vérifier l'historique de cette blockchain par intervalles de 27 heures, en commençant par n'importe quel hachage de bloc passé et en synchronisant jusqu'au hachage de bloc actuel.
couche d'exécution
L'objectif du client léger de la couche d'exécution est d'utiliser les en-têtes de blocs de balise vérifiés par la couche de consensus en combinaison avec des RPC de la couche d'exécution non vérifiés, afin de fournir des données de la couche d'exécution vérifiées. Ces données peuvent ensuite être consultées via un serveur RPC hébergé localement par Helios.
Prenons l'exemple de l'obtention du solde d'un compte pour expliquer simplement comment Ethereum stocke l'état. Chaque compte contient plusieurs champs, tels que le hash du code du contrat, le nombre aléatoire, le hash de stockage et le solde. Ces comptes sont stockés dans un grand arbre Merkle-Patricia modifié, appelé arbre d'état. Tant que l'on connaît la racine de l'arbre d'état, on peut vérifier la preuve Merkle pour prouver l'existence de tout compte dans l'arbre. Cette preuve est irréfutable.
Helios a obtenu la racine d'état vérifiée de la couche de consensus. En appliquant cette racine d'état et la demande de preuve Merkle à un RPC de couche d'exécution non fiable, Helios peut vérifier localement toutes les données stockées sur Ethereum.
Nous utilisons différentes technologies pour valider les diverses données utilisées par la couche d'exécution. De cette manière, nous pouvons valider toutes les données provenant de RPC non fiables. Les RPC non fiables peuvent refuser d'accéder aux données, mais ne peuvent pas fournir de résultats erronés.
Utilisation de Helios dans des environnements complexes
Il est courant de rencontrer des problèmes pour concilier commodité et décentralisation. Grâce au léger Helios, les utilisateurs peuvent accéder en toute sécurité aux données off-chain depuis n'importe quel appareil (y compris les téléphones mobiles et les plug-ins de navigateur). Cela permettra à davantage de personnes d'accéder aux données d'Éther sans avoir à faire confiance, sans être limité par du matériel. Les utilisateurs peuvent configurer Helios comme fournisseur RPC dans certains portefeuilles, permettant un accès sans confiance à diverses DApps, le tout sans nécessiter d'autres modifications.
De plus, le soutien de Rust pour WebAssembly permet aux développeurs d'applications d'intégrer facilement Helios dans des applications JavaScript (comme des portefeuilles et des DApp). Ces intégrations renforceront la sécurité d'Ethereum et réduiront notre dépendance à l'infrastructure centralisée.
La réaction de la communauté à cela est très attendue. Il existe plusieurs façons de contribuer à Helios, en plus d'ajouter des briques à la base de code, en construisant des logiciels intégrant Helios pour tirer parti de ses avantages. Voici quelques idées passionnantes :