Vitalik : l'avenir potentiel d'Ethereum, The Purge
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 dans l'histoire doivent être stockés de manière permanente par tous les clients et téléchargés par tout nouveau client, afin de se synchroniser complètement avec le réseau. Cela entraînera une augmentation continue de la charge du client 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 augmentation de la complexité 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 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 mettre 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 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 certains que leurs dépendances ne seront pas mises à niveau de manière à les compromettre - en particulier L1 lui-même.
Si nous nous engageons à trouver un équilibre entre 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 déjà réussi : la preuve de travail a disparu, l'opcode SELFDESTRUCT a en grande partie disparu, et les nœuds de la chaîne de balises ont stocké des données anciennes pendant jusqu'à 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 l'évolutivité à 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.
Historique d'expiration
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 en outre plusieurs centaines de Go d'espace disque pour le client de consensus. La majeure partie de cela est historique : il s'agit de 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 du problème de stockage historique est que, comme 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 présent pour atteindre un consensus sur l'histoire. 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 n'importe quel participant unique ainsi qu'une preuve de Merkle, et cette preuve permet à quiconque d'autre de vérifier son 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 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 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 établir un réseau de 100 000 nœuds, où chaque nœud stocke 10 % des historiques de manière aléatoire, chaque donnée sera copiée 10 000 fois - exactement le même facteur de duplication que celui d'un réseau de 10 000 nœuds, où chaque nœud stocke tout le contenu.
Aujourd'hui, Ethereum commence à 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 de preuve de participation) ne stockent que pendant environ 6 mois. Les Blob 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 sera 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 facteur de réplication identique. En fait, le Blob a déjà utilisé des codes d'effacement pour soutenir l'échantillonnage de la disponibilité des données. La solution la plus simple sera probablement de réutiliser ces codes d'effacement et d'inclure les données d'exécution et de consensus dans le blob.
a quels liens a-t-il avec les recherches existantes ?
EIP-4444
Torrents et EIP-4444
Réseau de 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 gas (Paradigm)
Que faut-il encore faire, et quel équilibre doit-on trouver ?
Le travail principal restant consiste à construire et à intégrer une solution distribuée concrète pour stocker l'historique ------ au moins l'historique d'exécution, mais finalement également 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'Éthereum appelée réseau Portal. Une fois l'un d'eux introduit, nous pouvons ouvrir 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. 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 raison de la connexion à d'autres nœuds s'attendant à télécharger l'historique complet mais ne l'obtenant en réalité pas.
Les principaux compromis concernent nos efforts pour fournir des données historiques "anciennes". La solution la plus simple serait d'arrêter de stocker l'historique ancien demain et de 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 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 distribuée. Ici, "dans quelle mesure 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 : en réalité, cela exigerait que chaque validateur de preuve de participation stocke un certain pourcentage d'historique et vérifie régulièrement de manière cryptographique s'il le fait. Une méthode plus douce consisterait à établir une norme volontaire pour le pourcentage d'historique stocké par chaque client.
Pour (2), la réalisation de base ne concerne que le travail déjà effectué aujourd'hui : le Portal a déjà stocké un fichier ERA contenant l'ensemble de l'histoire d'Ethereum. Une réalisation 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 peut le faire par synchronisation directe depuis le réseau Portal.
Comment interagit-il avec d'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 peut être considéré comme plus important que la sans état : sur les 1,1 To requis par le nœud, environ 300 Go sont un état, les 800 Go restants étant devenus historiques. Ce n'est qu'en réalisant la sans état et l'EIP-4444 que nous pourrons réaliser la vision d'exécuter un nœud Ethereum sur une montre intelligente et de le configurer en seulement quelques minutes.
Limiter le stockage historique rend également les nœuds Ethereum plus viables, ne prenant en charge que la dernière version du protocole, ce qui les rend plus simples. Par exemple, il est désormais 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 par déni de service de 2016 ont été supprimés. Étant donné 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.
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 de croître, d'environ 50 Go par an, car l'état continue de croître : 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 actuels et futurs.
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 à tout moment par n'importe quelle transaction. Si nous introduisons la non-état, certains pensent que ce problème n'est peut-être pas si grave : seules les classes 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 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 souhaiter faire expirer l'état pour maintenir la décentralisation d'Ethereum.
Qu'est-ce que c'est et comment ça fonctionne
Aujourd'hui, lorsque vous créez un nouvel objet d'état (ce qui peut se faire de l'une des trois manières suivantes : (i) envoyer de l'ETH à un nouveau compte, (ii) créer un nouveau compte par code, (iii) configurer un emplacement de stockage qui n'a pas été touché auparavant), cet objet d'état reste dans cet état indéfiniment. Au contraire, ce que nous souhaitons, c'est que l'objet expire automatiquement avec le 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'expiration.
Facilité d'utilisation : Si quelqu'un entre dans la grotte pendant cinq ans et revient, il ne devrait pas perdre l'accès à ses positions ETH, ERC20, NFT, CDP...
Amabilité pour les développeurs : Les développeurs ne doivent pas 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 très facile de résoudre des problèmes si ces objectifs ne sont pas satisfaits. Par exemple, vous pouvez faire en sorte que chaque objet d'état stocke également un compteur de date d'expiration (qui peut être prolongé par la combustion d'ÉTH, ce qui peut se produire automatiquement lors d'une lecture ou d'une écriture à tout moment), et avoir un processus qui parcourt l'état pour supprimer les objets d'état des dates d'expiration. Cependant, cela introduit des calculs supplémentaires (voire 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 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 rendra l'économie plus difficile : les développeurs doivent réfléchir à la façon de "transférer" les coûts de stockage continus aux utilisateurs.
Ces problèmes sont ceux que la communauté de développement centrale 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". En fin de compte, 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 pires" :
Solutions pour l'expiration de certains états
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 manière permanente la "carte principale", où les blocs peuvent être 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" 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) moi
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.
15 J'aime
Récompense
15
6
Partager
Commentaire
0/400
OnchainGossiper
· Il y a 14h
La synchronisation du client est tellement lente que j'en ai envie de vomir.
Voir l'originalRépondre0
MidnightSnapHunter
· 07-26 22:22
Vitalik Buterin enfin en liquidation ?
Voir l'originalRépondre0
PriceOracleFairy
· 07-24 21:24
ngl le bloat du protocole est réel... les cauchemars de scalabilité me tiennent éveillé à 3h du matin pro
Voir l'originalRépondre0
WhaleWatcher
· 07-24 21:14
Vitalik Buterin, aide-moi à calculer les frais de stockage.
Voir l'originalRépondre0
Degen4Breakfast
· 07-24 21:00
Dites au revoir au gonflement du système.
Voir l'originalRépondre0
FloorPriceWatcher
· 07-24 20:58
Pas d'amour pour les nouvelles fonctionnalités, amour pour le stockage zéro.
Vitalik parle de The Purge : le chemin vers la durabilité à long terme d'Ethereum
Vitalik : l'avenir potentiel d'Ethereum, The Purge
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 dans l'histoire doivent être stockés de manière permanente par tous les clients et téléchargés par tout nouveau client, afin de se synchroniser complètement avec le réseau. Cela entraînera une augmentation continue de la charge du client 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 augmentation de la complexité 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 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 mettre 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 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 certains que leurs dépendances ne seront pas mises à niveau de manière à les compromettre - en particulier L1 lui-même.
Si nous nous engageons à trouver un équilibre entre 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 déjà réussi : la preuve de travail a disparu, l'opcode SELFDESTRUCT a en grande partie disparu, et les nœuds de la chaîne de balises ont stocké des données anciennes pendant jusqu'à 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 l'évolutivité à 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.
Historique d'expiration
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 en outre plusieurs centaines de Go d'espace disque pour le client de consensus. La majeure partie de cela est historique : il s'agit de 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 du problème de stockage historique est que, comme 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 présent pour atteindre un consensus sur l'histoire. 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 n'importe quel participant unique ainsi qu'une preuve de Merkle, et cette preuve permet à quiconque d'autre de vérifier son 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 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 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 établir un réseau de 100 000 nœuds, où chaque nœud stocke 10 % des historiques de manière aléatoire, chaque donnée sera copiée 10 000 fois - exactement le même facteur de duplication que celui d'un réseau de 10 000 nœuds, où chaque nœud stocke tout le contenu.
Aujourd'hui, Ethereum commence à 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 de preuve de participation) ne stockent que pendant environ 6 mois. Les Blob 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 sera 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 facteur de réplication identique. En fait, le Blob a déjà utilisé des codes d'effacement pour soutenir l'échantillonnage de la disponibilité des données. La solution la plus simple sera probablement de réutiliser ces codes d'effacement et d'inclure les données d'exécution et de consensus dans le blob.
a quels liens a-t-il avec les recherches existantes ?
Que faut-il encore faire, et quel équilibre doit-on trouver ?
Le travail principal restant consiste à construire et à intégrer une solution distribuée concrète pour stocker l'historique ------ au moins l'historique d'exécution, mais finalement également 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'Éthereum appelée réseau Portal. Une fois l'un d'eux introduit, nous pouvons ouvrir 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. 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 raison de la connexion à d'autres nœuds s'attendant à télécharger l'historique complet mais ne l'obtenant en réalité pas.
Les principaux compromis concernent nos efforts pour fournir des données historiques "anciennes". La solution la plus simple serait d'arrêter de stocker l'historique ancien demain et de 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 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 distribuée. Ici, "dans quelle mesure 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 : en réalité, cela exigerait que chaque validateur de preuve de participation stocke un certain pourcentage d'historique et vérifie régulièrement de manière cryptographique s'il le fait. Une méthode plus douce consisterait à établir une norme volontaire pour le pourcentage d'historique stocké par chaque client.
Pour (2), la réalisation de base ne concerne que le travail déjà effectué aujourd'hui : le Portal a déjà stocké un fichier ERA contenant l'ensemble de l'histoire d'Ethereum. Une réalisation 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 peut le faire par synchronisation directe depuis le réseau Portal.
Comment interagit-il avec d'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 peut être considéré comme plus important que la sans état : sur les 1,1 To requis par le nœud, environ 300 Go sont un état, les 800 Go restants étant devenus historiques. Ce n'est qu'en réalisant la sans état et l'EIP-4444 que nous pourrons réaliser la vision d'exécuter un nœud Ethereum sur une montre intelligente et de le configurer en seulement quelques minutes.
Limiter le stockage historique rend également les nœuds Ethereum plus viables, ne prenant en charge que la dernière version du protocole, ce qui les rend plus simples. Par exemple, il est désormais 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 par déni de service de 2016 ont été supprimés. Étant donné 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.
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 de croître, d'environ 50 Go par an, car l'état continue de croître : 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 actuels et futurs.
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 à tout moment par n'importe quelle transaction. Si nous introduisons la non-état, certains pensent que ce problème n'est peut-être pas si grave : seules les classes 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 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 souhaiter faire expirer l'état pour maintenir la décentralisation d'Ethereum.
Qu'est-ce que c'est et comment ça fonctionne
Aujourd'hui, lorsque vous créez un nouvel objet d'état (ce qui peut se faire de l'une des trois manières suivantes : (i) envoyer de l'ETH à un nouveau compte, (ii) créer un nouveau compte par code, (iii) configurer un emplacement de stockage qui n'a pas été touché auparavant), cet objet d'état reste dans cet état indéfiniment. Au contraire, ce que nous souhaitons, c'est que l'objet expire automatiquement avec le 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'expiration.
Facilité d'utilisation : Si quelqu'un entre dans la grotte pendant cinq ans et revient, il ne devrait pas perdre l'accès à ses positions ETH, ERC20, NFT, CDP...
Amabilité pour les développeurs : Les développeurs ne doivent pas 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 très facile de résoudre des problèmes si ces objectifs ne sont pas satisfaits. Par exemple, vous pouvez faire en sorte que chaque objet d'état stocke également un compteur de date d'expiration (qui peut être prolongé par la combustion d'ÉTH, ce qui peut se produire automatiquement lors d'une lecture ou d'une écriture à tout moment), et avoir un processus qui parcourt l'état pour supprimer les objets d'état des dates d'expiration. Cependant, cela introduit des calculs supplémentaires (voire 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 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 rendra l'économie plus difficile : les développeurs doivent réfléchir à la façon de "transférer" les coûts de stockage continus aux utilisateurs.
Ces problèmes sont ceux que la communauté de développement centrale 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". En fin de compte, 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 pires" :
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 manière permanente la "carte principale", où les blocs peuvent être 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" 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) moi