Les critiques les plus courantes concernant l'augmentation de la limite de gaz L1, en dehors des préoccupations liées à la sécurité du réseau, sont que cela rendra l'exécution des nœuds complets plus difficile. Surtout dans le contexte d'une feuille de route centrée sur "le détachement des nœuds complets", il est nécessaire de comprendre la signification de l'existence des nœuds complets pour résoudre ce problème.
La vision traditionnelle considère que les nœuds complets sont utilisés pour vérifier les données sur la chaîne. Si c'est le seul problème, alors le ZK-EVM peut débloquer l'extension L1 : la seule limite est de maintenir le coût de construction de blocs et de preuve suffisamment bas, afin que les deux puissent à la fois maintenir une résistance à la censure de type 1 sur n et former un marché concurrentiel.
Mais dans la réalité, ce n'est pas le seul critère. Un autre facteur important est : exécuter un nœud complet vous permet d'avoir un serveur RPC local, ce qui vous permet de lire les données de la chaîne de manière sans confiance, résistant à la censure et en protégeant votre vie privée. Cet article discutera de la façon d'ajuster la feuille de route d'extension L1 actuelle pour atteindre cet objectif.
1. Pourquoi ne pas se contenter de la décentralisation et de la vie privée réalisées par ZK-EVM+PIR ?
La feuille de route sur la confidentialité que j'ai publiée le mois dernier plaide pour : l'adoption à court terme des solutions TEE + ORAM, et à long terme pour la technologie PIR. En combinant Helios et ZK-EVM pour la vérification, les utilisateurs peuvent être totalement sûrs lors de la connexion à un RPC externe : que les données de la chaîne obtenues sont correctes, que la confidentialité des données est protégée. Cela soulève une question : pourquoi ne pas s'arrêter là ? Ces solutions cryptographiques avancées rendent-elles les nœuds auto-hébergés obsolètes ?
À ce sujet, j'ai quelques réponses :
--Les solutions cryptographiques totalement sans confiance (comme le PIR à serveur unique) sont coûteuses. Les frais actuels sont irréalistes, même après plusieurs optimisations de l'efficacité, elles peuvent encore rester à un prix élevé.
--Problèmes de confidentialité des métadonnées. Les métadonnées telles que l'heure de la demande de l'adresse IP, le modèle de demande, etc., peuvent elles-mêmes révéler une grande quantité d'informations sur les utilisateurs.
--Vérification des vulnérabilités : Une structure de marché dominée par un petit nombre de fournisseurs RPC sera confrontée à une forte pression d'interdiction ou de censure des utilisateurs. De nombreux fournisseurs RPC ont commencé à bloquer complètement certains pays.
Par conséquent, il reste précieux de garantir la commodité de fonctionnement des nœuds personnels.
( 2. Priorités à court terme
Déploiement complet prioritaire de l'EIP-4444, visant finalement à ce que chaque nœud ne stocke environ que 36 jours de données. Cela réduira considérablement les besoins en espace disque - actuellement le principal obstacle à l'exécution des nœuds. Par la suite, les besoins en stockage des nœuds ne comprendront que : )i( données d'état, )ii### branche de Merkle d'état, (iii)36 jours de données historiques.
Construire une solution de stockage historique distribué, permettant à chaque nœud de stocker une petite quantité de données historiques obsolètes. Maximiser la fiabilité grâce à la technologie de code de correction d'erreurs. Cela garantit à la fois la caractéristique "la blockchain conserve de manière permanente" et ne nécessite pas de dépendre de fournisseurs centralisés ni d'imposer un lourd fardeau aux opérateurs de nœuds.
Ajuster la stratégie de tarification du Gas, augmenter les coûts de stockage et réduire les coûts d'exécution. Mettre l'accent sur l'augmentation des coûts en Gas pour les opérations suivantes : (i) exécuter SSTORE pour un nouveau slot de stockage, (ii) créer du code de contrat, (iii) transférer de l'ETH à un compte à solde zéro/nouvelle nonce.
( 3, Objectif à moyen terme : validation sans état
Après la mise en œuvre de la validation sans état, les nœuds prenant en charge RPC (c'est-à-dire les nœuds qui stockent l'état) n'auront plus besoin de conserver les branches de Merkle de l'état. Cela peut réduire les besoins de stockage d'environ 50 %.
4, Nouveaux nœuds : certains nœuds sans état
Cette idée innovante sera la clé pour maintenir le fonctionnement des nœuds personnels après une augmentation de 10 à 100 fois de la limite de gaz L1.
Nous avons ajouté un nouveau type de nœud : validation des blocs de manière sans état, en validant l'ensemble de la chaîne soit par validation sans état, soit par validation ZK-EVM, tout en maintenant uniquement une partie des données d'état. Tant que les données requises par la requête RPC se trouvent dans ce sous-ensemble d'état, le nœud peut répondre ; d'autres requêtes échoueront (ou devront revenir à une solution cryptographique hébergée externe - le retour doit être choisi par l'utilisateur).
Les états spécifiques à maintenir dépendent de la configuration de l'utilisateur, par exemple :
--Exclure tous les états en dehors des contrats poubelles connus.
--État lié à tous les comptes EOA, SCW ainsi qu'aux jetons et applications ERC20/ERC721 courants.
--État des comptes EOA/SCW actifs au cours des deux dernières années + État de certains tokens ERC20 courants + État des applications swap/DeFi/privées sélectionnées.
La configuration peut être gérée par un contrat sur la chaîne : lorsque les utilisateurs exécutent un nœud, ils utilisent le paramètre "--save_state_by_config 0x12345...67890", cette adresse définira la liste des adresses que le nœud doit sauvegarder et mettre à jour en temps réel, ainsi que les emplacements de stockage (storage slots) ou les règles de filtrage d'état dans une langue spécifique. Notez que les utilisateurs n'ont pas besoin de sauvegarder la branche de Merkle, ils doivent uniquement sauvegarder les valeurs brutes.
Ce type de nœud offre à la fois l'avantage d'un accès direct local aux états clés et garantit une confidentialité d'accès totale.
Voir l'original
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 : une proposition d'optimisation de la feuille de route d'extension axée sur les nœuds locaux
Auteur : Vitalik, fondateur d'Ethereum ; Traduction : Jinse Caijingxiaozhou
Les critiques les plus courantes concernant l'augmentation de la limite de gaz L1, en dehors des préoccupations liées à la sécurité du réseau, sont que cela rendra l'exécution des nœuds complets plus difficile. Surtout dans le contexte d'une feuille de route centrée sur "le détachement des nœuds complets", il est nécessaire de comprendre la signification de l'existence des nœuds complets pour résoudre ce problème.
La vision traditionnelle considère que les nœuds complets sont utilisés pour vérifier les données sur la chaîne. Si c'est le seul problème, alors le ZK-EVM peut débloquer l'extension L1 : la seule limite est de maintenir le coût de construction de blocs et de preuve suffisamment bas, afin que les deux puissent à la fois maintenir une résistance à la censure de type 1 sur n et former un marché concurrentiel.
Mais dans la réalité, ce n'est pas le seul critère. Un autre facteur important est : exécuter un nœud complet vous permet d'avoir un serveur RPC local, ce qui vous permet de lire les données de la chaîne de manière sans confiance, résistant à la censure et en protégeant votre vie privée. Cet article discutera de la façon d'ajuster la feuille de route d'extension L1 actuelle pour atteindre cet objectif.
1. Pourquoi ne pas se contenter de la décentralisation et de la vie privée réalisées par ZK-EVM+PIR ?
La feuille de route sur la confidentialité que j'ai publiée le mois dernier plaide pour : l'adoption à court terme des solutions TEE + ORAM, et à long terme pour la technologie PIR. En combinant Helios et ZK-EVM pour la vérification, les utilisateurs peuvent être totalement sûrs lors de la connexion à un RPC externe : que les données de la chaîne obtenues sont correctes, que la confidentialité des données est protégée. Cela soulève une question : pourquoi ne pas s'arrêter là ? Ces solutions cryptographiques avancées rendent-elles les nœuds auto-hébergés obsolètes ?
À ce sujet, j'ai quelques réponses :
--Les solutions cryptographiques totalement sans confiance (comme le PIR à serveur unique) sont coûteuses. Les frais actuels sont irréalistes, même après plusieurs optimisations de l'efficacité, elles peuvent encore rester à un prix élevé.
--Problèmes de confidentialité des métadonnées. Les métadonnées telles que l'heure de la demande de l'adresse IP, le modèle de demande, etc., peuvent elles-mêmes révéler une grande quantité d'informations sur les utilisateurs.
--Vérification des vulnérabilités : Une structure de marché dominée par un petit nombre de fournisseurs RPC sera confrontée à une forte pression d'interdiction ou de censure des utilisateurs. De nombreux fournisseurs RPC ont commencé à bloquer complètement certains pays.
Par conséquent, il reste précieux de garantir la commodité de fonctionnement des nœuds personnels.
( 2. Priorités à court terme
Déploiement complet prioritaire de l'EIP-4444, visant finalement à ce que chaque nœud ne stocke environ que 36 jours de données. Cela réduira considérablement les besoins en espace disque - actuellement le principal obstacle à l'exécution des nœuds. Par la suite, les besoins en stockage des nœuds ne comprendront que : )i( données d'état, )ii### branche de Merkle d'état, (iii)36 jours de données historiques.
Construire une solution de stockage historique distribué, permettant à chaque nœud de stocker une petite quantité de données historiques obsolètes. Maximiser la fiabilité grâce à la technologie de code de correction d'erreurs. Cela garantit à la fois la caractéristique "la blockchain conserve de manière permanente" et ne nécessite pas de dépendre de fournisseurs centralisés ni d'imposer un lourd fardeau aux opérateurs de nœuds.
Ajuster la stratégie de tarification du Gas, augmenter les coûts de stockage et réduire les coûts d'exécution. Mettre l'accent sur l'augmentation des coûts en Gas pour les opérations suivantes : (i) exécuter SSTORE pour un nouveau slot de stockage, (ii) créer du code de contrat, (iii) transférer de l'ETH à un compte à solde zéro/nouvelle nonce.
( 3, Objectif à moyen terme : validation sans état
Après la mise en œuvre de la validation sans état, les nœuds prenant en charge RPC (c'est-à-dire les nœuds qui stockent l'état) n'auront plus besoin de conserver les branches de Merkle de l'état. Cela peut réduire les besoins de stockage d'environ 50 %.
4, Nouveaux nœuds : certains nœuds sans état
Cette idée innovante sera la clé pour maintenir le fonctionnement des nœuds personnels après une augmentation de 10 à 100 fois de la limite de gaz L1.
Nous avons ajouté un nouveau type de nœud : validation des blocs de manière sans état, en validant l'ensemble de la chaîne soit par validation sans état, soit par validation ZK-EVM, tout en maintenant uniquement une partie des données d'état. Tant que les données requises par la requête RPC se trouvent dans ce sous-ensemble d'état, le nœud peut répondre ; d'autres requêtes échoueront (ou devront revenir à une solution cryptographique hébergée externe - le retour doit être choisi par l'utilisateur).
![qWmAn09ZE4jt0rEyydlCshCydJI7aVcg5fEeT5qk.png])https://img.gateio.im/social/moments-03f98897bcef682e26eb0c90558d1df9 "7370273"(
Les états spécifiques à maintenir dépendent de la configuration de l'utilisateur, par exemple :
--Exclure tous les états en dehors des contrats poubelles connus.
--État lié à tous les comptes EOA, SCW ainsi qu'aux jetons et applications ERC20/ERC721 courants.
--État des comptes EOA/SCW actifs au cours des deux dernières années + État de certains tokens ERC20 courants + État des applications swap/DeFi/privées sélectionnées.
La configuration peut être gérée par un contrat sur la chaîne : lorsque les utilisateurs exécutent un nœud, ils utilisent le paramètre "--save_state_by_config 0x12345...67890", cette adresse définira la liste des adresses que le nœud doit sauvegarder et mettre à jour en temps réel, ainsi que les emplacements de stockage (storage slots) ou les règles de filtrage d'état dans une langue spécifique. Notez que les utilisateurs n'ont pas besoin de sauvegarder la branche de Merkle, ils doivent uniquement sauvegarder les valeurs brutes.
Ce type de nœud offre à la fois l'avantage d'un accès direct local aux états clés et garantit une confidentialité d'accès totale.