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 à deux endroits :
Données historiques : Toutes les transactions effectuées et tous les comptes créés à tout moment dans le passé doivent être stockés en permanence par tous les clients et téléchargés par tout nouveau client, afin d'être complètement synchronisés avec le réseau. Cela entraînera une charge client et un temps de synchronisation qui augmentent continuellement avec le 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é du code qui augmente avec le 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 au fil du 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 placer un NFT, une lettre d'amour dans les données d'un 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 ressortant, découvrir 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 à jour, elles doivent être convaincues que leurs dépendances ne seront pas mises à jour de manière à les compromettre - en particulier la L1 elle-même.
Si nous nous décidons à équilibrer ces deux besoins et à minimiser ou inverser l'encombrement, la complexité et le déclin tout en maintenant la continuité, c'est absolument possible. Les organismes vivants 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 très longue durée de vie. Dans certains cas, Ethereum a réussi : la preuve de travail a disparu, l'opcode SELFDESTRUCT a presque disparu, et les nœuds de la chaîne de balises ont stocké des données anciennes pendant jusqu'à six mois. Trouver cette voie pour Ethereum de manière plus générale et avancer 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 le besoin pour chaque nœud de stocker de manière permanente tous 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( historique enregistré à l'expiration)
État d'expiration( état d'expiration)
Feature cleanup( nettoyage des caractéristiques)
Historique d'expiration
Quel problème cela 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 faire fonctionner le client, et plusieurs centaines de Go d'espace disque pour le client de consensus. La majeure partie de cela concerne l'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, comment ça marche?
Une caractéristique clé de la simplification des problèmes de stockage historique est que, parce que chaque bloc est lié au précédent par un 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, n'importe quel bloc historique ou transaction ou é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 la 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 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 fonctionne le réseau de semences 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 qu'un petit nombre de ces fichiers. Peut-être contre-intuitivement, cette approche ne réduit même pas nécessairement la robustesse des données. Si, en rendant le fonctionnement des nœuds plus économique, nous pouvons établir un réseau de 100 000 nœuds, chacun stockant aléatoirement 10 % des historiques, alors chaque donnée sera copiée 10 000 fois - ce qui est exactement le même facteur de réplication que dans 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 conservent en permanence toute l'historique. Le bloc de consensus (, qui est lié à la partie du consensus par preuve de participation, ne conserve que pendant environ 6 mois. Les blobs ne sont conservé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 de stocker tout le contenu, puis de créer un réseau pair-à-pair composé de nœuds Ethereum, stockant 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 supporter 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.
)# Quels liens existe-t-il avec les recherches existantes ?
EIP-4444;
Torrents et EIP-4444;
Portail réseau;
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, quelles sont les choses à prendre en compte?
Les principales tâches restantes comprennent 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 éventuellement aussi le consensus et le blob. La solution la plus simple est ###i( d'introduire simplement des bibliothèques torrent existantes, ainsi que )ii( appelé solution native d'Ethereum du réseau Portal. Une fois l'une ou l'autre introduite, nous pouvons activer 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 s'attendant à télécharger l'historique complet en se connectant à d'autres nœuds, 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 de stocker l'historique ancien demain 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 de l'Éthereum en tant que registre permanent. Une approche plus difficile mais plus sûre consiste à construire et à intégrer d'abord un réseau torrent pour stocker l'historique de manière décentralisée. Ici, "à quel point nous nous battons" a deux dimensions :
Comment faisons-nous pour 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 approche extrême et paranoïaque pour ) impliquerait une preuve de dépôt : exigeant en réalité 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), l'implémentation 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'histoire 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'archivage, même s'il n'y a pas d'autres nœuds d'archivage en ligne, il puisse le faire via une synchronisation directe depuis le réseau du Portail.
(# Comment interagit-il avec d'autres parties de la feuille de route ?
Si nous voulons que le fonctionnement ou le lancement des nœuds soit extrêmement facile, alors réduire les exigences de stockage historique peut être considéré comme plus important que l'absence d'état : sur les 1,1 To nécessaires pour le nœud, environ 300 Go sont des états, les 800 Go restants étant devenus historiques. Ce n'est qu'en réalisant l'absence d'état et l'EIP-4444 que nous pourrons concrétiser la vision de faire fonctionner un nœud Ethereum sur une montre connectée et de le configurer en quelques minutes.
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 les emplacements de stockage vides créés lors de l'attaque DoS de 2016 ont tous été supprimés. Maintenant que la transition vers la preuve d'enjeu est devenue historique, les clients peuvent supprimer en toute sécurité tout le code lié à la preuve de travail.
) État d'expiration
Quel problème résout-il?
Même si nous éliminons le besoin de stockage historique côté client, les besoins de stockage côté 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 impose un fardeau éternel 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 l'absence d'é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 ###, même ceux qui incluent la génération de listes ! ### peuvent fonctionner sans état. Cependant, il y a un avis 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'ÉTH à un nouveau compte, ( ii ) créer un nouveau compte avec du code, ( iii ) définir un emplacement de stockage qui n'a jamais été touché auparavant (, cet objet d'état reste toujours dans cet état. 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 une grotte pendant cinq ans et en ressort, il ne devrait pas perdre l'accès à ses positions ETH, ERC20, NFT, CDP...
Compatibilité avec les développeurs : Les développeurs ne sont pas obligés de passer à un modèle de pensée complètement inconnu. De plus, les applications qui sont actuellement rigides et non mises à jour devraient continuer à fonctionner normalement.
Ne pas atteindre ces objectifs rend la résolution des problèmes très facile. Par exemple, vous pouvez faire en sorte que chaque objet d'état stocke également un compteur de date d'expiration. ) 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 il y a un processus qui parcourt l'état pour supprimer les objets d'état avec des dates d'expiration. Cependant, cela introduit des exigences de calcul supplémentaires. ( et même 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 impliquant des valeurs de stockage qui sont parfois réinitialisées à zéro. Si vous définissez un chronomètre d'expiration dans la portée du contrat, cela rend techniquement la vie des développeurs plus facile, mais cela rend l'économie plus difficile : les développeurs doivent réfléchir à la manière de "répercuter" les coûts de stockage continus sur les utilisateurs.
Ce sont tous des problèmes que la communauté des développeurs principaux d'Ethereum s'efforce de résoudre depuis des années, y compris des propositions telles que "le loyer de la 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 partiellement périmés
Suggestions d'expiration de l'état basées sur le cycle d'adresse.
(# Expiration partielle de l'état
Certaines propositions d'expiration d'état suivent les mêmes principes. Nous divisons l'état en blocs. Chacun stocke de façon permanente la "carte de niveau supérieur", où les blocs sont vides ou non vides. Ce n'est que lorsque le plus
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.
24 J'aime
Récompense
24
5
Partager
Commentaire
0/400
0xSherlock
· Il y a 23h
C'est trop difficile, ceux qui comprennent lèvent la main.
Voir l'originalRépondre0
WalletDetective
· 07-25 22:52
C'est aussi un gros problème, hein~
Voir l'originalRépondre0
DeFiGrayling
· 07-25 22:51
La Blockchain gonfle plus vite que le prix des jetons.
Voir l'originalRépondre0
0xLuckbox
· 07-25 22:51
Le compromis est plus facile que l'innovation.
Voir l'originalRépondre0
CryptoFortuneTeller
· 07-25 22:50
Didi, la première synchronisation ressemble vraiment à un tapis de course, jamais fini.
La vision future d'Éthereum : comment The Purge redéfinit l'écosystème Blockchain
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 à deux endroits :
Données historiques : Toutes les transactions effectuées et tous les comptes créés à tout moment dans le passé doivent être stockés en permanence par tous les clients et téléchargés par tout nouveau client, afin d'être complètement synchronisés avec le réseau. Cela entraînera une charge client et un temps de synchronisation qui augmentent continuellement avec le 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é du code qui augmente avec le 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 au fil du 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 placer un NFT, une lettre d'amour dans les données d'un 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 ressortant, découvrir 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 à jour, elles doivent être convaincues que leurs dépendances ne seront pas mises à jour de manière à les compromettre - en particulier la L1 elle-même.
Si nous nous décidons à équilibrer ces deux besoins et à minimiser ou inverser l'encombrement, la complexité et le déclin tout en maintenant la continuité, c'est absolument possible. Les organismes vivants 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 très longue durée de vie. Dans certains cas, Ethereum a réussi : la preuve de travail a disparu, l'opcode SELFDESTRUCT a presque disparu, et les nœuds de la chaîne de balises ont stocké des données anciennes pendant jusqu'à six mois. Trouver cette voie pour Ethereum de manière plus générale et avancer 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 le besoin pour chaque nœud de stocker de manière permanente tous 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( historique enregistré à l'expiration)
État d'expiration( état d'expiration)
Feature cleanup( nettoyage des caractéristiques)
Historique d'expiration
Quel problème cela 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 faire fonctionner le client, et plusieurs centaines de Go d'espace disque pour le client de consensus. La majeure partie de cela concerne l'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, comment ça marche?
Une caractéristique clé de la simplification des problèmes de stockage historique est que, parce que chaque bloc est lié au précédent par un 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, n'importe quel bloc historique ou transaction ou é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 la 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 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 fonctionne le réseau de semences 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 qu'un petit nombre de ces fichiers. Peut-être contre-intuitivement, cette approche ne réduit même pas nécessairement la robustesse des données. Si, en rendant le fonctionnement des nœuds plus économique, nous pouvons établir un réseau de 100 000 nœuds, chacun stockant aléatoirement 10 % des historiques, alors chaque donnée sera copiée 10 000 fois - ce qui est exactement le même facteur de réplication que dans 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 conservent en permanence toute l'historique. Le bloc de consensus (, qui est lié à la partie du consensus par preuve de participation, ne conserve que pendant environ 6 mois. Les blobs ne sont conservé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 de stocker tout le contenu, puis de créer un réseau pair-à-pair composé de nœuds Ethereum, stockant 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 supporter 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.
)# Quels liens existe-t-il avec les recherches existantes ?
EIP-4444;
Torrents et EIP-4444;
Portail réseau;
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, quelles sont les choses à prendre en compte?
Les principales tâches restantes comprennent 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 éventuellement aussi le consensus et le blob. La solution la plus simple est ###i( d'introduire simplement des bibliothèques torrent existantes, ainsi que )ii( appelé solution native d'Ethereum du réseau Portal. Une fois l'une ou l'autre introduite, nous pouvons activer 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 s'attendant à télécharger l'historique complet en se connectant à d'autres nœuds, 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 de stocker l'historique ancien demain 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 de l'Éthereum en tant que registre permanent. Une approche plus difficile mais plus sûre consiste à construire et à intégrer d'abord un réseau torrent pour stocker l'historique de manière décentralisée. Ici, "à quel point nous nous battons" a deux dimensions :
Comment faisons-nous pour 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 approche extrême et paranoïaque pour ) impliquerait une preuve de dépôt : exigeant en réalité 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), l'implémentation 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'histoire 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'archivage, même s'il n'y a pas d'autres nœuds d'archivage en ligne, il puisse le faire via une synchronisation directe depuis le réseau du Portail.
(# Comment interagit-il avec d'autres parties de la feuille de route ?
Si nous voulons que le fonctionnement ou le lancement des nœuds soit extrêmement facile, alors réduire les exigences de stockage historique peut être considéré comme plus important que l'absence d'état : sur les 1,1 To nécessaires pour le nœud, environ 300 Go sont des états, les 800 Go restants étant devenus historiques. Ce n'est qu'en réalisant l'absence d'état et l'EIP-4444 que nous pourrons concrétiser la vision de faire fonctionner un nœud Ethereum sur une montre connectée et de le configurer en quelques minutes.
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 les emplacements de stockage vides créés lors de l'attaque DoS de 2016 ont tous été supprimés. Maintenant que la transition vers la preuve d'enjeu est devenue historique, les clients peuvent supprimer en toute sécurité tout le code lié à la preuve de travail.
) État d'expiration
Quel problème résout-il?
Même si nous éliminons le besoin de stockage historique côté client, les besoins de stockage côté 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 impose un fardeau éternel 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 l'absence d'é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 ###, même ceux qui incluent la génération de listes ! ### peuvent fonctionner sans état. Cependant, il y a un avis 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'ÉTH à un nouveau compte, ( ii ) créer un nouveau compte avec du code, ( iii ) définir un emplacement de stockage qui n'a jamais été touché auparavant (, cet objet d'état reste toujours dans cet état. 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 une grotte pendant cinq ans et en ressort, il ne devrait pas perdre l'accès à ses positions ETH, ERC20, NFT, CDP...
Compatibilité avec les développeurs : Les développeurs ne sont pas obligés de passer à un modèle de pensée complètement inconnu. De plus, les applications qui sont actuellement rigides et non mises à jour devraient continuer à fonctionner normalement.
Ne pas atteindre ces objectifs rend la résolution des problèmes très facile. Par exemple, vous pouvez faire en sorte que chaque objet d'état stocke également un compteur de date d'expiration. ) 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 il y a un processus qui parcourt l'état pour supprimer les objets d'état avec des dates d'expiration. Cependant, cela introduit des exigences de calcul supplémentaires. ( et même 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 impliquant des valeurs de stockage qui sont parfois réinitialisées à zéro. Si vous définissez un chronomètre d'expiration dans la portée du contrat, cela rend techniquement la vie des développeurs plus facile, mais cela rend l'économie plus difficile : les développeurs doivent réfléchir à la manière de "répercuter" les coûts de stockage continus sur les utilisateurs.
Ce sont tous des problèmes que la communauté des développeurs principaux d'Ethereum s'efforce de résoudre depuis des années, y compris des propositions telles que "le loyer de la 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'expiration d'état suivent les mêmes principes. Nous divisons l'état en blocs. Chacun stocke de façon permanente la "carte de niveau supérieur", où les blocs sont vides ou non vides. Ce n'est que lorsque le plus