Scaling Base: En regardant vers la prochaine mise Ă niveau de Tectra
Base’s Initiatives roadmap 2024 rend onchain accessible et abordable pour tout le monde. Nous sommes concentré sur la livraison de transactions rapides et peu coûteuses sur un L2 sécurisé et décentralisé pour permettre une participation mondiale à l'économie onchain.
Nous présentons nos progrès dans cette nouvelle série de blogs Scaling Base, où nous partageons les mises à jour et notre plan alors que nous apportons un milliard de personnes onchain. Dans cet épisode, nous partageons notre approche pour augmenter la capacité de disponibilité des données alors que nous nous tournons vers l'intégration de PeerDAS dans la prochaine mise à niveau de Pectra.
Ethereum a introduit EIP-4844 en mars de cette année, une mise à niveau qui a entraîné une réduction de 100x des frais de gas L2 en les découplant des frais Ethereum Mainnet. Ce découplage est ce qui permet au réseau combiné d'évoluer. Si une couche 2 est congestionnée, elle peut agir indépendamment pour augmenter sa capacité cible et ramener les frais de transaction.
En conséquence, nous avons réduit le débit de Base’s de 4x depuis son lancement il y a un an, augmentant l'objectif de gas par bloc de 2,5 Mg/s à 10 Mg/s pour maintenir les frais sous un cent (0.01) à mesure que l'activité augmente. Cela n'a été possible qu'en raison d'une énorme quantité de travail acharné de l'équipe de Base et de l'ensemble de l'écosystème des constructeurs qui mettent à l'échelle l'OP Stack, les clients Ethereum et l'EVM.
Il y a quelques mois, nous nous sommes fixés un objectif ambitieux : atteindre une capacité de 1 Ggas/s pour Base. Nous savons que ce parcours demandera beaucoup de travail et de collaboration entre de nombreuses équipes. En prenant du recul, nous avons réalisé que, tant pour notre équipe interne que pour l’écosystème plus large, plus nous pouvons apporter de la prévisibilité dans notre processus de mise à l'échelle, plus il sera facile de planifier et de coordonner le travail nécessaire.
Pour offrir cette clarté, nous changeons notre approche sur l'évolution de Base : nous nous engageons à un rythme constant d'augmentation de la cible de gas, puis à faire le nécessaire pour atteindre cette augmentation en travaillant sur toutes les propriétés clés.
Pour commencer, nous nous engageons publiquement à augmenter la cible de gas de Base de 1 Mgas/s chaque semaine, à partir de la fin septembre. Ces augmentations seront soumises à une surveillance et des tests continus, et si nous devons modifier les plans, nous communiquerons clairement nos principaux enseignements et changements. Au fur et à mesure que nous continuerons à faire évoluer l'infrastructure sous-jacente et à gagner en confiance, notre objectif est ensuite d'accélérer ce rythme d'augmentation (par exemple, 2 Mgas/s par semaine) pour avancer plus rapidement vers les 1 Ggas/s.
Si vous construisez sur Base ou que vous contribuez à l'évolution de l'infrastructure qui alimente Base, nous espérons que ces directives pourront vous servir de boussole pour coordonner et planifier vos efforts. Et si vous avez des retours sur notre approche, nous serions ravis de les entendre !
Alors que Base continue de se développer, nous nous tournons vers la communauté Ethereum pour intégrer les mises à jour nécessaires du mainnet afin d’augmenter la disponibilité des données sur L1, garantissant que les L2s puissent continuer à amener le prochain milliard d’utilisateurs onchain.
Depuis deux ans, nous collaborons avec la communauté des développeurs Ethereum autour de cette mission, en commençant par l'EIP-4844. Cette mise à jour, co-dirigée par l'équipe Base, OP Labs et les développeurs d'Ethereum, a considérablement réduit les coûts sur Base et d'autres L2s en introduisant un espace blob et en fournissant une quantité fixe d’espace blob pour la disponibilité des données.
Cependant, avec une demande croissante, nos projections montrent que les limites actuelles ne répondront pas aux besoins de Base pour l'année à venir. C'est là que PeerDAS entre en jeu.
PeerDAS (Peer Data Availability Sampling), une modification du protocole dans la prochaine mise à jour du hard fork Pectra, résout ce problème en augmentant la capacité totale de blob sans que chaque nœud ait à télécharger chaque blob. Cela permet aux nœuds Ethereum d'accéder à toutes les données blob tout en ne téléchargeant qu'une fraction, réduisant ainsi considérablement les besoins en bande passante du réseau et augmentant la capacité de disponibilité des données.
L'équipe centrale de Base travaille activement à préparer PeerDAS pour son inclusion dans la mise à jour Pectra:
Nous collaborons avec ethPandaOps pour mener des analyses de réseau sur les devnets PeerDAS, fournissant des données essentielles pour orienter les recommandations.
Nous contribuons à la mise en œuvre au sein de Prysm, qui est utilisée pour mener les premières analyses.
En parallèle de ces contributions, nous préconisons une augmentation significative de la capacité des blobs avec l'activation de PeerDAS. Cela est essentiel pour les efforts de scalabilité, permettant de traiter plus de données sans surcharger les nœuds individuels.
Toute modification de protocole affectant la bande passante doit naturellement être examinée de près par les développeurs, étant donné les risques d'instabilité du réseau et les attaques par déni de service liées à la mise en réseau. En raison de la complexité de PeerDAS, certains préconisent son inclusion tout en maintenant initialement la capacité des blobs inchangée. Cette approche repousserait toute augmentation de la capacité de disponibilité des données à une mise à jour ultérieure, qui pourrait avoir lieu plusieurs mois (voire un an) après l'activation de Pectra en 2025.
Bien que les détails finaux de PeerDAS soient encore en discussion, nous pensons que son architecture permet aux validateurs limités par la bande passante de participer en toute sécurité. De plus, l’EIP-7251, également prévu pour Pectra, devrait réduire le trafic p2p du sync_committee, le principal consommateur de bande passante des nœuds.
Imposer un prix minimum plus élevé pour les données des blobs
Un argument contre l'augmentation de la capacité est que les nœuds L1 doivent être équitablement rémunérés pour les ressources de calcul, de stockage et de bande passante nécessaires à la fourniture de la disponibilité des données. Lorsque la demande de blobs est inférieure à la capacité cible, les prix chutent au minimum : 1 wei par octet de données de blob. Lorsque la demande dépasse la capacité cible, un mécanisme de tarification basé sur le marché entre en jeu, permettant une meilleure compensation des coûts encourus par les nœuds L1.
Nous pensons que limiter la capacité DA pour résoudre ce problème est une mauvaise direction ; à la place, nous suggérons une approche différente pour garantir un marché sain pour l'espace de blob, afin que le réseau soit équitablement rémunéré tout en maintenant une capacité non restreinte. Certaines solutions possibles incluent l'augmentation des frais minimums pour les blobs ou la mise en place d'un autre mécanisme de tarification pour les données des blobs.
Augmenter la capacité cible pour un scaling positif
Après l’EIP-4844, les frais de transaction L2 resteront découplés des frais du Mainnet Ethereum tant que la demande moyenne de blobs restera inférieure à la capacité cible (actuellement de 3 par bloc).
Jusqu'à présent, nous n'avons observé que quelques cas où la demande de blobs a dépassé cette cible pendant des périodes prolongées. Certains pourraient voir cette demande inférieure à la cible comme une raison de rester prudents. Cependant, avec le plan de scaling de Base et la demande croissante des L2, nous nous attendons à ce que la demande atteigne ou dépasse régulièrement la capacité dans les mois à venir. Dépasser la capacité cible mettrait fin au découplage des frais de transaction, empêchant les L2 d'augmenter indépendamment leur capacité tout en maintenant des frais bas.
Lorsque la disponibilité des données atteint la capacité cible, la scalabilité devient un jeu à somme nulle : l'augmentation du débit d'un L2 nuirait à un autre. Nous visons à créer un environnement de scaling à somme positive. La mise en œuvre de PeerDAS et l'augmentation du nombre de blobs sont des étapes cruciales pour atteindre cet objectif.
La disponibilité des données sur L1 peut être indirectement augmentée grâce à des améliorations du protocole L2 qui réduisent les données nécessaires. La pile OP (OP Stack) intègre déjà des innovations telles que la mise en forme des données de lots span batch et la compression Brotli issue de la mise à niveau Fjord, ce qui a amélioré le ratio de compression des données de Base de 25 %. Les futures améliorations incluent la compression stateful et les signatures agrégables pour les transactions L2 et les UserOps. Bien que ces améliorations soient utiles, elles constituent la cerise sur le gâteau. En fin de compte, la capacité de disponibilité des données du mainnet doit croître pour soutenir une feuille de route de scalabilité saine.
Perspectives d'avenir
À mesure qu'Ethereum continue de croître, toute augmentation de la capacité de disponibilité des données sera finalement absorbée par la demande organique. Bien qu'un régime de tarification basé sur le marché pour la disponibilité des données soit inévitable, maintenir des frais découplés aussi longtemps que possible permettra à Ethereum de se développer plus rapidement et d'atteindre son plein potentiel.
Présentation de "Scaling Base", une nouvelle série documentant nos progrès techniques pour rendre Base accessible à tous. https://paragraph.xyz/@base-french/scaling-base