L'histoire d'Ethereum se compose de tous les blocs et transactions exécutés tout au long de sa vie. Ces données sont nécessaires pour synchroniser la chaîne depuis le bloc initial jusqu'à son état actuel. La croissance historique fait référence à l'accumulation de nouveaux blocs et transactions au fil du temps.
La figure 1 montre la relation entre la croissance historique, diverses métriques de protocole et les limitations matérielles du nœud Ethereum. Contrairement à la croissance de l'état, la croissance historique est limitée par un ensemble différent de limitations matérielles. Cette croissance met la pression sur l'E/S du réseau car de nouveaux blocs et transactions doivent être transmis à travers le réseau. Il sollicite également l'espace de stockage du nœud, car chaque nœud Ethereum stocke une copie complète de l'historique. Si la croissance historique dépasse ces limitations matérielles, les nœuds ne pourront plus atteindre un consensus stable avec leurs pairs. Pour un aperçu de la croissance de l'état et d'autres goulots d'étranglement de mise à l'échelle, veuillez vous référer àPartie 1de cette série.
Figure 1: Ethereum expansion bottleneck
Jusqu'à récemment, la majeure partie du débit du réseau de chaque nœud était utilisée pour transmettre des enregistrements historiques (par exemple, nouveaux blocs et transactions). Cela a changé avec l'introduction de blobs dans le Dencunfork dur. Les blobs constituent désormais une partie importante de l'activité du réseau de nœuds. Cependant, les blobs ne sont pas considérés comme faisant partie de l'historique car 1) les nœuds les stockent pendant seulement 2 semaines avant de les supprimer, et 2) ils ne sont pas nécessaires pour rejouer la chaîne depuis Genesis. En raison du point (1), les blobs n'augmentent pas de manière significative la charge de stockage de chaque nœud Ethereum. Nous discuterons des blobs plus en détail plus tard dans cet article.
Dans cet article, nous nous concentrerons sur la croissance des données historiques et sa relation avec la croissance de l'état. Comme la croissance de l'état et la croissance historique partagent certaines contraintes matérielles communes, ce sont des problèmes interdépendants; traiter l'un peut aider à atténuer l'autre.
La figure 2 montre le taux de croissance historique au fil du temps depuis la genèse d'Ethereum. Chaque barre verticale représente la croissance d'un mois. L'axe Y représente le nombre de Go ajoutés à l'histoire ce mois-là. Les transactions sont catégorisées par leur "adresse de destination" et leur taille est déterminée en utilisant leur RLPreprésentation en octet. Les contrats qui ne peuvent pas être facilement identifiés sont classés comme "inconnus". La catégorie "autre" comprend une longue liste de catégories plus petites comme l'infrastructure et les jeux.
Plusieurs conclusions clés peuvent être tirées de ce graphique :
Le montant des données historiques générées par chaque catégorie de contrat révèle comment les schémas d'utilisation d'Ethereum ont évolué au fil du temps. La figure 3 montre les contributions relatives des différentes catégories de contrat. Ceci utilise les mêmes données que la figure 2, normalisées à 100%.
Les données révèlent quatre époques distinctes de modèles d'utilisation d'Ethereum :
Au début de l'ère (violet) : Au cours des premières années d'Ethereum, l'activité on-chain était minimale. La plupart de ces premiers contrats sont maintenant difficiles à identifier et sont étiquetés comme "inconnus" dans le graphique.
Ère ERC-20 (Vert) : Le norme ERC-20a été finalisé fin 2015 mais n'a pas connu un essor significatif avant 2017 et 2018. En 2019, les contrats ERC-20 sont devenus la plus grande catégorie de croissance historique.
Ère DEX/DeFi (Marron) : Les contrats DEX et DeFi sont apparus en chaîne dès 2016 et ont commencé à attirer l'attention en 2017. Cependant, ils ne sont pas devenus la plus grande catégorie historiquejusqu'à l'été DeFi de 2020Les contrats DeFi et DEX ont atteint plus de 50 % de croissance historique à divers moments en 2021 et 2022.
Ère Rollup (Gris) : Début 2023, les Rollups de L2 ont commencé à exécuter de manière cohérenteplus de transactions que le mainnet.Cela a coïncidé avec leurs contrats générant une grande partie des données historiques, représentant environ les deux tiers de la croissance historique d'Éthereum dans les mois précédant Dencun.
Chaque ère représente des schémas d'utilisation de plus en plus complexes sur Ethereum. Avec le temps, cette complexité peut être vue comme une forme de mise à l'échelle d'Ethereum, non capturée par des métriques simples comme les transactions par seconde.
Dans les données les plus récentes (avril 2024), les rollups ne génèrent plus la majorité des enregistrements historiques. Il n'est pas clair si la croissance historique future sera dominée par les DEX et DeFi ou si de nouveaux schémas d'utilisation émergeront.
L'introduction des blobs dans la mise à niveau Dencun a considérablement modifié la dynamique de la croissance historique, permettant aux Rollups d'utiliser des blobs bon marché au lieu d'enregistrements historiques pour poster des données. La figure 4 se concentre sur le taux de croissance historique autour de la date de la mise à niveau Dencun. Ce graphique est similaire à la figure 2, mais chaque barre verticale représente un jour au lieu d'un mois.
Plusieurs conclusions clés peuvent être tirées de ce graphique :
La croissance historique des rollups a diminué d'environ deux tiers depuis Dencun : la plupart des rollups ont cessé d'utiliser les données d'appel au profit des blobs, réduisant ainsi de manière significative la quantité de données historiques qu'ils génèrent. Cependant, en avril 2024, certains rollupsn'ont pas encore basculé des données d'appel vers des blobs.
La croissance historique totale a diminué d'environ un tiers depuis Dencun: Dencun a principalement réduit la croissance historique des rollups. La croissance historique des autres catégories de contrats a légèrement augmenté. Même après Dencun, la croissance historique reste d'environ huit fois celle de la croissance de l'état (détails dans la section suivante).
Malgré la réduction de la croissance historique, les blobs restent une nouvelle addition à Ethereum. Il n'est actuellement pas clair où la croissance historique se stabilisera en présence de blobs.
Augmenter la limite de gaz augmentera le taux de croissance historique. Par conséquent, les propositions visant à augmenter la limite de gaz (comme Pompe le Gaz) doit considérer la relation entre la croissance historique et les goulots d'étranglement matériels sur chaque nœud.
Pour déterminer un taux de croissance historique acceptable, il est utile d'examiner d'abord combien de temps les réseaux de nœuds modernes et le matériel de nœuds de stockage peuvent maintenir l'état actuel. Le matériel du réseau peut maintenir le statu quo indéfiniment car les taux de croissance historiques sont peu susceptibles de revenir aux niveaux d'avant Dencun avant les augmentations de la limite de gaz. Cependant, la charge de stockage des enregistrements historiques augmente avec le temps. Selon les politiques de stockage actuelles, le disque de stockage de chaque nœud sera finalement rempli d'histoire.
La figure 5 illustre la charge de stockage des nœuds Ethereum au fil du temps et prévoit également comment cette charge pourrait augmenter au cours des 3 prochaines années. Les prédictions sont faites en utilisant les taux de croissance à partir d'avril 2024. Ce taux pourrait augmenter ou diminuer à l'avenir en raison de changements dans les schémas d'utilisation ou les limites de gaz.
Plusieurs conclusions clés peuvent être tirées de ce graphique:
L'espace de stockage utilisé par l'histoire est d'environ trois fois celui de l'État : cet écart augmentera au fil du temps car le taux de croissance de l'histoire est d'environ huit fois celui de l'État.
Seuil critique autour de 1,8 TiB : De nombreux nœuds seront contraints de mettre à niveau leurs disques de stockage à ce stade. Un disque de 2 To, une taille courante, ne fournit que 1,8 TiB d'espace utilisable. Notez que les TB (térabits) et TiB (tébibytes, = 1024^4 octets) sont des unités différentes. Pour de nombreux opérateurs de nœuds, le seuil critique "réel" est encore plus bas car les validateurs doivent exécuter un client de consensus ainsi qu'un client d'exécution post-fusion.
Seuil atteint dans 2-3 ans : Toute augmentation de la limite de gaz accélérera ce calendrier. Atteindre ce seuil imposera un fardeau important de maintenance aux opérateurs de nœuds, nécessitant l'achat de matériel supplémentaire, tel qu'un Disque NVME de 300 $.
Stockage séparé pour les données historiques : Contrairement aux données d'état, les données historiques sont en lecture seule et sont beaucoup moins souvent consultées. Par conséquent, elles pourraient théoriquement être stockées séparément des données d'état sur des supports de stockage moins chers. Certains clients, comme Geth, déjà prendre en charge cette séparation.
Le réseau IO en tant que limitation matérielle : Outre la capacité de stockage, le réseau IO est une autre contrainte matérielle majeure pour la croissance historique. Contrairement à la capacité de stockage, les limites du réseau IO ne poseront pas de problèmes immédiats pour les nœuds, mais deviendront significatives pour les futures augmentations de la limite de gaz.
Pour comprendre dans quelle mesure la capacité de réseau d'un nœud Ethereum typique peut prendre en charge une croissance historique, il est nécessaire de décrire la relation entre la croissance historique et diverses métriques de santé du réseau, telles que le taux de réorganisation, les manques de créneaux, le manque de finalité, les attestations manquantes, les manques de comité de synchronisation et les retards de proposition de bloc. Analyser ces métriques dépasse le cadre de cet article, mais elles peuvent être trouvées dans des enquêtes antérieures sur la santé de la couche de consensus [1] [2] [3].4]. De plus, la Fondation Ethereum @ethpandaops/xatu-overview">Le projet Xatu a construit des ensembles de données publics pour faciliter de telles analyses.
La croissance historique est un problème plus facile à aborder que la croissance de l'État. Le proposé EIP-4444résout presque complètement ce problème. Cet EIP modifie l'exigence pour chaque nœud de conserver l'ensemble de l'historique d'Ethereum à ne conserver qu'un an d'historique. Une fois EIP-4444 mis en œuvre, même avec des augmentations significatives de la limite de gaz à long terme, le stockage des données ne sera plus un goulot d'étranglement pour l'évolutivité d'Ethereum. EIP-4444 est essentiel pour la durabilité à long terme du réseau, sinon, les données historiques augmenteront suffisamment rapidement pour nécessiter des mises à niveau régulières du matériel pour les nœuds du réseau.
La figure 6 montre comment l'EIP-4444 affecterait la charge de stockage de chaque nœud au cours des 3 prochaines années. Il s'agit du même que la figure 4, avec l'ajout de lignes plus fines représentant la charge de stockage après la mise en œuvre de l'EIP-4444.
Plusieurs conclusions clés peuvent être tirées de ce graphique :
EIP-4444 Réduira de moitié la charge de stockage actuelle : la charge de stockage passera de 1,2 TiB à 633 GiB.
EIP-4444 Stabilisera le fardeau de stockage historique : En supposant un taux de croissance historique constant, les données historiques seront abandonnées au même rythme qu'elles sont générées.
Après l'EIP-4444, il faudra de nombreuses années pour que le fardeau de stockage atteigne le niveau actuel : cela est dû à la croissance de l'état, qui est plus lente que la croissance historique, sera le seul facteur augmentant le fardeau de stockage.
EIP-4444 imposera toujours une certaine charge de stockage en raison d'une année de données historiques : Cependant, cette charge sera gérable même si Ethereum se déploie à l'échelle mondiale. Une fois que la méthode de traitement des données historiques se révèle fiable, la période de rétention d'un an dans l'EIP-4444 pourrait être raccourcie à quelques mois, semaines, voire moins.
EIP-4444 soulève la question : si les nœuds Ethereum ne préservent pas eux-mêmes l'historique, comment devrait-il être préservé ? L'historique est crucial pour la vérification, la comptabilité et l'analyse d'Ethereum, il doit donc être préservé. Heureusement, la préservation de l'historique est simple, ne nécessitant que 1/n de fournisseurs de données honnêtes, par rapport au problème de consensus sur l'état, qui nécessite 1/3 à 2/3 de participants honnêtes. Les opérateurs de nœuds peuvent vérifier l'authenticité de tout ensemble de données historiques en : 1) rejouant toutes les transactions depuis la Genèse ; et 2) vérifiant si ces transactions reproduisent le même état racine que l'extrémité actuelle de la chaîne.
Il existe plusieurs méthodes pour préserver l'histoire, chacune devant être déployée en parallèle pour maximiser les chances de préservation :
Torrents / P2P: Torrentssont la méthode la plus simple et la plus robuste. Les nœuds Ethereum peuvent périodiquement regrouper des parties de l'historique et les partager sous forme de fichiers torrent publics. Par exemple, un nœud pourrait créer un nouveau fichier torrent d'historique tous les 100 000 blocs. Certains clients de nœuds, comme Erigon, effectuent déjà ce processus de manière non standardisée. Pour standardiser ce processus, tous les clients de nœuds doivent utiliser le même format de données, les mêmes paramètres et le même réseau P2P. Les nœuds peuvent choisir de participer à ce réseau en fonction de leur capacité de stockage et de bande passante. L'avantage des torrents est l'utilisation de normes ouvertes matures prises en charge par un grand écosystème d'outils de données.
Réseau de Portail: Le Réseau de Portail est un nouveau réseau conçu spécifiquement pour héberger des données Ethereum. Cette approche est similaire aux torrents mais offre des fonctionnalités supplémentaires pour faciliter la vérification des données. L'avantage du Portal Network est que ces couches supplémentaires de vérification offrent aux clients légers des utilitaires de vérification et de requête efficaces pour les ensembles de données partagés.
Hébergement Cloud : Services de stockage Cloud comme AWS S3 ou Cloudflare R2offrir des options bon marché et performantes pour la préservation de l'histoire. Cependant, cette méthode comporte plus de risques juridiques et opérationnels pour l'entreprise, car ces services cloud pourraient ne pas toujours être disposés ou capables d'héberger des données de cryptomonnaie.
Les défis restants en matière de mise en œuvre sont plus sociaux que techniques. La communauté Ethereum doit coordonner les détails de mise en œuvre spécifiques afin qu'ils puissent être directement intégrés dans chaque client de nœud. Notamment, la synchronisation complète à partir de Genesis (au lieu de la synchronisation par snapshot) nécessitera de récupérer l'historique auprès des fournisseurs de données historiques plutôt que des nœuds Ethereum. Ces changements ne nécessitent pas de hard fork et peuvent être mis en œuvre avant le prochain hard fork d'Ethereum, Pectra.
Les L2 peuvent également utiliser toutes ces méthodes pour préserver les données du blob qu'ils publient sur le mainnet. La préservation des blobs est 1) plus difficile en raison du volume total des données plus important; 2) moins critique car les blobs ne sont pas nécessaires pour rejouer l'historique du mainnet. Cependant, la préservation des blobs est nécessaire pour que chaque L2 rejoue sa propre histoire. Par conséquent, une forme de préservation des blobs est cruciale pour l'ensemble de l'écosystème Ethereum. De plus, si les L2 développent une infrastructure de stockage de blobs robuste, ils peuvent également stocker facilement les données historiques de L1.
Une comparaison directe des ensembles de données stockés par différentes configurations de nœuds avant et après l'EIP-4444 est utile. La Figure 7 montre la charge de stockage des types de nœuds Ethereum. Les données d'état comprennent les comptes et les contrats, les données historiques comprennent les blocs et les transactions, et les données d'archive sont un ensemble d'index de données facultatifs. Les octets dans le tableau sont basés sur des instantanés récents de reth, mais les chiffres devraient être globalement comparables à ceux des autres clients de nœuds.
Figure 7: Charge de stockage des types de nœuds Ethereum
En langue,
Enfin, il existe d'autres propositions d'écosystème visant à limiter le taux de croissance historique plutôt que de simplement s'adapter au taux actuel. Celles-ci sont utiles pour maintenir les limites d'E/S réseau à court terme et les limites de stockage à long terme. Alors que l'EIP-4444 est essentiel à la durabilité à long terme du réseau, ces autres EIP aideront Ethereum à évoluer de manière plus efficace à l'avenir:
EIP-7623: Cette proposition suggère de revoir les données d'appel de tarification afin que les transactions avec des données d'appel excessives deviennent plus coûteuses. Rendre ces schémas d'utilisation plus coûteux encouragera certains à passer des données d'appel aux blobs, réduisant ainsi le taux de croissance historique.
EIP-4488: Cette proposition impose des limites sur le montant total de données d'appel pouvant être incluses dans chaque bloc, appliquant un contrôle plus strict sur le taux de croissance historique.
Ces EIP sont plus faciles à mettre en œuvre que l'EIP-4444 et peuvent servir de mesures intérimaires avant que l'EIP-4444 ne soit prêt pour la production.
L'objectif de cet article est de fournir une compréhension basée sur les données de la manière dont la croissance historique fonctionne et comment aborder ce problème. Une grande partie des données présentées dans cet article ont traditionnellement été difficiles d'accès, c'est pourquoi nous cherchons à offrir des perspectives nouvelles sur le problème de la croissance historique.
La croissance historique en tant que goulot d'étranglement pour la scalabilité d'Ethereum n'a pas reçu une attention suffisante. Même sans augmenter les limites de gaz, la pratique actuelle de conserver l'historique sur Ethereum nécessiterait que de nombreux nœuds mettent à niveau leur matériel dans quelques années. Heureusement, ce n'est pas un problème particulièrement difficile à résoudre. Des solutions claires ont été exposées dans l'EIP-4444. Nous pensons qu'il devrait y avoir une accélération dans la mise en œuvre de cet EIP pour faire place à des augmentations futures des limites de gaz.
Si vous êtes intéressé par la recherche sur la scalabilité d'Ethereum, veuillez contacterstorm@paradigm.xyzetgeorgios@paradigm.xyz.Nous aimerions entendre vos perspectives sur cette question et explorer des collaborations potentielles. Les données et le code utilisés dans cet article peuvent être trouvé surGithub.
Un grand merci à Thomas Thiery、Équipe Beiko、Toni Wahrstaetter、Oliver NordbjergetRoman Krasiukpour leur examen et leurs commentaires. Merci à lAchal Srinivasanpour les chiffres fournis dans la Figure 1 et la Figure 7.
分享
L'histoire d'Ethereum se compose de tous les blocs et transactions exécutés tout au long de sa vie. Ces données sont nécessaires pour synchroniser la chaîne depuis le bloc initial jusqu'à son état actuel. La croissance historique fait référence à l'accumulation de nouveaux blocs et transactions au fil du temps.
La figure 1 montre la relation entre la croissance historique, diverses métriques de protocole et les limitations matérielles du nœud Ethereum. Contrairement à la croissance de l'état, la croissance historique est limitée par un ensemble différent de limitations matérielles. Cette croissance met la pression sur l'E/S du réseau car de nouveaux blocs et transactions doivent être transmis à travers le réseau. Il sollicite également l'espace de stockage du nœud, car chaque nœud Ethereum stocke une copie complète de l'historique. Si la croissance historique dépasse ces limitations matérielles, les nœuds ne pourront plus atteindre un consensus stable avec leurs pairs. Pour un aperçu de la croissance de l'état et d'autres goulots d'étranglement de mise à l'échelle, veuillez vous référer àPartie 1de cette série.
Figure 1: Ethereum expansion bottleneck
Jusqu'à récemment, la majeure partie du débit du réseau de chaque nœud était utilisée pour transmettre des enregistrements historiques (par exemple, nouveaux blocs et transactions). Cela a changé avec l'introduction de blobs dans le Dencunfork dur. Les blobs constituent désormais une partie importante de l'activité du réseau de nœuds. Cependant, les blobs ne sont pas considérés comme faisant partie de l'historique car 1) les nœuds les stockent pendant seulement 2 semaines avant de les supprimer, et 2) ils ne sont pas nécessaires pour rejouer la chaîne depuis Genesis. En raison du point (1), les blobs n'augmentent pas de manière significative la charge de stockage de chaque nœud Ethereum. Nous discuterons des blobs plus en détail plus tard dans cet article.
Dans cet article, nous nous concentrerons sur la croissance des données historiques et sa relation avec la croissance de l'état. Comme la croissance de l'état et la croissance historique partagent certaines contraintes matérielles communes, ce sont des problèmes interdépendants; traiter l'un peut aider à atténuer l'autre.
La figure 2 montre le taux de croissance historique au fil du temps depuis la genèse d'Ethereum. Chaque barre verticale représente la croissance d'un mois. L'axe Y représente le nombre de Go ajoutés à l'histoire ce mois-là. Les transactions sont catégorisées par leur "adresse de destination" et leur taille est déterminée en utilisant leur RLPreprésentation en octet. Les contrats qui ne peuvent pas être facilement identifiés sont classés comme "inconnus". La catégorie "autre" comprend une longue liste de catégories plus petites comme l'infrastructure et les jeux.
Plusieurs conclusions clés peuvent être tirées de ce graphique :
Le montant des données historiques générées par chaque catégorie de contrat révèle comment les schémas d'utilisation d'Ethereum ont évolué au fil du temps. La figure 3 montre les contributions relatives des différentes catégories de contrat. Ceci utilise les mêmes données que la figure 2, normalisées à 100%.
Les données révèlent quatre époques distinctes de modèles d'utilisation d'Ethereum :
Au début de l'ère (violet) : Au cours des premières années d'Ethereum, l'activité on-chain était minimale. La plupart de ces premiers contrats sont maintenant difficiles à identifier et sont étiquetés comme "inconnus" dans le graphique.
Ère ERC-20 (Vert) : Le norme ERC-20a été finalisé fin 2015 mais n'a pas connu un essor significatif avant 2017 et 2018. En 2019, les contrats ERC-20 sont devenus la plus grande catégorie de croissance historique.
Ère DEX/DeFi (Marron) : Les contrats DEX et DeFi sont apparus en chaîne dès 2016 et ont commencé à attirer l'attention en 2017. Cependant, ils ne sont pas devenus la plus grande catégorie historiquejusqu'à l'été DeFi de 2020Les contrats DeFi et DEX ont atteint plus de 50 % de croissance historique à divers moments en 2021 et 2022.
Ère Rollup (Gris) : Début 2023, les Rollups de L2 ont commencé à exécuter de manière cohérenteplus de transactions que le mainnet.Cela a coïncidé avec leurs contrats générant une grande partie des données historiques, représentant environ les deux tiers de la croissance historique d'Éthereum dans les mois précédant Dencun.
Chaque ère représente des schémas d'utilisation de plus en plus complexes sur Ethereum. Avec le temps, cette complexité peut être vue comme une forme de mise à l'échelle d'Ethereum, non capturée par des métriques simples comme les transactions par seconde.
Dans les données les plus récentes (avril 2024), les rollups ne génèrent plus la majorité des enregistrements historiques. Il n'est pas clair si la croissance historique future sera dominée par les DEX et DeFi ou si de nouveaux schémas d'utilisation émergeront.
L'introduction des blobs dans la mise à niveau Dencun a considérablement modifié la dynamique de la croissance historique, permettant aux Rollups d'utiliser des blobs bon marché au lieu d'enregistrements historiques pour poster des données. La figure 4 se concentre sur le taux de croissance historique autour de la date de la mise à niveau Dencun. Ce graphique est similaire à la figure 2, mais chaque barre verticale représente un jour au lieu d'un mois.
Plusieurs conclusions clés peuvent être tirées de ce graphique :
La croissance historique des rollups a diminué d'environ deux tiers depuis Dencun : la plupart des rollups ont cessé d'utiliser les données d'appel au profit des blobs, réduisant ainsi de manière significative la quantité de données historiques qu'ils génèrent. Cependant, en avril 2024, certains rollupsn'ont pas encore basculé des données d'appel vers des blobs.
La croissance historique totale a diminué d'environ un tiers depuis Dencun: Dencun a principalement réduit la croissance historique des rollups. La croissance historique des autres catégories de contrats a légèrement augmenté. Même après Dencun, la croissance historique reste d'environ huit fois celle de la croissance de l'état (détails dans la section suivante).
Malgré la réduction de la croissance historique, les blobs restent une nouvelle addition à Ethereum. Il n'est actuellement pas clair où la croissance historique se stabilisera en présence de blobs.
Augmenter la limite de gaz augmentera le taux de croissance historique. Par conséquent, les propositions visant à augmenter la limite de gaz (comme Pompe le Gaz) doit considérer la relation entre la croissance historique et les goulots d'étranglement matériels sur chaque nœud.
Pour déterminer un taux de croissance historique acceptable, il est utile d'examiner d'abord combien de temps les réseaux de nœuds modernes et le matériel de nœuds de stockage peuvent maintenir l'état actuel. Le matériel du réseau peut maintenir le statu quo indéfiniment car les taux de croissance historiques sont peu susceptibles de revenir aux niveaux d'avant Dencun avant les augmentations de la limite de gaz. Cependant, la charge de stockage des enregistrements historiques augmente avec le temps. Selon les politiques de stockage actuelles, le disque de stockage de chaque nœud sera finalement rempli d'histoire.
La figure 5 illustre la charge de stockage des nœuds Ethereum au fil du temps et prévoit également comment cette charge pourrait augmenter au cours des 3 prochaines années. Les prédictions sont faites en utilisant les taux de croissance à partir d'avril 2024. Ce taux pourrait augmenter ou diminuer à l'avenir en raison de changements dans les schémas d'utilisation ou les limites de gaz.
Plusieurs conclusions clés peuvent être tirées de ce graphique:
L'espace de stockage utilisé par l'histoire est d'environ trois fois celui de l'État : cet écart augmentera au fil du temps car le taux de croissance de l'histoire est d'environ huit fois celui de l'État.
Seuil critique autour de 1,8 TiB : De nombreux nœuds seront contraints de mettre à niveau leurs disques de stockage à ce stade. Un disque de 2 To, une taille courante, ne fournit que 1,8 TiB d'espace utilisable. Notez que les TB (térabits) et TiB (tébibytes, = 1024^4 octets) sont des unités différentes. Pour de nombreux opérateurs de nœuds, le seuil critique "réel" est encore plus bas car les validateurs doivent exécuter un client de consensus ainsi qu'un client d'exécution post-fusion.
Seuil atteint dans 2-3 ans : Toute augmentation de la limite de gaz accélérera ce calendrier. Atteindre ce seuil imposera un fardeau important de maintenance aux opérateurs de nœuds, nécessitant l'achat de matériel supplémentaire, tel qu'un Disque NVME de 300 $.
Stockage séparé pour les données historiques : Contrairement aux données d'état, les données historiques sont en lecture seule et sont beaucoup moins souvent consultées. Par conséquent, elles pourraient théoriquement être stockées séparément des données d'état sur des supports de stockage moins chers. Certains clients, comme Geth, déjà prendre en charge cette séparation.
Le réseau IO en tant que limitation matérielle : Outre la capacité de stockage, le réseau IO est une autre contrainte matérielle majeure pour la croissance historique. Contrairement à la capacité de stockage, les limites du réseau IO ne poseront pas de problèmes immédiats pour les nœuds, mais deviendront significatives pour les futures augmentations de la limite de gaz.
Pour comprendre dans quelle mesure la capacité de réseau d'un nœud Ethereum typique peut prendre en charge une croissance historique, il est nécessaire de décrire la relation entre la croissance historique et diverses métriques de santé du réseau, telles que le taux de réorganisation, les manques de créneaux, le manque de finalité, les attestations manquantes, les manques de comité de synchronisation et les retards de proposition de bloc. Analyser ces métriques dépasse le cadre de cet article, mais elles peuvent être trouvées dans des enquêtes antérieures sur la santé de la couche de consensus [1] [2] [3].4]. De plus, la Fondation Ethereum @ethpandaops/xatu-overview">Le projet Xatu a construit des ensembles de données publics pour faciliter de telles analyses.
La croissance historique est un problème plus facile à aborder que la croissance de l'État. Le proposé EIP-4444résout presque complètement ce problème. Cet EIP modifie l'exigence pour chaque nœud de conserver l'ensemble de l'historique d'Ethereum à ne conserver qu'un an d'historique. Une fois EIP-4444 mis en œuvre, même avec des augmentations significatives de la limite de gaz à long terme, le stockage des données ne sera plus un goulot d'étranglement pour l'évolutivité d'Ethereum. EIP-4444 est essentiel pour la durabilité à long terme du réseau, sinon, les données historiques augmenteront suffisamment rapidement pour nécessiter des mises à niveau régulières du matériel pour les nœuds du réseau.
La figure 6 montre comment l'EIP-4444 affecterait la charge de stockage de chaque nœud au cours des 3 prochaines années. Il s'agit du même que la figure 4, avec l'ajout de lignes plus fines représentant la charge de stockage après la mise en œuvre de l'EIP-4444.
Plusieurs conclusions clés peuvent être tirées de ce graphique :
EIP-4444 Réduira de moitié la charge de stockage actuelle : la charge de stockage passera de 1,2 TiB à 633 GiB.
EIP-4444 Stabilisera le fardeau de stockage historique : En supposant un taux de croissance historique constant, les données historiques seront abandonnées au même rythme qu'elles sont générées.
Après l'EIP-4444, il faudra de nombreuses années pour que le fardeau de stockage atteigne le niveau actuel : cela est dû à la croissance de l'état, qui est plus lente que la croissance historique, sera le seul facteur augmentant le fardeau de stockage.
EIP-4444 imposera toujours une certaine charge de stockage en raison d'une année de données historiques : Cependant, cette charge sera gérable même si Ethereum se déploie à l'échelle mondiale. Une fois que la méthode de traitement des données historiques se révèle fiable, la période de rétention d'un an dans l'EIP-4444 pourrait être raccourcie à quelques mois, semaines, voire moins.
EIP-4444 soulève la question : si les nœuds Ethereum ne préservent pas eux-mêmes l'historique, comment devrait-il être préservé ? L'historique est crucial pour la vérification, la comptabilité et l'analyse d'Ethereum, il doit donc être préservé. Heureusement, la préservation de l'historique est simple, ne nécessitant que 1/n de fournisseurs de données honnêtes, par rapport au problème de consensus sur l'état, qui nécessite 1/3 à 2/3 de participants honnêtes. Les opérateurs de nœuds peuvent vérifier l'authenticité de tout ensemble de données historiques en : 1) rejouant toutes les transactions depuis la Genèse ; et 2) vérifiant si ces transactions reproduisent le même état racine que l'extrémité actuelle de la chaîne.
Il existe plusieurs méthodes pour préserver l'histoire, chacune devant être déployée en parallèle pour maximiser les chances de préservation :
Torrents / P2P: Torrentssont la méthode la plus simple et la plus robuste. Les nœuds Ethereum peuvent périodiquement regrouper des parties de l'historique et les partager sous forme de fichiers torrent publics. Par exemple, un nœud pourrait créer un nouveau fichier torrent d'historique tous les 100 000 blocs. Certains clients de nœuds, comme Erigon, effectuent déjà ce processus de manière non standardisée. Pour standardiser ce processus, tous les clients de nœuds doivent utiliser le même format de données, les mêmes paramètres et le même réseau P2P. Les nœuds peuvent choisir de participer à ce réseau en fonction de leur capacité de stockage et de bande passante. L'avantage des torrents est l'utilisation de normes ouvertes matures prises en charge par un grand écosystème d'outils de données.
Réseau de Portail: Le Réseau de Portail est un nouveau réseau conçu spécifiquement pour héberger des données Ethereum. Cette approche est similaire aux torrents mais offre des fonctionnalités supplémentaires pour faciliter la vérification des données. L'avantage du Portal Network est que ces couches supplémentaires de vérification offrent aux clients légers des utilitaires de vérification et de requête efficaces pour les ensembles de données partagés.
Hébergement Cloud : Services de stockage Cloud comme AWS S3 ou Cloudflare R2offrir des options bon marché et performantes pour la préservation de l'histoire. Cependant, cette méthode comporte plus de risques juridiques et opérationnels pour l'entreprise, car ces services cloud pourraient ne pas toujours être disposés ou capables d'héberger des données de cryptomonnaie.
Les défis restants en matière de mise en œuvre sont plus sociaux que techniques. La communauté Ethereum doit coordonner les détails de mise en œuvre spécifiques afin qu'ils puissent être directement intégrés dans chaque client de nœud. Notamment, la synchronisation complète à partir de Genesis (au lieu de la synchronisation par snapshot) nécessitera de récupérer l'historique auprès des fournisseurs de données historiques plutôt que des nœuds Ethereum. Ces changements ne nécessitent pas de hard fork et peuvent être mis en œuvre avant le prochain hard fork d'Ethereum, Pectra.
Les L2 peuvent également utiliser toutes ces méthodes pour préserver les données du blob qu'ils publient sur le mainnet. La préservation des blobs est 1) plus difficile en raison du volume total des données plus important; 2) moins critique car les blobs ne sont pas nécessaires pour rejouer l'historique du mainnet. Cependant, la préservation des blobs est nécessaire pour que chaque L2 rejoue sa propre histoire. Par conséquent, une forme de préservation des blobs est cruciale pour l'ensemble de l'écosystème Ethereum. De plus, si les L2 développent une infrastructure de stockage de blobs robuste, ils peuvent également stocker facilement les données historiques de L1.
Une comparaison directe des ensembles de données stockés par différentes configurations de nœuds avant et après l'EIP-4444 est utile. La Figure 7 montre la charge de stockage des types de nœuds Ethereum. Les données d'état comprennent les comptes et les contrats, les données historiques comprennent les blocs et les transactions, et les données d'archive sont un ensemble d'index de données facultatifs. Les octets dans le tableau sont basés sur des instantanés récents de reth, mais les chiffres devraient être globalement comparables à ceux des autres clients de nœuds.
Figure 7: Charge de stockage des types de nœuds Ethereum
En langue,
Enfin, il existe d'autres propositions d'écosystème visant à limiter le taux de croissance historique plutôt que de simplement s'adapter au taux actuel. Celles-ci sont utiles pour maintenir les limites d'E/S réseau à court terme et les limites de stockage à long terme. Alors que l'EIP-4444 est essentiel à la durabilité à long terme du réseau, ces autres EIP aideront Ethereum à évoluer de manière plus efficace à l'avenir:
EIP-7623: Cette proposition suggère de revoir les données d'appel de tarification afin que les transactions avec des données d'appel excessives deviennent plus coûteuses. Rendre ces schémas d'utilisation plus coûteux encouragera certains à passer des données d'appel aux blobs, réduisant ainsi le taux de croissance historique.
EIP-4488: Cette proposition impose des limites sur le montant total de données d'appel pouvant être incluses dans chaque bloc, appliquant un contrôle plus strict sur le taux de croissance historique.
Ces EIP sont plus faciles à mettre en œuvre que l'EIP-4444 et peuvent servir de mesures intérimaires avant que l'EIP-4444 ne soit prêt pour la production.
L'objectif de cet article est de fournir une compréhension basée sur les données de la manière dont la croissance historique fonctionne et comment aborder ce problème. Une grande partie des données présentées dans cet article ont traditionnellement été difficiles d'accès, c'est pourquoi nous cherchons à offrir des perspectives nouvelles sur le problème de la croissance historique.
La croissance historique en tant que goulot d'étranglement pour la scalabilité d'Ethereum n'a pas reçu une attention suffisante. Même sans augmenter les limites de gaz, la pratique actuelle de conserver l'historique sur Ethereum nécessiterait que de nombreux nœuds mettent à niveau leur matériel dans quelques années. Heureusement, ce n'est pas un problème particulièrement difficile à résoudre. Des solutions claires ont été exposées dans l'EIP-4444. Nous pensons qu'il devrait y avoir une accélération dans la mise en œuvre de cet EIP pour faire place à des augmentations futures des limites de gaz.
Si vous êtes intéressé par la recherche sur la scalabilité d'Ethereum, veuillez contacterstorm@paradigm.xyzetgeorgios@paradigm.xyz.Nous aimerions entendre vos perspectives sur cette question et explorer des collaborations potentielles. Les données et le code utilisés dans cet article peuvent être trouvé surGithub.
Un grand merci à Thomas Thiery、Équipe Beiko、Toni Wahrstaetter、Oliver NordbjergetRoman Krasiukpour leur examen et leurs commentaires. Merci à lAchal Srinivasanpour les chiffres fournis dans la Figure 1 et la Figure 7.