a16z Crypto lance Helios light client : un accès véritablement sans confiance à Ethereum
Le 8 novembre 2023, a16z Crypto a lancé Helios, un client léger Ethereum développé en Rust, qui vise à fournir un accès totalement sans confiance au réseau Ethereum.
L'une des valeurs fondamentales de la technologie blockchain est de permettre aux utilisateurs de ne pas avoir à dépendre de la confiance d'un tiers, leur permettant ainsi de contrôler véritablement leur richesse et leurs données. Les blockchains comme Ethereum ont en grande partie réalisé cette promesse, garantissant que nos actifs nous appartiennent réellement.
Cependant, pour des raisons de commodité, la plupart des utilisateurs ont fait certains compromis lors de l'utilisation de la blockchain. L'un des compromis les plus évidents est de dépendre des serveurs RPC( centralisés pour les appels à distance ). Les utilisateurs accèdent généralement au réseau Ethereum via certains fournisseurs de services centralisés. Ces entreprises exécutent des nœuds haute performance sur des serveurs cloud, aidant les utilisateurs à obtenir facilement des données en chaîne. Lorsque le portefeuille interroge le solde des jetons ou vérifie l'état des transactions, cela se fait presque toujours par le biais de ces services centralisés.
Le principal problème du système actuel est que les utilisateurs doivent faire confiance à ces fournisseurs et ne peuvent pas vérifier eux-mêmes l'exactitude des informations obtenues.
Helios : léger et entièrement vérifiable
Helios, en tant que light client Ethereum basé sur Rust, offre un accès pratique à la blockchain sans compromettre la sécurité. Il utilise le protocole light client mis en place après que Ethereum a adopté PoS pour convertir les données provenant de fournisseurs RPC centralisés non fiables en RPC local sécurisé et vérifiable. En collaboration avec les RPC centralisés, Helios peut vérifier l'authenticité des données sans exécuter de nœud complet.
Ce léger client peut synchroniser en environ deux secondes, sans espace de stockage supplémentaire, permettant aux utilisateurs d'accéder en toute sécurité aux données sur la chaîne via n'importe quel appareil (, y compris les téléphones et les plugins de navigateur ).
Risques potentiels des infrastructures centralisées
Dans la "forêt sombre" d'Ethereum, il existe des risques théoriques. Ces risques ne proviennent pas des attaques frontales dans le pool de mémoire des transactions (Mempool), mais plutôt de la mise en place de pièges à travers la simulation des infrastructures centralisées sur lesquelles nous comptons.
Les utilisateurs victimes de ce type d'attaque n'ont peut-être commis aucune erreur : ils ont simplement accédé à un DEX couramment utilisé, ont défini un glissement raisonnable et ont effectué des transactions de jetons normales. Cependant, ils peuvent toujours faire face à une attaque sandwich particulière, qui se cache à l'entrée d'accès d'Ethereum — les fournisseurs RPC.
Lorsqu’un utilisateur exécute une transaction sur le DEX, plusieurs paramètres sont fournis au contrat intelligent : le jeton à échanger, le nombre de transactions et le nombre minimum de jetons que l’utilisateur est prêt à accepter ( c’est-à-dire le ) de glissement. Si le slippage est correctement réglé, l’utilisateur ne subira théoriquement pas d’attaque en sandwich. Mais que se passe-t-il si le fournisseur de bacs réutilisables ne fournit pas un devis précis pour le contrat DEX ? Les utilisateurs peuvent être induits en erreur en signant des transactions avec un montant minimum d’acceptation inférieur. Pour aggraver les choses, les utilisateurs peuvent envoyer des transactions directement à des fournisseurs de RPC malveillants, qui peuvent garder ces transactions privées et les envoyer directement aux producteurs de blocs par le biais de canaux spécifiques à des fins lucratives.
La cause fondamentale de ce type d'attaque est que les utilisateurs doivent dépendre de tiers pour obtenir l'état de la blockchain. Pour résoudre ce problème, les utilisateurs expérimentés choisissent généralement de faire fonctionner leur propre nœud Ethereum, mais 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. Bien que ce processus ait été simplifié par rapport au passé, il reste difficile à réaliser pour la plupart des utilisateurs, en particulier pour ceux utilisant des appareils mobiles.
Il convient de noter que, bien que l'attaque des fournisseurs RPC centralisés soit théoriquement tout à fait possible, aucun fournisseur majeur et connu n'a encore été trouvé en train de se livrer à de telles pratiques. Néanmoins, avant d'ajouter des fournisseurs RPC inconnus à votre portefeuille, il est toujours nécessaire de mener des recherches approfondies.
Fonctionnement de Helios : analyse approfondie
L’introduction par Ethereum du protocole client léger a créé de nouvelles possibilités pour des interactions rapides avec la blockchain et la vérification des points de terminaison RPC avec des exigences matérielles minimales. Dans le mois qui a suivi la fusion (The Merge), un certain nombre de projets de clients légers distincts, (Lodestar, Nimbus et Kevlar) basés sur JavaScript, ont émergé, chacun avec une approche différente. Mais ils poursuivent tous le même objectif : fournir un accès fiable et efficace sans exécuter un nœud complet.
Helios, comme tous les clients Ethereum, est composé d'une couche d'exécution et d'une couche de consensus. Mais contrairement à la plupart des clients, Helios combine ces deux couches de manière étroite, permettant à l'utilisateur d'installer et d'exécuter un seul logiciel.
couche de consensus
Le client léger de couche consensus d’Helios suit la spécification du client léger Beacon Chain, en s’appuyant sur le comité de synchronisation de la Beacon Chain ( en introduisant ) dans le hard fork Altair. Le comité de synchronisation est un groupe de 512 validateurs sélectionnés au hasard avec un cycle de service d’environ 27 heures.
Les validateurs signent tous les en-têtes de blocs de la chaîne de balisage qu'ils voient au sein du comité de synchronisation. Si plus des deux tiers des membres du comité signent l'en-tête du bloc, alors ce bloc est presque certainement positionné dans la chaîne de balisage conforme. Lorsque Helios comprend la composition actuelle du comité de synchronisation, il peut suivre de manière fiable la tête de chaîne en interrogeant les signatures récentes du comité de synchronisation.
Grâce à la technologie d'agrégation des signatures BLS, une seule requête suffit pour valider l'en-tête d'un nouveau bloc. Tant que la signature est valide et que plus des deux tiers des membres du comité ont signé, cela garantit que le bloc a été inclus dans la chaîne.
Le système doit d’abord obtenir un point de contrôle de subjectivité faible (weak la subjectivité checkpoint) comme source de confiance. Il s’agit d’un hachage de bloc qui est garanti d’avoir été inclus dans la chaîne à un moment donné dans le passé. Grâce à ce point de contrôle, Helios peut capturer et vérifier les comités de synchronisation actuels et suivants afin d’examiner rapidement l’historique de la blockchain et de se synchroniser avec le dernier bloc.
couche d'exécution
L'objectif du light client de la couche d'exécution est d'utiliser l'en-tête du bloc de balises validé par la couche de consensus en combinaison avec un RPC de la couche d'exécution non fiable, fournissant ainsi des données de la couche d'exécution vérifiées. Ensuite, ces données sont accessibles via un serveur RPC hébergé localement par Helios.
Ethereum stocke les informations de compte via l'arbre d'état, y compris le hachage du code des contrats, un nombre aléatoire, le hachage de stockage et le solde. Tant que la racine de l'arbre d'état est connue, il est possible de vérifier la preuve Merkle, prouvant l'existence de tout compte dans l'arbre, cette preuve ne peut pas être falsifiée.
Helios obtient la racine d'état vérifiée de la couche de consensus et l'associe à la demande de preuve Merkle de la couche d'exécution non fiable, permettant une vérification locale de toutes les données stockées sur Ethereum. De cette manière, les RPC non fiables peuvent refuser d'accorder l'accès aux données, mais ne peuvent pas fournir de résultats erronés.
Applications pratiques de Helios
Le design léger de Helios permet aux utilisateurs d'accéder en toute sécurité aux données blockchain depuis n'importe quel appareil (, y compris les téléphones et les plugins de navigateur ). Les utilisateurs peuvent configurer Helios comme fournisseur RPC dans MetaMask, permettant un accès sans confiance à divers DApp sans aucune autre modification.
De plus, le bon support de Rust pour WebAssembly permet aux développeurs d'applications d'incorporer facilement Helios dans des applications JavaScript ( telles que des portefeuilles et des DApp ). Ces intégrations amélioreront la sécurité d'Ethereum et réduiront la dépendance à l'égard des infrastructures centralisées.
La communauté peut contribuer à Helios de plusieurs manières, y compris :
Prend en charge l'acquisition de données de light client directement depuis le réseau P2P
Implémenter les méthodes RPC manquantes
Construire une version de Helios pouvant être compilée en WebAssembly
Intégrer Helios directement dans le logiciel de portefeuille
Construire un tableau de bord réseau pour voir le solde des jetons
Connectez la couche de consensus Helios aux nœuds complets de la couche d'exécution existante
Le code source de ce projet est open source, les développeurs intéressés sont les bienvenus pour contribuer.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
14 J'aime
Récompense
14
10
Partager
Commentaire
0/400
CryptoCross-TalkClub
· Il y a 13h
La chaîne ne fait pas confiance aux gens, elle fait confiance aux serveurs.
a16z lance Helios, un nouveau client léger pour accéder à Ethereum sans confiance.
a16z Crypto lance Helios light client : un accès véritablement sans confiance à Ethereum
Le 8 novembre 2023, a16z Crypto a lancé Helios, un client léger Ethereum développé en Rust, qui vise à fournir un accès totalement sans confiance au réseau Ethereum.
L'une des valeurs fondamentales de la technologie blockchain est de permettre aux utilisateurs de ne pas avoir à dépendre de la confiance d'un tiers, leur permettant ainsi de contrôler véritablement leur richesse et leurs données. Les blockchains comme Ethereum ont en grande partie réalisé cette promesse, garantissant que nos actifs nous appartiennent réellement.
Cependant, pour des raisons de commodité, la plupart des utilisateurs ont fait certains compromis lors de l'utilisation de la blockchain. L'un des compromis les plus évidents est de dépendre des serveurs RPC( centralisés pour les appels à distance ). Les utilisateurs accèdent généralement au réseau Ethereum via certains fournisseurs de services centralisés. Ces entreprises exécutent des nœuds haute performance sur des serveurs cloud, aidant les utilisateurs à obtenir facilement des données en chaîne. Lorsque le portefeuille interroge le solde des jetons ou vérifie l'état des transactions, cela se fait presque toujours par le biais de ces services centralisés.
Le principal problème du système actuel est que les utilisateurs doivent faire confiance à ces fournisseurs et ne peuvent pas vérifier eux-mêmes l'exactitude des informations obtenues.
Helios : léger et entièrement vérifiable
Helios, en tant que light client Ethereum basé sur Rust, offre un accès pratique à la blockchain sans compromettre la sécurité. Il utilise le protocole light client mis en place après que Ethereum a adopté PoS pour convertir les données provenant de fournisseurs RPC centralisés non fiables en RPC local sécurisé et vérifiable. En collaboration avec les RPC centralisés, Helios peut vérifier l'authenticité des données sans exécuter de nœud complet.
Ce léger client peut synchroniser en environ deux secondes, sans espace de stockage supplémentaire, permettant aux utilisateurs d'accéder en toute sécurité aux données sur la chaîne via n'importe quel appareil (, y compris les téléphones et les plugins de navigateur ).
Risques potentiels des infrastructures centralisées
Dans la "forêt sombre" d'Ethereum, il existe des risques théoriques. Ces risques ne proviennent pas des attaques frontales dans le pool de mémoire des transactions (Mempool), mais plutôt de la mise en place de pièges à travers la simulation des infrastructures centralisées sur lesquelles nous comptons.
Les utilisateurs victimes de ce type d'attaque n'ont peut-être commis aucune erreur : ils ont simplement accédé à un DEX couramment utilisé, ont défini un glissement raisonnable et ont effectué des transactions de jetons normales. Cependant, ils peuvent toujours faire face à une attaque sandwich particulière, qui se cache à l'entrée d'accès d'Ethereum — les fournisseurs RPC.
Lorsqu’un utilisateur exécute une transaction sur le DEX, plusieurs paramètres sont fournis au contrat intelligent : le jeton à échanger, le nombre de transactions et le nombre minimum de jetons que l’utilisateur est prêt à accepter ( c’est-à-dire le ) de glissement. Si le slippage est correctement réglé, l’utilisateur ne subira théoriquement pas d’attaque en sandwich. Mais que se passe-t-il si le fournisseur de bacs réutilisables ne fournit pas un devis précis pour le contrat DEX ? Les utilisateurs peuvent être induits en erreur en signant des transactions avec un montant minimum d’acceptation inférieur. Pour aggraver les choses, les utilisateurs peuvent envoyer des transactions directement à des fournisseurs de RPC malveillants, qui peuvent garder ces transactions privées et les envoyer directement aux producteurs de blocs par le biais de canaux spécifiques à des fins lucratives.
La cause fondamentale de ce type d'attaque est que les utilisateurs doivent dépendre de tiers pour obtenir l'état de la blockchain. Pour résoudre ce problème, les utilisateurs expérimentés choisissent généralement de faire fonctionner leur propre nœud Ethereum, mais 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. Bien que ce processus ait été simplifié par rapport au passé, il reste difficile à réaliser pour la plupart des utilisateurs, en particulier pour ceux utilisant des appareils mobiles.
Il convient de noter que, bien que l'attaque des fournisseurs RPC centralisés soit théoriquement tout à fait possible, aucun fournisseur majeur et connu n'a encore été trouvé en train de se livrer à de telles pratiques. Néanmoins, avant d'ajouter des fournisseurs RPC inconnus à votre portefeuille, il est toujours nécessaire de mener des recherches approfondies.
Fonctionnement de Helios : analyse approfondie
L’introduction par Ethereum du protocole client léger a créé de nouvelles possibilités pour des interactions rapides avec la blockchain et la vérification des points de terminaison RPC avec des exigences matérielles minimales. Dans le mois qui a suivi la fusion (The Merge), un certain nombre de projets de clients légers distincts, (Lodestar, Nimbus et Kevlar) basés sur JavaScript, ont émergé, chacun avec une approche différente. Mais ils poursuivent tous le même objectif : fournir un accès fiable et efficace sans exécuter un nœud complet.
Helios, comme tous les clients Ethereum, est composé d'une couche d'exécution et d'une couche de consensus. Mais contrairement à la plupart des clients, Helios combine ces deux couches de manière étroite, permettant à l'utilisateur d'installer et d'exécuter un seul logiciel.
couche de consensus
Le client léger de couche consensus d’Helios suit la spécification du client léger Beacon Chain, en s’appuyant sur le comité de synchronisation de la Beacon Chain ( en introduisant ) dans le hard fork Altair. Le comité de synchronisation est un groupe de 512 validateurs sélectionnés au hasard avec un cycle de service d’environ 27 heures.
Les validateurs signent tous les en-têtes de blocs de la chaîne de balisage qu'ils voient au sein du comité de synchronisation. Si plus des deux tiers des membres du comité signent l'en-tête du bloc, alors ce bloc est presque certainement positionné dans la chaîne de balisage conforme. Lorsque Helios comprend la composition actuelle du comité de synchronisation, il peut suivre de manière fiable la tête de chaîne en interrogeant les signatures récentes du comité de synchronisation.
Grâce à la technologie d'agrégation des signatures BLS, une seule requête suffit pour valider l'en-tête d'un nouveau bloc. Tant que la signature est valide et que plus des deux tiers des membres du comité ont signé, cela garantit que le bloc a été inclus dans la chaîne.
Le système doit d’abord obtenir un point de contrôle de subjectivité faible (weak la subjectivité checkpoint) comme source de confiance. Il s’agit d’un hachage de bloc qui est garanti d’avoir été inclus dans la chaîne à un moment donné dans le passé. Grâce à ce point de contrôle, Helios peut capturer et vérifier les comités de synchronisation actuels et suivants afin d’examiner rapidement l’historique de la blockchain et de se synchroniser avec le dernier bloc.
couche d'exécution
L'objectif du light client de la couche d'exécution est d'utiliser l'en-tête du bloc de balises validé par la couche de consensus en combinaison avec un RPC de la couche d'exécution non fiable, fournissant ainsi des données de la couche d'exécution vérifiées. Ensuite, ces données sont accessibles via un serveur RPC hébergé localement par Helios.
Ethereum stocke les informations de compte via l'arbre d'état, y compris le hachage du code des contrats, un nombre aléatoire, le hachage de stockage et le solde. Tant que la racine de l'arbre d'état est connue, il est possible de vérifier la preuve Merkle, prouvant l'existence de tout compte dans l'arbre, cette preuve ne peut pas être falsifiée.
Helios obtient la racine d'état vérifiée de la couche de consensus et l'associe à la demande de preuve Merkle de la couche d'exécution non fiable, permettant une vérification locale de toutes les données stockées sur Ethereum. De cette manière, les RPC non fiables peuvent refuser d'accorder l'accès aux données, mais ne peuvent pas fournir de résultats erronés.
Applications pratiques de Helios
Le design léger de Helios permet aux utilisateurs d'accéder en toute sécurité aux données blockchain depuis n'importe quel appareil (, y compris les téléphones et les plugins de navigateur ). Les utilisateurs peuvent configurer Helios comme fournisseur RPC dans MetaMask, permettant un accès sans confiance à divers DApp sans aucune autre modification.
De plus, le bon support de Rust pour WebAssembly permet aux développeurs d'applications d'incorporer facilement Helios dans des applications JavaScript ( telles que des portefeuilles et des DApp ). Ces intégrations amélioreront la sécurité d'Ethereum et réduiront la dépendance à l'égard des infrastructures centralisées.
La communauté peut contribuer à Helios de plusieurs manières, y compris :
Le code source de ce projet est open source, les développeurs intéressés sont les bienvenus pour contribuer.