Un des grands défis auxquels Ethereum est confronté est de savoir comment réduire la complexité et les besoins de stockage à long terme, tout en maintenant la durabilité et les caractéristiques de décentralisation de la blockchain. Cela nécessite que nous agissions dans plusieurs domaines clés :
Historique expiré
Actuellement, un nœud Ethereum complètement synchronisé nécessite environ 1,1 To d'espace de stockage, dont la majeure partie est utilisée pour stocker des données historiques. Même si la limite de gaz reste inchangée, la taille des nœuds continuera d'augmenter de plusieurs centaines de Go chaque année.
La solution consiste à établir un réseau pair-à-pair composé de nœuds Ethereum pour stocker de manière distribuée les anciennes données. Chaque nœud n'a besoin de stocker que les données des 18 derniers jours, les données plus anciennes pouvant être récupérées via le réseau. Cela permet de réduire considérablement la charge de stockage d'un nœud individuel.
Les principales tâches liées à l'expiration des enregistrements historiques comprennent :
Construire et intégrer des solutions de stockage distribué spécifiques, comme l'introduction de bibliothèques torrent existantes ou du réseau Portal natif d'Ethereum.
Activer EIP-4444, limiter la durée de stockage des données historiques par les nœuds.
Décider comment traiter les données historiques "anciennes", s'il faut complètement dépendre des nœuds d'archivage existants ou construire un réseau de stockage distribué plus robuste.
État expiré
Même si la nécessité de stocker l'historique est éliminée, les besoins de stockage des clients continueront d'augmenter d'environ 50 Go par an, car l'état (, le solde des comptes, le code des contrats, etc. ) continuent d'augmenter.
Il existe deux principales catégories de solutions :
État partiel expiré : diviser l'état en blocs, ne stocker que les blocs de données récemment consultés, les autres données ne conserveront qu'un engagement de 32 octets.
Expiration d'état basée sur le cycle d'adresse : ajout régulier de nouveaux arbres d'état vides, l'ancien arbre est gelé. Les nœuds complets ne stockent que les deux derniers arbres.
Ces deux solutions ont leurs avantages et leurs inconvénients, et il est nécessaire de trouver un équilibre entre la complexité, la convivialité pour les utilisateurs et la convivialité pour les développeurs. Quelle que soit la solution adoptée, il faudra résoudre le problème de l'expansion ou de la contraction de l'espace d'adresses, ce qui constitue en soi un énorme défi.
Nettoyage des fonctionnalités
Pour réduire la complexité du protocole, nous devons supprimer certaines fonctionnalités inutiles ou peu utilisées :
Remplacer complètement l'encodage RLP par SSZ
Supprimer l'ancien type de transaction
Mécanisme de journal simplifié
Supprimer le mécanisme du comité de synchronisation de la chaîne de balises
Format de données unifié
Simplification du mécanisme de gas
Supprimer certaines précompilations
Annuler la visibilité du gaz
Améliorer la capacité d'analyse statique
Lors de la réalisation de ces simplifications, il est nécessaire de peser le degré de simplification/vitesse contre la rétrocompatibilité. Un processus standardisé devrait être établi pour traiter les modifications rétrocompatibles non urgentes.
Une méthode de simplification plus radicale consiste à transformer une grande partie du contenu du protocole en code de contrat. Par exemple, simplifier Ethereum L1 pour qu'il ne contienne que la chaîne de balises, introduire une machine virtuelle minimale, puis reconstruire l'EVM dessus en tant que premier agrégat. Cette méthode peut simplifier considérablement le protocole, mais sa mise en œuvre est plus difficile.
Dans l'ensemble, grâce à ces mesures, nous pouvons réduire considérablement la complexité et les besoins de stockage d'Ethereum tout en préservant les valeurs fondamentales de l'Éther, établissant ainsi une base pour un développement durable à long terme. Cela nécessite un effort commun de la part de la communauté pour trouver un équilibre entre l'innovation technologique et la compatibilité ascendante.
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.
6 J'aime
Récompense
6
8
Partager
Commentaire
0/400
BTCRetirementFund
· 07-22 21:24
C'est exactement ce qu'il faut simplifier!
Voir l'originalRépondre0
GraphGuru
· 07-22 00:00
Que faire si je n'ai pas d'argent pour upgrader la machine ?
Voir l'originalRépondre0
failed_dev_successful_ape
· 07-21 23:58
Eh bien, tant de changements.
Voir l'originalRépondre0
DoomCanister
· 07-21 23:56
Continue à faire des bêtises et c'est tout.
Voir l'originalRépondre0
DeFiVeteran
· 07-21 23:54
Le développement technologique doit être prudent.
Voir l'originalRépondre0
BridgeTrustFund
· 07-21 23:46
La mise à niveau du Mainnet doit être faite lentement.
Voir l'originalRépondre0
Token_Sherpa
· 07-21 23:39
mdr un autre plan de "optimisation"... j'espère que ce n'est pas juste du ponzinomics déguisé
Feuille de route de développement à long terme d'Ethereum : optimisation du stockage, simplification du protocole, amélioration de l'efficacité
Vers un Ethereum plus simple et plus efficace
Un des grands défis auxquels Ethereum est confronté est de savoir comment réduire la complexité et les besoins de stockage à long terme, tout en maintenant la durabilité et les caractéristiques de décentralisation de la blockchain. Cela nécessite que nous agissions dans plusieurs domaines clés :
Historique expiré
Actuellement, un nœud Ethereum complètement synchronisé nécessite environ 1,1 To d'espace de stockage, dont la majeure partie est utilisée pour stocker des données historiques. Même si la limite de gaz reste inchangée, la taille des nœuds continuera d'augmenter de plusieurs centaines de Go chaque année.
La solution consiste à établir un réseau pair-à-pair composé de nœuds Ethereum pour stocker de manière distribuée les anciennes données. Chaque nœud n'a besoin de stocker que les données des 18 derniers jours, les données plus anciennes pouvant être récupérées via le réseau. Cela permet de réduire considérablement la charge de stockage d'un nœud individuel.
Les principales tâches liées à l'expiration des enregistrements historiques comprennent :
Construire et intégrer des solutions de stockage distribué spécifiques, comme l'introduction de bibliothèques torrent existantes ou du réseau Portal natif d'Ethereum.
Activer EIP-4444, limiter la durée de stockage des données historiques par les nœuds.
Décider comment traiter les données historiques "anciennes", s'il faut complètement dépendre des nœuds d'archivage existants ou construire un réseau de stockage distribué plus robuste.
État expiré
Même si la nécessité de stocker l'historique est éliminée, les besoins de stockage des clients continueront d'augmenter d'environ 50 Go par an, car l'état (, le solde des comptes, le code des contrats, etc. ) continuent d'augmenter.
Il existe deux principales catégories de solutions :
État partiel expiré : diviser l'état en blocs, ne stocker que les blocs de données récemment consultés, les autres données ne conserveront qu'un engagement de 32 octets.
Expiration d'état basée sur le cycle d'adresse : ajout régulier de nouveaux arbres d'état vides, l'ancien arbre est gelé. Les nœuds complets ne stockent que les deux derniers arbres.
Ces deux solutions ont leurs avantages et leurs inconvénients, et il est nécessaire de trouver un équilibre entre la complexité, la convivialité pour les utilisateurs et la convivialité pour les développeurs. Quelle que soit la solution adoptée, il faudra résoudre le problème de l'expansion ou de la contraction de l'espace d'adresses, ce qui constitue en soi un énorme défi.
Nettoyage des fonctionnalités
Pour réduire la complexité du protocole, nous devons supprimer certaines fonctionnalités inutiles ou peu utilisées :
Lors de la réalisation de ces simplifications, il est nécessaire de peser le degré de simplification/vitesse contre la rétrocompatibilité. Un processus standardisé devrait être établi pour traiter les modifications rétrocompatibles non urgentes.
Une méthode de simplification plus radicale consiste à transformer une grande partie du contenu du protocole en code de contrat. Par exemple, simplifier Ethereum L1 pour qu'il ne contienne que la chaîne de balises, introduire une machine virtuelle minimale, puis reconstruire l'EVM dessus en tant que premier agrégat. Cette méthode peut simplifier considérablement le protocole, mais sa mise en œuvre est plus difficile.
Dans l'ensemble, grâce à ces mesures, nous pouvons réduire considérablement la complexité et les besoins de stockage d'Ethereum tout en préservant les valeurs fondamentales de l'Éther, établissant ainsi une base pour un développement durable à long terme. Cela nécessite un effort commun de la part de la communauté pour trouver un équilibre entre l'innovation technologique et la compatibilité ascendante.