L’un des problèmes d’Ethereum, ou de toute blockchain, est que sa taille augmente avec le temps. Cela signifie une augmentation de la complexité de son code et de ses besoins de stockage.
Une blockchain doit conserver toutes les données tout au long de son historique qui doivent être stockées par tous les clients et téléchargées par les nouveaux clients. Cela entraîne une augmentation constante de la charge client et du temps de synchronisation.
De plus, la complexité du code augmente avec le temps car il est « plus facile d’ajouter une nouvelle fonctionnalité que de supprimer une ancienne », a écrit Vitalik Buterin sur son blog.
Par conséquent, Buterin estime que les développeurs doivent travailler activement pour endiguer ces tendances croissantes tout en préservant la permanence d’Ethereum. Buterin a donc présenté The Purge, un plan en trois parties visant à simplifier la blockchain et à réduire sa charge de données.
Partie 1 : Expiration de l’historique
Un nœud Ethereum entièrement synchronisé nécessite actuellement environ 1,1 To d’espace de stockage pour le client d’exécution. Cela nécessite quelques centaines de gigaoctets supplémentaires pour le client de consensus. Selon Buterin, la plupart de ces données sont historiques, telles que les données sur les blocs historiques, les transactions et les reçus, dont beaucoup datent de plusieurs années. Pour stocker tout cet historique, l’espace disque requis ne cesse d’augmenter de centaines de gigaoctets chaque année.
Buterin pense que le problème peut être résolu par quelque chose appelé expiration de l’historique.
Chaque bloc d’une blockchain pointe vers le précédent via un lien de hachage. Cela signifie qu’un consensus sur le bloc actuel indique un consensus sur l’histoire.
Selon Buterin, tant que le réseau dispose d’un consensus sur le bloc actuel, toutes les données historiques associées peuvent être fournies par un seul acteur via une preuve Merkle, qui permet à quiconque de vérifier son intégrité. Cela signifie qu’au lieu que chaque nœud stocke toutes les données, chaque nœud pourrait stocker un petit pourcentage des données, réduisant ainsi les besoins de stockage.
Buterin suggère essentiellement d’adopter le modèle opérationnel des réseaux torrent, où chaque participant stocke et distribue seulement une petite partie des données stockées et distribuées par le réseau.
Ethereum a déjà pris des mesures pour réduire les besoins de stockage : certaines informations ont désormais une date d’expiration. Par exemple, les blocs de consensus sont stockés pendant six mois et les blobs pendant 18 jours.
EIP-4444 est une autre étape dans cette direction : il vise à limiter la période de stockage des blocs et des reçus historiques à un an. L’objectif à long terme, cependant, est d’avoir une période fixe, par exemple 18 jours, pendant laquelle chaque nœud doit tout stocker, puis les anciennes données sont stockées de manière distribuée sur un réseau peer-to-peer.
Partie 2 : Expiration de l’État
Selon Buterin, supprimer la nécessité pour les clients de stocker l’intégralité de l’historique ne résout pas complètement le problème des exigences de stockage excessives. En effet, un client doit augmenter sa capacité de stockage d’environ 50 Go chaque année en raison de la « croissance continue de l’État : soldes des comptes et nonces, code du contrat et stockage du contrat ».
Un nouvel objet d’état peut être créé de trois manières : en créant un nouveau compte, en envoyant ETH vers un nouveau compte et en définissant un emplacement de stockage précédemment inactif. Une fois qu’un objet d’état est créé, il reste dans cet état pour toujours.
Buterin estime que la solution permettant d’expirer automatiquement les objets d’état au fil du temps doit être efficace, conviviale et conviviale pour les développeurs. Cela signifie que la solution ne devrait pas nécessiter de grandes quantités de calculs, que les utilisateurs ne devraient pas perdre l’accès à leurs jetons s’ils les laissent intacts pendant des années, et que les développeurs ne seront pas trop gênés dans le processus.
Buterin suggère deux types de « solutions connues les moins mauvaises » :
- Solutions d’expiration d’état partielle
- Propositions d’expiration d’état basées sur la période d’adresse.
Expiration partielle de l’état
Les propositions d’expiration partielle de l’État fonctionnent sur la base du principe de division de l’État en « morceaux ». Cela nécessiterait que tout le monde stocke la « carte de niveau supérieur » dont les morceaux sont vides ou non vides pour toujours. Les données contenues dans les morceaux ne sont stockées que si elles ont été récemment consultées. Le mécanisme de « résurrection » permet à quiconque de rapporter les données en bloc si elles ne sont pas stockées en fournissant la preuve de leur nature.
Expiration de l’état basée sur la période d’adresse
L’expiration de l’état basée sur la période d’adresse propose d’avoir une liste croissante d’arborescences d’état au lieu d’une seule stockant l’intégralité de l’état. Tout état lu ou écrit est mis à jour dans l’arborescence d’état la plus récente. Une nouvelle arborescence d’état vide est ajoutée une fois par période, qui peut durer un an.
Dans ce scénario, les anciennes arborescences d’état sont gelées et les nœuds complets doivent stocker uniquement les deux dernières arborescences. Si un objet d’état fait partie d’une arborescence expirée, il peut être lu ou écrit, mais la transaction nécessiterait une preuve Merkle pour cela. Après la transaction, il sera rajouté à la dernière arborescence.
Nettoyage des fonctionnalités
Au fil du temps, tous les protocoles deviennent complexes, aussi simples soient-ils au départ.
Buterin a écrit :
« Si nous ne voulons pas qu’Ethereum entre dans un trou noir d’une complexité toujours croissante, nous devons faire l’une des deux choses suivantes : (i) arrêter d’apporter des changements et ossifier le protocole(ii) être capable de réellement retirer fonctionnalités et réduire complexité.»
Selon Buterin, nettoyer la complexité d’Ethereum nécessite plusieurs petites corrections, comme la suppression de l’opcode SELFDESTRUCT, la suppression des anciens types de transactions et des comités de chaîne de balises, la réforme de LOG, etc. Buterin a également suggéré de simplifier la mécanique des gaz, de supprimer l’observabilité des gaz et d’améliorer l’analyse statique.
Mentionné dans cet article
