Vitalik explore dans son article l'avenir du protocole Ethereum The Purge, y compris les besoins de stockage de Goutte et la complexité du protocole Ethereum.

Odaily星球日报讯 Vitalik publie le développement futur de l’ethereum protocole (partie 5 : The Purge), les objectifs clés sont les suivants : En réduisant ou en éliminant le besoin pour chaque Nœud de stocker de manière permanente tout l’historique, voire l’état, le client Goutte répond aux exigences de stockage ; Simplifiez la complexité du protocole en éliminant les fonctionnalités inutiles. Le texte mentionne que Ethereum a commencé à se débarrasser du mode de stockage permanent de tous les enregistrements historiques par chaque nœud. La partie liée au consensus d’attestation ne stocke que environ 6 mois de blocs. Le Blob ne stocke que environ 18 jours. L’EIP-4444 vise à introduire une période de stockage d’un an pour les blocs et les reçus historiques. L’objectif à long terme est d’avoir une période de coordination (peut-être environ 18 jours) au cours de laquelle chaque nœud est responsable de stocker tout le contenu, puis les données anciennes sont stockées de manière distribuée par le réseau pair à pair composé de nœuds Ethereum. En plus de la demande de stockage de l’historique par le client, la demande de stockage par le client continuera à augmenter, d’environ 50 Go par an, en raison de l’augmentation constante de l’état : solde du compte et nombres aléatoires, code de contrat et stockage de contrat. Les utilisateurs peuvent payer des frais ponctuels, ce qui alourdit définitivement le client Ethereum actuel et futur. Dans la complexité Goutteprotocole, deux choses doivent être faites： Arrêtez de modifier et de rendre le protocole figé ; Capable de supprimer réellement les fonctionnalités et de réduire la complexité. En outre, Vitalik a mentionné que l’approche la plus radicale pour réduire la complexité consiste à conserver le protocole tel quel, mais à déplacer la majeure partie de ses fonctionnalités vers le code du contrat ; l’approche la plus douce consiste à maintenir la relation entre la chaîne de balises et l’environnement d’exécution actuel d’ETH, en choisissant RISC-V, Cairo ou une autre machine virtuelle comme nouvelle machine virtuelle officielle d’ETH, puis à convertir tous les contrats EVM en code de nouvelle machine virtuelle qui interprète la logique du code source d’origine (par le biais de la compilation ou de l’interprétation). Théoriquement, on pourrait même accomplir cette opération en utilisant la version EOF de la machine virtuelle cible.