Vitalik Buterin a récemment publié une série d'articles de discussion sur l'avenir du développement d'Ethereum, abordant des sujets allant de la fusion, de l'afflux, de la fougue, de la marge à la dernière phase de purification. Ces articles montrent la vision de Vitalik pour l'avenir du réseau principal d'Ethereum et comment résoudre les problèmes actuellement rencontrés.
L'objectif principal de la phase de purification est de réduire les exigences de stockage des clients en diminuant ou en éliminant la nécessité pour chaque nœud de conserver en permanence tous les historiques, voire l'état final, et de réduire la complexité du protocole en éliminant les fonctionnalités inutiles.
Historique expiré
L'expiration historique vise à résoudre le problème de l'espace disque nécessaire pour les nœuds Ethereum entièrement synchronisés. Actuellement, un client d'exécution nécessite environ 1,1 To d'espace disque, tandis qu'un client de consensus nécessite également plusieurs centaines de Go. La grande majorité de cela est des données historiques datant de plusieurs années.
La clé de l'expiration historique réside dans l'exploitation des caractéristiques du mécanisme de consensus, il suffit d'atteindre un consensus sur le dernier bloc pour vérifier l'exactitude des données historiques. Cela offre plusieurs options pour le stockage des enregistrements historiques, comme chaque nœud ne stocke qu'une partie des données.
Actuellement, Ethereum a commencé à se débarrasser progressivement du modèle où tous les nœuds stockent de manière permanente tout l'historique. Les blocs de consensus ne stockent que pendant environ 6 mois, les blobs ne sont stockés que pendant environ 18 jours. L'objectif futur est d'établir une période de stockage unifiée ( pouvant durer environ 18 jours ), puis de stocker les anciennes données via un réseau distribué.
La réalisation de l'expiration historique nécessite la construction et l'intégration de solutions de stockage distribué spécifiques, telles que l'introduction de bibliothèques torrent existantes ou du réseau Portal natif d'Ethereum. Le principal compromis réside dans la manière de fournir des données historiques "anciennes" et la profondeur de l'intégration du stockage historique dans le protocole.
L'expiration historique est cruciale pour le fonctionnement et le démarrage des nœuds, contribuant à réaliser la vision de faire fonctionner un nœud Ethereum sur une montre intelligente. Cela rend également la mise en œuvre de nœuds Ethereum plus récents plus viable, ne prenant en charge que la dernière version du protocole.
État expiré
L'expiration de l'état vise à résoudre le problème selon lequel les besoins de stockage du client continuent d'augmenter même si la nécessité de conserver l'historique de stockage est éliminée. Cela est dû au fait que le solde du compte (, le nombre aléatoire, le code du contrat et le stockage ) continueront d'augmenter, et les utilisateurs ne paient qu'un frais unique pour imposer un fardeau de stockage au client de manière permanente.
L'expiration d'état est plus difficile à réaliser que l'expiration historique, car la conception de l'EVM suppose que les objets d'état, une fois créés, existent éternellement. Actuellement, il existe deux principales catégories de solutions : l'expiration partielle de l'état et l'expiration de l'état basée sur le cycle d'adresse.
Certaines états obsolètes divisent l'état en blocs, seules les données récemment accessibles seront stockées. L'EIP-7736 est une proposition concrète, basée sur le design "tige-feuille" introduit pour l'arbre Verkle.
La conception basée sur le cycle d'adresse résout le problème des conflits de résurrection grâce à une liste d'arbres d'état en constante augmentation. Chaque période (, comme 1 an ), ajoute un nouvel arbre d'état vide, les nœuds complets ne stockent que les deux derniers arbres.
Le principal défi de la mise en œuvre de l'expiration de l'état est l'expansion ou la contraction de l'espace d'adresses, ce qui nécessite de résoudre des problèmes complexes de compatibilité et de sécurité. Que l'expiration de l'état soit mise en œuvre ou non, il faudra finalement résoudre le problème de l'espace d'adresses.
Nettoyage des fonctionnalités
Le nettoyage des fonctionnalités vise à réduire la complexité du protocole, à améliorer la sécurité, l'accessibilité et la neutralité de confiance. Les principales méthodes incluent la suppression des fonctionnalités inutiles, la simplification des mécanismes existants, l'unification des formats de données, etc.
Quelques opportunités de simplification spécifiques incluent :
Convertir RLP en SSZ
Supprimer l'ancien type de transaction
Réformer le mécanisme LOG
Supprimer le mécanisme du comité de synchronisation de la chaîne de balises
Format de données unifié
Supprimer le comité de la chaîne de balises
Supprimer l'ordre des octets mélangé
Simplification du mécanisme Gas
Supprimer le précompilé
Supprimer la visibilité des gas
Améliorer l'analyse statique
Le principal compromis de la simplification fonctionnelle est le degré de simplification et la rapidité par rapport à la compatibilité descendante. Il est nécessaire d'établir un pipeline standardisé pour effectuer des modifications non urgentes qui rompent la compatibilité descendante, en cherchant un équilibre entre la suppression de fonctionnalités et la prudence.
Le format d'objet EVM ( EOF ) est un ensemble de modifications majeures proposées pour l'EVM, visant à permettre à l'EVM d'être mis à jour de manière plus robuste. Son avantage est de créer un chemin naturel pour l'ajout de nouvelles fonctionnalités à l'EVM, mais cela augmente également considérablement la complexité du protocole.
Une stratégie de simplification plus radicale consiste à transformer la majeure partie du contenu du protocole en code de contrat, comme faire de l'Ethereum L1 une chaîne de balise uniquement, en introduisant une machine virtuelle minimale permettant de créer des résumés. Ou bien échanger l'EVM sur place, en choisissant une "officielle Ethereum VM" nouvelle.
En général, la phase de purification vise à réduire les besoins de stockage et la complexité du protocole grâce à l'expiration historique, l'expiration d'état et le nettoyage des fonctionnalités, posant ainsi les bases de l'évolutivité et de la durabilité à long terme d'Ethereum. Cela nécessite de rechercher un équilibre entre simplification et compatibilité, et peut impliquer des transformations profondes du protocole.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
9 J'aime
Récompense
9
7
Partager
Commentaire
0/400
NFTragedy
· Il y a 11h
Vendre le vieux pour avancer, n'est-ce pas !
Voir l'originalRépondre0
CryptoCross-TalkClub
· Il y a 11h
Encore une mise à jour, les pigeons ont été pris pour des idiots et les mineurs.
Voir l'originalRépondre0
TokenomicsTrapper
· Il y a 11h
ngmi juste une autre histoire de cope eth pour être honnête...
Voir l'originalRépondre0
DegenDreamer
· Il y a 11h
Encore en train de parler de simplification mais ça n'augmente pas.
Voir l'originalRépondre0
DaisyUnicorn
· Il y a 11h
Vitalik Buterin va tailler le jardin d'Éthereum~
Voir l'originalRépondre0
DogeBachelor
· Il y a 11h
Après une mise à jour de plusieurs heures, le prix n'a toujours pas augmenté.
Voir l'originalRépondre0
AlwaysMissingTops
· Il y a 12h
Cowhide a finalement attendu pour faire ces vieilles données
Chemin de purification de l'Ethereum : Goutte des exigences de stockage et simplification de la complexité du protocole
L'avenir potentiel de l'Ethereum : purification
Vitalik Buterin a récemment publié une série d'articles de discussion sur l'avenir du développement d'Ethereum, abordant des sujets allant de la fusion, de l'afflux, de la fougue, de la marge à la dernière phase de purification. Ces articles montrent la vision de Vitalik pour l'avenir du réseau principal d'Ethereum et comment résoudre les problèmes actuellement rencontrés.
L'objectif principal de la phase de purification est de réduire les exigences de stockage des clients en diminuant ou en éliminant la nécessité pour chaque nœud de conserver en permanence tous les historiques, voire l'état final, et de réduire la complexité du protocole en éliminant les fonctionnalités inutiles.
Historique expiré
L'expiration historique vise à résoudre le problème de l'espace disque nécessaire pour les nœuds Ethereum entièrement synchronisés. Actuellement, un client d'exécution nécessite environ 1,1 To d'espace disque, tandis qu'un client de consensus nécessite également plusieurs centaines de Go. La grande majorité de cela est des données historiques datant de plusieurs années.
La clé de l'expiration historique réside dans l'exploitation des caractéristiques du mécanisme de consensus, il suffit d'atteindre un consensus sur le dernier bloc pour vérifier l'exactitude des données historiques. Cela offre plusieurs options pour le stockage des enregistrements historiques, comme chaque nœud ne stocke qu'une partie des données.
Actuellement, Ethereum a commencé à se débarrasser progressivement du modèle où tous les nœuds stockent de manière permanente tout l'historique. Les blocs de consensus ne stockent que pendant environ 6 mois, les blobs ne sont stockés que pendant environ 18 jours. L'objectif futur est d'établir une période de stockage unifiée ( pouvant durer environ 18 jours ), puis de stocker les anciennes données via un réseau distribué.
La réalisation de l'expiration historique nécessite la construction et l'intégration de solutions de stockage distribué spécifiques, telles que l'introduction de bibliothèques torrent existantes ou du réseau Portal natif d'Ethereum. Le principal compromis réside dans la manière de fournir des données historiques "anciennes" et la profondeur de l'intégration du stockage historique dans le protocole.
L'expiration historique est cruciale pour le fonctionnement et le démarrage des nœuds, contribuant à réaliser la vision de faire fonctionner un nœud Ethereum sur une montre intelligente. Cela rend également la mise en œuvre de nœuds Ethereum plus récents plus viable, ne prenant en charge que la dernière version du protocole.
État expiré
L'expiration de l'état vise à résoudre le problème selon lequel les besoins de stockage du client continuent d'augmenter même si la nécessité de conserver l'historique de stockage est éliminée. Cela est dû au fait que le solde du compte (, le nombre aléatoire, le code du contrat et le stockage ) continueront d'augmenter, et les utilisateurs ne paient qu'un frais unique pour imposer un fardeau de stockage au client de manière permanente.
L'expiration d'état est plus difficile à réaliser que l'expiration historique, car la conception de l'EVM suppose que les objets d'état, une fois créés, existent éternellement. Actuellement, il existe deux principales catégories de solutions : l'expiration partielle de l'état et l'expiration de l'état basée sur le cycle d'adresse.
Certaines états obsolètes divisent l'état en blocs, seules les données récemment accessibles seront stockées. L'EIP-7736 est une proposition concrète, basée sur le design "tige-feuille" introduit pour l'arbre Verkle.
La conception basée sur le cycle d'adresse résout le problème des conflits de résurrection grâce à une liste d'arbres d'état en constante augmentation. Chaque période (, comme 1 an ), ajoute un nouvel arbre d'état vide, les nœuds complets ne stockent que les deux derniers arbres.
Le principal défi de la mise en œuvre de l'expiration de l'état est l'expansion ou la contraction de l'espace d'adresses, ce qui nécessite de résoudre des problèmes complexes de compatibilité et de sécurité. Que l'expiration de l'état soit mise en œuvre ou non, il faudra finalement résoudre le problème de l'espace d'adresses.
Nettoyage des fonctionnalités
Le nettoyage des fonctionnalités vise à réduire la complexité du protocole, à améliorer la sécurité, l'accessibilité et la neutralité de confiance. Les principales méthodes incluent la suppression des fonctionnalités inutiles, la simplification des mécanismes existants, l'unification des formats de données, etc.
Quelques opportunités de simplification spécifiques incluent :
Le principal compromis de la simplification fonctionnelle est le degré de simplification et la rapidité par rapport à la compatibilité descendante. Il est nécessaire d'établir un pipeline standardisé pour effectuer des modifications non urgentes qui rompent la compatibilité descendante, en cherchant un équilibre entre la suppression de fonctionnalités et la prudence.
Le format d'objet EVM ( EOF ) est un ensemble de modifications majeures proposées pour l'EVM, visant à permettre à l'EVM d'être mis à jour de manière plus robuste. Son avantage est de créer un chemin naturel pour l'ajout de nouvelles fonctionnalités à l'EVM, mais cela augmente également considérablement la complexité du protocole.
Une stratégie de simplification plus radicale consiste à transformer la majeure partie du contenu du protocole en code de contrat, comme faire de l'Ethereum L1 une chaîne de balise uniquement, en introduisant une machine virtuelle minimale permettant de créer des résumés. Ou bien échanger l'EVM sur place, en choisissant une "officielle Ethereum VM" nouvelle.
En général, la phase de purification vise à réduire les besoins de stockage et la complexité du protocole grâce à l'expiration historique, l'expiration d'état et le nettoyage des fonctionnalités, posant ainsi les bases de l'évolutivité et de la durabilité à long terme d'Ethereum. Cela nécessite de rechercher un équilibre entre simplification et compatibilité, et peut impliquer des transformations profondes du protocole.