EIP-4844 : comment la nouvelle mise à niveau permet-elle aux Rollup de réduire les frais et d'augmenter le débit ?
TechFlow SélectionTechFlow Sélection
EIP-4844 : comment la nouvelle mise à niveau permet-elle aux Rollup de réduire les frais et d'augmenter le débit ?
EIP-4844 a apporté une impulsion énorme.
Dédié à des analyses Web3 approfondiesRédaction : Jesse Pollak
Traduction : TechFlow
TL;DR
Le travail autour de l'EIP-4844 a connu une forte accélération, avec plusieurs réunions d'impact élevé tenues pendant la Devcon, des ajustements mineurs aux spécifications identifiés, et une mise en œuvre désormais en plein essor.
L’EIP-4844 permettra de réduire les frais des rollups de couche 2 par un facteur 10 à 100, tout en augmentant leur débit transactionnel. Cela est rendu possible grâce à une nouvelle structure appelée « Blobspace », qui introduit une disponibilité de données sur Ethereum pour les rollups.
Ce changement est crucial pour encourager l’adoption d’Ethereum — par exemple chez Coinbase, « nous considérons que l’EIP-4844 est un levier clé pour intégrer nos clients à l’économie cryptographique, en leur offrant une expérience plus sûre, simple, rapide et moins coûteuse ».
L’objectif de la Devcon était de rassembler toutes les équipes clientes afin de discuter de « la meilleure façon de livrer l’EIP-4844 ». Pour y parvenir, les développeurs d’Ethereum, d’OPLab et de Coinbase ont passé les cinq derniers mois à rédiger les spécifications, implémenter celles-ci dans Geth et Prysm, lancer deux réseaux de test et préparer la cérémonie KZG.
Durant la conférence, de nombreuses discussions ont eu lieu : plusieurs ateliers lors de la journée R&D précédant la Devcon, des échanges à EthMagicians, une réunion de travail de demi-journée avec les équipes clientes, ainsi que des conversations informelles presque quotidiennes.
Ces échanges nous ont permis d’identifier quelques petits ajustements aux spécifications des couches d’exécution et de consensus. Nous avons également constaté que la principale préoccupation des équipes clientes concerne l’impact réseau accru des blobs.
Au niveau de la couche de consensus, nous avons décidé de combiner les blobs et les blocs plutôt que de les séparer. Cette décision vise à simplifier l’implémentation, sachant que ce n’est probablement qu’à l’étape suivante du projet Danksharding que nous envisagerons une séparation.
Au niveau de la couche d’exécution, afin de limiter les vecteurs potentiels de DOS, nous avons décidé de mettre à jour le protocole réseau pour que les transactions contenant des blobs soient uniquement publiées, et non diffusées (broadcast). Cela permet aux clients de gérer plus sûrement la récupération des blobs.
La préoccupation majeure exprimée par les clients porte surtout sur la latence réseau : avec les blobs, la bande passante totale du réseau pourrait fortement augmenter. Bien que ce comportement soit attendu, il est souhaitable d’en minimiser autant que possible les risques.
Pour répondre à cela, nous prévoyons de simuler le comportement du réseau en créant, sur les réseaux de test puis sur le réseau principal, un volume continu de blocs remplis de CALLDATA. Cela permettra d’observer comment les nœuds du réseau gèrent cette charge.
En fonction des résultats des tests, nous ajusterons la taille cible des blobs en tenant compte des limites de bande passante, et mettrons en place toute mesure complémentaire nécessaire. Nous sommes impatients d’obtenir des données réelles pour définir les paramètres finaux adaptés à l’EIP-4844.
Enfin, les discussions ont porté sur les bibliothèques à utiliser pour implémenter les engagements KZG entre les couches d’exécution et de consensus. Nous nous sommes entendus sur l’utilisation par défaut de la bibliothèque c-kzg (basée sur Blst), même si les clients restent libres d’utiliser des bibliothèques spécifiques à leur plateforme.
Tout au long de la Devcon, de nombreux échanges ont eu lieu concernant le calendrier précis de l’EIP-4844. Bien que la plupart des équipes clientes considèrent le shardage/l’extensibilité comme une priorité absolue, il existe aussi un fort désir de garantir un financement suffisant pour mener à bien l’EIP-4844.
Aucune décision formelle n’a été prise quant à l’intégration de l’EIP-4844 dans la prochaine bifurcation dure, mais cette hypothèse est largement envisagée. La manière optimale de refléter cela dans les spécifications et les bases de code des clients reste en cours de définition.
Sur la base de ces retours, le groupe de travail s’engage à pleinement intensifier ses efforts à court terme : implémenter 2 à 3 autres clients (Lodestar, Erigon, Nethermind), réaliser des tests de bande passante, et lancer Devnet 3.
Nous prévoyons de faire un nouveau point plus tard ce mois-ci afin d’évaluer si nos progrès sont alignés avec le calendrier du hard fork Shanghai. Nous sommes optimistes : grâce à un solide groupe de travail transversal inter-entreprises, nous devrions être en mesure de finaliser rapidement l’EIP-4844.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
