Ce que Merge ne fera pas
Tous les regards sont tournés vers la prochaine transition d’Ethereum vers le consensus Proof-of-Stake. Mais une mise à niveau moins connue devrait permettre de réduire les coûts de transaction d’Ethereum et d’améliorer l’évolutivité, contrairement à ce que The Merge va apporter.
La mise à niveau EIP-4844 devrait introduire le proto-danksharding en même temps que la prochaine bifurcation d’Ethereum après la fusion. Cela devrait multiplier jusqu’à 100 fois l’évolutivité des rollups de couche 2 tout en ouvrant la voie à la mise en œuvre du sharding complet.
La feuille de route actuelle d’Ethereum prévoit que l’écosystème naissant de la couche 2 du réseau gère l’évolutivité et l’atténuation des frais, jusqu’à ce que le sharding soit mis en œuvre plus tard. Le sharding répartira la charge de calcul d’Ethereum sur un écosystème de petites chaînes travaillant en parallèle, les chaînes de couche 2 devant devenir les shards du réseau à l’avenir.
The Merge, qui devrait être effective à la mi-septembre, entraînera une réduction de plus de 99% de la consommation d’énergie du réseau et une baisse d’environ 90% des nouvelles émissions d’Ether. Mais de nombreux membres de la communauté s’attendent, à tort, à ce que la mise à niveau entraîne une augmentation significative de l’évolutivité d’Ethereum et une réduction des frais de réseau.
Sharding et Proto-Danksharding
Le Proto-danksharding est la première des deux parties du processus d’Ethereum visant à introduire le sharding. Il mettra en œuvre la majorité de l’infrastructure pour le sharding. Cela comprendra les formats de transaction, les règles de vérification, la logique de consensus et d’exécution, et les ajustements du prix du gaz inclus dans les spécifications du Danksharding.
Avec le Danksharding, chaque validateur ne doit télécharger qu’une petite partie du bloc, ce qui permet de multiplier la taille du bloc et le débit par environ 100 dans les rollups de contexte par rapport à aujourd’hui.
Les rollups sont devenus la principale solution de mise à l’échelle de la couche 2 d’Ethereum et sont mis en œuvre par des entreprises comme Arbitrum, Optimism et Polygon. Ils fonctionnent en regroupant les transactions exécutées sur un réseau de couche 2 à faible coût, qui sont ensuite soumises par lots pour validation sur la couche de base d’Ethereum afin de réduire considérablement les frais de transaction.
Cela permettra à Ethereum d’offrir une solution complète de disponibilité des données pour les rollups pendant que le sharding complet est en cours de développement, ce qui réduit considérablement leurs coûts.
Grâce à la proposition EIP-4844, le proto-danksharding permettra aux transactions de transporter des « blobs » à la place des données d’appel. Les blobs sont beaucoup plus petits et moins chers à traiter par le réseau que les données d’appel qu’ils remplaceront.
Suppression des données historiques
Les données historiques seront également supprimées du réseau après 30 jours une fois que l’EIP-4844 entrera en vigueur. « Le but du protocole de consensus Ethereum n’est pas de garantir le stockage de toutes les données historiques pour toujours », a écrit Buterin. « L’objectif est plutôt de fournir un tableau d’affichage en temps réel hautement sécurisé, et de laisser la place à d’autres protocoles décentralisés pour effectuer un stockage à plus long terme. »
La suppression de la nécessité de stocker les données historiques est l’une des principales caractéristiques de l’EIP-4844 qui permettra d’accroître l’évolutivité des rollups.
Les rollups génèrent beaucoup de données qu’ils doivent retransmettre à la blockchain et le proto-dankharding leur fournit un moyen moins coûteux de le faire. Cette conception est particulièrement bien adaptée aux rollups car ils n’ont pas besoin d’un stockage permanent, mais plutôt d’une garantie forte que les données ont été disponibles sur le réseau Ethereum pendant une durée spécifique.
L’effacement des données historiques ne présente des risques que pour les applications individuelles et non pour le protocole Ethereum lui-même. Il est logique que les applications assument la charge de stocker les données pertinentes pour elles-mêmes. Les explorateurs de blocs, les fournisseurs d’API et les autres services de données stockeront probablement l’historique complet.
