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 : Toutes les transactions effectuées et tous les comptes créés à tout moment de l'histoire doivent être stockés de manière permanente par tous les clients et téléchargés par tout nouveau client pour être complètement synchronisés avec le réseau. Cela entraînera 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 constante.
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é du code qui augmente avec le temps.
Pour que l'Ethereum puisse durer à long terme, nous devons exercer une forte pression inverse sur ces deux tendances, réduisant la complexité et l'expansion au fil du temps. Mais en même temps, nous devons conserver l'une des propriétés clés qui rendent la blockchain incroyable : la durabilité. Vous pouvez placer un NFT, une lettre d'amour dans les données d'appel de 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 se décentraliser complètement en toute confiance et supprimer les clés de mise à niveau, ils doivent être sûrs que leurs dépendances ne seront pas mises à niveau de manière à les endommager - en particulier L1 lui-même.
Si nous nous engageons à trouver un équilibre entre ces deux besoins, tout en minimisant ou en inversant le gaspillage, la complexité et le déclin, tout en maintenant la continuité, c'est absolument possible. Les organismes peuvent y parvenir : 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 principalement disparu, et les nœuds de la chaîne de balise ont stocké des données anciennes pendant un maximum de six mois. Trouver ce chemin 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 durabilité à long terme d'Ethereum, sa durabilité technique et même sa sécurité.
The Purge : objectif principal.
Réduire les exigences de stockage des clients en diminuant ou en éliminant le besoin pour chaque nœud de conserver toutes les historiques, voire l'état final.
Réduire la complexité du protocole en éliminant les fonctionnalités inutiles.
Table des matières :
Historique d'expiration（历史记录到期）
État d'expiration（状态到期）
Nettoyage des fonctionnalités
Histoire d'expiration
Quel problème cela résout-il ?
À la date de 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 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 des nœuds continuera à 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 pointe vers le bloc précédent par un lien de hachage (et d'autres structures), il suffit d'atteindre un consensus sur le bloc actuel pour parvenir à un consensus sur l'historique. Tant que le réseau parvient à un consensus sur le dernier bloc, n'importe quel bloc, transaction ou état historique (solde de compte, nombre aléatoire, code, stockage) peut être fourni par un seul participant ainsi qu'une preuve Merkle, et cette preuve permet à quiconque d'autre de vérifier sa validité. 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 fonctionne le réseau des graines 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 fichiers parmi eux. Peut-être contre-intuitivement, cette méthode ne réduit même pas nécessairement la robustesse des données. Si nous pouvons construire 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 - ce qui est exactement le même facteur de copie qu'un réseau de 10 000 nœuds, où chaque nœud stocke tout.
Aujourd'hui, Ethereum commence à se libérer 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 stockent 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 uniforme (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, où les anciennes données sont stockées de manière distribuée.
Les codes d'effacement peuvent être utilisés pour améliorer la robustesse tout en maintenant le facteur de réplication identique. En fait, le Blob a déjà utilisé des codes d'effacement pour soutenir l'échantillonnage de disponibilité des données. La solution la plus simple sera probablement de réutiliser ces codes d'effacement et d'inclure également les données d'exécution et de consensus dans le blob.
Quelles sont les relations avec les recherches existantes ?
EIP-4444；
Torrents et EIP-4444；
Réseau de porte
Réseau de porte 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, quels compromis faut-il envisager ?
Les travaux restants incluent la construction et l'intégration d'une solution distribuée concrète pour stocker l'historique ------ au moins l'historique d'exécution, mais finalement aussi le consensus et le blob. La solution la plus simple est (i) d'introduire simplement une bibliothèque torrent existante, ainsi que (ii) appelée solution native d'Ethereum, le réseau Portal. Une fois l'un ou l'autre introduit, nous pouvons ouvrir l'EIP-4444. L'EIP-4444 lui-même ne nécessite pas de hard fork, mais il nécessite une nouvelle version du protocole réseau. Par conséquent, il est utile de l'activer simultanément pour tous les clients, sinon il existe un risque que les clients échouent en essayant de se connecter à d'autres nœuds en s'attendant à télécharger l'historique complet mais ne le récupérant pas réellement.
Les principaux compromis concernent nos efforts pour fournir des données historiques "anciennes". La solution la plus simple consiste à cesser de stocker les anciennes données historiques demain et à s'appuyer 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 décentralisée. Ici, "dans quelle mesure nous nous efforçons" a deux dimensions :
Comment nous efforçons-nous de nous assurer que le plus grand ensemble de nœuds stocke réellement toutes les données ?
Quelle est la profondeur de l'intégration du stockage historique dans le protocole ?
Une méthode extrême et paranoïaque pour (1) impliquerait une preuve de garde : exigeant en réalité que chaque validateur de preuve de participation stocke une certaine proportion 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é un fichier ERA contenant l'ensemble 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 si aucun autre nœud d'archivage n'est en ligne, il pourrait le faire en se 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 des nœuds extrêmement facile, alors réduire les besoins en stockage historique peut être considéré comme plus important que la statelessness : sur les 1,1 To requis par le nœud, environ 300 Go sont l'état, le reste, environ 800 Go, est devenu historique. Ce n'est qu'en réalisant la statelessness 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 atteinte.
La limitation du stockage historique permet également aux nœuds Ethereum plus récents de devenir plus viables, 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 espaces de stockage vides créés durant l'attaque par déni de service (DoS) de 2016 ont été supprimés. Maintenant que la transition vers la preuve d'enjeu est devenue historique, les clients peuvent en toute sécurité supprimer tout le code lié à la preuve de travail.
État d'expiration
Quel problème cela résout-il ?
Même si nous éliminons le besoin de stockage d'historique côté client, les besoins de stockage du client continueront de croître, d'environ 50 Go par an, car l'état continue d'augmenter : soldes des comptes et nombres aléatoires, code des contrats et 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 existera toujours et pourra être lu par toute transaction à tout moment. Si nous introduisons la non-état, certains pensent que ce problème n'est peut-être pas si grave : seuls des types de constructeurs de blocs spécialisés doivent réellement stocker l'état, tandis que tous les autres nœuds (y compris ceux générant 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 non-état, et finalement, nous pourrions vouloir faire expirer l'état pour maintenir la décentralisation d'Ethereum.
Que 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 à l'aide de code, (iii) définir un emplacement de stockage qui n'a pas été touché auparavant), cet objet d'état demeure dans cet état indéfiniment. 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 d'un grand nombre de calculs supplémentaires 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 à ses positions en Éther, 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 qui sont 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 peut se produire automatiquement à tout moment lors d'une lecture ou d'une écriture), et avoir un processus qui parcourt les états pour supprimer les objets d'état ayant une date d'expiration. Cependant, cela introduit des calculs supplémentaires (voire des besoins de stockage) et cela ne répond certainement pas 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 la portée du contrat, cela facilitera techniquement la vie des développeurs, mais cela compliquera l'économie : les développeurs doivent réfléchir à comment "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 comme "la rente blockchain" et "la régénération". Finalement, 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 partiels 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 "top mapping", où les blocs sont vides.
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.
Ethereum The Purge : réduire la complexité, améliorer la durabilité et la sécurité
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 : Toutes les transactions effectuées et tous les comptes créés à tout moment de l'histoire doivent être stockés de manière permanente par tous les clients et téléchargés par tout nouveau client pour être complètement synchronisés avec le réseau. Cela entraînera 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 constante.
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é du code qui augmente avec le temps.
Pour que l'Ethereum puisse durer à long terme, nous devons exercer une forte pression inverse sur ces deux tendances, réduisant la complexité et l'expansion au fil du temps. Mais en même temps, nous devons conserver l'une des propriétés clés qui rendent la blockchain incroyable : la durabilité. Vous pouvez placer un NFT, une lettre d'amour dans les données d'appel de 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 se décentraliser complètement en toute confiance et supprimer les clés de mise à niveau, ils doivent être sûrs que leurs dépendances ne seront pas mises à niveau de manière à les endommager - en particulier L1 lui-même.
Si nous nous engageons à trouver un équilibre entre ces deux besoins, tout en minimisant ou en inversant le gaspillage, la complexité et le déclin, tout en maintenant la continuité, c'est absolument possible. Les organismes peuvent y parvenir : 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 principalement disparu, et les nœuds de la chaîne de balise ont stocké des données anciennes pendant un maximum de six mois. Trouver ce chemin 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 durabilité à long terme d'Ethereum, sa durabilité technique et même sa sécurité.
The Purge : objectif principal.
Réduire les exigences de stockage des clients en diminuant ou en éliminant le besoin pour chaque nœud de conserver toutes les historiques, voire l'état final.
Réduire la complexité du protocole en éliminant les fonctionnalités inutiles.
Table des matières :
Historique d'expiration（历史记录到期）
État d'expiration（状态到期）
Nettoyage des fonctionnalités
Histoire d'expiration
Quel problème cela résout-il ?
À la date de 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 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 des nœuds continuera à 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 pointe vers le bloc précédent par un lien de hachage (et d'autres structures), il suffit d'atteindre un consensus sur le bloc actuel pour parvenir à un consensus sur l'historique. Tant que le réseau parvient à un consensus sur le dernier bloc, n'importe quel bloc, transaction ou état historique (solde de compte, nombre aléatoire, code, stockage) peut être fourni par un seul participant ainsi qu'une preuve Merkle, et cette preuve permet à quiconque d'autre de vérifier sa validité. 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 fonctionne le réseau des graines 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 fichiers parmi eux. Peut-être contre-intuitivement, cette méthode ne réduit même pas nécessairement la robustesse des données. Si nous pouvons construire 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 - ce qui est exactement le même facteur de copie qu'un réseau de 10 000 nœuds, où chaque nœud stocke tout.
Aujourd'hui, Ethereum commence à se libérer 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 stockent 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 uniforme (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, où les anciennes données sont stockées de manière distribuée.
Les codes d'effacement peuvent être utilisés pour améliorer la robustesse tout en maintenant le facteur de réplication identique. En fait, le Blob a déjà utilisé des codes d'effacement pour soutenir l'échantillonnage de disponibilité des données. La solution la plus simple sera probablement de réutiliser ces codes d'effacement et d'inclure également les données d'exécution et de consensus dans le blob.
Quelles sont les relations avec les recherches existantes ?
EIP-4444；
Torrents et EIP-4444；
Réseau de porte
Réseau de porte 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, quels compromis faut-il envisager ?
Les travaux restants incluent la construction et l'intégration d'une solution distribuée concrète pour stocker l'historique ------ au moins l'historique d'exécution, mais finalement aussi le consensus et le blob. La solution la plus simple est (i) d'introduire simplement une bibliothèque torrent existante, ainsi que (ii) appelée solution native d'Ethereum, le réseau Portal. Une fois l'un ou l'autre introduit, nous pouvons ouvrir l'EIP-4444. L'EIP-4444 lui-même ne nécessite pas de hard fork, mais il nécessite une nouvelle version du protocole réseau. Par conséquent, il est utile de l'activer simultanément pour tous les clients, sinon il existe un risque que les clients échouent en essayant de se connecter à d'autres nœuds en s'attendant à télécharger l'historique complet mais ne le récupérant pas réellement.
Les principaux compromis concernent nos efforts pour fournir des données historiques "anciennes". La solution la plus simple consiste à cesser de stocker les anciennes données historiques demain et à s'appuyer 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 décentralisée. Ici, "dans quelle mesure nous nous efforçons" a deux dimensions :
Comment nous efforçons-nous de nous assurer que le plus grand ensemble de nœuds stocke réellement toutes les données ?
Quelle est la profondeur de l'intégration du stockage historique dans le protocole ?
Une méthode extrême et paranoïaque pour (1) impliquerait une preuve de garde : exigeant en réalité que chaque validateur de preuve de participation stocke une certaine proportion 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é un fichier ERA contenant l'ensemble 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 si aucun autre nœud d'archivage n'est en ligne, il pourrait le faire en se 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 des nœuds extrêmement facile, alors réduire les besoins en stockage historique peut être considéré comme plus important que la statelessness : sur les 1,1 To requis par le nœud, environ 300 Go sont l'état, le reste, environ 800 Go, est devenu historique. Ce n'est qu'en réalisant la statelessness 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 atteinte.
La limitation du stockage historique permet également aux nœuds Ethereum plus récents de devenir plus viables, 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 espaces de stockage vides créés durant l'attaque par déni de service (DoS) de 2016 ont été supprimés. Maintenant que la transition vers la preuve d'enjeu est devenue historique, les clients peuvent en toute sécurité supprimer tout le code lié à la preuve de travail.
État d'expiration
Quel problème cela résout-il ?
Même si nous éliminons le besoin de stockage d'historique côté client, les besoins de stockage du client continueront de croître, d'environ 50 Go par an, car l'état continue d'augmenter : soldes des comptes et nombres aléatoires, code des contrats et 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 existera toujours et pourra être lu par toute transaction à tout moment. Si nous introduisons la non-état, certains pensent que ce problème n'est peut-être pas si grave : seuls des types de constructeurs de blocs spécialisés doivent réellement stocker l'état, tandis que tous les autres nœuds (y compris ceux générant 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 non-état, et finalement, nous pourrions vouloir faire expirer l'état pour maintenir la décentralisation d'Ethereum.
Que 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 à l'aide de code, (iii) définir un emplacement de stockage qui n'a pas été touché auparavant), cet objet d'état demeure dans cet état indéfiniment. 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 d'un grand nombre de calculs supplémentaires 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 à ses positions en Éther, 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 qui sont 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 peut se produire automatiquement à tout moment lors d'une lecture ou d'une écriture), et avoir un processus qui parcourt les états pour supprimer les objets d'état ayant une date d'expiration. Cependant, cela introduit des calculs supplémentaires (voire des besoins de stockage) et cela ne répond certainement pas 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 la portée du contrat, cela facilitera techniquement la vie des développeurs, mais cela compliquera l'économie : les développeurs doivent réfléchir à comment "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 comme "la rente blockchain" et "la régénération". Finalement, 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 "top mapping", où les blocs sont vides.