Un défi auquel Ethereum fait face 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 : Toutes les transactions effectuées et tous les comptes créés à tout moment dans le passé doivent être stockés de manière permanente par tous les clients et téléchargés par tout nouveau client pour se synchroniser complètement avec le réseau. Cela entraîne une augmentation constante de la charge des clients et du temps de synchronisation, 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 de anciennes fonctionnalités, ce qui entraîne une complexité du code qui augmente avec le temps.
Pour que l'Ethereum puisse maintenir sa durabilité à long terme, nous devons exercer une forte contre-pression sur ces deux tendances, réduisant la complexité et l'expansion au fil du temps. 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 placer des NFT, des lettres d'amour dans des enregistrements de transactions, ou des contrats intelligents contenant 1 million de dollars sur la chaîne, et 10 ans plus tard, ils seront toujours là, attendant que vous les lisiez et interagissiez. Pour que les DApp puissent être complètement décentralisées en toute confiance et supprimer les clés de mise à niveau, elles doivent être convaincues que leurs dépendances ne seront pas mises à niveau de manière à les détruire - en particulier L1 lui-même.
Si nous nous engageons à trouver un équilibre entre ces deux besoins, tout en minimisant ou en inversant le fardeau, la complexité et le déclin tout en maintenant la continuité, c'est tout à fait possible. Les organismes peuvent le faire : bien que la plupart des organismes vieillissent avec le temps, quelques chanceux 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, l'opcode SELFDESTRUCT a pour la plupart disparu, et les nœuds de la chaîne de balise ont stocké des données anciennes pendant jusqu'à six mois. Trouver ce chemin pour Ethereum de manière plus générale et avancer vers un résultat final stable à long terme représente le défi ultime pour l'évolutivité à long terme d'Ethereum, la durabilité technique et même la sécurité.
L'objectif principal de The Purge :
Réduire les exigences de stockage du client en diminuant ou en éliminant la nécessité pour chaque nœud de conserver de manière permanente tous les historiques, voire l'état final.
Réduire la complexité du protocole en éliminant les fonctionnalités inutiles
Expiration de l'historique
résout quel problème ?
À la date de rédaction de cet article, un nœud Ethereum entièrement synchronisé nécessite environ 1,1 To d'espace disque pour exécuter le client, et il faut également plusieurs centaines de Go d'espace disque pour le client de consensus. La grande majorité de cela est historique : des données concernant 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 du nœud continuera d'augmenter de plusieurs centaines de Go chaque année.
Qu'est-ce que c'est, comment ça fonctionne ?
Une caractéristique clé de la simplification des problèmes de stockage historique est que, parce que chaque bloc est lié par hachage à ( et à d'autres structures ) pointant vers le bloc précédent, il suffit d'atteindre un consensus sur l'état actuel pour atteindre un consensus sur l'histoire. Tant que le réseau parvient à un consensus sur le dernier bloc, tout bloc historique, transaction ou état (, solde de compte, nombre aléatoire, code, stockage ) peut être fourni par n'importe quel participant unique ainsi qu'une preuve Merkle, et cette preuve permet à quiconque d'en valider l'exactitude. Le consensus est un modèle de confiance N/2-of-N, tandis que l'histoire est un modèle de confiance N-of-N.
Cela nous offre de nombreuses options sur la façon de stocker les historiques. Un choix naturel est un réseau où chaque nœud ne stocke qu'une petite partie des données. C'est ainsi que les réseaux de semences fonctionnent depuis des décennies : bien que le réseau ait stocké et distribué des millions de fichiers au total, chaque participant ne stocke et ne distribue que quelques fichiers parmi eux. Peut-être contre-intuitivement, cette méthode ne réduit même pas nécessairement la robustesse des données. Si, en rendant l'exécution des nœuds plus économique, nous pouvons établir un réseau de 100 000 nœuds, chacun stockant 10 % des historiques de manière aléatoire, alors chaque donnée sera copiée 10 000 fois - ce qui est exactement le même facteur de réplication qu'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 en permanence toute l'histoire. Le bloc de consensus (, qui est lié à la partie de consensus par preuve de participation, ne stocke 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 ) qui pourrait durer environ 18 jours (, durant laquelle chaque nœud serait responsable du stockage de tout le contenu, puis d'établir un réseau pair-à-pair composé de nœuds Ethereum qui stockeraient 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, les blobs ont déjà utilisé des codes d'effacement pour prendre en charge l'échantillonnage de la disponibilité des données. La solution la plus simple sera probablement de réutiliser ces codes d'effacement et de placer également les données d'exécution et de consensus des blocs dans le blob.
) est en lien avec les recherches existantes?
EIP-4444
Torrents et EIP-4444
Réseau portail
Réseau de portail et EIP-4444
Stockage et récupération distribués des objets SSZ dans le Portail
Comment augmenter la limite de gaz ### Paradigm (
) Que faut-il encore faire, quels éléments doivent être pesés?
Les principales tâches restantes incluent la construction et l'intégration d'une solution distribuée concrète pour stocker les historiques - au moins l'historique d'exécution, mais finalement aussi le consensus et les blobs. La solution la plus simple est ###i( d'introduire simplement une bibliothèque torrent existante, ainsi que )ii( 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 hard fork, mais il nécessite effectivement une nouvelle version du protocole réseau. Il est donc utile de l'activer simultanément pour tous les clients, sinon il existe un risque que des clients échouent en essayant de se connecter à d'autres nœuds avec l'espoir de télécharger l'historique complet, mais ne parviennent pas réellement à le faire.
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'historique ancien et à s'appuyer sur les nœuds d'archives existants et divers fournisseurs centralisés pour la réplication. C'est facile, mais cela affaiblit le statut d'Ethereum en tant que lieu d'enregistrement permanent. Une voie plus difficile mais plus sûre consiste d'abord à construire et à intégrer un réseau torrent pour stocker l'historique de manière décentralisée. Ici, "à quel point 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 d'intégration du stockage historique dans le protocole ?
Une méthode extrême et paranoïaque pour ) impliquerait une preuve de garde : exigeant en réalité que chaque vérificateur de preuve d'enjeu stocke un certain pourcentage de l'historique et vérifie régulièrement de manière cryptographique s'il le fait. Une méthode plus douce consisterait à établir un standard volontaire pour le pourcentage d'historique stocké par chaque client.
Pour (2), l'implémentation de base ne concerne que le travail déjà effectué aujourd'hui : le portail a déjà stocké un fichier ERA contenant l'ensemble de l'historique d'Ethereum. Une implémentation 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'archive, même s'il n'y a pas d'autres nœuds d'archive en ligne, il puisse le faire en synchronisant directement à partir du 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 d'un nœud extrêmement facile, alors réduire les besoins en stockage historique peut être considéré comme plus important que la sans état : parmi les 1,1 To nécessaires pour le nœud, environ 300 Go sont l'état, les 800 Go restants sont devenus historiques. Ce n'est qu'en réalisant la sans état et l'EIP-4444 que nous pourrons concrétiser la vision de faire fonctionner un nœud Ethereum sur une montre intelligente et de le configurer en quelques minutes.
La limitation du stockage historique rend également la mise en œuvre des nouveaux nœuds Ethereum plus viable, ne supportant que la dernière version du protocole, ce qui les rend plus simples. Par exemple, de nombreuses lignes de code peuvent désormais être supprimées en toute sécurité, car tous les emplacements de stockage vides créés lors de l'attaque par déni de service (DoS) de 2016 ont été supprimés. Maintenant que la transition vers la preuve d'enjeu appartient à l'histoire, les clients peuvent supprimer en toute sécurité tout le code lié à la preuve de travail.
![Vitalik : L'avenir possible d'Ethereum, The Purge])https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp###
Expiration de l'état
( résout quel problème ?
Même si nous éliminons le besoin de stockage de l'historique par le client, les besoins de stockage du client continueront d'augmenter, 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 actuels et futurs.
L'état est plus difficile à "expirer" que l'historique, car l'EVM est fondamentalement conçu autour de l'hypothèse suivante : 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 une absence d'état, certains pensent que ce problème n'est peut-être pas si grave : seules les classes de constructeurs de blocs spécialisées ont besoin de stocker réellement l'état, tandis que tous les autres nœuds ), même ceux contenant des listes générées ! ###, peuvent fonctionner sans état. Cependant, il existe un point de vue selon lequel nous ne voulons pas trop dépendre de l'absence d'état, et finalement, nous pourrions vouloir faire expirer l'état pour maintenir 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, ) 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 à l'aide de code, ( iii ) définir un emplacement de stockage jamais 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 de manière à atteindre trois objectifs.
Efficacité : pas besoin de calculs supplémentaires importants pour exécuter le processus d'expiration.
Facilité d'utilisation : si quelqu'un entre dans la grotte pendant cinq ans et en revient, il ne devrait pas perdre l'accès à ETH, ERC20, NFT, CDP...
Amabilité pour les développeurs : les développeurs n'ont pas besoin de passer à un modèle de pensée complètement inconnu. De plus, les applications actuellement rigides et non mises à jour devraient pouvoir 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 pourrait se produire automatiquement lors de toute lecture ou écriture ), et il y a un processus de boucle pour parcourir l'état afin de supprimer les objets d'état de date d'expiration. Cependant, cela introduit des exigences de calcul supplémentaires ( et même des besoins de stockage ), et cela ne peut certainement pas satisfaire aux exigences de convivialité. Les développeurs ont également du mal à raisonner sur les cas limites impliquant des valeurs de stockage qui sont parfois réinitialisées à zéro. Si vous définissez un minuteur d'expiration dans la portée du contrat, cela rendra techniquement la vie des développeurs plus facile, mais cela compliquera l'économie : les développeurs devront réfléchir à la manière 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 "la rente blockchain" et "la régénération". Enfin, nous avons combiné les meilleures parties des propositions et nous nous sommes concentrés sur deux catégories de "solutions connues comme étant les moins mauvaises" :
Solutions pour les états expirés
Suggestions d'expiration d'état basées sur le cycle d'adresse
( Expiration partielle de l'état
Certaines propositions d'état expirées suivent les mêmes principes. Nous divisons l'état en blocs. Chacun stocke de manière permanente la "carte de sommet", où les blocs sont vides ou non vides. 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", 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 définissons "bloc" ? Une proposition concrète est l'EIP-7736, qui s'appuie sur le design "tige-feuille" introduit pour les arbres Verkle ( bien qu'il soit compatible avec toute forme d'état sans état, comme les arbres binaires ). Dans ce design, les en-têtes, le code et les emplacements de stockage adjacents sont stockés sous une même "tige". Les données stockées sous une tige peuvent atteindre un maximum de 256 * 31 = 7 936 octets. Dans de nombreux cas, l'ensemble de l'en-tête et du code d'un compte ainsi que de nombreux emplacements de stockage de clés seront stockés sous la même tige. Si les données sous une tige donnée n'ont pas été lues ou écrites pendant 6 mois, ces données ne seront plus stockées, mais uniquement les 32 octets de ces données.
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.
14 J'aime
Récompense
14
6
Partager
Commentaire
0/400
LadderToolGuy
· 08-01 17:23
Des données historiques osent même être supprimées.
Voir l'originalRépondre0
Ser_APY_2000
· 08-01 13:46
V神 sait vraiment comment créer des choses.
Voir l'originalRépondre0
TrustlessMaximalist
· 07-29 18:30
Vitalik Buterin parle toujours de manière très solide.
Voir l'originalRépondre0
ConfusedWhale
· 07-29 18:27
Vitalik parle toujours de manière si profonde.
Voir l'originalRépondre0
hodl_therapist
· 07-29 18:17
Vieux dit vrai
Voir l'originalRépondre0
MetaverseLandlord
· 07-29 18:06
L'espace de stockage est trop cher, il vaut mieux le nettoyer que de le garder.
Ethereum The Purge : Goutte historique de stockage Simplification du protocole Amélioration de la durabilité
Ethereum : The Purge
Auteur : Vitalik Buterin
Un défi auquel Ethereum fait face 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 : Toutes les transactions effectuées et tous les comptes créés à tout moment dans le passé doivent être stockés de manière permanente par tous les clients et téléchargés par tout nouveau client pour se synchroniser complètement avec le réseau. Cela entraîne une augmentation constante de la charge des clients et du temps de synchronisation, 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 de anciennes fonctionnalités, ce qui entraîne une complexité du code qui augmente avec le temps.
Pour que l'Ethereum puisse maintenir sa durabilité à long terme, nous devons exercer une forte contre-pression sur ces deux tendances, réduisant la complexité et l'expansion au fil du temps. 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 placer des NFT, des lettres d'amour dans des enregistrements de transactions, ou des contrats intelligents contenant 1 million de dollars sur la chaîne, et 10 ans plus tard, ils seront toujours là, attendant que vous les lisiez et interagissiez. Pour que les DApp puissent être complètement décentralisées en toute confiance et supprimer les clés de mise à niveau, elles doivent être convaincues que leurs dépendances ne seront pas mises à niveau de manière à les détruire - en particulier L1 lui-même.
Si nous nous engageons à trouver un équilibre entre ces deux besoins, tout en minimisant ou en inversant le fardeau, la complexité et le déclin tout en maintenant la continuité, c'est tout à fait possible. Les organismes peuvent le faire : bien que la plupart des organismes vieillissent avec le temps, quelques chanceux 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, l'opcode SELFDESTRUCT a pour la plupart disparu, et les nœuds de la chaîne de balise ont stocké des données anciennes pendant jusqu'à six mois. Trouver ce chemin pour Ethereum de manière plus générale et avancer vers un résultat final stable à long terme représente le défi ultime pour l'évolutivité à long terme d'Ethereum, la durabilité technique et même la sécurité.
L'objectif principal de The Purge :
Expiration de l'historique
résout quel problème ?
À la date de rédaction de cet article, un nœud Ethereum entièrement synchronisé nécessite environ 1,1 To d'espace disque pour exécuter le client, et il faut également plusieurs centaines de Go d'espace disque pour le client de consensus. La grande majorité de cela est historique : des données concernant 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 du nœud continuera d'augmenter de plusieurs centaines de Go chaque année.
Qu'est-ce que c'est, comment ça fonctionne ?
Une caractéristique clé de la simplification des problèmes de stockage historique est que, parce que chaque bloc est lié par hachage à ( et à d'autres structures ) pointant vers le bloc précédent, il suffit d'atteindre un consensus sur l'état actuel pour atteindre un consensus sur l'histoire. Tant que le réseau parvient à un consensus sur le dernier bloc, tout bloc historique, transaction ou état (, solde de compte, nombre aléatoire, code, stockage ) peut être fourni par n'importe quel participant unique ainsi qu'une preuve Merkle, et cette preuve permet à quiconque d'en valider l'exactitude. Le consensus est un modèle de confiance N/2-of-N, tandis que l'histoire est un modèle de confiance N-of-N.
Cela nous offre de nombreuses options sur la façon de stocker les historiques. Un choix naturel est un réseau où chaque nœud ne stocke qu'une petite partie des données. C'est ainsi que les réseaux de semences fonctionnent depuis des décennies : bien que le réseau ait stocké et distribué des millions de fichiers au total, chaque participant ne stocke et ne distribue que quelques fichiers parmi eux. Peut-être contre-intuitivement, cette méthode ne réduit même pas nécessairement la robustesse des données. Si, en rendant l'exécution des nœuds plus économique, nous pouvons établir un réseau de 100 000 nœuds, chacun stockant 10 % des historiques de manière aléatoire, alors chaque donnée sera copiée 10 000 fois - ce qui est exactement le même facteur de réplication qu'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 en permanence toute l'histoire. Le bloc de consensus (, qui est lié à la partie de consensus par preuve de participation, ne stocke 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 ) qui pourrait durer environ 18 jours (, durant laquelle chaque nœud serait responsable du stockage de tout le contenu, puis d'établir un réseau pair-à-pair composé de nœuds Ethereum qui stockeraient 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, les blobs ont déjà utilisé des codes d'effacement pour prendre en charge l'échantillonnage de la disponibilité des données. La solution la plus simple sera probablement de réutiliser ces codes d'effacement et de placer également les données d'exécution et de consensus des blocs dans le blob.
) est en lien avec les recherches existantes?
) Que faut-il encore faire, quels éléments doivent être pesés?
Les principales tâches restantes incluent la construction et l'intégration d'une solution distribuée concrète pour stocker les historiques - au moins l'historique d'exécution, mais finalement aussi le consensus et les blobs. La solution la plus simple est ###i( d'introduire simplement une bibliothèque torrent existante, ainsi que )ii( 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 hard fork, mais il nécessite effectivement une nouvelle version du protocole réseau. Il est donc utile de l'activer simultanément pour tous les clients, sinon il existe un risque que des clients échouent en essayant de se connecter à d'autres nœuds avec l'espoir de télécharger l'historique complet, mais ne parviennent pas réellement à le faire.
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'historique ancien et à s'appuyer sur les nœuds d'archives existants et divers fournisseurs centralisés pour la réplication. C'est facile, mais cela affaiblit le statut d'Ethereum en tant que lieu d'enregistrement permanent. Une voie plus difficile mais plus sûre consiste d'abord à construire et à intégrer un réseau torrent pour stocker l'historique de manière décentralisée. Ici, "à quel point 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 d'intégration du stockage historique dans le protocole ?
Une méthode extrême et paranoïaque pour ) impliquerait une preuve de garde : exigeant en réalité que chaque vérificateur de preuve d'enjeu stocke un certain pourcentage de l'historique et vérifie régulièrement de manière cryptographique s'il le fait. Une méthode plus douce consisterait à établir un standard volontaire pour le pourcentage d'historique stocké par chaque client.
Pour (2), l'implémentation de base ne concerne que le travail déjà effectué aujourd'hui : le portail a déjà stocké un fichier ERA contenant l'ensemble de l'historique d'Ethereum. Une implémentation 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'archive, même s'il n'y a pas d'autres nœuds d'archive en ligne, il puisse le faire en synchronisant directement à partir du 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 d'un nœud extrêmement facile, alors réduire les besoins en stockage historique peut être considéré comme plus important que la sans état : parmi les 1,1 To nécessaires pour le nœud, environ 300 Go sont l'état, les 800 Go restants sont devenus historiques. Ce n'est qu'en réalisant la sans état et l'EIP-4444 que nous pourrons concrétiser la vision de faire fonctionner un nœud Ethereum sur une montre intelligente et de le configurer en quelques minutes.
La limitation du stockage historique rend également la mise en œuvre des nouveaux nœuds Ethereum plus viable, ne supportant que la dernière version du protocole, ce qui les rend plus simples. Par exemple, de nombreuses lignes de code peuvent désormais être supprimées en toute sécurité, car tous les emplacements de stockage vides créés lors de l'attaque par déni de service (DoS) de 2016 ont été supprimés. Maintenant que la transition vers la preuve d'enjeu appartient à l'histoire, les clients peuvent supprimer en toute sécurité tout le code lié à la preuve de travail.
![Vitalik : L'avenir possible d'Ethereum, The Purge])https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp###
Expiration de l'état
( résout quel problème ?
Même si nous éliminons le besoin de stockage de l'historique par le client, les besoins de stockage du client continueront d'augmenter, 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 actuels et futurs.
L'état est plus difficile à "expirer" que l'historique, car l'EVM est fondamentalement conçu autour de l'hypothèse suivante : 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 une absence d'état, certains pensent que ce problème n'est peut-être pas si grave : seules les classes de constructeurs de blocs spécialisées ont besoin de stocker réellement l'état, tandis que tous les autres nœuds ), même ceux contenant des listes générées ! ###, peuvent fonctionner sans état. Cependant, il existe un point de vue selon lequel nous ne voulons pas trop dépendre de l'absence d'état, et finalement, nous pourrions vouloir faire expirer l'état pour maintenir 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, ) 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 à l'aide de code, ( iii ) définir un emplacement de stockage jamais 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 de manière à atteindre trois objectifs.
Efficacité : pas besoin de calculs supplémentaires importants pour exécuter le processus d'expiration.
Facilité d'utilisation : si quelqu'un entre dans la grotte pendant cinq ans et en revient, il ne devrait pas perdre l'accès à ETH, ERC20, NFT, CDP...
Amabilité pour les développeurs : les développeurs n'ont pas besoin de passer à un modèle de pensée complètement inconnu. De plus, les applications actuellement rigides et non mises à jour devraient pouvoir 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 pourrait se produire automatiquement lors de toute lecture ou écriture ), et il y a un processus de boucle pour parcourir l'état afin de supprimer les objets d'état de date d'expiration. Cependant, cela introduit des exigences de calcul supplémentaires ( et même des besoins de stockage ), et cela ne peut certainement pas satisfaire aux exigences de convivialité. Les développeurs ont également du mal à raisonner sur les cas limites impliquant des valeurs de stockage qui sont parfois réinitialisées à zéro. Si vous définissez un minuteur d'expiration dans la portée du contrat, cela rendra techniquement la vie des développeurs plus facile, mais cela compliquera l'économie : les développeurs devront réfléchir à la manière 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 "la rente blockchain" et "la régénération". Enfin, nous avons combiné les meilleures parties des propositions et nous nous sommes concentrés sur deux catégories de "solutions connues comme étant les moins mauvaises" :
( Expiration partielle de l'état
Certaines propositions d'état expirées suivent les mêmes principes. Nous divisons l'état en blocs. Chacun stocke de manière permanente la "carte de sommet", où les blocs sont vides ou non vides. 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", 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 définissons "bloc" ? Une proposition concrète est l'EIP-7736, qui s'appuie sur le design "tige-feuille" introduit pour les arbres Verkle ( bien qu'il soit compatible avec toute forme d'état sans état, comme les arbres binaires ). Dans ce design, les en-têtes, le code et les emplacements de stockage adjacents sont stockés sous une même "tige". Les données stockées sous une tige peuvent atteindre un maximum de 256 * 31 = 7 936 octets. Dans de nombreux cas, l'ensemble de l'en-tête et du code d'un compte ainsi que de nombreux emplacements de stockage de clés seront stockés sous la même tige. Si les données sous une tige donnée n'ont pas été lues ou écrites pendant 6 mois, ces données ne seront plus stockées, mais uniquement les 32 octets de ces données.