Un grand merci à Micah Zoltu, Toni Wahrstätter, Justin Traglia et pcaversaccio pour la discussion
La critique la plus courante concernant l'augmentation de la limite de gaz L1, en dehors des préoccupations concernant la sécurité du réseau, est qu'elle rend plus difficile l'exécution d'un nœud complet.
Surtout dans le contexte d'une feuille de route axée sur dégroupagele nœud complet, pour aborder cela il est nécessaire de comprendre à quoi servent les nœuds complets.
Historiquement, on pensait que les nœuds complets servaient à valider la chaîne; voir icipour ma propre exposition de ce qui pourrait se passer si les utilisateurs réguliers ne peuvent pas vérifier. Si c'est le seul problème, alors la mise à l'échelle L1 est débloquée par ZK-EVM : la seule limite est de maintenir les coûts de construction de bloc et de preuve assez bas pour que les deux puissent rester1-sur-nrésistant à la censure et un marché concurrentiel.
Cependant, en réalité, ce n'est pas vraiment la seule préoccupation. L'autre préoccupation majeure est : il est précieux d'avoir un nœud complet afin de disposer d'un serveur RPC local que vous pouvez utiliser pour lire la chaîne de manière décentralisée, résistante à la censure et respectueuse de la vie privée. Ce document discutera des ajustements à apporter à la feuille de route actuelle de mise à l'échelle L1 pour que cela se produise.
Pourquoi ne pas s'arrêter avec la non-confiance et la confidentialité via ZK-EVM + PIR ?
Le feuille de route de confidentialité que j'ai publiée le mois dernierse concentre sur les TEEs +ORAMcomme un correctif à court terme plus PIRcomme solution à long terme. Cela, associé à la vérification de Helios et ZK-EVM, permettrait à tout utilisateur de se connecter à des RPC externes et d'être pleinement confiant que (i) la chaîne qu'ils obtiennent est correcte et (ii) leur confidentialité des données est protégée. Il vaut donc la peine de se poser la question : pourquoi ne pas s'arrêter ici ? Ces types de solutions cryptographiques avancées ne rendent-elles pas les nœuds auto-hébergés obsolètes ?
Ici, je peux donner quelques réponses :
- Les solutions cryptographiques entièrement sans confiance (c'est-à-dire le PIR à 1 serveur) seront coûteuses. Actuellement, les frais généraux sont impraticablement élevés, et même après de nombreuses améliorations d'efficacité, il est probable qu'ils restent élevés.
- La confidentialité des métadonnées. Les données indiquant l'adresse IP à partir de laquelle des requêtes sont effectuées et les horaires des requêtes, ainsi que le modèle des requêtes, suffisent en soi à révéler de nombreuses informations sur les utilisateurs.
- Vulnérabilité à la censure : une structure de marché dominée par quelques fournisseurs RPC est celle qui subira une forte pression pour déplatformer ou censurer les utilisateurs. De nombreux fournisseurs RPC excluent déjà des pays entiers.
Pour ces raisons, il est utile de continuer à garantir une plus grande facilité d'exécution d'un nœud personnel.
Priorités à court terme
- Donnez la priorité à un déploiement complet de l'EIP-4444, jusqu'à l'état final où chaque nœud stocke des données pendant seulement environ 36 jours. Cela réduit considérablement les besoins en espace disque, qui sont le principal problème empêchant plus de personnes de faire fonctionner des nœuds. Après cela, les besoins en espace disque pour un nœud seront (i) la taille de l'état, (ii) les branches Merkle de l'état, (iii) 36 jours d'historique.
- Construisez une solution de stockage d'historique distribuée, grâce à laquelle chaque nœud peut stocker un petit pourcentage de données historiques plus anciennes que la limite. Utilisez un codage d'effacement pour maximiser la robustesse. Cela garantit la propriété selon laquelle «une blockchain est éternelle» sans dépendre de fournisseurs centralisés ou alourdir les opérateurs de nœuds.
- Ajustez les prix du gaz pour rendre le stockage plus cher et l'exécution moins chère. Une priorité particulièrement élevée est d'augmenter le coût du gaz pour la création de nouveaux états : (i) SSTORE pour de nouveaux emplacements de stockage, (ii) la création de code de contrat, (iii) l'envoi d'ETH à des comptes n'ayant pas encore de solde ou de nonce.
Priorité à moyen terme : vérification sans état
Une fois que nous activons la vérification sans état, il devient possible d'exécuter un nœud capable de RPC (c'est-à-dire un nœud qui stocke l'état) sans stocker les branches de Merkle d'état. Cela réduit encore les besoins de stockage d'environ 2 fois.
Un nouveau type de nœud : nœuds partiellement sans état
Il s'agit de la nouvelle idée, et sera clé pour permettre le fonctionnement du nœud personnel même dans un contexte où la limite de gaz L1 augmente de 10 à 100 fois.
Nous ajoutons un type de nœud qui vérifie les états des blocs de manière sans état, et vérifie l'ensemble de la chaîne (soit par validation sans état, soit par ZK-EVM) et maintient à jour une partie de l'état. Le nœud est capable de répondre aux demandes RPC tant que les données requises se trouvent dans ce sous-ensemble de l'état ; les autres demandes échoueront (ou devront recourir à une solution cryptographique hébergée à l'extérieur ; que ce soit le choix de l'utilisateur ou non).
partial_statelessness.drawio776×341 19.9 KB
La partie exacte de l'état à détenir dépendra d'une configuration choisie par l'utilisateur. Quelques exemples pourraient être:
- Tous les états sauf pour les contrats qui sont connus pour être du spam
- État associé à tous les EOAs et SCWs et à tous les jetons et applications ERC20 et ERC721 couramment utilisés
- État associé à tous les EOAs et SCWs qui ont été consultés au cours des deux dernières années, certains jetons ERC20 couramment utilisés, ainsi qu'un ensemble limité et sélectionné d'applications d'échange, de financement décentralisé et de confidentialité
La configuration pourrait être gérée par un contrat onchain : un utilisateur exécuterait son nœud avec —save_state_by_config 0x12345…67890, et l'adresse spécifierait dans une certaine langue une liste d'adresses, d'emplacements de stockage ou de régions filtrées de l'état que le nœud enregistrerait et maintiendrait à jour. Notez qu'il n'est pas nécessaire que l'utilisateur enregistre les branches de Merkle ; ils ont seulement besoin d'enregistrer les valeurs brutes.
Ce type de nœud offrirait les avantages d'un accès local direct à l'état dont un utilisateur doit se soucier, ainsi qu'une confidentialité maximale de l'accès à cet état.
Clause de non-responsabilité：
- Cet article est repris de [ethresear]. Tous les droits d'auteur appartiennent à l'auteur original [vbuterin]. Si vous avez des objections à cette réimpression, veuillez contacter le Porte Apprendrel'équipe, et ils s'en occuperont rapidement.
- Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
- Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.
