- Rubrique
22k Popularité
55k Popularité
5k Popularité
15k Popularité
30k Popularité
722 Popularité
112k Popularité
26k Popularité
26k Popularité
7k Popularité
- Épingler
22k Popularité
55k Popularité
5k Popularité
15k Popularité
30k Popularité
722 Popularité
112k Popularité
26k Popularité
26k Popularité
7k Popularité
Avenir du développement d'Ethereum : The Purge vise à simplifier le protocole et à réduire les besoins en stockage.
L'avenir possible d'Ethereum : The Purge
Depuis le 14 octobre, le fondateur d'Ethereum, Vitalik Buterin, a publié une série d'articles de discussion sur le développement futur d'Ethereum, allant de « The Merge » au dernier « The Purge », montrant sa vision pour le développement futur du réseau principal d'Ethereum et ses solutions aux problèmes actuels.
L'article « The Purge » explore comment Ethereum peut réduire la complexité et les besoins de stockage à long terme, tout en maintenant la durabilité et la décentralisation de la chaîne. Les principales mesures comprennent la réduction de la charge de stockage des clients grâce à l'"expiration historique" et à l'"expiration d'état", ainsi que la simplification du protocole par le biais de la "nettoyage des caractéristiques", afin d'assurer la durabilité et l'évolutivité du réseau.
Historique d'expiration 历史记录到期
résout quel problème?
Actuellement, un nœud Ethereum complètement synchronisé nécessite environ 1,1 To d'espace disque pour exécuter le client, et plusieurs centaines de Go supplémentaires pour le client de consensus. La grande majorité consiste en des données historiques, même si la limite de Gas reste inchangée, la taille du nœud augmentera chaque année de plusieurs centaines de Go.
Qu'est-ce que c'est, comment ça fonctionne?
Une caractéristique clé du stockage historique est que le consensus actuel suffit à établir un consensus sur l'histoire. Cela offre diverses options pour le stockage des enregistrements historiques, comme un réseau où chaque nœud ne stocke qu'une partie des données.
Ethereum a commencé à se défaire 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, et les Blobs ne sont stockés que pendant environ 18 jours. L'EIP-4444 vise à introduire une période de stockage d'un an pour les blocs historiques et les reçus. L'objectif à long terme est d'établir une période de stockage unifiée d'environ 18 jours, puis de créer un réseau P2P composé de nœuds Ethereum pour stocker les anciennes données de manière distribuée.
Les codes d'effacement peuvent être utilisés pour améliorer la robustesse tout en maintenant le même facteur de réplication. La solution la plus simple pourrait être de réutiliser les codes d'effacement existants du Blob et d'inclure également les données d'exécution et de consensus dans le blob.
Que faut-il encore faire, quels éléments doivent être pesés ?
Les principales tâches incluent la construction et l'intégration d'une solution distribuée spécifique pour stocker des historiques. La solution la plus simple consiste à introduire une bibliothèque torrent existante ou une solution native Ethereum connue sous le nom de réseau Portal.
Les principaux compromis concernent la manière de s'efforcer de fournir des données historiques "anciennes". La solution la plus simple consiste à cesser immédiatement de stocker des anciennes données historiques et à s'appuyer sur les nœuds d'archivage existants. Une solution plus sûre mais plus difficile consiste d'abord à construire et à intégrer un réseau torrent.
avec les autres parties de la feuille de route
Réduire les besoins de stockage historique est essentiel pour rendre l'exécution des nœuds extrêmement facile. Ce n'est qu'en réalisant l'absence d'état et l'EIP-4444 que la vision de faire fonctionner un nœud Ethereum sur une montre intelligente pourra être réalisée.
La limitation du stockage historique rend également plus viable la mise en œuvre de nouveaux nœuds Ethereum ne prenant en charge que la dernière version du protocole, simplifiant ainsi le client.
Expiration de l'état 状态到期
résout quel problème ?
Même si la demande de stockage des historiques est éliminée, la demande de stockage des clients continuera d'augmenter d'environ 50 Go chaque année, car les soldes des comptes d'état (, le code des contrats, etc. ) continueront de croître. Les utilisateurs peuvent payer une fois pour apporter un fardeau permanent aux clients actuels et futurs.
Qu'est-ce que c'est, comment ça fonctionne ?
L'état est plus difficile à "expirer" que l'historique, car l'EVM suppose que les objets d'état existent éternellement une fois créés. L'objectif est de permettre aux objets d'expirer automatiquement avec le temps, tout en maintenant l'efficacité, la convivialité pour les utilisateurs et la convivialité pour les développeurs.
Il existe principalement deux types de solutions :
État partiel expiré : diviser l'état en morceaux, ne stocker que les données récemment accessibles. L'EIP-7736 propose une solution basée sur les arbres Verkle, où les données non accessibles depuis 6 mois ne stockent qu'un petit extrait de 32 octets.
Expiration de l'état basée sur le cycle d'adresse : utilisation d'une liste d'arbres d'état en constante croissance, ajout d'un nouvel arbre vide chaque année. Les nœuds complets ne conservent que les deux derniers arbres. Les données périmées nécessitent une preuve pour être lues ou écrites.
que faut-il encore faire, quels compromis faut-il envisager?
Les chemins possibles pour l'avenir incluent :
Réaliser sans état, sans introduire d'expiration d'état. L'état continue de croître mais nécessite seulement le stockage d'utilisateurs spéciaux.
Mettre en œuvre une partie de l'expiration de l'état, en acceptant un taux de croissance permanent plus faible mais non nul.
Réaliser l'expiration de l'état par l'extension de l'espace d'adresses. Un processus de plusieurs années est nécessaire pour garantir que la conversion du format d'adresse est sécurisée et efficace.
Réaliser l'expiration de l'état par la contraction de l'espace d'adresses. Un processus de plusieurs années est nécessaire pour garantir la résolution de tous les risques de sécurité.
Quel que soit le plan adopté, il est nécessaire de résoudre le problème de l'expansion et de la contraction de l'espace d'adresses, car les attaques par conflit d'adresses deviendront plus faciles à l'avenir.
Nettoyage des fonctionnalités
résout quel problème ?
La simplicité des protocoles est la clé de la sécurité, de l'accessibilité et de la neutralité de confiance. Cependant, les protocoles ont tendance à devenir plus complexes avec le temps. Nous devons être en mesure de supprimer des fonctionnalités et de réduire la complexité.
Qu'est-ce que c'est, comment ça fonctionne ?
Il n'y a pas de solution majeure unique pour réduire la complexité du protocole, mais plutôt de nombreuses petites solutions. Quelques exemples clés incluent :
Exemples dans l'EVM :
que faut-il encore faire, quels compromis faut-il envisager ?
Le principal compromis est entre le degré de simplification et la vitesse d'exécution par rapport à la compatibilité descendante. Il est nécessaire de créer un processus standardisé pour effectuer des modifications non urgentes qui rompent la compatibilité descendante, y compris l'analyse des impacts, la dépréciation formelle des EIP, la suppression finale, etc.
Le format d'objet EVM ( EOF ) propose une série de modifications de l'EVM, visant à permettre plus de mises à niveau. Il est nécessaire de peser la complexité accrue par rapport à l'objectif de simplifier l'ensemble de l'EVM.
Une approche plus radicale consiste à transformer la majeure partie du contenu du protocole en code de contrat, comme transformer l'EVM en un résumé ou remplacer l'EVM par une nouvelle VM. Cela peut simplifier considérablement le protocole, mais nécessite un compromis sur la compatibilité.