L'un des défis auxquels Ethereum est confronté est que, par défaut, l'expansion et la complexité de tout protocole de blockchain augmentent avec le temps. Cela se produit de deux manières:
Données historiques : Toute transaction effectuée à tout moment dans le passé et tout compte créé doit être stocké de manière permanente par tous les clients et téléchargé par tout nouveau client, afin d'être entièrement synchronisé avec le réseau. Cela entraîne une augmentation continue de la charge des clients et du temps de synchronisation au fil du temps, même si la capacité de la chaîne reste inchangée.
Fonctionnalité du protocole : ajouter de nouvelles fonctionnalités est beaucoup plus facile que de supprimer d'anciennes fonctionnalités, ce qui entraîne une complexité croissante du code au fil du temps.
Pour que l'Ethereum puisse se maintenir à long terme, nous devons exercer une forte contre-pression sur ces deux tendances, réduisant la complexité et l'expansion avec le temps. Mais en même temps, nous devons préserver l'une des propriétés clés qui rendent la blockchain formidable : la durabilité. Vous pouvez mettre un NFT, une lettre d'amour dans les données d'appel d'une transaction, ou un contrat intelligent contenant 1 million de dollars sur la chaîne, entrer dans une grotte pendant dix ans, et en ressortir en découvrant qu'il est toujours là, attendant que vous le lisiez et interagissiez. Pour que les DApps puissent être entièrement décentralisés et supprimer les clés de mise à jour en toute confiance, ils doivent être sûrs que leurs dépendances ne seront pas mises à jour de manière à les compromettre - en particulier L1 lui-même.
Si nous nous engageons à trouver un équilibre entre ces deux besoins, tout en minimisant ou inversant l'encombrement, la complexité et le déclin tout en maintenant la continuité, cela est tout à fait possible. Les organismes vivants peuvent le faire : bien que la plupart des organismes vieillissent avec le temps, quelques heureux élus ne le font pas. Même les systèmes sociaux peuvent avoir une durée de vie très longue. Dans certains cas, Ethereum a déjà réussi : la preuve de travail a disparu, le code d'opération SELFDESTRUCT a en grande partie disparu, et les nœuds de la chaîne de balise ont stocké des données anciennes pendant jusqu'à six mois. Trouver cette voie pour Ethereum de manière plus générale et se diriger vers un résultat final stable à long terme est le défi ultime pour la scalabilité à long terme d'Ethereum, la durabilité technique et même la sécurité.
The Purge: objectif principal.
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.
Réduire la complexité du protocole en éliminant les fonctionnalités inutiles.
Table des matières :
Histoire d'expiration
État d'expiration（状态到期）
Nettoyage des caractéristiques
Historique d'expiration
Quel problème résout-il ?
Au moment de la rédaction de cet article, un nœud Ethereum complètement synchronisé nécessite environ 1,1 To d'espace disque pour exécuter le client, et nécessite également plusieurs centaines de Go d'espace disque pour le client de consensus. La majeure partie de cela est historique : des données sur les blocs historiques, les transactions et les reçus, dont la plupart ont plusieurs années. Cela signifie que même si la limite de Gas n'augmente pas du tout, la taille des nœuds continuera d'augmenter de plusieurs centaines de Go chaque année.
Qu'est-ce que c'est et comment ça fonctionne ?
Une caractéristique clé de la simplification des problèmes de stockage historique est que, puisque chaque bloc fait référence au bloc précédent par des liens de hachage (et d'autres structures), il suffit d'atteindre un consensus sur l'état actuel pour parvenir à un consensus sur l'historique. Tant que le réseau parvient à un consensus sur le dernier bloc, tout bloc historique, toute transaction ou tout état (solde de compte, nombre aléatoire, code, stockage) peut être fourni par n'importe quel participant individuel ainsi que par une preuve Merkle, et cette preuve permet à quiconque d'en vérifier l'exactitude. Le consensus est un modèle de confiance N/2-of-N, tandis que l'historique est un modèle de confiance N-of-N.
Cela nous offre de nombreuses options sur la façon de stocker l'historique. Un choix naturel est un réseau où chaque nœud ne stocke qu'une petite partie des données. C'est ainsi que fonctionnent les réseaux de semences depuis des décennies : bien que le réseau stocke et distribue des millions de fichiers au total, chaque participant ne stocke et ne distribue que quelques-uns de ces fichiers. Peut-être contre-intuitivement, cette méthode ne réduit même pas nécessairement la robustesse des données. Si nous pouvons rendre le fonctionnement des nœuds plus économique, nous pourrions établir un réseau de 100 000 nœuds, où chaque nœud stocke aléatoirement 10 % de l'historique, alors chaque donnée sera copiée 10 000 fois - identique au facteur de copie d'un réseau de 10 000 nœuds, où chaque nœud stocke tout.
Aujourd'hui, Ethereum a commencé à se débarrasser du modèle où tous les nœuds stockent de manière permanente toute l'historique. Les blocs de consensus (c'est-à-dire la partie liée au consensus par preuve d'enjeu) ne conservent que pendant environ 6 mois. 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 unifiée (probablement d'environ 18 jours) pendant laquelle chaque nœud est responsable du stockage de tout, puis de créer un réseau pair-à-pair composé de nœuds Ethereum, qui stockera 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. En fait, le Blob a déjà été soumis à des codes d'effacement pour soutenir l'échantillonnage de la disponibilité des données. La solution la plus simple consiste probablement à réutiliser ces codes d'effacement et à placer également les données d'exécution et de consensus des blocs dans le blob.
Quels liens y a-t-il avec les recherches existantes ?
EIP-4444；
Torrents et EIP-4444；
réseau de portails ;
Portail réseau et EIP-4444 ;
Stockage et récupération distribués des objets SSZ dans le Portail ;
Comment augmenter la limite de gas (Paradigm).
Que faut-il encore faire et quels aspects faut-il évaluer ?
Les principales tâches restantes consistent à construire et à intégrer une solution distribuée concrète pour stocker les historiques ------ au moins les historiques d'exécution, mais finalement aussi le consensus et les blobs. La solution la plus simple est d'introduire simplement des bibliothèques torrent existantes et une solution native Ethereum appelée réseau Portal. Une fois l'un ou l'autre introduit, nous pouvons activer l'EIP-4444. L'EIP-4444 lui-même ne nécessite pas de fork dur, mais il nécessite une nouvelle version du protocole réseau. Par conséquent, il est utile de l'activer pour tous les clients en même temps, sinon il existe un risque que des clients échouent en se connectant à d'autres nœuds qui s'attendent à télécharger l'historique complet mais ne l'obtiennent en réalité pas.
Les principaux compromis concernent nos efforts pour fournir des données historiques "anciennes". La solution la plus simple consiste à arrêter demain de stocker l'histoire ancienne et à compter sur les nœuds d'archivage existants et divers fournisseurs centralisés pour la réplication. C'est facile, mais cela affaiblit la position d'Ethereum en tant que lieu d'enregistrement permanent. Une approche plus difficile mais plus sûre consiste d'abord à construire et à intégrer un réseau torrent pour stocker l'historique de manière distribuée. Ici, "combien nous nous efforçons" a deux dimensions :
Comment nous efforçons-nous de garantir que le plus grand ensemble de nœuds stocke effectivement toutes les données ?
Quelle est la profondeur de l'intégration de l'historique de stockage dans le protocole ?
Une méthode extrême et paranoïaque pour (1) impliquerait la preuve de garde : exigeant en fait que chaque validateur de preuve d'enjeu stocke un certain pourcentage d'historique et vérifie régulièrement de manière cryptographique s'il le fait. Une approche plus douce serait de définir une norme volontaire pour le pourcentage d'historique stocké par chaque client.
Pour (2), la mise en œuvre de base ne concerne que le travail déjà accompli aujourd'hui : le portail a déjà stocké des fichiers ERA contenant l'intégralité de l'historique d'Ethereum. Une mise en œuvre plus complète impliquerait de le connecter réellement au processus de synchronisation, de sorte que si quelqu'un souhaite synchroniser un nœud de stockage d'historique complet ou un nœud d'archivage, même s'il n'y a pas d'autres nœuds d'archivage en ligne, il pourrait le faire par une synchronisation directe via le réseau du portail.
(# Comment interagit-il avec les autres parties de la feuille de route ?
Si nous voulons rendre l'exécution ou le démarrage des nœuds extrêmement facile, alors réduire les besoins de stockage historique est sans doute plus important que la non-état : sur les 1,1 To nécessaires au nœud, environ 300 Go sont l'état, le reste d'environ 800 Go étant devenu historique. Ce n'est qu'en réalisant la non-état et l'EIP-4444 que la vision de faire fonctionner un nœud Ethereum sur une montre intelligente et de le configurer en quelques minutes pourra être réalisée.
La limitation du stockage historique rend également la mise en œuvre des nœuds Ethereum plus viable, ne prenant en charge que la dernière version du protocole, ce qui les rend plus simples. Par exemple, il est maintenant possible de supprimer en toute sécurité de nombreuses lignes de code, car tous les emplacements de stockage vides créés lors de l'attaque DoS de 2016 ont été supprimés. Étant donné que la transition vers la preuve d'enjeu est devenue une réalité, les clients peuvent supprimer en toute sécurité tout le code lié à la preuve de travail.
![Vitalik : l'avenir potentiel d'Ethereum, The Purge])https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp(
) État d'expiration
Quel problème résout-il ?
Même si nous éliminons le besoin de stockage des historiques sur le client, les besoins de stockage du client continueront de croître, d'environ 50 Go par an, car l'état continue de croître : les soldes des comptes et les nombres aléatoires, le code des contrats et le stockage des contrats. Les utilisateurs peuvent payer des frais uniques, ce qui imposera un fardeau aux clients Ethereum d'aujourd'hui et de demain.
L'état est plus difficile à "expirer" que l'historique, car l'EVM est fondamentalement conçu autour de cette hypothèse : une fois qu'un objet d'état est créé, il existe toujours et peut être lu à tout moment par n'importe quelle transaction. Si nous introduisons la sans-état, certains pensent que ce problème n'est peut-être pas si grave : seuls des types de constructeurs de blocs spécialisés ont besoin de stocker réellement l'état, tandis que tous les autres nœuds (y compris ceux qui génèrent des listes !) peuvent fonctionner sans état. Cependant, il y a un point de vue selon lequel nous ne voulons pas trop dépendre de la sans-état, et finalement, nous pourrions vouloir rendre l'état obsolète pour préserver la décentralisation d'Ethereum.
(# Qu'est-ce que c'est, comment ça fonctionne
Aujourd'hui, lorsque vous créez un nouvel objet d'état (ce qui peut se produire de l'une des trois manières suivantes : (i) envoyer de l'ETH à un nouveau compte, (ii) créer un nouveau compte avec du code, (iii) définir un emplacement de stockage qui n'a pas été touché auparavant), cet objet d'état reste dans cet état pour toujours. En revanche, ce que nous voulons, c'est que l'objet expire automatiquement au fil du temps. Le défi clé est de le faire d'une manière qui réalise trois objectifs :
Efficacité : pas besoin de calculs supplémentaires importants pour exécuter le processus d'échéance.
Facilité d'utilisation : Si quelqu'un entre dans une grotte pendant cinq ans et revient, il ne devrait pas perdre l'accès à l'ETH, aux ERC20, aux NFT, et aux positions CDP...
Facilité d'utilisation pour les développeurs : les développeurs n'ont pas besoin de passer à un modèle de pensée totalement inconnu. De plus, les applications qui sont actuellement rigides et non mises à jour devraient continuer à fonctionner normalement.
Il est facile de résoudre des problèmes si ces objectifs ne sont pas atteints. Par exemple, vous pouvez faire en sorte que chaque objet d'état stocke également un compteur de date d'expiration (qui peut être prolongé en brûlant de l'ETH, ce qui peut se produire automatiquement à tout moment lors de la lecture ou de l'écriture), et avoir un processus pour parcourir l'état afin de supprimer les objets d'état dont la date d'expiration est dépassée. Cependant, cela introduit des calculs supplémentaires (voire des besoins de stockage) et cela ne peut certainement pas répondre aux exigences de convivialité. Les développeurs ont également du mal à raisonner sur les cas limites où les valeurs de stockage sont parfois réinitialisées à zéro. Si vous définissez un minuteur d'expiration dans le contrat, cela rendra techniquement la vie des développeurs plus facile, mais cela rendra l'économie plus difficile : les développeurs doivent réfléchir à la façon de "transférer" le coût de stockage continu aux utilisateurs.
Ces problèmes sont ceux sur lesquels la communauté des développeurs principaux d'Ethereum travaille depuis des années, y compris des propositions telles que "le loyer de la blockchain" et "la régénération". En fin de compte, nous avons combiné les meilleures parties des propositions et nous nous sommes concentrés sur deux catégories de "solutions reconnues comme les moins mauvaises" :
Solution pour l'expiration de certains états
Suggestions d'expiration d'état basées sur le cycle d'adresse.
![Vitalik : l'avenir potentiel d'Ethereum, The Purge])https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp###
Expiration partielle de l'état
Certaines propositions d'état expirer suivent les mêmes principes. Nous divisons l'état en blocs. Chacun stocke de manière permanente la "carte supérieure", où les blocs sont vides ou non. Les données dans chaque bloc ne sont stockées que si elles ont été récemment consultées. Il existe un mécanisme de "résurrection" qui s'active si elles ne sont plus stockées.
La principale différence entre ces propositions est : (i) comment nous définissons "récemment" et (ii) comment nous
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
13 J'aime
Récompense
13
6
Reposter
Partager
Commentaire
0/400
PanicSeller
· 08-13 15:50
Pas possible, l'eth doit aussi subir un grand nettoyage ?
Voir l'originalRépondre0
0xTherapist
· 08-11 20:08
Le redémarrage aurait dû arriver plus tôt, il est temps de maigrir.
Voir l'originalRépondre0
NoodlesOrTokens
· 08-10 22:26
off-chain塞的太满啦 赶紧清理
Voir l'originalRépondre0
PumpDetector
· 08-10 22:18
smart money a observé cette purge... exactement ce que nous avions averti en 2017 à vrai dire
Voir l'originalRépondre0
LiquidatorFlash
· 08-10 22:12
données historiques off-chain +3.47T, risque à fond, faites du Hedging avant que ce ne soit à zéro
Ethereum Le plan Purge : expiration historique et simplification de l'état contre l'expansion de la complexité
L'avenir possible d'Ethereum : The Purge
L'un des défis auxquels Ethereum est confronté est que, par défaut, l'expansion et la complexité de tout protocole de blockchain augmentent avec le temps. Cela se produit de deux manières:
Données historiques : Toute transaction effectuée à tout moment dans le passé et tout compte créé doit être stocké de manière permanente par tous les clients et téléchargé par tout nouveau client, afin d'être entièrement synchronisé avec le réseau. Cela entraîne une augmentation continue de la charge des clients et du temps de synchronisation au fil du temps, même si la capacité de la chaîne reste inchangée.
Fonctionnalité du protocole : ajouter de nouvelles fonctionnalités est beaucoup plus facile que de supprimer d'anciennes fonctionnalités, ce qui entraîne une complexité croissante du code au fil du temps.
Pour que l'Ethereum puisse se maintenir à long terme, nous devons exercer une forte contre-pression sur ces deux tendances, réduisant la complexité et l'expansion avec le temps. Mais en même temps, nous devons préserver l'une des propriétés clés qui rendent la blockchain formidable : la durabilité. Vous pouvez mettre un NFT, une lettre d'amour dans les données d'appel d'une transaction, ou un contrat intelligent contenant 1 million de dollars sur la chaîne, entrer dans une grotte pendant dix ans, et en ressortir en découvrant qu'il est toujours là, attendant que vous le lisiez et interagissiez. Pour que les DApps puissent être entièrement décentralisés et supprimer les clés de mise à jour en toute confiance, ils doivent être sûrs que leurs dépendances ne seront pas mises à jour de manière à les compromettre - en particulier L1 lui-même.
Si nous nous engageons à trouver un équilibre entre ces deux besoins, tout en minimisant ou inversant l'encombrement, la complexité et le déclin tout en maintenant la continuité, cela est tout à fait possible. Les organismes vivants peuvent le faire : bien que la plupart des organismes vieillissent avec le temps, quelques heureux élus ne le font pas. Même les systèmes sociaux peuvent avoir une durée de vie très longue. Dans certains cas, Ethereum a déjà réussi : la preuve de travail a disparu, le code d'opération SELFDESTRUCT a en grande partie disparu, et les nœuds de la chaîne de balise ont stocké des données anciennes pendant jusqu'à six mois. Trouver cette voie pour Ethereum de manière plus générale et se diriger vers un résultat final stable à long terme est le défi ultime pour la scalabilité à long terme d'Ethereum, la durabilité technique et même la sécurité.
The Purge: objectif principal.
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.
Réduire la complexité du protocole en éliminant les fonctionnalités inutiles.
Table des matières :
Histoire d'expiration
État d'expiration（状态到期）
Nettoyage des caractéristiques
Historique d'expiration
Quel problème résout-il ?
Au moment de la rédaction de cet article, un nœud Ethereum complètement synchronisé nécessite environ 1,1 To d'espace disque pour exécuter le client, et nécessite également plusieurs centaines de Go d'espace disque pour le client de consensus. La majeure partie de cela est historique : des données sur les blocs historiques, les transactions et les reçus, dont la plupart ont plusieurs années. Cela signifie que même si la limite de Gas n'augmente pas du tout, la taille des nœuds continuera d'augmenter de plusieurs centaines de Go chaque année.
Qu'est-ce que c'est et comment ça fonctionne ?
Une caractéristique clé de la simplification des problèmes de stockage historique est que, puisque chaque bloc fait référence au bloc précédent par des liens de hachage (et d'autres structures), il suffit d'atteindre un consensus sur l'état actuel pour parvenir à un consensus sur l'historique. Tant que le réseau parvient à un consensus sur le dernier bloc, tout bloc historique, toute transaction ou tout état (solde de compte, nombre aléatoire, code, stockage) peut être fourni par n'importe quel participant individuel ainsi que par une preuve Merkle, et cette preuve permet à quiconque d'en vérifier l'exactitude. Le consensus est un modèle de confiance N/2-of-N, tandis que l'historique est un modèle de confiance N-of-N.
Cela nous offre de nombreuses options sur la façon de stocker l'historique. Un choix naturel est un réseau où chaque nœud ne stocke qu'une petite partie des données. C'est ainsi que fonctionnent les réseaux de semences depuis des décennies : bien que le réseau stocke et distribue des millions de fichiers au total, chaque participant ne stocke et ne distribue que quelques-uns de ces fichiers. Peut-être contre-intuitivement, cette méthode ne réduit même pas nécessairement la robustesse des données. Si nous pouvons rendre le fonctionnement des nœuds plus économique, nous pourrions établir un réseau de 100 000 nœuds, où chaque nœud stocke aléatoirement 10 % de l'historique, alors chaque donnée sera copiée 10 000 fois - identique au facteur de copie d'un réseau de 10 000 nœuds, où chaque nœud stocke tout.
Aujourd'hui, Ethereum a commencé à se débarrasser du modèle où tous les nœuds stockent de manière permanente toute l'historique. Les blocs de consensus (c'est-à-dire la partie liée au consensus par preuve d'enjeu) ne conservent que pendant environ 6 mois. 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 unifiée (probablement d'environ 18 jours) pendant laquelle chaque nœud est responsable du stockage de tout, puis de créer un réseau pair-à-pair composé de nœuds Ethereum, qui stockera 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. En fait, le Blob a déjà été soumis à des codes d'effacement pour soutenir l'échantillonnage de la disponibilité des données. La solution la plus simple consiste probablement à réutiliser ces codes d'effacement et à placer également les données d'exécution et de consensus des blocs dans le blob.
Quels liens y a-t-il avec les recherches existantes ?
EIP-4444；
Torrents et EIP-4444；
réseau de portails ;
Portail réseau et EIP-4444 ;
Stockage et récupération distribués des objets SSZ dans le Portail ;
Comment augmenter la limite de gas (Paradigm).
Que faut-il encore faire et quels aspects faut-il évaluer ?
Les principales tâches restantes consistent à construire et à intégrer une solution distribuée concrète pour stocker les historiques ------ au moins les historiques d'exécution, mais finalement aussi le consensus et les blobs. La solution la plus simple est d'introduire simplement des bibliothèques torrent existantes et une solution native Ethereum appelée réseau Portal. Une fois l'un ou l'autre introduit, nous pouvons activer l'EIP-4444. L'EIP-4444 lui-même ne nécessite pas de fork dur, mais il nécessite une nouvelle version du protocole réseau. Par conséquent, il est utile de l'activer pour tous les clients en même temps, sinon il existe un risque que des clients échouent en se connectant à d'autres nœuds qui s'attendent à télécharger l'historique complet mais ne l'obtiennent en réalité pas.
Les principaux compromis concernent nos efforts pour fournir des données historiques "anciennes". La solution la plus simple consiste à arrêter demain de stocker l'histoire ancienne et à compter sur les nœuds d'archivage existants et divers fournisseurs centralisés pour la réplication. C'est facile, mais cela affaiblit la position d'Ethereum en tant que lieu d'enregistrement permanent. Une approche plus difficile mais plus sûre consiste d'abord à construire et à intégrer un réseau torrent pour stocker l'historique de manière distribuée. Ici, "combien nous nous efforçons" a deux dimensions :
Comment nous efforçons-nous de garantir que le plus grand ensemble de nœuds stocke effectivement toutes les données ?
Quelle est la profondeur de l'intégration de l'historique de stockage dans le protocole ?
Une méthode extrême et paranoïaque pour (1) impliquerait la preuve de garde : exigeant en fait que chaque validateur de preuve d'enjeu stocke un certain pourcentage d'historique et vérifie régulièrement de manière cryptographique s'il le fait. Une approche plus douce serait de définir une norme volontaire pour le pourcentage d'historique stocké par chaque client.
Pour (2), la mise en œuvre de base ne concerne que le travail déjà accompli aujourd'hui : le portail a déjà stocké des fichiers ERA contenant l'intégralité de l'historique d'Ethereum. Une mise en œuvre plus complète impliquerait de le connecter réellement au processus de synchronisation, de sorte que si quelqu'un souhaite synchroniser un nœud de stockage d'historique complet ou un nœud d'archivage, même s'il n'y a pas d'autres nœuds d'archivage en ligne, il pourrait le faire par une synchronisation directe via le réseau du portail.
(# Comment interagit-il avec les autres parties de la feuille de route ?
Si nous voulons rendre l'exécution ou le démarrage des nœuds extrêmement facile, alors réduire les besoins de stockage historique est sans doute plus important que la non-état : sur les 1,1 To nécessaires au nœud, environ 300 Go sont l'état, le reste d'environ 800 Go étant devenu historique. Ce n'est qu'en réalisant la non-état et l'EIP-4444 que la vision de faire fonctionner un nœud Ethereum sur une montre intelligente et de le configurer en quelques minutes pourra être réalisée.
La limitation du stockage historique rend également la mise en œuvre des nœuds Ethereum plus viable, ne prenant en charge que la dernière version du protocole, ce qui les rend plus simples. Par exemple, il est maintenant possible de supprimer en toute sécurité de nombreuses lignes de code, car tous les emplacements de stockage vides créés lors de l'attaque DoS de 2016 ont été supprimés. Étant donné que la transition vers la preuve d'enjeu est devenue une réalité, les clients peuvent supprimer en toute sécurité tout le code lié à la preuve de travail.
![Vitalik : l'avenir potentiel d'Ethereum, The Purge])https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp(
) État d'expiration
Quel problème résout-il ?
Même si nous éliminons le besoin de stockage des historiques sur le client, les besoins de stockage du client continueront de croître, d'environ 50 Go par an, car l'état continue de croître : les soldes des comptes et les nombres aléatoires, le code des contrats et le stockage des contrats. Les utilisateurs peuvent payer des frais uniques, ce qui imposera un fardeau aux clients Ethereum d'aujourd'hui et de demain.
L'état est plus difficile à "expirer" que l'historique, car l'EVM est fondamentalement conçu autour de cette hypothèse : une fois qu'un objet d'état est créé, il existe toujours et peut être lu à tout moment par n'importe quelle transaction. Si nous introduisons la sans-état, certains pensent que ce problème n'est peut-être pas si grave : seuls des types de constructeurs de blocs spécialisés ont besoin de stocker réellement l'état, tandis que tous les autres nœuds (y compris ceux qui génèrent des listes !) peuvent fonctionner sans état. Cependant, il y a un point de vue selon lequel nous ne voulons pas trop dépendre de la sans-état, et finalement, nous pourrions vouloir rendre l'état obsolète pour préserver la décentralisation d'Ethereum.
(# Qu'est-ce que c'est, comment ça fonctionne
Aujourd'hui, lorsque vous créez un nouvel objet d'état (ce qui peut se produire de l'une des trois manières suivantes : (i) envoyer de l'ETH à un nouveau compte, (ii) créer un nouveau compte avec du code, (iii) définir un emplacement de stockage qui n'a pas été touché auparavant), cet objet d'état reste dans cet état pour toujours. En revanche, ce que nous voulons, c'est que l'objet expire automatiquement au fil du temps. Le défi clé est de le faire d'une manière qui réalise trois objectifs :
Efficacité : pas besoin de calculs supplémentaires importants pour exécuter le processus d'échéance.
Facilité d'utilisation : Si quelqu'un entre dans une grotte pendant cinq ans et revient, il ne devrait pas perdre l'accès à l'ETH, aux ERC20, aux NFT, et aux positions CDP...
Facilité d'utilisation pour les développeurs : les développeurs n'ont pas besoin de passer à un modèle de pensée totalement inconnu. De plus, les applications qui sont actuellement rigides et non mises à jour devraient continuer à fonctionner normalement.
Il est facile de résoudre des problèmes si ces objectifs ne sont pas atteints. Par exemple, vous pouvez faire en sorte que chaque objet d'état stocke également un compteur de date d'expiration (qui peut être prolongé en brûlant de l'ETH, ce qui peut se produire automatiquement à tout moment lors de la lecture ou de l'écriture), et avoir un processus pour parcourir l'état afin de supprimer les objets d'état dont la date d'expiration est dépassée. Cependant, cela introduit des calculs supplémentaires (voire des besoins de stockage) et cela ne peut certainement pas répondre aux exigences de convivialité. Les développeurs ont également du mal à raisonner sur les cas limites où les valeurs de stockage sont parfois réinitialisées à zéro. Si vous définissez un minuteur d'expiration dans le contrat, cela rendra techniquement la vie des développeurs plus facile, mais cela rendra l'économie plus difficile : les développeurs doivent réfléchir à la façon de "transférer" le coût de stockage continu aux utilisateurs.
Ces problèmes sont ceux sur lesquels la communauté des développeurs principaux d'Ethereum travaille depuis des années, y compris des propositions telles que "le loyer de la blockchain" et "la régénération". En fin de compte, nous avons combiné les meilleures parties des propositions et nous nous sommes concentrés sur deux catégories de "solutions reconnues comme les moins mauvaises" :
![Vitalik : l'avenir potentiel d'Ethereum, The Purge])https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp###
Expiration partielle de l'état
Certaines propositions d'état expirer suivent les mêmes principes. Nous divisons l'état en blocs. Chacun stocke de manière permanente la "carte supérieure", où les blocs sont vides ou non. Les données dans chaque bloc ne sont stockées que si elles ont été récemment consultées. Il existe un mécanisme de "résurrection" qui s'active si elles ne sont plus stockées.
La principale différence entre ces propositions est : (i) comment nous définissons "récemment" et (ii) comment nous