Client léger Ethereum Helios : accès à la blockchain sans confiance
Le 8 novembre, un nouveau light client Ethereum, Helios, a été officiellement lancé. Ce client est développé en langage Rust et vise à fournir un accès Ethereum totalement sans confiance.
L'un des principaux objectifs de l'utilisation de la Blockchain est de réaliser un système sans confiance. Grâce à la Blockchain, nous pouvons maîtriser nos richesses et nos données de manière autonome. Dans la plupart des cas, des Blockchains comme Ethereum tiennent réellement cette promesse : nos actifs nous appartiennent vraiment.
Cependant, pour des raisons de commodité, nous avons également fait des compromis. L'un d'eux est l'utilisation d'un appel à distance RPC( centralisé vers le serveur ). 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 tout le monde à accéder facilement aux données sur la chaîne. Lorsque le portefeuille vérifie le solde des jetons ou consulte l'état d'une transaction, ces 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 si les résultats des requêtes sont corrects.
Helios est un light client Ethereum basé sur Rust, capable de fournir un accès à Ethereum entièrement sans confiance. Il utilise le protocole de light client réalisé après le passage d'Ethereum au PoS, pouvant transformer les données provenant de fournisseurs RPC centralisés non fiables en RPC local sécurisé et vérifiable. En combinant RPC centralisés, Helios peut vérifier l'authenticité des données sans avoir besoin d'exécuter un nœud complet.
Ce client peut synchroniser en environ deux secondes, sans nécessiter de stockage. Les utilisateurs peuvent 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 extensions de navigateur ). Mais quels sont les risques potentiels liés à la dépendance à une infrastructure centralisée ? Nous allons analyser ces risques, présenter le design de Helios et fournir quelques idées pour améliorer la bibliothèque de code.
Les risques potentiels des infrastructures centralisées
Une forme théorique d'attaque est latente dans la "forêt sombre" d'Ethereum. Elle ne cherche pas de cibles dans la mémoire des transactions, mais établit des pièges en imitant l'infrastructure centralisée sur laquelle nous comptons. Les utilisateurs peuvent tomber dans le piège même s'ils n'ont pas commis d'erreur : ils échangent simplement sur un DEX comme d'habitude, avec un slippage raisonnable... mais ils peuvent tout de même faire face à un nouveau type d'attaque sandwich, qui est un piège soigneusement placé chez le fournisseur RPC.
Lorsqu'un utilisateur effectue une transaction sur un échange décentralisé, il doit fournir plusieurs paramètres au contrat intelligent : le jeton à échanger, le montant de l'échange, et surtout, le nombre minimum de jetons que l'utilisateur est prêt à accepter. Le dernier paramètre indique le "rendement minimum" que l'échange doit atteindre, sinon la transaction sera annulée. Cela est généralement appelé "slippage", qui fixe effectivement l'écart de prix maximal pouvant survenir entre l'envoi de la transaction et son inscription sur la blockchain. Si le slippage est réglé trop bas, l'utilisateur pourrait ne recevoir que peu de jetons et risquerait également d'être victime d'une attaque sandwich.
Tant que le paramètre de production minimale est réglé dans une plage raisonnable, il ne sera pas affecté par une attaque sandwich. Mais que se passe-t-il si le fournisseur RPC ne fournit pas une estimation précise du contrat intelligent DEX ? Cela pourrait induire les utilisateurs en erreur, en leur faisant signer des transactions d'échange avec des paramètres de production minimale plus bas. Pire encore, les utilisateurs pourraient également envoyer des transactions directement à des fournisseurs RPC malveillants. Les fournisseurs peuvent choisir de ne pas diffuser la transaction dans le pool de mémoire publique, mais plutôt de la retenir en privé et d'envoyer directement le paquet de transactions attaquées à des entités spécifiques pour en tirer profit.
La cause fondamentale de cette attaque est de faire confiance aux autres pour obtenir l'état de la Blockchain. Pour résoudre ce problème, les utilisateurs expérimentés exécutent généralement leur propre nœud Ethereum, mais cela nécessite beaucoup de temps et de ressources, au moins un appareil en ligne en permanence, des centaines de Go d'espace de stockage et environ une journée pour synchroniser depuis le début. Bien que le seuil pour exécuter un nœud ait maintenant été abaissé, cela reste encore très difficile pour la plupart des utilisateurs, en particulier ceux qui utilisent des appareils mobiles.
Il convient de noter que les attaques des fournisseurs RPC centralisés, bien qu'elles puissent tout à fait se produire, ne sont généralement que de simples attaques de phishing, et le type d'attaque que nous décrivons n'a pas encore eu lieu. Bien que les antécédents des fournisseurs de premier plan soient dignes de confiance, il est toujours sage de faire un peu plus de recherches avant d'utiliser des fournisseurs RPC inconnus.
Helios: réaliser un accès à Ethereum sans confiance
Ethereum a lancé un protocole de light client, ouvrant de nouvelles possibilités pour une interaction rapide avec la Blockchain et la validation des points de terminaison RPC avec des exigences matérielles minimales. Un mois après The Merge, plusieurs light clients indépendants ont été lancés, adoptant des méthodes différentes mais ayant un objectif commun : réaliser un accès efficace et sans confiance sans exécuter de nœuds complets.
Helios est un light client Ethereum qui peut synchroniser en environ deux secondes, sans stockage, et offre un accès Ethereum entièrement sans confiance. Comme tous les clients Ethereum, Helios comprend une couche d'exécution et une couche de consensus. Mais contrairement à la plupart des clients, Helios couple étroitement les deux couches, permettant à l'utilisateur d'installer et d'exécuter un seul logiciel.
Le fonctionnement de Helios est le suivant : la couche de consensus utilise un hachage de bloc de chaîne de balise connue et se connecte à un RPC non fiable pour synchroniser de manière vérifiable avec le bloc actuel. La couche d'exécution combine ces blocs de chaîne de balise vérifiés avec un RPC d'exécution non fiable pour vérifier diverses informations sur l'état de la chaîne, telles que les soldes des comptes, le stockage des contrats, les reçus de transaction et les résultats des appels de contrats intelligents. Ces composants travaillent ensemble pour fournir un RPC totalement sans confiance aux utilisateurs, sans avoir besoin d'exécuter un nœud complet.
couche de consensus
Le léger client de la couche de consensus suit les spécifications du léger client de la chaîne de balises, en utilisant le comité de synchronisation de la chaîne de balises. Le comité de synchronisation est un sous-ensemble de 512 validateurs choisis au hasard, avec un cycle de service d'environ 27 heures.
Une fois que les validateurs rejoignent le comité de synchronisation, ils signeront tous les en-têtes de blocs de la chaîne de balises qu'ils voient. Si plus de 2/3 des membres du comité signent un en-tête de bloc, alors ce bloc est très probablement situé dans la chaîne de balises conforme. Si Helios connaît la composition actuelle du comité de synchronisation, il peut suivre de manière fiable le chef de la chaîne en interrogeant les signatures récentes du comité de synchronisation.
Grâce à l'agrégation de signatures BLS, il suffit d'une seule requête pour valider le nouvel en-tête de bloc. Tant que la signature est valide et que plus de 2/3 des membres du comité ont signé, cela garantit que le bloc est inclus dans la chaîne. Bien sûr, le suivi de la finalité du bloc peut fournir une garantie plus forte.
Cette stratégie doit également résoudre la question de savoir comment trouver le comité de synchronisation actuel. Tout d'abord, il faut obtenir une racine de confiance appelée point de contrôle de faible subjectivité. Cela représente un ancien hachage de bloc qui peut être garanti d'avoir été inclus dans la chaîne à un moment donné dans le passé. En ce qui concerne la durée d'existence des points de contrôle, l'analyse théorique montre que dans le pire des cas, cela prend environ deux semaines, tandis que l'estimation réelle peut durer plusieurs mois.
Si le point de contrôle est trop ancien, il existe théoriquement une attaque pouvant tromper les nœuds pour suivre une chaîne erronée. Dans ce cas, obtenir un point de contrôle de faible subjectivité dépasse la capacité du protocole. La solution de Helios est de fournir un point de contrôle initial, codé en dur dans le code source de (, qui peut être facilement écrasé ). Il sauvegardera 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, puis de prouver la validité du contenu du bloc par comparaison de hachage. Helios utilise cette propriété pour obtenir et vérifier les champs clés dans les blocs de points de contrôle de subjectivité faible, y compris 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 examiner rapidement l'historique de la blockchain.
Avec le point de contrôle de subjectivité faible en place, nous pouvons obtenir et vérifier le comité de synchronisation actuel et suivant. Si l'en-tête de la chaîne actuelle et le point de contrôle se trouvent dans le même cycle de comité de synchronisation, nous pouvons immédiatement utiliser l'en-tête du comité de synchronisation signé pour valider le nouveau bloc. Si le point de contrôle est positionné après plusieurs comités de synchronisation, nous pouvons :
Utilisez le prochain comité de synchronisation après le point de contrôle pour obtenir et vérifier un bloc du comité de synchronisation qui sera généré à l'avenir.
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 examiner rapidement l'historique de cette Blockchain par intervalles de 27 heures, en synchronisant depuis n'importe quel hachage de bloc passé jusqu'au hachage de bloc actuel.
couche d'exécution
L'objectif du light client de la couche d'exécution est de combiner les en-têtes de blocs de signaux validés par la couche de consensus avec des RPC de la couche d'exécution non sécurisés, afin de fournir des données de la couche d'exécution vérifiées. Ces données peuvent ensuite être accessibles via un serveur RPC hébergé localement par Helios.
Voici un exemple simple pour obtenir le solde d'un compte, en introduisant brièvement comment Ethereum stocke l'état. Chaque compte contient plusieurs champs, tels que le hachage du code du contrat, un nonce, le hachage du stockage et le solde. Ces comptes sont stockés dans un grand arbre Merkle-Patricia ajusté, appelé arbre d'état. Tant que la racine de l'arbre d'état est connue, il est possible de vérifier les preuves Merkle pour prouver l'existence de tout compte dans l'arbre. Cette preuve ne peut pas être falsifiée.
Helios obtient la racine de l'état vérifiée à partir de la couche de consensus. En appliquant cette racine d'état et la preuve Merkle sur le RPC de la couche d'exécution non fiable, Helios peut valider localement toutes les données stockées dans Ethereum.
Nous utilisons différentes technologies pour vérifier les diverses données utilisées par la couche d'exécution, ce qui nous permet de 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.
Perspectives d'application de Helios
Il est souvent difficile de concilier commodité et décentralisation. Grâce à Helios, un client léger, les utilisateurs peuvent accéder à des données sécurisées sur la chaîne depuis n'importe quel appareil (, y compris un téléphone et un plugin de navigateur ). Cela permettra à un plus grand nombre de personnes d'accéder aux données d'Ethereum sans avoir besoin de faire confiance, quel que soit le matériel utilisé. Les utilisateurs peuvent utiliser Helios comme fournisseur RPC dans leur portefeuille, pour accéder sans confiance à diverses DApp, le tout sans aucune autre modification.
De plus, le support de Rust pour WebAssembly permet aux développeurs d'applications d'intégrer 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 notre besoin de confiance dans les infrastructures centralisées.
La communauté peut contribuer à Helios de plusieurs manières. En plus d'améliorer la base de code, elle peut également développer des logiciels intégrant Helios pour tirer parti de ses avantages. Voici quelques directions de développement potentielles :
Prise en charge de l'obtention directe des données du client léger à partir du réseau P2P, plutôt que de dépendre de RPC
Implémenter les méthodes RPC manquantes
Développer une version Helios pouvant être compilée en WebAssembly
Intégrer Helios directement dans le logiciel de portefeuille
Construire un tableau de bord réseau pour visualiser le solde des jetons, intégrer Helios dans un site Web utilisant WebAssembly pour obtenir des données.
Déployer l'API du moteur, connecter la couche de consensus Helios au nœud complet de la couche d'exécution existante.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
17 J'aime
Récompense
17
4
Reposter
Partager
Commentaire
0/400
BearMarketSurvivor
· Il y a 11h
Le coût de confiance a enfin goutte.
Voir l'originalRépondre0
SerLiquidated
· Il y a 12h
Il est nécessaire de résoudre le cancer de la centralisation.
Voir l'originalRépondre0
FUDwatcher
· 08-06 03:54
Rust est effectivement très puissant
Voir l'originalRépondre0
shadowy_supercoder
· 08-06 03:47
La performance de Rust est vraiment impressionnante.
Helios light client: Mise en œuvre d'un accès aux données Ethereum off-chain sans confiance.
Client léger Ethereum Helios : accès à la blockchain sans confiance
Le 8 novembre, un nouveau light client Ethereum, Helios, a été officiellement lancé. Ce client est développé en langage Rust et vise à fournir un accès Ethereum totalement sans confiance.
L'un des principaux objectifs de l'utilisation de la Blockchain est de réaliser un système sans confiance. Grâce à la Blockchain, nous pouvons maîtriser nos richesses et nos données de manière autonome. Dans la plupart des cas, des Blockchains comme Ethereum tiennent réellement cette promesse : nos actifs nous appartiennent vraiment.
Cependant, pour des raisons de commodité, nous avons également fait des compromis. L'un d'eux est l'utilisation d'un appel à distance RPC( centralisé vers le serveur ). 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 tout le monde à accéder facilement aux données sur la chaîne. Lorsque le portefeuille vérifie le solde des jetons ou consulte l'état d'une transaction, ces 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 si les résultats des requêtes sont corrects.
Helios est un light client Ethereum basé sur Rust, capable de fournir un accès à Ethereum entièrement sans confiance. Il utilise le protocole de light client réalisé après le passage d'Ethereum au PoS, pouvant transformer les données provenant de fournisseurs RPC centralisés non fiables en RPC local sécurisé et vérifiable. En combinant RPC centralisés, Helios peut vérifier l'authenticité des données sans avoir besoin d'exécuter un nœud complet.
Ce client peut synchroniser en environ deux secondes, sans nécessiter de stockage. Les utilisateurs peuvent 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 extensions de navigateur ). Mais quels sont les risques potentiels liés à la dépendance à une infrastructure centralisée ? Nous allons analyser ces risques, présenter le design de Helios et fournir quelques idées pour améliorer la bibliothèque de code.
Les risques potentiels des infrastructures centralisées
Une forme théorique d'attaque est latente dans la "forêt sombre" d'Ethereum. Elle ne cherche pas de cibles dans la mémoire des transactions, mais établit des pièges en imitant l'infrastructure centralisée sur laquelle nous comptons. Les utilisateurs peuvent tomber dans le piège même s'ils n'ont pas commis d'erreur : ils échangent simplement sur un DEX comme d'habitude, avec un slippage raisonnable... mais ils peuvent tout de même faire face à un nouveau type d'attaque sandwich, qui est un piège soigneusement placé chez le fournisseur RPC.
Lorsqu'un utilisateur effectue une transaction sur un échange décentralisé, il doit fournir plusieurs paramètres au contrat intelligent : le jeton à échanger, le montant de l'échange, et surtout, le nombre minimum de jetons que l'utilisateur est prêt à accepter. Le dernier paramètre indique le "rendement minimum" que l'échange doit atteindre, sinon la transaction sera annulée. Cela est généralement appelé "slippage", qui fixe effectivement l'écart de prix maximal pouvant survenir entre l'envoi de la transaction et son inscription sur la blockchain. Si le slippage est réglé trop bas, l'utilisateur pourrait ne recevoir que peu de jetons et risquerait également d'être victime d'une attaque sandwich.
Tant que le paramètre de production minimale est réglé dans une plage raisonnable, il ne sera pas affecté par une attaque sandwich. Mais que se passe-t-il si le fournisseur RPC ne fournit pas une estimation précise du contrat intelligent DEX ? Cela pourrait induire les utilisateurs en erreur, en leur faisant signer des transactions d'échange avec des paramètres de production minimale plus bas. Pire encore, les utilisateurs pourraient également envoyer des transactions directement à des fournisseurs RPC malveillants. Les fournisseurs peuvent choisir de ne pas diffuser la transaction dans le pool de mémoire publique, mais plutôt de la retenir en privé et d'envoyer directement le paquet de transactions attaquées à des entités spécifiques pour en tirer profit.
La cause fondamentale de cette attaque est de faire confiance aux autres pour obtenir l'état de la Blockchain. Pour résoudre ce problème, les utilisateurs expérimentés exécutent généralement leur propre nœud Ethereum, mais cela nécessite beaucoup de temps et de ressources, au moins un appareil en ligne en permanence, des centaines de Go d'espace de stockage et environ une journée pour synchroniser depuis le début. Bien que le seuil pour exécuter un nœud ait maintenant été abaissé, cela reste encore très difficile pour la plupart des utilisateurs, en particulier ceux qui utilisent des appareils mobiles.
Il convient de noter que les attaques des fournisseurs RPC centralisés, bien qu'elles puissent tout à fait se produire, ne sont généralement que de simples attaques de phishing, et le type d'attaque que nous décrivons n'a pas encore eu lieu. Bien que les antécédents des fournisseurs de premier plan soient dignes de confiance, il est toujours sage de faire un peu plus de recherches avant d'utiliser des fournisseurs RPC inconnus.
Helios: réaliser un accès à Ethereum sans confiance
Ethereum a lancé un protocole de light client, ouvrant de nouvelles possibilités pour une interaction rapide avec la Blockchain et la validation des points de terminaison RPC avec des exigences matérielles minimales. Un mois après The Merge, plusieurs light clients indépendants ont été lancés, adoptant des méthodes différentes mais ayant un objectif commun : réaliser un accès efficace et sans confiance sans exécuter de nœuds complets.
Helios est un light client Ethereum qui peut synchroniser en environ deux secondes, sans stockage, et offre un accès Ethereum entièrement sans confiance. Comme tous les clients Ethereum, Helios comprend une couche d'exécution et une couche de consensus. Mais contrairement à la plupart des clients, Helios couple étroitement les deux couches, permettant à l'utilisateur d'installer et d'exécuter un seul logiciel.
Le fonctionnement de Helios est le suivant : la couche de consensus utilise un hachage de bloc de chaîne de balise connue et se connecte à un RPC non fiable pour synchroniser de manière vérifiable avec le bloc actuel. La couche d'exécution combine ces blocs de chaîne de balise vérifiés avec un RPC d'exécution non fiable pour vérifier diverses informations sur l'état de la chaîne, telles que les soldes des comptes, le stockage des contrats, les reçus de transaction et les résultats des appels de contrats intelligents. Ces composants travaillent ensemble pour fournir un RPC totalement sans confiance aux utilisateurs, sans avoir besoin d'exécuter un nœud complet.
couche de consensus
Le léger client de la couche de consensus suit les spécifications du léger client de la chaîne de balises, en utilisant le comité de synchronisation de la chaîne de balises. Le comité de synchronisation est un sous-ensemble de 512 validateurs choisis au hasard, avec un cycle de service d'environ 27 heures.
Une fois que les validateurs rejoignent le comité de synchronisation, ils signeront tous les en-têtes de blocs de la chaîne de balises qu'ils voient. Si plus de 2/3 des membres du comité signent un en-tête de bloc, alors ce bloc est très probablement situé dans la chaîne de balises conforme. Si Helios connaît la composition actuelle du comité de synchronisation, il peut suivre de manière fiable le chef de la chaîne en interrogeant les signatures récentes du comité de synchronisation.
Grâce à l'agrégation de signatures BLS, il suffit d'une seule requête pour valider le nouvel en-tête de bloc. Tant que la signature est valide et que plus de 2/3 des membres du comité ont signé, cela garantit que le bloc est inclus dans la chaîne. Bien sûr, le suivi de la finalité du bloc peut fournir une garantie plus forte.
Cette stratégie doit également résoudre la question de savoir comment trouver le comité de synchronisation actuel. Tout d'abord, il faut obtenir une racine de confiance appelée point de contrôle de faible subjectivité. Cela représente un ancien hachage de bloc qui peut être garanti d'avoir été inclus dans la chaîne à un moment donné dans le passé. En ce qui concerne la durée d'existence des points de contrôle, l'analyse théorique montre que dans le pire des cas, cela prend environ deux semaines, tandis que l'estimation réelle peut durer plusieurs mois.
Si le point de contrôle est trop ancien, il existe théoriquement une attaque pouvant tromper les nœuds pour suivre une chaîne erronée. Dans ce cas, obtenir un point de contrôle de faible subjectivité dépasse la capacité du protocole. La solution de Helios est de fournir un point de contrôle initial, codé en dur dans le code source de (, qui peut être facilement écrasé ). Il sauvegardera 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, puis de prouver la validité du contenu du bloc par comparaison de hachage. Helios utilise cette propriété pour obtenir et vérifier les champs clés dans les blocs de points de contrôle de subjectivité faible, y compris 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 examiner rapidement l'historique de la blockchain.
Avec le point de contrôle de subjectivité faible en place, nous pouvons obtenir et vérifier le comité de synchronisation actuel et suivant. Si l'en-tête de la chaîne actuelle et le point de contrôle se trouvent dans le même cycle de comité de synchronisation, nous pouvons immédiatement utiliser l'en-tête du comité de synchronisation signé pour valider le nouveau bloc. Si le point de contrôle est positionné après plusieurs comités de synchronisation, nous pouvons :
Utilisez le prochain comité de synchronisation après le point de contrôle pour obtenir et vérifier un bloc du comité de synchronisation qui sera généré à l'avenir.
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 examiner rapidement l'historique de cette Blockchain par intervalles de 27 heures, en synchronisant depuis n'importe quel hachage de bloc passé jusqu'au hachage de bloc actuel.
couche d'exécution
L'objectif du light client de la couche d'exécution est de combiner les en-têtes de blocs de signaux validés par la couche de consensus avec des RPC de la couche d'exécution non sécurisés, afin de fournir des données de la couche d'exécution vérifiées. Ces données peuvent ensuite être accessibles via un serveur RPC hébergé localement par Helios.
Voici un exemple simple pour obtenir le solde d'un compte, en introduisant brièvement comment Ethereum stocke l'état. Chaque compte contient plusieurs champs, tels que le hachage du code du contrat, un nonce, le hachage du stockage et le solde. Ces comptes sont stockés dans un grand arbre Merkle-Patricia ajusté, appelé arbre d'état. Tant que la racine de l'arbre d'état est connue, il est possible de vérifier les preuves Merkle pour prouver l'existence de tout compte dans l'arbre. Cette preuve ne peut pas être falsifiée.
Helios obtient la racine de l'état vérifiée à partir de la couche de consensus. En appliquant cette racine d'état et la preuve Merkle sur le RPC de la couche d'exécution non fiable, Helios peut valider localement toutes les données stockées dans Ethereum.
Nous utilisons différentes technologies pour vérifier les diverses données utilisées par la couche d'exécution, ce qui nous permet de 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.
Perspectives d'application de Helios
Il est souvent difficile de concilier commodité et décentralisation. Grâce à Helios, un client léger, les utilisateurs peuvent accéder à des données sécurisées sur la chaîne depuis n'importe quel appareil (, y compris un téléphone et un plugin de navigateur ). Cela permettra à un plus grand nombre de personnes d'accéder aux données d'Ethereum sans avoir besoin de faire confiance, quel que soit le matériel utilisé. Les utilisateurs peuvent utiliser Helios comme fournisseur RPC dans leur portefeuille, pour accéder sans confiance à diverses DApp, le tout sans aucune autre modification.
De plus, le support de Rust pour WebAssembly permet aux développeurs d'applications d'intégrer 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 notre besoin de confiance dans les infrastructures centralisées.
La communauté peut contribuer à Helios de plusieurs manières. En plus d'améliorer la base de code, elle peut également développer des logiciels intégrant Helios pour tirer parti de ses avantages. Voici quelques directions de développement potentielles :