Construire Helios : accès entièrement sans confiance à Ethereum

L’une des principales raisons pour lesquelles nous utilisons les blockchains est le manque de confiance. Cette propriété promet de nous permettre un accès autonome à nos richesses et à nos données. Pour la plupart, les blockchains comme Ethereum ont tenu cette promesse : nos actifs sont véritablement les nôtres. 

Cependant, nous avons fait des concessions par souci de commodité. L’un de ces domaines concerne notre utilisation de serveurs RPC (appel de procédure à distance) centralisés. Les utilisateurs accèdent généralement à Ethereum via des fournisseurs centralisés comme Alchemy. Ces entreprises exécutent des nœuds hautes performances sur des serveurs cloud afin que d'autres puissent facilement accéder aux données de la chaîne. Lorsqu'un portefeuille interroge ses soldes de jetons ou vérifie si une transaction en attente a été incluse dans un bloc, il le fait presque toujours via l'un de ces fournisseurs centralisés. 

Le problème avec le système existant est que les utilisateurs doivent faire confiance aux fournisseurs et il n’existe aucun moyen de vérifier l’exactitude de leurs requêtes.

Entrer Helios, un client léger Ethereum basé sur Rust que nous avons développé et qui fournit un accès totalement sans confiance à Ethereum. Helios — qui utilise le protocole client léger d'Ethereum, rendu possible par le changement récent à la preuve de la participation — convertit les données d'un fournisseur RPC centralisé non fiable en un RPC local vérifiable et sécurisé. Helios fonctionne avec des RPC centralisés pour permettre de vérifier leur authenticité sans exécuter un nœud complet. 

Le compromis entre portabilité et décentralisation est un problème courant, mais notre client – ​​que nous avons mis à la disposition du public pour s'appuyer et plus encore – se synchronise en deux secondes environ, ne nécessite aucun stockage et permet aux utilisateurs d'accéder aux données de la chaîne sécurisée depuis n’importe quel appareil (y compris les téléphones mobiles et les extensions de navigateur). Mais que sont les pièges potentiels du recours à une infrastructure centralisée ? Nous expliquons comment ils pourraient se dérouler dans cet article, passons en revue nos décisions de conception et décrivons également quelques idées permettant à d'autres de contribuer au base de code.

Les pièges des infrastructures centralisées : créatures théoriques dans la « forêt sombre » d'Ethereum

Une créature (théorique) se cache dans le forêt Noire. Celui-ci ne chasse pas sa proie dans le pool de mémoire Ethereum, mais tend plutôt ses pièges en imitant l'infrastructure centralisée sur laquelle nous comptons. Les utilisateurs pris dans ce piège ne commettent aucune erreur : ils visitent leur plateforme d'échange décentralisée préférée, fixent une tolérance de glissement raisonnable et achètent et vendent des jetons comme d'habitude… Ils font tout correctement, mais sont quand même victimes d'un nouveau type de attaque sandwich, un piège méticuleusement tendu à l'entrée même de la sombre forêt d'Ethereum : les fournisseurs RPC.

Avant d'élaborer, regardons comment fonctionnent les échanges sur les échanges décentralisés. Lorsque les utilisateurs envoient une transaction d'échange, ils fournissent plusieurs paramètres au contrat intelligent : les jetons à échanger, le montant de l'échange et, plus important encore, le nombre minimum de jetons qu'un utilisateur doit recevoir pour que la transaction puisse être effectuée. Ce dernier paramètre spécifie que le swap doit satisfaire une « sortie minimale » ou revenir. Ceci est souvent connu sous le nom de « tolérance de glissement », car cela définit effectivement le changement de prix maximum qui peut se produire entre le moment où la transaction est envoyée au pool de mémoire et le moment où elle est incluse dans un bloc. Si ce paramètre est réglé trop bas, l'utilisateur accepte la possibilité de recevoir moins de jetons. Cette situation peut également conduire à une attaque sandwich, dans laquelle un attaquant prend effectivement en sandwich l'offre entre deux échanges malveillants. Les swaps font monter le prix au comptant et obligent l'utilisateur à s'exécuter à un prix moins favorable. L’attaquant vend ensuite immédiatement pour réaliser un petit profit.

