Cet article est provenant de : cofondateur d'Ethereum Vitalik
Compilation | Odaily Planet Daily (@OdailyChina)
Traducteur | Ethan（@ethanzhang_web3）
En plus des préoccupations en matière de sécurité réseau, la critique la plus courante concernant l'augmentation de la limite de gaz L1 est qu'elle rend plus difficile l'exécution de nœuds complets. En particulier dans le contexte d'une feuille de route axée sur la séparation des nœuds complets, il est essentiel de comprendre le rôle des nœuds complets pour résoudre ce problème.
Historiquement, les gens ont toujours considéré que les nœuds complets étaient utilisés pour valider les données sur la chaîne ; veuillez consulter ici pour comprendre mon propre exposé sur ce qui pourrait se passer si les utilisateurs ordinaires ne peuvent pas valider. Si c'est le seul problème, alors le ZK-EVM peut débloquer l'extension L1 : la seule limite est de maintenir les coûts de construction de blocs et de preuve à un niveau suffisamment bas, permettant ainsi aux deux de conserver une résistance à la censure de type 1-of-n et une compétitivité sur le marché.
Mais en réalité, ce n'est pas le seul problème. Un autre problème majeur est que posséder un nœud complet est très précieux, car cela vous permet d'avoir un serveur RPC local pour lire la chaîne de manière sans confiance, anti-censure et respectueuse de la vie privée. Ce document discutera des ajustements apportés à la feuille de route actuelle d'extension L1 pour atteindre cet objectif.
Pourquoi continuer à réaliser la confiance et la confidentialité sans confiance grâce à ZK-EVM + PIR ?
Dans la feuille de route sur la confidentialité que j'ai publiée le mois dernier, j'ai proposé TEE + ORAM comme solution temporaire, ainsi que PIR comme solution à long terme. Ainsi, en plus de Helios et de la vérification ZK-EVM, tout utilisateur peut se connecter à un RPC externe et être entièrement assuré : (i) que la chaîne qu'il obtient est correcte ; (ii) que la confidentialité de ses données est protégée. Nous ne pouvons donc nous empêcher de nous demander : pourquoi ne pas s'arrêter là ? Ces solutions cryptographiques avancées ne rendront-elles pas les nœuds auto-hébergés obsolètes ?
Ici, je peux donner plusieurs réponses :
Les solutions cryptographiques totalement sans confiance (c'est-à-dire 1-server PIR) seront très coûteuses. Les frais actuels sont irréalistes et, même après plusieurs améliorations d'efficacité, il est très probable qu'elles restent coûteuses.
Confidentialité des métadonnées. Quelle adresse IP a émis une demande à quel moment, ainsi que le modèle de la demande, ces données elles-mêmes suffisent à révéler une grande quantité d'informations sur l'utilisateur.
Examen des vulnérabilités : la structure du marché dominée par quelques fournisseurs de RPC sera soumise à une forte pression pour annuler des plateformes ou censurer des utilisateurs. De nombreux fournisseurs de RPC ont déjà exclu des pays entiers.
Pour ces raisons, il est précieux de continuer à garantir un fonctionnement plus pratique des nœuds personnels.
Priorités à court terme
Prioriser la promotion complète de l'EIP-4444 jusqu'à ce que chaque nœud ne stocke qu'un état final de données d'environ 36 jours. Cela réduira considérablement les besoins en espace disque, qui sont le principal obstacle à ce que davantage de personnes exécutent des nœuds. Par la suite, les besoins en espace disque des nœuds seront : (i) taille de l'état ; (ii) branche Merkle de l'état ; (iii) historique de 36 jours.
Construire des solutions de stockage historique distribué, où chaque nœud peut stocker une petite partie des données historiques antérieures à la date limite. Utiliser des codes de correction pour maximiser la robustesse. Cela peut garantir que la caractéristique "la blockchain est éternelle" sans avoir besoin de dépendre de fournisseurs centralisés ou d'imposer un lourd fardeau aux opérateurs de nœuds.
Ajuster la tarification du Gas pour rendre le coût de stockage plus élevé et le coût d'exécution plus bas. Il est particulièrement prioritaire d'augmenter le coût en Gas pour créer un nouvel état : (i) SSTORE pour un nouveau slot de stockage, (ii) création de code de contrat, (iii) envoyer de l'ETH à des comptes sans solde ni nonce.
Priorités à moyen terme : vérification sans état
Une fois que nous avons activé la validation sans état, il devient possible d'exécuter des nœuds avec des fonctionnalités RPC (c'est-à-dire des nœuds stockant l'état) sans stocker les branches Merkle de l'état. Cela réduira encore les besoins en stockage d'environ 2 fois.
Un nouveau type de nœud : nœud sans état partiel
C'est une nouvelle idée, et c'est aussi la clé permettant aux nœuds individuels de fonctionner dans le cadre d'une augmentation de 10 à 100 fois de la limitation de gaz L1.
Nous avons ajouté un type de nœud qui peut valider les blocs sans état, valider l'ensemble de la chaîne (via la validation sans état ou ZK-EVM), et maintenir une partie de l'état à jour. Tant que les données requises sont dans cet ensemble d'état, le nœud peut répondre aux requêtes RPC ; d'autres requêtes échoueront (ou devront être renvoyées à une solution cryptographique hébergée externe ; la décision d'agir ainsi doit être laissée à l'utilisateur).
La partie spécifique de l'état à maintenir dépend de la configuration choisie par l'utilisateur. Voici un exemple.
Tous les états à l'exception des contrats poubelles connus
État lié à tous les EOA et SCW ainsi qu'à tous les jetons et applications ERC 20 et ERC 721 courants.
État lié à tous les EOA et SCW visités au cours des deux dernières années, ainsi qu'à quelques jetons ERC 20 courants, ajouté à un ensemble limité d'applications d'échange, de defi et de confidentialité.
La configuration peut être gérée via des contrats en chaîne : les utilisateurs peuvent exécuter leur nœud en utilisant --save_state_by_config 0x 12345...67890 ; cette adresse spécifiera dans une certaine langue l'adresse à laquelle le nœud sauvegardera et maintiendra l'état à jour, ainsi que la liste des emplacements de stockage ou d'autres zones filtrées. Veuillez noter que les utilisateurs n'ont pas besoin de sauvegarder la branche Merkle ; ils doivent simplement sauvegarder la valeur d'origine.
Ce type de nœud permet aux utilisateurs d'accéder directement en local à l'état qu'ils souhaitent surveiller, tout en protégeant au maximum la vie privée d'accès à cet état.
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.
Vitalik : nouvelle solution pour résoudre le problème d'évolutivité de L1 d'Ethereum
Cet article est provenant de : cofondateur d'Ethereum Vitalik
Compilation | Odaily Planet Daily (@OdailyChina)
Traducteur | Ethan（@ethanzhang_web3）
En plus des préoccupations en matière de sécurité réseau, la critique la plus courante concernant l'augmentation de la limite de gaz L1 est qu'elle rend plus difficile l'exécution de nœuds complets. En particulier dans le contexte d'une feuille de route axée sur la séparation des nœuds complets, il est essentiel de comprendre le rôle des nœuds complets pour résoudre ce problème.
Historiquement, les gens ont toujours considéré que les nœuds complets étaient utilisés pour valider les données sur la chaîne ; veuillez consulter ici pour comprendre mon propre exposé sur ce qui pourrait se passer si les utilisateurs ordinaires ne peuvent pas valider. Si c'est le seul problème, alors le ZK-EVM peut débloquer l'extension L1 : la seule limite est de maintenir les coûts de construction de blocs et de preuve à un niveau suffisamment bas, permettant ainsi aux deux de conserver une résistance à la censure de type 1-of-n et une compétitivité sur le marché.
Mais en réalité, ce n'est pas le seul problème. Un autre problème majeur est que posséder un nœud complet est très précieux, car cela vous permet d'avoir un serveur RPC local pour lire la chaîne de manière sans confiance, anti-censure et respectueuse de la vie privée. Ce document discutera des ajustements apportés à la feuille de route actuelle d'extension L1 pour atteindre cet objectif.
Pourquoi continuer à réaliser la confiance et la confidentialité sans confiance grâce à ZK-EVM + PIR ?
Dans la feuille de route sur la confidentialité que j'ai publiée le mois dernier, j'ai proposé TEE + ORAM comme solution temporaire, ainsi que PIR comme solution à long terme. Ainsi, en plus de Helios et de la vérification ZK-EVM, tout utilisateur peut se connecter à un RPC externe et être entièrement assuré : (i) que la chaîne qu'il obtient est correcte ; (ii) que la confidentialité de ses données est protégée. Nous ne pouvons donc nous empêcher de nous demander : pourquoi ne pas s'arrêter là ? Ces solutions cryptographiques avancées ne rendront-elles pas les nœuds auto-hébergés obsolètes ?
Ici, je peux donner plusieurs réponses :
Pour ces raisons, il est précieux de continuer à garantir un fonctionnement plus pratique des nœuds personnels.
Priorités à court terme
Priorités à moyen terme : vérification sans état
Une fois que nous avons activé la validation sans état, il devient possible d'exécuter des nœuds avec des fonctionnalités RPC (c'est-à-dire des nœuds stockant l'état) sans stocker les branches Merkle de l'état. Cela réduira encore les besoins en stockage d'environ 2 fois.
Un nouveau type de nœud : nœud sans état partiel
C'est une nouvelle idée, et c'est aussi la clé permettant aux nœuds individuels de fonctionner dans le cadre d'une augmentation de 10 à 100 fois de la limitation de gaz L1.
Nous avons ajouté un type de nœud qui peut valider les blocs sans état, valider l'ensemble de la chaîne (via la validation sans état ou ZK-EVM), et maintenir une partie de l'état à jour. Tant que les données requises sont dans cet ensemble d'état, le nœud peut répondre aux requêtes RPC ; d'autres requêtes échoueront (ou devront être renvoyées à une solution cryptographique hébergée externe ; la décision d'agir ainsi doit être laissée à l'utilisateur).
La partie spécifique de l'état à maintenir dépend de la configuration choisie par l'utilisateur. Voici un exemple.
La configuration peut être gérée via des contrats en chaîne : les utilisateurs peuvent exécuter leur nœud en utilisant --save_state_by_config 0x 12345...67890 ; cette adresse spécifiera dans une certaine langue l'adresse à laquelle le nœud sauvegardera et maintiendra l'état à jour, ainsi que la liste des emplacements de stockage ou d'autres zones filtrées. Veuillez noter que les utilisateurs n'ont pas besoin de sauvegarder la branche Merkle ; ils doivent simplement sauvegarder la valeur d'origine.
Ce type de nœud permet aux utilisateurs d'accéder directement en local à l'état qu'ils souhaitent surveiller, tout en protégeant au maximum la vie privée d'accès à cet état.