Client léger Ethereum Helios : accès à la blockchain sans confiance
Le 8 novembre, un nouveau light client Ethereum, Helios, a été lancé. Ce client développé en langage Rust vise à fournir un accès Ethereum totalement sans confiance.
L'une des principales raisons pour lesquelles nous utilisons la blockchain est l'absence de confiance nécessaire. Grâce à la blockchain, nous pouvons contrôler nos richesses et nos données de manière autonome. Dans la plupart des cas, des blockchains comme Ethereum ont effectivement tenu cette promesse : nos actifs nous appartiennent véritablement.
Cependant, pour rechercher la commodité, nous avons également fait certains compromis. L'un d'eux est l'utilisation d'un RPC centralisé ( pour appeler à distance 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 les utilisateurs à accéder facilement aux données on-chain. Lorsque le portefeuille interroge le solde des tokens ou vérifie si une transaction en attente a été incluse dans un bloc, 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 totalement sans confiance. Il utilise le protocole light client mis en œuvre après le passage d'Ethereum au PoS, permettant de convertir les données provenant de fournisseurs RPC centralisés non fiables en RPC local sécurisable et vérifiable. En combinant les RPC centralisés, Helios peut vérifier l'authenticité des données sans exécuter de nœud complet.
Il est courant de rencontrer des difficultés à concilier commodité et décentralisation. Ce nouveau client peut synchroniser en environ deux secondes, sans nécessiter de stockage. Les utilisateurs peuvent accéder aux données sécurisées de la chaîne via n'importe quel appareil (, y compris des téléphones et des extensions de navigateur ). Mais quels sont les risques potentiels associés à la dépendance aux infrastructures centralisées ? Cet article examinera ces risques, présentera le design de Helios et proposera quelques idées pour aider les développeurs à contribuer à la base de code.
Les risques des infrastructures centralisées : produits théoriques dans la "forêt sombre" d'Ethereum
Un produit théorique se cache dans la forêt sombre. Il ne cherche pas de proies dans le pool de mémoire des transactions Ethereum, mais établit des pièges en simulant l'infrastructure centralisée sur laquelle nous comptons. Les utilisateurs qui tombent dans ce piège n'ont commis aucune erreur : ils ont simplement visité des échanges décentralisés qu'ils fréquentent, ont défini un glissement raisonnable et ont échangé des jetons comme d'habitude... Ils n'ont rien fait de mal, mais ont néanmoins rencontré une nouvelle forme d'attaque sandwich, un piège soigneusement placé à l'entrée de la forêt sombre d'Ethereum - le fournisseur RPC.
Avant de donner des explications détaillées, examinons comment les échanges décentralisés traitent les transactions. Lorsque les utilisateurs effectuent des transactions d'échange, ils fournissent plusieurs paramètres au contrat intelligent : les jetons à échanger, le montant à échanger, et surtout, la quantité minimale de jetons que l'utilisateur doit recevoir pour que la transaction soit validée. Ce 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", car il fixe effectivement l'écart de prix maximal qui peut survenir entre l'envoi de la transaction dans le mempool et l'inclusion de la transaction dans le bloc. Si le slippage est réglé trop bas, l'utilisateur risque de ne recevoir que peu de jetons. Cela peut également entraîner une attaque par sandwich, où un attaquant peut intercaler l'offre de l'utilisateur entre deux transactions malveillantes. Ces transactions feront monter le prix au comptant, obligeant l'utilisateur à effectuer la transaction à un prix moins favorable. Ensuite, l'attaquant vendra immédiatement les jetons pour réaliser un petit profit.
Tant que ce paramètre de rendement minimal est réglé près de la valeur équitable, vous ne serez pas victime d'une attaque sandwich. Mais que se passe-t-il si votre fournisseur RPC ne fournit pas de devis précis pour les contrats intelligents des échanges décentralisés ? Dans ce cas, les utilisateurs pourraient être dupés et signer des transactions d'échange avec des paramètres de rendement minimal plus bas. Pire encore, les utilisateurs pourraient également envoyer la transaction directement à un fournisseur RPC malveillant. Le fournisseur peut ne pas diffuser cette transaction dans le pool de mémoire public (, où des dizaines de robots se disputent pour effectuer une attaque sandwich ), mais la retenir en privé et envoyer directement le paquet de transactions ciblées à une plateforme MEV, pour en tirer profit.
La cause fondamentale de cette attaque est de faire confiance aux autres pour vous aider à 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, ce qui 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 à partir de zéro. Ce processus est manifestement simplifié par rapport au passé. Certains groupes travaillent sans relâche pour aider tout le monde à faire fonctionner des nœuds avec du matériel à faible coût (, par exemple, un mini-ordinateur Raspberry Pi avec un disque dur externe ). Mais même si les exigences sont considérablement réduites, faire fonctionner un nœud reste difficile pour la plupart des utilisateurs, en particulier pour ceux qui utilisent des appareils mobiles.
Il est important de noter que les attaques par des fournisseurs RPC centralisés, bien que tout à fait possibles, ne sont généralement que de simples attaques de phishing, et le type d'attaque dont nous parlons n'a pas encore eu lieu. Bien que les antécédents des grands fournisseurs ne nous donnent aucune raison de douter d'eux, il est néanmoins judicieux de faire des recherches supplémentaires avant d'ajouter des fournisseurs RPC non familiers à votre portefeuille.
Introduction à Helios : accès à Ethereum totalement sans confiance
Ethereum a lancé un protocole de light client, ouvrant des possibilités passionnantes pour une interaction rapide avec la Blockchain et la vérification des points d'extrémité RPC avec des exigences matérielles minimales. Un mois après The Merge, une série de light clients indépendants ont émergé, chacun suivant son propre chemin, mais visant le même objectif : un accès efficace sans confiance, sans avoir à utiliser de nœuds complets.
Helios est un light client Ethereum, capable de synchroniser en environ deux secondes, sans nécessiter de stockage, et offrant un accès à Ethereum entièrement 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 couplent étroitement ces deux couches, permettant à l'utilisateur d'installer et d'exécuter un seul logiciel.
Comment cela fonctionne-t-il ? La couche de consensus Helios utilise un hachage de bloc de chaîne de balises connu et se connecte à un RPC non fiable pour synchroniser de manière vérifiable avec le bloc actuel. La couche d'exécution Helios combine ces blocs de chaîne de balises vérifiés avec un RPC non fiable de la couche d'exécution pour vérifier diverses informations sur l'état de la chaîne, telles que le solde 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 aux utilisateurs un RPC entièrement sans confiance, sans avoir besoin d'exécuter un nœud complet.
couche de consensus
Le light client de la couche de consensus respecte les spécifications du light client de la chaîne de balise et utilise le comité de synchronisation de la chaîne de balise (, qui a été lancé avant le Merge de la hard fork Altair ). Le comité de synchronisation est un sous-ensemble de 512 validateurs choisis au hasard, avec une durée de service d'environ 27 heures.
Une fois que les validateurs rejoignent le comité de synchronisation, ils signeront tous les en-têtes de bloc de la chaîne de balises qu'ils voient (block header). Si plus des deux tiers des membres du comité signent un en-tête de bloc, ce bloc est très probablement situé dans la chaîne de balises conforme. Si Helios comprend la composition actuelle du comité de synchronisation, il peut suivre avec certitude l'état de la chaîne en interrogeant un RPC non fiable pour les signatures récentes du comité de synchronisation.
Grâce à l'agrégation des signatures BLS, il suffit d'une seule requête pour vérifier 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 (. 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 cette stratégie manque manifestement d'un élément : comment trouver le comité de synchronisation actuel. Tout d'abord, il faut obtenir une racine de confiance appelée point de contrôle de subjectivité faible (weak subjectivity checkpoint). Ne laissez pas le nom vous intimider, cela signifie simplement un ancien hachage de bloc qui peut garantir d'avoir été inclus dans la chaîne à un moment donné dans le passé. Il y a des calculs mathématiques intéressants concernant le moment exact de l'existence du point de contrôle : l'analyse du pire des cas montre environ deux semaines, tandis que les estimations plus réalistes indiquent plusieurs mois.
Si le point de contrôle est trop ancien, il existe théoriquement une attaque pouvant inciter les nœuds à suivre une chaîne erronée. À ce stade, obtenir un point de contrôle de subjectivité faible 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 (, qui peut facilement être écrasé ). Il conservera 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 balises peuvent facilement produire un hachage de bloc de balises unique. Cela permet de consulter facilement le bloc de balises complet auprès des nœuds, puis, en effectuant une opération de hachage et en comparant avec le hachage de bloc connu, de prouver la validité du contenu du bloc. Helios utilise cette propriété pour obtenir et vérifier certains champs dans les blocs de points de contrôle de faibles subjectivités, y compris deux champs essentiels : le comité de synchronisation actuel et le prochain comité de synchronisation. Le plus important est que les légers clients peuvent utiliser ce mécanisme pour consulter rapidement l'historique de la blockchain.
Maintenant que nous avons un point de contrôle de subjectivité faible, nous pouvons récupérer et vérifier le comité de synchronisation actuel et suivant. Si la tête de chaîne actuelle et le point de contrôle se trouvent dans le même cycle de comité de synchronisation, nous pouvons immédiatement commencer à utiliser l'en-tête du comité de synchronisation signé pour vérifier le nouveau bloc. Si notre point de contrôle est situé plusieurs comités de synchronisation après, nous pouvons:
Utiliser le prochain comité de synchronisation après le point de contrôle pour obtenir et vérifier le bloc d'un 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 en arrière, retournez à l'étape 1.
Grâce à ce processus, nous pouvons rapidement examiner l'historique de cette Blockchain par tranches de 27 heures, en synchronisant depuis n'importe quel hash de Bloc du passé jusqu'au hash de Bloc actuel.
couche d'exécution
L'objectif du light client de la couche d'exécution est d'utiliser l'en-tête de bloc de signal validé par la couche de consensus avec un RPC de la couche d'exécution non fiable, 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, tout d'abord une brève introduction sur la façon dont Ethereum stocke l'état. Chaque compte contient plusieurs champs, tels que le hachage du code du contrat, le nombre aléatoire, le hachage de 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 la preuve Merkle pour prouver l'existence de tout compte dans l'arbre. Cette preuve ne peut pas être falsifiée.
Helios a une racine d'état vérifiée provenant de la couche de consensus (state root). En appliquant cette racine d'état et les demandes de preuve Merkle via un RPC de couche d'exécution non fiable, Helios peut valider localement toutes les données stockées sur 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 plus fournir de résultats erronés.
Utiliser Helios dans le monde réel
Il est courant de rencontrer des difficultés à concilier commodité et décentralisation. Grâce à Helios, un client léger, les utilisateurs peuvent accéder aux données sécurisées sur la chaîne depuis n'importe quel appareil (, y compris les téléphones et les extensions de navigateur ). Cela permettra à un plus grand nombre de personnes d'accéder aux données Ethereum sans confiance, peu importe le matériel utilisé. Les utilisateurs peuvent configurer Helios comme leur fournisseur RPC dans certains portefeuilles, afin d'accéder sans confiance à diverses DApp, le tout sans nécessiter d'autres modifications.
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 renforceront la sécurité d'Ethereum et réduiront notre besoin de confiance dans les infrastructures centralisées.
Il existe de nombreuses façons de contribuer à Helios. En plus d'enrichir le code source, vous pouvez également développer des logiciels intégrant Helios pour tirer parti de ses avantages. Voici quelques idées passionnantes :
Prend en charge l'obtention de données de light client directement à partir du réseau P2P, plutôt que par RPC.
Déployer certaines 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 tokens, 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 aux nœuds complets existants de la couche d'exécution
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.
23 J'aime
Récompense
23
4
Partager
Commentaire
0/400
AirdropHarvester
· 07-23 19:58
rpc, c'est quand qu'il pourra enfin être décentralisé ?
Voir l'originalRépondre0
All-InQueen
· 07-20 22:35
Cette serrure, décidément, c'est parti !
Voir l'originalRépondre0
ConfusedWhale
· 07-20 22:23
Copier à la vitesse de la lumière le nœud léger Doge.
Helios light client : réaliser un accès à Ethereum sans confiance
Client léger Ethereum Helios : accès à la blockchain sans confiance
Le 8 novembre, un nouveau light client Ethereum, Helios, a été lancé. Ce client développé en langage Rust vise à fournir un accès Ethereum totalement sans confiance.
L'une des principales raisons pour lesquelles nous utilisons la blockchain est l'absence de confiance nécessaire. Grâce à la blockchain, nous pouvons contrôler nos richesses et nos données de manière autonome. Dans la plupart des cas, des blockchains comme Ethereum ont effectivement tenu cette promesse : nos actifs nous appartiennent véritablement.
Cependant, pour rechercher la commodité, nous avons également fait certains compromis. L'un d'eux est l'utilisation d'un RPC centralisé ( pour appeler à distance 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 les utilisateurs à accéder facilement aux données on-chain. Lorsque le portefeuille interroge le solde des tokens ou vérifie si une transaction en attente a été incluse dans un bloc, 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 totalement sans confiance. Il utilise le protocole light client mis en œuvre après le passage d'Ethereum au PoS, permettant de convertir les données provenant de fournisseurs RPC centralisés non fiables en RPC local sécurisable et vérifiable. En combinant les RPC centralisés, Helios peut vérifier l'authenticité des données sans exécuter de nœud complet.
Il est courant de rencontrer des difficultés à concilier commodité et décentralisation. Ce nouveau client peut synchroniser en environ deux secondes, sans nécessiter de stockage. Les utilisateurs peuvent accéder aux données sécurisées de la chaîne via n'importe quel appareil (, y compris des téléphones et des extensions de navigateur ). Mais quels sont les risques potentiels associés à la dépendance aux infrastructures centralisées ? Cet article examinera ces risques, présentera le design de Helios et proposera quelques idées pour aider les développeurs à contribuer à la base de code.
Les risques des infrastructures centralisées : produits théoriques dans la "forêt sombre" d'Ethereum
Un produit théorique se cache dans la forêt sombre. Il ne cherche pas de proies dans le pool de mémoire des transactions Ethereum, mais établit des pièges en simulant l'infrastructure centralisée sur laquelle nous comptons. Les utilisateurs qui tombent dans ce piège n'ont commis aucune erreur : ils ont simplement visité des échanges décentralisés qu'ils fréquentent, ont défini un glissement raisonnable et ont échangé des jetons comme d'habitude... Ils n'ont rien fait de mal, mais ont néanmoins rencontré une nouvelle forme d'attaque sandwich, un piège soigneusement placé à l'entrée de la forêt sombre d'Ethereum - le fournisseur RPC.
Avant de donner des explications détaillées, examinons comment les échanges décentralisés traitent les transactions. Lorsque les utilisateurs effectuent des transactions d'échange, ils fournissent plusieurs paramètres au contrat intelligent : les jetons à échanger, le montant à échanger, et surtout, la quantité minimale de jetons que l'utilisateur doit recevoir pour que la transaction soit validée. Ce 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", car il fixe effectivement l'écart de prix maximal qui peut survenir entre l'envoi de la transaction dans le mempool et l'inclusion de la transaction dans le bloc. Si le slippage est réglé trop bas, l'utilisateur risque de ne recevoir que peu de jetons. Cela peut également entraîner une attaque par sandwich, où un attaquant peut intercaler l'offre de l'utilisateur entre deux transactions malveillantes. Ces transactions feront monter le prix au comptant, obligeant l'utilisateur à effectuer la transaction à un prix moins favorable. Ensuite, l'attaquant vendra immédiatement les jetons pour réaliser un petit profit.
Tant que ce paramètre de rendement minimal est réglé près de la valeur équitable, vous ne serez pas victime d'une attaque sandwich. Mais que se passe-t-il si votre fournisseur RPC ne fournit pas de devis précis pour les contrats intelligents des échanges décentralisés ? Dans ce cas, les utilisateurs pourraient être dupés et signer des transactions d'échange avec des paramètres de rendement minimal plus bas. Pire encore, les utilisateurs pourraient également envoyer la transaction directement à un fournisseur RPC malveillant. Le fournisseur peut ne pas diffuser cette transaction dans le pool de mémoire public (, où des dizaines de robots se disputent pour effectuer une attaque sandwich ), mais la retenir en privé et envoyer directement le paquet de transactions ciblées à une plateforme MEV, pour en tirer profit.
La cause fondamentale de cette attaque est de faire confiance aux autres pour vous aider à 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, ce qui 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 à partir de zéro. Ce processus est manifestement simplifié par rapport au passé. Certains groupes travaillent sans relâche pour aider tout le monde à faire fonctionner des nœuds avec du matériel à faible coût (, par exemple, un mini-ordinateur Raspberry Pi avec un disque dur externe ). Mais même si les exigences sont considérablement réduites, faire fonctionner un nœud reste difficile pour la plupart des utilisateurs, en particulier pour ceux qui utilisent des appareils mobiles.
Il est important de noter que les attaques par des fournisseurs RPC centralisés, bien que tout à fait possibles, ne sont généralement que de simples attaques de phishing, et le type d'attaque dont nous parlons n'a pas encore eu lieu. Bien que les antécédents des grands fournisseurs ne nous donnent aucune raison de douter d'eux, il est néanmoins judicieux de faire des recherches supplémentaires avant d'ajouter des fournisseurs RPC non familiers à votre portefeuille.
Introduction à Helios : accès à Ethereum totalement sans confiance
Ethereum a lancé un protocole de light client, ouvrant des possibilités passionnantes pour une interaction rapide avec la Blockchain et la vérification des points d'extrémité RPC avec des exigences matérielles minimales. Un mois après The Merge, une série de light clients indépendants ont émergé, chacun suivant son propre chemin, mais visant le même objectif : un accès efficace sans confiance, sans avoir à utiliser de nœuds complets.
Helios est un light client Ethereum, capable de synchroniser en environ deux secondes, sans nécessiter de stockage, et offrant un accès à Ethereum entièrement 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 couplent étroitement ces deux couches, permettant à l'utilisateur d'installer et d'exécuter un seul logiciel.
Comment cela fonctionne-t-il ? La couche de consensus Helios utilise un hachage de bloc de chaîne de balises connu et se connecte à un RPC non fiable pour synchroniser de manière vérifiable avec le bloc actuel. La couche d'exécution Helios combine ces blocs de chaîne de balises vérifiés avec un RPC non fiable de la couche d'exécution pour vérifier diverses informations sur l'état de la chaîne, telles que le solde 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 aux utilisateurs un RPC entièrement sans confiance, sans avoir besoin d'exécuter un nœud complet.
couche de consensus
Le light client de la couche de consensus respecte les spécifications du light client de la chaîne de balise et utilise le comité de synchronisation de la chaîne de balise (, qui a été lancé avant le Merge de la hard fork Altair ). Le comité de synchronisation est un sous-ensemble de 512 validateurs choisis au hasard, avec une durée de service d'environ 27 heures.
Une fois que les validateurs rejoignent le comité de synchronisation, ils signeront tous les en-têtes de bloc de la chaîne de balises qu'ils voient (block header). Si plus des deux tiers des membres du comité signent un en-tête de bloc, ce bloc est très probablement situé dans la chaîne de balises conforme. Si Helios comprend la composition actuelle du comité de synchronisation, il peut suivre avec certitude l'état de la chaîne en interrogeant un RPC non fiable pour les signatures récentes du comité de synchronisation.
Grâce à l'agrégation des signatures BLS, il suffit d'une seule requête pour vérifier 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 (. 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 cette stratégie manque manifestement d'un élément : comment trouver le comité de synchronisation actuel. Tout d'abord, il faut obtenir une racine de confiance appelée point de contrôle de subjectivité faible (weak subjectivity checkpoint). Ne laissez pas le nom vous intimider, cela signifie simplement un ancien hachage de bloc qui peut garantir d'avoir été inclus dans la chaîne à un moment donné dans le passé. Il y a des calculs mathématiques intéressants concernant le moment exact de l'existence du point de contrôle : l'analyse du pire des cas montre environ deux semaines, tandis que les estimations plus réalistes indiquent plusieurs mois.
Si le point de contrôle est trop ancien, il existe théoriquement une attaque pouvant inciter les nœuds à suivre une chaîne erronée. À ce stade, obtenir un point de contrôle de subjectivité faible 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 (, qui peut facilement être écrasé ). Il conservera 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 balises peuvent facilement produire un hachage de bloc de balises unique. Cela permet de consulter facilement le bloc de balises complet auprès des nœuds, puis, en effectuant une opération de hachage et en comparant avec le hachage de bloc connu, de prouver la validité du contenu du bloc. Helios utilise cette propriété pour obtenir et vérifier certains champs dans les blocs de points de contrôle de faibles subjectivités, y compris deux champs essentiels : le comité de synchronisation actuel et le prochain comité de synchronisation. Le plus important est que les légers clients peuvent utiliser ce mécanisme pour consulter rapidement l'historique de la blockchain.
Maintenant que nous avons un point de contrôle de subjectivité faible, nous pouvons récupérer et vérifier le comité de synchronisation actuel et suivant. Si la tête de chaîne actuelle et le point de contrôle se trouvent dans le même cycle de comité de synchronisation, nous pouvons immédiatement commencer à utiliser l'en-tête du comité de synchronisation signé pour vérifier le nouveau bloc. Si notre point de contrôle est situé plusieurs comités de synchronisation après, nous pouvons:
Utiliser le prochain comité de synchronisation après le point de contrôle pour obtenir et vérifier le bloc d'un 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 en arrière, retournez à l'étape 1.
Grâce à ce processus, nous pouvons rapidement examiner l'historique de cette Blockchain par tranches de 27 heures, en synchronisant depuis n'importe quel hash de Bloc du passé jusqu'au hash de Bloc actuel.
couche d'exécution
L'objectif du light client de la couche d'exécution est d'utiliser l'en-tête de bloc de signal validé par la couche de consensus avec un RPC de la couche d'exécution non fiable, 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, tout d'abord une brève introduction sur la façon dont Ethereum stocke l'état. Chaque compte contient plusieurs champs, tels que le hachage du code du contrat, le nombre aléatoire, le hachage de 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 la preuve Merkle pour prouver l'existence de tout compte dans l'arbre. Cette preuve ne peut pas être falsifiée.
Helios a une racine d'état vérifiée provenant de la couche de consensus (state root). En appliquant cette racine d'état et les demandes de preuve Merkle via un RPC de couche d'exécution non fiable, Helios peut valider localement toutes les données stockées sur 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 plus fournir de résultats erronés.
Utiliser Helios dans le monde réel
Il est courant de rencontrer des difficultés à concilier commodité et décentralisation. Grâce à Helios, un client léger, les utilisateurs peuvent accéder aux données sécurisées sur la chaîne depuis n'importe quel appareil (, y compris les téléphones et les extensions de navigateur ). Cela permettra à un plus grand nombre de personnes d'accéder aux données Ethereum sans confiance, peu importe le matériel utilisé. Les utilisateurs peuvent configurer Helios comme leur fournisseur RPC dans certains portefeuilles, afin d'accéder sans confiance à diverses DApp, le tout sans nécessiter d'autres modifications.
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 renforceront la sécurité d'Ethereum et réduiront notre besoin de confiance dans les infrastructures centralisées.
Il existe de nombreuses façons de contribuer à Helios. En plus d'enrichir le code source, vous pouvez également développer des logiciels intégrant Helios pour tirer parti de ses avantages. Voici quelques idées passionnantes :