Un défi majeur auquel Ethereum est confronté est de savoir comment réduire la complexité et les besoins de stockage à long terme, tout en maintenant la durabilité et la décentralisation de la chaîne. Pour que Ethereum puisse perdurer à long terme, nous devons exercer une forte contre-pression sur la complexité et l'expansion, afin de réduire la complexité et l'expansion au fil du temps. Mais en même temps, nous devons préserver cette propriété clé de durabilité de la blockchain.
Les principaux objectifs de purification incluent :
Réduire les exigences de stockage des clients en diminuant ou en éliminant la nécessité 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.
Historique expiré
résout quel problème ?
À ce jour, un nœud Ethereum complètement synchronisé nécessite environ 1,1 To d'espace disque pour exécuter le client, et plusieurs centaines de Go supplémentaires sont nécessaires pour le client de consensus. La grande majorité de ces données sont historiques, et même si la taille des blocs reste constante, la taille des nœuds continuera d'augmenter de plusieurs centaines de Go chaque année.
Qu'est-ce que c'est, comment ça fonctionne ?
Une caractéristique clé de simplification du problème de stockage historique est que, puisque chaque bloc est lié au bloc précédent par un hachage, il suffit de parvenir à un consensus sur le présent pour parvenir à un consensus sur le passé. Cela nous offre de nombreuses options sur la manière de stocker les enregistrements historiques. Un choix naturel est un réseau où chaque nœud ne stocke qu'une petite partie des données.
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 ne stockent qu'environ 6 mois. Les blobs ne sont stockés que pendant environ 18 jours. L'EIP-4444 vise à introduire une période de stockage d'un an pour les blocs historiques et les reçus. L'objectif à long terme est d'établir une période unifiée ( qui pourrait durer environ 18 jours ), pendant laquelle chaque nœud serait responsable du stockage de tout, puis de créer un réseau pair à pair composé de nœuds Ethereum pour stocker les anciennes données de manière distribuée.
Que faut-il encore faire, que faut-il peser ?
Les principales tâches restantes comprennent la construction et l'intégration d'une solution distribuée concrète pour stocker l'historique. La solution la plus simple consiste à introduire une bibliothèque torrent existante ou une solution native d'Ethereum appelée réseau Portal. Le principal compromis concerne la manière dont nous nous efforçons de fournir des données historiques "anciennes". La solution la plus simple est 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. Une voie plus difficile mais plus sécurisée consiste d'abord à construire et à intégrer un réseau torrent pour stocker l'historique de manière distribuée.
comment interagit avec les autres parties de la feuille de route ?
Si nous voulons que l'exécution ou le démarrage 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. Ce n'est qu'en réalisant l'absence d'état et l'EIP-4444 que nous pourrons réaliser la vision de faire fonctionner un nœud Ethereum sur une montre intelligente et de pouvoir le configurer en seulement quelques minutes.
État d'expiration
résout quel problème ?
Même si nous avons éliminé le besoin de stocker l'historique côté client, les besoins de stockage du client continueront de croître, d'environ 50 Go par an, car l'état continue de croître. Les utilisateurs peuvent payer des frais uniques, ce qui permettra de peser sur les clients Ethereum actuels et futurs.
Qu'est-ce que c'est, comment ça fonctionne ?
Aujourd'hui, lors de la création d'un nouvel objet d'état, cet objet d'état reste dans cet état de manière permanente. 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 d'une manière qui atteigne trois objectifs : efficacité, convivialité pour les utilisateurs et convivialité pour les développeurs.
Actuellement, il existe deux types de "solutions connues comme étant les moins mauvaises" :
Solutions de résolution des états partiels à expiration
Suggestions de date d'expiration de l'état basé sur le cycle d'adresse
Certaines propositions d'état expirées divisent l'état en blocs. Chacun stocke de manière permanente la "carte principale", où les blocs sont vides ou non vides. Les données dans chaque bloc ne sont stockées que si ces données ont été récemment consultées. Il existe un mécanisme de "résurrection" si les données ne sont plus stockées.
La conception basée sur le cycle d'adresse utilise une liste d'arbres d'état en constante augmentation, et tout état lu ou écrit sera conservé dans le dernier arbre d'état. Chaque période ( par exemple : une nouvelle arbre d'état vide est ajoutée une fois par an ). Les anciens arbres sont tous gelés. Les nœuds complets ne stockent que les deux derniers arbres.
Que faut-il encore faire, quels sont les compromis à considérer ?
Je pense qu'il y a quatre voies possibles à l'avenir :
Nous restons sans état et ne faisons jamais entrer l'expiration de l'état.
Nous acceptons un taux de croissance de la taille de l'état permanent beaucoup plus bas mais toujours non nul, en procédant à une expiration partielle de l'état.
Nous effectuons l'expiration de l'état par l'extension de l'espace d'adresses.
Nous effectuons l'expiration de l'état par la réduction de l'espace d'adresses.
Un point important est que, que le plan d'expiration basé sur le changement de format d'adresse soit ou non mis en œuvre, il est finalement nécessaire de résoudre le problème de l'expansion et de la contraction de l'espace d'adresses.
Nettoyage des fonctionnalités
résout quel problème ?
L'une des conditions préalables clés à la sécurité, à l'accessibilité et à la neutralité de confiance est la simplicité. Si le protocole est esthétique et simple, cela réduit la probabilité d'erreurs. Cela augmente les chances que de nouveaux développeurs puissent participer à n'importe quelle partie. Il est plus susceptible d'être juste et plus facile de résister aux intérêts particuliers. Malheureusement, le protocole, comme tout système social, a tendance à devenir plus complexe avec le temps par défaut.
Qu'est-ce que c'est, comment ça fonctionne ?
Il n'y a pas de solution unique majeure qui puisse réduire la complexité du protocole ; la nature du problème est qu'il existe de nombreuses petites solutions. Quelques exemples clés incluent :
Conversion RLP → SSZ
Supprimer l'ancien type de transaction
LOG Réforme
Suppression définitive du mécanisme du comité de synchronisation de la chaîne de balises
Format de données unifié
Supprimer le comité de la chaîne de balises
Supprimer l'ordre des octets mélangés
Simplification du mécanisme de gaz
Supprimer le précompilé
Suppression de la visibilité des gas
Amélioration de l'analyse statique
que faut-il encore faire, quels compromis faut-il envisager ?
Le principal compromis de cette simplification fonctionnelle est le degré et la rapidité de notre simplification par rapport à la compatibilité ascendante. La question sociale plus large est de créer un pipeline standardisé pour effectuer des modifications qui ne sont pas urgentes et qui rompent la compatibilité ascendante.
Le format d'objet EVM ( EOF ) est un ensemble de modifications majeures proposées pour l'EVM. Son avantage est qu'il crée un chemin naturel pour ajouter de nouvelles fonctionnalités à l'EVM et encourage la migration vers une version plus stricte de l'EVM avec de meilleures garanties. Son inconvénient est qu'il augmente considérablement la complexité du protocole, à moins que nous ne trouvions un moyen de finalement déprécier et supprimer l'ancienne EVM.
Une stratégie de simplification d'Ethereum plus radicale consiste à maintenir le protocole inchangé, mais à transférer la majeure partie de ses fonctionnalités de protocole vers le code des contrats. La version la plus extrême serait de faire en sorte qu'Ethereum L1 soit "techniquement" uniquement la chaîne de balisage, et d'introduire une machine virtuelle minimale, permettant à d'autres de créer leurs propres agrégations. Ensuite, l'EVM deviendrait le premier de ces agrégations.
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.
16 J'aime
Récompense
16
4
Partager
Commentaire
0/400
SchroedingersFrontrun
· Il y a 14h
L'optimisation du stockage est vraiment nécessaire.
Le chemin de purification de l'Ethereum : un défi à long terme pour réduire la complexité et les besoins de stockage
L'avenir potentiel d'Ethereum : purification
Un défi majeur auquel Ethereum est confronté est de savoir comment réduire la complexité et les besoins de stockage à long terme, tout en maintenant la durabilité et la décentralisation de la chaîne. Pour que Ethereum puisse perdurer à long terme, nous devons exercer une forte contre-pression sur la complexité et l'expansion, afin de réduire la complexité et l'expansion au fil du temps. Mais en même temps, nous devons préserver cette propriété clé de durabilité de la blockchain.
Les principaux objectifs de purification incluent :
Réduire les exigences de stockage des clients en diminuant ou en éliminant la nécessité 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.
Historique expiré
résout quel problème ?
À ce jour, un nœud Ethereum complètement synchronisé nécessite environ 1,1 To d'espace disque pour exécuter le client, et plusieurs centaines de Go supplémentaires sont nécessaires pour le client de consensus. La grande majorité de ces données sont historiques, et même si la taille des blocs reste constante, la taille des nœuds continuera d'augmenter de plusieurs centaines de Go chaque année.
Qu'est-ce que c'est, comment ça fonctionne ?
Une caractéristique clé de simplification du problème de stockage historique est que, puisque chaque bloc est lié au bloc précédent par un hachage, il suffit de parvenir à un consensus sur le présent pour parvenir à un consensus sur le passé. Cela nous offre de nombreuses options sur la manière de stocker les enregistrements historiques. Un choix naturel est un réseau où chaque nœud ne stocke qu'une petite partie des données.
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 ne stockent qu'environ 6 mois. Les blobs ne sont stockés que pendant environ 18 jours. L'EIP-4444 vise à introduire une période de stockage d'un an pour les blocs historiques et les reçus. L'objectif à long terme est d'établir une période unifiée ( qui pourrait durer environ 18 jours ), pendant laquelle chaque nœud serait responsable du stockage de tout, puis de créer un réseau pair à pair composé de nœuds Ethereum pour stocker les anciennes données de manière distribuée.
Que faut-il encore faire, que faut-il peser ?
Les principales tâches restantes comprennent la construction et l'intégration d'une solution distribuée concrète pour stocker l'historique. La solution la plus simple consiste à introduire une bibliothèque torrent existante ou une solution native d'Ethereum appelée réseau Portal. Le principal compromis concerne la manière dont nous nous efforçons de fournir des données historiques "anciennes". La solution la plus simple est 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. Une voie plus difficile mais plus sécurisée consiste d'abord à construire et à intégrer un réseau torrent pour stocker l'historique de manière distribuée.
comment interagit avec les autres parties de la feuille de route ?
Si nous voulons que l'exécution ou le démarrage 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. Ce n'est qu'en réalisant l'absence d'état et l'EIP-4444 que nous pourrons réaliser la vision de faire fonctionner un nœud Ethereum sur une montre intelligente et de pouvoir le configurer en seulement quelques minutes.
État d'expiration
résout quel problème ?
Même si nous avons éliminé le besoin de stocker l'historique côté client, les besoins de stockage du client continueront de croître, d'environ 50 Go par an, car l'état continue de croître. Les utilisateurs peuvent payer des frais uniques, ce qui permettra de peser sur les clients Ethereum actuels et futurs.
Qu'est-ce que c'est, comment ça fonctionne ?
Aujourd'hui, lors de la création d'un nouvel objet d'état, cet objet d'état reste dans cet état de manière permanente. 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 d'une manière qui atteigne trois objectifs : efficacité, convivialité pour les utilisateurs et convivialité pour les développeurs.
Actuellement, il existe deux types de "solutions connues comme étant les moins mauvaises" :
Certaines propositions d'état expirées divisent l'état en blocs. Chacun stocke de manière permanente la "carte principale", où les blocs sont vides ou non vides. Les données dans chaque bloc ne sont stockées que si ces données ont été récemment consultées. Il existe un mécanisme de "résurrection" si les données ne sont plus stockées.
La conception basée sur le cycle d'adresse utilise une liste d'arbres d'état en constante augmentation, et tout état lu ou écrit sera conservé dans le dernier arbre d'état. Chaque période ( par exemple : une nouvelle arbre d'état vide est ajoutée une fois par an ). Les anciens arbres sont tous gelés. Les nœuds complets ne stockent que les deux derniers arbres.
Que faut-il encore faire, quels sont les compromis à considérer ?
Je pense qu'il y a quatre voies possibles à l'avenir :
Un point important est que, que le plan d'expiration basé sur le changement de format d'adresse soit ou non mis en œuvre, il est finalement nécessaire de résoudre le problème de l'expansion et de la contraction de l'espace d'adresses.
Nettoyage des fonctionnalités
résout quel problème ?
L'une des conditions préalables clés à la sécurité, à l'accessibilité et à la neutralité de confiance est la simplicité. Si le protocole est esthétique et simple, cela réduit la probabilité d'erreurs. Cela augmente les chances que de nouveaux développeurs puissent participer à n'importe quelle partie. Il est plus susceptible d'être juste et plus facile de résister aux intérêts particuliers. Malheureusement, le protocole, comme tout système social, a tendance à devenir plus complexe avec le temps par défaut.
Qu'est-ce que c'est, comment ça fonctionne ?
Il n'y a pas de solution unique majeure qui puisse réduire la complexité du protocole ; la nature du problème est qu'il existe de nombreuses petites solutions. Quelques exemples clés incluent :
que faut-il encore faire, quels compromis faut-il envisager ?
Le principal compromis de cette simplification fonctionnelle est le degré et la rapidité de notre simplification par rapport à la compatibilité ascendante. La question sociale plus large est de créer un pipeline standardisé pour effectuer des modifications qui ne sont pas urgentes et qui rompent la compatibilité ascendante.
Le format d'objet EVM ( EOF ) est un ensemble de modifications majeures proposées pour l'EVM. Son avantage est qu'il crée un chemin naturel pour ajouter de nouvelles fonctionnalités à l'EVM et encourage la migration vers une version plus stricte de l'EVM avec de meilleures garanties. Son inconvénient est qu'il augmente considérablement la complexité du protocole, à moins que nous ne trouvions un moyen de finalement déprécier et supprimer l'ancienne EVM.
Une stratégie de simplification d'Ethereum plus radicale consiste à maintenir le protocole inchangé, mais à transférer la majeure partie de ses fonctionnalités de protocole vers le code des contrats. La version la plus extrême serait de faire en sorte qu'Ethereum L1 soit "techniquement" uniquement la chaîne de balisage, et d'introduire une machine virtuelle minimale, permettant à d'autres de créer leurs propres agrégations. Ensuite, l'EVM deviendrait le premier de ces agrégations.