Arweave TX
TLDR : Pour construire une économie onchain mondiale, nous devons atteindre une échelle où les frais de gas restent en dessous d’un centime. Notre objectif pour 2025 est d’atteindre une capacité de 250 Mgas/s — soit 100x par rapport à notre point de départ. Au premier trimestre, nous avons franchi un cap important : 25 Mgas/s, soit 10x depuis le lancement. Nous sommes maintenant en bonne voie pour atteindre 50 Mgas/s d’ici la fin du deuxième trimestre. Cette revue trimestrielle fait le point sur les principaux blocages en matière de scalabilité., et sur nos avancées pour les éliminer.
La mission de Base est de construire une économie onchain mondiale qui stimule l’innovation, la créativité et la liberté. Pour y parvenir, l’un des cinq piliers stratégiques de Base pour 2025 est de faire passer Base à l’échelle et de réduire les frais de gas afin que tout le monde, partout dans le monde, puisse venir onchain. En 2024, nous avons fait évoluer Base jusqu’à 20 Mgas/s — soit presque 10 fois plus qu’à nos débuts. Cette année, notre objectif est d’atteindre un gas target de 250 Mgas/s — augmentant ainsi la capacité de Base à gérer plus de transactions, plus de builders et plus de personnes onchain.
En début d’année, nous avons partagé notre approche pour le scaling de Base en 2025. Aujourd’hui, nous faisons un point sur les progrès réalisés jusqu’ici, et sur les priorités actuelles alors que nous continuons d’augmenter la capacité de traitement de Base et de lever les principaux blocages pour accélérer encore davantage.
Dans notre précédent article sur le scaling, nous avions présenté les principaux blocages que nous cherchons à éliminer pour atteindre notre objectif de 250 Mgas/s d’ici 2025. Voici une mise à jour sur ces points de blocage à l’approche du deuxième trimestre.
Le Blobspace est resté à pleine capacité pendant plusieurs mois. Le hard fork Pectra, qui sera activé sur Ethereum Mainnet le 7 mai, doublera la capacité des blobs et offrira plus de marge pour que les L2 puissent se développer. Doubler le blobspace avec Pectra a été un objectif majeur de l’équipe de Base durant l’année écoulée, et nous sommes ravis de voir cet objectif se concrétiser.
Nous savons, et avons su depuis un certain temps, que cela n’est qu’une victoire temporaire — l’écosystème risque d’utiliser ce blobspace peu de temps après son activation. Par conséquent, nous continuons à investir massivement dans PeerDAS, en collaboration avec la Fondation Ethereum, divers clients EL et CL, et d’autres L2, pour débloquer une augmentation beaucoup plus importante de la disponibilité des données sur L1.
PeerDAS sera inclus dans Fusaka, le hard fork suivant Pectra, prévu pour le troisième trimestre de cette année. Ce calendrier est ambitieux, mais avec le bon focus et les investissements nécessaires, nous pouvons en faire un déblocage majeur pour le scaling d’Ethereum. Nous pensons que tout retard dans le lancement de Fusaka est le plus grand risque pour Ethereum, en termes de soutien à l’adoption massive dans l’année à venir.
Si PeerDAS est lancé selon le calendrier, nous nous attendons à ce que le graphique des bottlenecks mis à jour ressemble à ce qui suit.
La vitesse d'exécution des clients peut être décomposée en deux catégories : la performance de la construction de blocs (le temps nécessaire au séquenceur pour créer un bloc) et la performance des validateurs (le temps nécessaire à un validateur pour synchroniser un bloc). Étant donné que la performance des clients d'exécution sous-tend ces deux aspects, nous continuons de les traiter comme un seul blocage.
Notre principal objectif pour améliorer la vitesse d'exécution des clients est de désactiver complètement les nœuds Geth Archive. Nous avons migré presque tous les nœuds, y compris le nœud séquenceur, hors de Geth Archive, et nous encourageons les autres à faire de même. Il reste une seule dépendance à Geth Archive liée aux preuves de défaillance, qui disparaîtra bientôt également.
Une source majeure de contraintes de performance EL — que nous avons identifiée précédemment et que nous continuons de valider avec des données réelles — est la latence significative causée par les accès aux bases de données sur le disque local. Nous sommes en train de prototyper activement et partagerons bientôt plus de détails sur une solution pour réduire cette latence.
D'ici la fin avril, Base mettra à jour sa version de Cannon, la machine virtuelle qui soutient actuellement le système de preuves de défaillance de Base. La version mise à jour, développée par OP Labs, étend l'architecture mémoire de Cannon de 32 bits à 64 bits et intègre la prise en charge du multithreading. Ces deux améliorations représentent un grand progrès en matière de scaling, en éliminant presque complètement les deux goulets d’étranglement du système actuel de preuves de défaillance : l’utilisation mémoire et le temps d'exécution des challengers.
Notre première analyse montre que le nouveau Cannon, que nous appelons MT64Cannon, supprime complètement les contraintes mémoire identifiées dans Cannon et réduit également de manière significative le temps d'exécution des challengers.
Afin de garantir que MT64Cannon continue de soutenir les objectifs de scaling de Base, nous suivons des métriques telles que les réussites / échecs des challengers, le temps d'exécution des challengers, l'utilisation mémoire et le nombre d'instructions MIPS.
Avec notre grande poussée pour migrer vers Reth, nous avons identifié les preuves de défaillance comme l'une des dernières dépendances à Geth. C'est pourquoi nous avons largement investi dans l'ajout de la compatibilité Reth pour op-program, afin de supprimer cette dépendance finale. Ce travail est désormais terminé et devrait être mis en production très prochainement.
Bien que MT64Cannon soutienne probablement nos objectifs de scaling pour 2025, il ne pourra pas assurer le scaling de Base indéfiniment. Nous évaluons actuellement des alternatives plus performantes, y compris des systèmes de preuves de défaillance entièrement basés sur Reth.
Lors de notre dernier examen de scaling, nous avons partagé notre objectif de maintenir l’utilisation disque des nœuds, en tant que proxy pour la croissance de l’historique, sous les 30 To, une limite basée sur les disques SSD NVMe fournis par les principaux fournisseurs de cloud actuels. Geth Archive a dépassé ce seuil, ce qui est une autre raison pour laquelle nous avons complètement migré hors de Geth Archive. Nous recommandons vivement à toute personne utilisant encore des nœuds Geth Archive de migrer vers des nœuds Geth Full ou Reth Archive.
Étant donné la suppression de la dépendance à Geth Archive, nous ne prévoyons aucun blocage pour le scaling à 250 Mgas/s.
En combinant tous les blocages, voici le graphique suivant.
En comparant cela au graphique d'il y a quelques mois, nous pouvons constater que nous avons fait des progrès significatifs dans l’élimination des blocages.
Mais c’est encore le premier jour – il reste beaucoup de travail à faire pour continuer à permettre à Base de se développer au rythme que nous avons prévu.
Un axe majeur pour notre équipe est de scaler de manière sécurisée. Nous avons des objectifs de scaling très ambitieux, mais nous ne les pousserons pas au détriment de la sécurité et de la fiabilité de la chaîne.
Au cours des six derniers mois, nous avons investi de manière significative dans l'optimisation de l'infrastructure interne de Base pour garantir son bon fonctionnement à mesure que nous nous développons. Nous avons mis en place un processus interne de go/no-go à chaque fois que nous augmentons l'objectif de gas de Base, ce qui permet de nous assurer que nos métriques sont saines avant l'augmentation.
Nous construisons également un outil de benchmarking complet pour nous permettre de valider la performance du système par rapport à la future limite de gas à laquelle nous nous développons, et non simplement à la limite de gas actuelle. Cela nous apportera davantage de confiance dans notre scaling en faisant remonter proactivement les inconnues, notamment à mesure que nous effectuons des augmentations plus importantes de la cible de gas.
À mesure que nous accélérons le scaling, nous voulons nous assurer qu'en plus de disposer d'une infrastructure interne saine, le reste de l'écosystème reste également en bonne santé. Base est déjà à une échelle où ne pas exécuter les bonnes configurations de nœuds peut entraîner des retards. Nous avons observé des cas où nos nœuds internes suivaient le trafic, mais où nous avons reçu des rapports indiquant que des nœuds externes prenaient du retard. Nous recommandons à tous les opérateurs de nœuds de vérifier régulièrement nos documents (docs.base.org) et de s'abonner à notre page de statut (status.base.org) pour obtenir les recommandations les plus récentes sur la configuration du matériel et des clients. On peut supposer que les recommandations fournies dans nos documents officiels ont passé nos tests de benchmarking.
Nous n'aurions pas pu faire évoluer Base jusqu'à son état actuel sans le soutien de nombreuses équipes au sein de l'écosystème — et nous continuerons à collaborer pour l’étendre davantage. Nous espérons que ces efforts pour faire évoluer Base offriront des enseignements et des infrastructures permettant à d'autres L2 et à l'ensemble de l'écosystème Ethereum de se développer.
2025 est l'année où nous évoluons ensemble. Nous recherchons des partenaires de collaboration pour relever des défis comme la mise en production de PeerDAS et l'optimisation des performances des clients d'exécution et des systèmes de preuves de défaillance. Si vous êtes intéressé par des solutions créatives et ambitieuses pour permettre au prochain milliard de personnes de rejoindre la blockchain, nous recrutons — et nous serions ravis de vous entendre.
Suivez-nous sur les réseaux sociaux pour rester à jour avec les dernières informations : X (équipe Base sur X) | Farcaster | Discord
To build a global onchain economy, we need to scale to keep gas fees under one cent. Our goal for 2025 is to reach a gas target of 250 Mgas/s - a 100x increase from where we started. In Q1, we hit a major milestone: 25 Mgas/s, 10x from launch.
Faire évoluer Base : Atteindre 50 Mgas/s au deuxième trimestre. https://paragraph.com/@base-french/faire-evoluer-base-atteindre-50-mgass-au-deuxieme-trimestre https://blog.base.dev/scaling-base-reaching-50-mgas-in-q2
To build a global onchain economy, achieving a gas target of 250 Mgas/s by 2025 is crucial, per @lifehxc. Recent advancements include reaching 25 Mgas/s and optimizing data availability through initiatives like PeerDAS and MT64Cannon. Key barriers are being addressed to ensure faster and reliable scaling.