Exécuter un Full Node vous permet d'avoir un serveur RPC local, vous permettant de lire des données on-chain de manière sans confiance, résistante à la censure et respectueuse de la vie privée.
Auteur : Vitalik, fondateur d'Ethereum
Compilation : Jinse Caijing xiaozhou
Les critiques les plus courantes concernant l'augmentation de la limite de gaz L1, en plus des préoccupations liées à la sécurité du réseau, sont que cela rendra l'exécution des Full Nodes plus difficile. Surtout dans le contexte d'une feuille de route centrée sur le « déliement des Full Nodes », il est nécessaire de comprendre le sens de l'existence des Full Nodes pour résoudre ce problème.
La conception traditionnelle considère que les Full Nodes sont utilisés pour vérifier les données on-chain. Si c'est le seul problème, alors le ZK-EVM peut débloquer l'extension L1 : la seule restriction est de maintenir le coût de construction des blocs et de preuve suffisamment bas, de sorte que les deux puissent à la fois maintenir la résistance à la censure 1 of n et former un marché concurrentiel.
Mais dans la réalité, ce n'est pas le seul critère à prendre en compte. Un autre facteur important est : faire fonctionner un Full Node vous permet d'avoir un serveur RPC local, ce qui vous permet de lire les données off-chain de manière sans confiance, résiliente à la censure et respectueuse de la vie privée. Cet article discutera de la manière d'ajuster la feuille de route actuelle d'expansion L1 pour atteindre cet objectif.
1. Pourquoi ne pas se contenter de la décentralisation et de la confidentialité réalisées par ZK-EVM+PIR ?
La feuille de route sur la confidentialité que j'ai publiée le mois dernier plaide pour : une adoption à court terme des solutions TEEs + ORAM, et à long terme un passage à la technologie PIR. En combinant Helios et la vérification ZK-EVM, les utilisateurs peuvent être totalement sûrs lorsqu'ils se connectent à un RPC externe : (i) que les données de chaîne obtenues sont correctes, et (ii) 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 ?
À cela, j'ai quelques réponses :
Les solutions cryptographiques complètement décentralisées (comme le PIR sur un seul serveur) sont coûteuses. Les dépenses actuelles sont irréalistes, même après plusieurs optimisations d'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, le modèle de demande et l'adresse IP peuvent elles-mêmes révéler une quantité importante d'informations sur les utilisateurs.
Examen des vulnérabilités : La structure du marché dominée par quelques fournisseurs RPC sera soumise à une forte pression de blocage ou de censure des utilisateurs. De nombreux fournisseurs RPC ont commencé à bloquer complètement certains pays.
Ainsi, il reste utile de continuer à garantir la commodité de fonctionnement des nœuds personnels.
2. Priorités à court terme
Privilégiez le déploiement complet de l’EIP-4444 pour atteindre seulement environ 36 jours de stockage de données par nœud. Cela réduira considérablement les besoins en espace disque dur, qui sont actuellement le principal obstacle empêchant les gens d’exécuter des nœuds. Par la suite, les besoins de stockage des nœuds se composeront uniquement des données d’état (i), (ii) branche 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 de « conservation permanente de la blockchain » et évite de dépendre de fournisseurs centralisés ou de créer un lourd fardeau pour les opérateurs de nœuds.
Ajustez votre stratégie de tarification du gaz pour augmenter les coûts de stockage et réduire les coûts d’exécution. Concentrez-vous sur l’augmentation du coût du gaz pour les opérations suivantes : (i) Exécuter SSTORE pour le nouvel emplacement de stockage, (ii) pour créer le code du contrat, (iii) Transférez des ETH vers un compte à solde zéro/zéro once.
3. Objectif à moyen terme : validation sans état
Après la mise en œuvre de la validation sans état, l'exécution des nœuds prenant en charge RPC (c'est-à-dire les nœuds stockant l'état) n'aura plus besoin de conserver la branche Merkle de l'état. Cela peut réduire encore 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 l'exécution des nœuds personnels même après une augmentation de 10 à 100 fois de la limite de gaz L1.
Nous avons ajouté un nouveau type de nœud : vérifier les blocs de manière sans état, en validant l'ensemble de la chaîne par une validation sans état ou une validation ZK-EVM, mais en maintenant uniquement une partie des données d'état. Tant que les données nécessaires à la requête RPC se trouvent dans ce sous-ensemble d'état, le nœud pourra répondre ; d'autres requêtes échoueront (ou devront revenir à une solution cryptographique hébergée extérieurement - le choix de revenir ou non doit être laissé à 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 et 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 des contrats sur la chaîne : lorsque l'utilisateur exécute un nœud, il utilise le paramètre « --save_state_by_config 0x12345...67890 », cette adresse définira en une langue spécifique la liste des adresses que le nœud doit sauvegarder et mettre à jour en temps réel, les emplacements de stockage (storage slot) ou les règles de filtrage d'état. Notez que l'utilisateur n'a pas besoin de sauvegarder la branche Merkle, mais seulement les valeurs brutes.
Ces nœuds offrent à la fois l'avantage d'un accès direct local aux états clés et garantissent 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 : un plan d'optimisation de la feuille de route d'extension axé sur les nœuds locaux
Auteur : Vitalik, fondateur d'Ethereum
Compilation : Jinse Caijing xiaozhou
Les critiques les plus courantes concernant l'augmentation de la limite de gaz L1, en plus des préoccupations liées à la sécurité du réseau, sont que cela rendra l'exécution des Full Nodes plus difficile. Surtout dans le contexte d'une feuille de route centrée sur le « déliement des Full Nodes », il est nécessaire de comprendre le sens de l'existence des Full Nodes pour résoudre ce problème.
La conception traditionnelle considère que les Full Nodes sont utilisés pour vérifier les données on-chain. Si c'est le seul problème, alors le ZK-EVM peut débloquer l'extension L1 : la seule restriction est de maintenir le coût de construction des blocs et de preuve suffisamment bas, de sorte que les deux puissent à la fois maintenir la résistance à la censure 1 of n et former un marché concurrentiel.
Mais dans la réalité, ce n'est pas le seul critère à prendre en compte. Un autre facteur important est : faire fonctionner un Full Node vous permet d'avoir un serveur RPC local, ce qui vous permet de lire les données off-chain de manière sans confiance, résiliente à la censure et respectueuse de la vie privée. Cet article discutera de la manière d'ajuster la feuille de route actuelle d'expansion L1 pour atteindre cet objectif.
1. Pourquoi ne pas se contenter de la décentralisation et de la confidentialité réalisées par ZK-EVM+PIR ?
La feuille de route sur la confidentialité que j'ai publiée le mois dernier plaide pour : une adoption à court terme des solutions TEEs + ORAM, et à long terme un passage à la technologie PIR. En combinant Helios et la vérification ZK-EVM, les utilisateurs peuvent être totalement sûrs lorsqu'ils se connectent à un RPC externe : (i) que les données de chaîne obtenues sont correctes, et (ii) 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 ?
À cela, j'ai quelques réponses :
Ainsi, il reste utile de continuer à garantir la commodité de fonctionnement des nœuds personnels.
2. Priorités à court terme
Privilégiez le déploiement complet de l’EIP-4444 pour atteindre seulement environ 36 jours de stockage de données par nœud. Cela réduira considérablement les besoins en espace disque dur, qui sont actuellement le principal obstacle empêchant les gens d’exécuter des nœuds. Par la suite, les besoins de stockage des nœuds se composeront uniquement des données d’état (i), (ii) branche 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 de « conservation permanente de la blockchain » et évite de dépendre de fournisseurs centralisés ou de créer un lourd fardeau pour les opérateurs de nœuds.
Ajustez votre stratégie de tarification du gaz pour augmenter les coûts de stockage et réduire les coûts d’exécution. Concentrez-vous sur l’augmentation du coût du gaz pour les opérations suivantes : (i) Exécuter SSTORE pour le nouvel emplacement de stockage, (ii) pour créer le code du contrat, (iii) Transférez des ETH vers un compte à solde zéro/zéro once.
3. Objectif à moyen terme : validation sans état
Après la mise en œuvre de la validation sans état, l'exécution des nœuds prenant en charge RPC (c'est-à-dire les nœuds stockant l'état) n'aura plus besoin de conserver la branche Merkle de l'état. Cela peut réduire encore 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 l'exécution des nœuds personnels même après une augmentation de 10 à 100 fois de la limite de gaz L1.
Nous avons ajouté un nouveau type de nœud : vérifier les blocs de manière sans état, en validant l'ensemble de la chaîne par une validation sans état ou une validation ZK-EVM, mais en maintenant uniquement une partie des données d'état. Tant que les données nécessaires à la requête RPC se trouvent dans ce sous-ensemble d'état, le nœud pourra répondre ; d'autres requêtes échoueront (ou devront revenir à une solution cryptographique hébergée extérieurement - le choix de revenir ou non doit être laissé à l'utilisateur).
Les états spécifiques à maintenir dépendent de la configuration de l'utilisateur, par exemple :
La configuration peut être gérée par des contrats sur la chaîne : lorsque l'utilisateur exécute un nœud, il utilise le paramètre « --save_state_by_config 0x12345...67890 », cette adresse définira en une langue spécifique la liste des adresses que le nœud doit sauvegarder et mettre à jour en temps réel, les emplacements de stockage (storage slot) ou les règles de filtrage d'état. Notez que l'utilisateur n'a pas besoin de sauvegarder la branche Merkle, mais seulement les valeurs brutes.
Ces nœuds offrent à la fois l'avantage d'un accès direct local aux états clés et garantissent une confidentialité d'accès totale.