Tant que ce paramètre de sortie minimum est proche de la juste valeur, vous êtes à l'abri des attaques sandwich. Mais que se passe-t-il si votre fournisseur RPC ne fournit pas de devis précis à partir du contrat intelligent d'échange décentralisé ? Un utilisateur peut alors être amené à signer une transaction d'échange avec un paramètre de sortie minimum inférieur et, pour aggraver les choses, envoyer la transaction directement au fournisseur RPC malveillant. Au lieu de diffuser cette transaction sur le pool de mémoire public, où des dizaines de robots s'affrontent pour effectuer l'attaque sandwich, le fournisseur peut la retenir et envoyer le paquet de transactions d'attaque directement aux Flashbots, s'assurant ainsi les bénéfices.

La cause première de cette attaque est de faire confiance à quelqu’un d’autre pour récupérer l’état de la blockchain. Les utilisateurs expérimentés ont traditionnellement résolu ce problème en exécutant leurs propres nœuds Ethereum – une entreprise gourmande en temps et en ressources qui, à tout le moins, nécessite une machine constamment en ligne, des centaines de gigaoctets de stockage et environ une journée pour se synchroniser à partir de zéro. Ce processus est certainement plus facile qu’avant ; des groupes comme Ethereum sur ARM ont travaillé sans relâche pour permettre d'exécuter des nœuds sur du matériel peu coûteux (comme un Raspberry Pi avec un disque dur externe connecté). Mais même avec ces exigences relativement minimes, exécuter 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 centralisées du fournisseur RPC, bien que tout à fait plausibles, sont généralement attaques de phishing simples – et celui que nous décrivons n’a pas encore eu lieu. Même si les antécédents de fournisseurs plus importants comme Alchemy nous donnent peu de raisons d'en douter, cela vaut la peine de faire des recherches plus approfondies avant d'ajouter des fournisseurs RPC inconnus à votre portefeuille.

Présentation d'Helios : un accès totalement sans confiance à Ethereum

En introduisant son protocole client léger (rendu possible par le récent passage à Proof of Stake), Ethereum a ouvert de nouvelles possibilités passionnantes pour interagir rapidement avec la blockchain et vérifier les points de terminaison RPC avec des exigences matérielles minimales. Dans le mois depuis La fusion, nous avons vu une nouvelle génération de clients légers émerger indépendamment les uns des autres (Étoile polaire, Nimbus, et le Javascript Kevlar) qui ont adopté différentes approches au service du même objectif : un accès efficace et sans confiance, sans utiliser de nœud complet.

Notre solution, Helios, est un client léger Ethereum qui se synchronise en deux secondes environ, ne nécessite aucun stockage et fournit un accès totalement sans confiance à Ethereum. Comme tous les clients Ethereum, Helios se compose d’une couche d’exécution et d’une couche de consensus. Contrairement à la plupart des autres clients, Helios associe étroitement les deux couches afin que les utilisateurs n'aient besoin d'installer et d'exécuter qu'un seul logiciel. (Érigon va également dans cette direction, en ajoutant un client léger de couche consensus intégré directement dans leur nœud d'archive). 

Alors, comment ça marche? La couche de consensus Helios utilise un blockhash de chaîne de balises déjà connu et une connexion à un RPC non fiable pour se synchroniser de manière vérifiable avec le bloc actuel. La couche d'exécution Helios utilise ces blocs de chaîne de balises authentifiés en tandem avec une couche d'exécution non fiable RPC pour prouver des informations arbitraires sur l'état de la chaîne telles que les soldes des comptes, le stockage des contrats, les reçus de transactions et les résultats des appels de contrats intelligents. Ces composants fonctionnent ensemble pour offrir aux utilisateurs un RPC totalement sans confiance, sans qu'il soit nécessaire d'exécuter un nœud complet.

…Au niveau du consensus

Le client léger de couche consensus est conforme au client léger de chaîne de balise spécification, et utilise les comités de synchronisation de la chaîne de balises (introduits avant la fusion dans le hard fork d'Altair). Le comité de synchronisation est un sous-ensemble sélectionné au hasard de 512 validateurs qui servent pendant des périodes d'environ 27 heures. 

Lorsqu'un validateur fait partie d'un comité de synchronisation, il signe chaque en-tête de bloc de chaîne de balise qu'il voit. Si plus des deux tiers du comité signent un en-tête de bloc donné, il est fort probable que ce bloc se trouve dans la chaîne de balises canonique. Si Helios connaît la composition du comité de synchronisation actuel, il peut suivre en toute confiance le chef de la chaîne en demandant à un RPC non fiable la signature la plus récente du comité de synchronisation. 

Merci à BLS Signature agrégation, une seule vérification est nécessaire pour valider le nouvel en-tête. Si la signature est valide et a été signée par plus des deux tiers du comité, on peut supposer que le bloc a été inclus dans la chaîne (bien sûr, il peut être réorganisé en dehors de la chaîne, mais le suivi de la finalité du bloc peut fournir garanties plus strictes).

Il manque cependant une pièce manquante dans cette stratégie : comment trouver le comité de synchronisation actuel. Cela commence par l'acquisition d'une racine de confiance appelée point de contrôle de subjectivité faible. Ne vous laissez pas intimider par le nom : il signifie simplement un vieux blockhash dont nous pouvons garantir qu'il a été inclus dans la chaîne à un moment donné dans le passé. Il y a des calculs intéressants derrière l’âge exact du point de contrôle ; l’analyse du pire des cas suggère environ deux semaines, tandis que des estimations plus pratiques suggèrent plusieurs mois. 

Si le point de contrôle est trop ancien, il y a attaques théoriques cela peut inciter les nœuds à suivre la mauvaise chaîne. L'acquisition d'un point de contrôle de subjectivité faible est hors de portée du protocole. Notre approche avec Helios fournit un point de contrôle initial codé en dur dans la base de code (qui peut facilement être remplacé) ; il enregistre ensuite localement le blockhash finalisé le plus récent pour l'utiliser comme point de contrôle à l'avenir, chaque fois que le nœud est synchronisé. 

Idéalement, les blocs de chaîne de balise peuvent être hachés pour produire un blockhash de balise unique. Cela signifie qu'il est facile de demander à un nœud un bloc de balise complet, puis de prouver que le contenu du bloc est valide en le hachant et en le comparant à un blockhash connu. Helios utilise cette propriété pour récupérer et prouver certains champs à l'intérieur du bloc de point de contrôle de subjectivité faible, y compris deux champs très importants : le comité de synchronisation actuel et le comité de synchronisation suivant. Ce mécanisme permet aux clients légers d’avancer rapidement dans l’historique de la blockchain.

Maintenant que nous disposons d'un point de contrôle de subjectivité faible, nous pouvons récupérer et vérifier les comités de synchronisation actuels et suivants. Si le chef de chaîne actuel se trouve dans la même période du comité de synchronisation que le point de contrôle, nous commençons immédiatement à vérifier les nouveaux blocs avec les en-têtes du comité de synchronisation signés. Si notre point de contrôle est en retard de plusieurs comités de synchronisation, nous pouvons :

1. Utilisez le prochain comité de synchronisation après notre point de contrôle pour récupérer et vérifier un bloc qui génère un comité de synchronisation dans le futur.
2. Utilisez ce nouveau bloc pour récupérer le nouveau comité de synchronisation suivant.
3. S'il est toujours en retard, revenez à l'étape 1.

Chaque itération de ce processus nous permet d'avancer rapidement dans 27 heures de l'historique de la chaîne, de commencer par n'importe quel blockhash du passé et de nous synchroniser avec le blockhash actuel.

…Au niveau de l'exécution

L'objectif du client léger de la couche d'exécution est de prendre les en-têtes de bloc de balise qui sont vérifiés par la couche de consensus et de les utiliser avec un RPC de couche d'exécution non fiable pour fournir des données de couche d'exécution vérifiées. Ces données sont ensuite accessibles via un serveur RPC hébergé localement par Helios.

Voici un exemple simple de récupération du solde d'un compte, en commençant par un aperçu rapide de la façon dont l'état est stocké dans Ethereum. Chaque compte contient quelques champs, tels que le hachage du code du contrat, le nom occasionnel, le hachage de stockage et le solde. Ces comptes sont stockés dans un grand fichier modifié Arbre Merkle-Patricia appelé l'arbre d'état. Si nous connaissons la racine de l'arbre d'état, nous pouvons valider preuves de Merkle pour prouver l'existence (ou l'exclusion) de tout compte au sein de l'arborescence. Ces preuves sont effectivement impossibles à falsifier.

Helios a une racine d'état authentifiée par la couche consensus. Utiliser cette racine ainsi que requêtes de preuve Merkle à la couche d'exécution non fiable RPC, Helios peut vérifier localement toutes les données stockées sur Ethereum.

Nous appliquons différentes techniques pour vérifier toutes sortes de données utilisées par la couche d'exécution ; utilisés ensemble, ceux-ci nous permettent d'authentifier toutes les données récupérées du RPC non fiable. Même si un RPC non fiable peut refuser l'accès aux données, il ne peut plus nous fournir de résultats incorrects.

Utiliser Helios dans la nature

Le compromis entre portabilité et décentralisation est un problème courant, mais comme Helios est si léger, les utilisateurs peuvent accéder aux données de la chaîne sécurisée à partir de n'importe quel appareil (y compris les téléphones mobiles et les extensions de navigateur). La possibilité d’exécuter Helios n’importe où permet à davantage de personnes d’accéder aux données Ethereum sans confiance, quel que soit leur matériel. Cela signifie que les utilisateurs peuvent utiliser Helios comme fournisseur RPC dans MetaMask et accéder en toute confiance aux dapps sans aucune autre modification. 

De plus, la prise en charge par Rust de WebAssembly permet aux développeurs d'applications d'intégrer facilement Helios dans des applications Javascript (telles que des portefeuilles et des dapps). Ces intégrations rendraient Ethereum plus sûr et réduiraient notre besoin de faire confiance à une infrastructure centralisée.

Nous avons hâte de voir ce que la communauté proposera. Mais en attendant, il existe de nombreuses façons de contribuer à Helios : si vous n'êtes pas intéressé à contribuer à la base de code, vous pouvez également créer un logiciel intégrant Helios pour profiter de ses avantages. Ce ne sont là que quelques-unes des idées qui nous passionnent :

• Prise en charge de la récupération des données des clients légers directement à partir du réseau P2P plutôt que via RPC
• Implémentez certaines des méthodes RPC manquantes
• Créer une version d'Helios qui se compile en WebAssembly
• Intégrez Helios directement dans le logiciel de portefeuille
• Créez un tableau de bord Web pour afficher vos soldes de jetons qui récupère les données d'Helios intégrées au site Web avec WebAssembly
• Implémentez l'API du moteur afin que la couche de consensus d'Helios puisse être connectée à un nœud complet de couche d'exécution existant

Consultez la base de code pour commencer — nous apprécions vos rapports de bogues, vos demandes de fonctionnalités et votre code. Et si vous construisez quelque chose de plus, partagez-le avec nous sur Twitter, Telegram, ou Farcaster @a16zcrypto.

***
Les opinions exprimées ici sont celles du personnel individuel d'AH Capital Management, LLC (« a16z ») cité et ne sont pas les opinions d'a16z ou de ses sociétés affiliées. Certaines informations contenues ici ont été obtenues de sources tierces, y compris de sociétés de portefeuille de fonds gérés par a16z. Bien qu'elles proviennent de sources considérées comme fiables, a16z n'a pas vérifié ces informations de manière indépendante et ne fait aucune déclaration quant à l'exactitude actuelle ou durable des informations ou à leur pertinence dans une situation donnée. De plus, ce contenu peut inclure des publicités de tiers ; a16z n'a pas examiné ces publicités et n'approuve aucun contenu publicitaire qu'elles contiennent.

Ce contenu est fourni à titre informatif uniquement et ne doit pas être considéré comme un conseil juridique, commercial, d'investissement ou fiscal. Vous devriez consulter vos propres conseillers sur ces questions. Les références à des titres ou à des actifs numériques sont uniquement à des fins d'illustration et ne constituent pas une recommandation d'investissement ou une offre de fournir des services de conseil en investissement. En outre, ce contenu n'est ni destiné ni destiné à être utilisé par des investisseurs ou des investisseurs potentiels, et ne peut en aucun cas être invoqué pour prendre une décision d'investir dans un fonds géré par a16z. (Une offre d'investissement dans un fonds a16z ne sera faite que par le mémorandum de placement privé, le contrat de souscription et toute autre documentation pertinente de ce fonds et doit être lu dans son intégralité.) Tous les investissements ou sociétés de portefeuille mentionnés, référencés ou décrits ne sont pas représentatifs de tous les investissements dans des véhicules gérés par a16z, et rien ne garantit que les investissements seront rentables ou que d'autres investissements réalisés à l'avenir auront des caractéristiques ou des résultats similaires. Une liste des investissements effectués par des fonds gérés par Andreessen Horowitz (à l'exclusion des investissements pour lesquels l'émetteur n'a pas autorisé a16z à divulguer publiquement ainsi que des investissements non annoncés dans des actifs numériques cotés en bourse) est disponible sur https://a16z.com/investments /.

Les tableaux et graphiques fournis ici sont uniquement à des fins d'information et ne doivent pas être utilisés pour prendre une décision d'investissement. Les performances passées ne représentent pas les résultats futurs. Le contenu ne parle qu'à la date indiquée. Toutes les projections, estimations, prévisions, objectifs, perspectives et/ou opinions exprimées dans ces documents sont susceptibles d'être modifiées sans préavis et peuvent différer ou être contraires aux opinions exprimées par d'autres. Veuillez consulter https://a16z.com/disclosures pour des informations importantes supplémentaires