Comprendre les goulots d'étranglissement du Rollup et ses méthodes d'optimisation à partir des différences de performance entre opBNB et les solutions L2 Ethereum
TechFlow SélectionTechFlow Sélection
Comprendre les goulots d'étranglissement du Rollup et ses méthodes d'optimisation à partir des différences de performance entre opBNB et les solutions L2 Ethereum
Cet article résume brièvement le fonctionnement et la portée commerciale d'opBNB, en retraçant une étape importante franchie par la blockchain BSC à l'ère des blockchains modularisées.
Dédié à des analyses Web3 approfondiesRédaction : Faust, Geek Web3
Introduction : Si l’on devait résumer l’année 2023 dans le monde du Web3 par un seul mot-clé, beaucoup penseraient naturellement à « l’été des Layer2 ». Bien que les innovations au niveau applicatif aient été nombreuses et variées, peu de sujets ont atteint la longévité d’un intérêt durable comme celui des L2. Avec le succès de Celestia dans la promotion du concept de blockchain modulaire, les termes « Layer2 » et « modularité » sont presque devenus synonymes d’infrastructure, tandis que les chaînes monolithiques peinent à retrouver leur ancienne gloire. Après les annonces successives de réseaux Layer2 dédiés par Coinbase, Bybit et MetaMask, la guerre des Layer2 fait désormais rage, rappelant fortement les affrontements entre nouvelles blockchains publiques.
Dans cette bataille menée par les exchanges, BNB Chain ne peut évidemment pas rester en arrière. Dès l’année dernière, elle avait lancé le réseau test zkBNB, mais en raison des performances insuffisantes du zkEVM pour une adoption à grande échelle, opBNB, basé sur la solution Optimistic Rollup, s’est imposé comme l’option privilégiée pour une Layer2 universelle. Cet article vise à présenter brièvement le fonctionnement technique et la portée stratégique d’opBNB, afin d’éclairer la première étape significative de BSC vers l’ère de la blockchain modulaire.
La voie des grands blocs de BNB Chain
À l’instar de Solana ou Heco, deux blockchains soutenues par des exchanges, BNB Smart Chain (BSC) a toujours poursuivi une quête de hautes performances. Dès son lancement en 2020, BSC a fixé la limite maximale de gas par bloc à 30 millions, avec un intervalle constant de 3 secondes entre chaque bloc. Grâce à ces paramètres, BSC a atteint un TPS théorique supérieur à 100 (mélange de différents types de transactions). En juin 2021, la limite de gas par bloc a été doublée à 60 millions, mais en juillet, un jeu blockchain nommé CryptoBlades est devenu viral sur BSC, générant plus de 8 millions de transactions quotidiennes, ce qui a fait exploser les frais de transaction. Cette situation a clairement mis en lumière les limites de performance de BSC à l’époque.
(Source : BscScan)
Pour résoudre les problèmes de performance, BSC a encore augmenté sa limite de gas par bloc, stabilisée ensuite autour de 80 à 85 millions pendant une longue période. En septembre 2022, la limite a atteint 120 millions, puis 140 millions fin d’année, soit près de cinq fois celle de 2020. BSC avait envisagé d’aller jusqu’à 300 millions, mais cette proposition de blocs géants n’a jamais été mise en œuvre, probablement en raison de la charge excessive qu’elle aurait représentée pour les nœuds validateurs.
(Source : YCHARTS)
Par la suite, BNB Chain semble avoir recentré ses efforts sur la modularité et les Layer2, abandonnant progressivement l’idée de scaler davantage sa couche L1. Depuis le lancement de zkBNB l’année dernière jusqu’à GreenField début 2023, cette orientation est devenue de plus en plus évidente. Cet article se concentre donc sur opBNB, explorant comment ses différences avec les Layer2 d’Ethereum illustrent les goulots d’étranglement des solutions Rollup.
L’avantage d’une haute débit de BSC pour la couche DA d’opBNB
Comme le souligne Celestia selon l’architecture modulaire, une blockchain peut être divisée en quatre composants clés :
-
Exécution (Execution) : l’environnement où le code des contrats est exécuté et les états mis à jour ;
-
Clôture (Settlement) : traitement des preuves de fraude ou de validité, ainsi que des ponts entre L2 et L1 ;
-
Consensus : accord sur l’ordre des transactions ;
-
Disponibilité des données (Data Availability - DA) : publication des données du grand livre permettant aux vérificateurs de les télécharger.
Les couches DA et consensus sont souvent couplées. Par exemple, les données DA d’un Rollup optimiste incluent une séquence de transactions L2. Quand un nœud complet L2 récupère ces données, il connaît immédiatement l’ordre exact de chaque transaction. (C’est pourquoi la communauté Ethereum considère DA et consensus comme liés lorsqu’elle hiérarchise les Rollups.)
Pour les Layer2 d’Ethereum, la faible capacité de traitement des données de la couche DA (Ethereum lui-même) constitue le principal goulot d’étranglement, car Ethereum ne peut supporter qu’un volume limité de données. Les Rollups doivent donc limiter leur TPS pour éviter de submerger le réseau principal.
En outre, cette faible bande passante entraîne un backlog massif de transactions sur Ethereum, poussant les frais de gaz à des sommets, ce qui augmente d’autant le coût de publication des données pour les Layer2. Résultat : de nombreux projets doivent recourir à des couches DA alternatives comme Celestia. En revanche, opBNB profite directement de la haute débit de BSC comme couche DA, contournant efficacement ce goulot d’étranglement.
Pour mieux comprendre, examinons la manière dont les Rollups publient leurs données DA. Prenons Arbitrum : une adresse EOA contrôlée par le séquenceur L2 envoie périodiquement une transaction à un contrat prédéfini, inscrivant dans le champ calldata les données regroupées de plusieurs transactions L2, déclenchant ainsi un événement permanent dans les logs du contrat.
Ainsi, les données des transactions L2 sont conservées durablement dans les blocs Ethereum. Tout utilisateur disposant d’un nœud L2 peut télécharger ces données et les décoder, bien que les nœuds Ethereum eux-mêmes n’exécutent pas ces transactions. On voit ici que L2 utilise uniquement Ethereum comme stockage, supportant les coûts de sauvegarde, tandis que le coût computationnel reste entièrement assumé par les nœuds L2.
Voici le mécanisme DA d’Arbitrum. Pour Optimism, le séquenceur envoie une transaction de transfert (transfer) vers une autre EOA, en y incluant les nouvelles données L2 dans les données annexes. Quant à opBNB, qui repose sur OP Stack, il suit essentiellement la même méthode de publication que Optimism.
Il est évident que le débit de la couche DA limite la taille des données que le Rollup peut publier par unité de temps, ce qui impacte directement le TPS. Considérons que, post-EIP1559, chaque bloc Ethereum a une limite de 30 millions de gas, avec un temps de bloc d’environ 12 secondes après la fusion. Le volume de gas traitable par seconde est donc d’environ 2,5 millions.
Dans la plupart des cas, chaque octet de calldata consomme 16 gas. Ainsi, Ethereum ne peut traiter qu’environ 150 Ko de calldata par seconde. En comparaison, BSC peut traiter jusqu’à 2910 Ko/s, soit 18,6 fois plus qu’Ethereum. L’écart entre les deux en tant que couches DA est donc flagrant.
On peut conclure qu’Ethereum peut au maximum héberger environ 150 Ko/s de données L2. Même après l’activation de l’EIP-4844, ce chiffre ne changera pas radicalement — seule la tarification sera améliorée. Mais combien de transactions cela représente-t-il ?
Il faut ici parler du taux de compression des données des Rollups. En 2021, Vitalik avait estimé de façon trop optimiste que les Rollups optimistes pouvaient réduire la taille des données à 11 % de leur taille initiale. Par exemple, un transfert ETH passerait de 112 octets à 12, un transfert ERC-20 à 16 octets, un swap Uniswap à 14 octets. Selon cette estimation, Ethereum pourrait enregistrer jusqu’à 10 000 transactions L2 par seconde. Mais selon les données publiées par Optimism en 2022, le taux de compression réel n’atteint au mieux que 37 %, soit 3,5 fois moins que l’estimation de Vitalik.
(L’estimation de Vitalik sur l’efficacité des Rollups s’éloigne largement de la réalité)
(Taux de compression réels publiés par Optimism)
On peut donc avancer un chiffre réaliste : même à pleine capacité, la somme totale du TPS de tous les Rollups optimistes sur Ethereum ne dépasserait pas 2000. Autrement dit, si tous les blocs Ethereum étaient remplis exclusivement par les données publiées par Arbitrum, Optimism, Base, Boba, etc., leur TPS cumulé resterait inférieur à 3000, même avec les algorithmes de compression les plus efficaces. De plus, après l’EIP1559, chaque bloc ne contient en moyenne que 50 % de son maximum de gas. Le chiffre doit donc être divisé par deux. Après l’activation de l’EIP4844, bien que les frais soient réduits, la taille maximale des blocs ne changera pas significativement (pour préserver la sécurité), donc notre estimation ne s’améliorera guère.
D’après Arbiscan et Etherscan, un lot de 1115 transactions Arbitrum consomme 1,81 million de gas sur Ethereum. Par extrapolation, si chaque bloc était rempli à saturation, le TPS théorique maximal d’Arbitrum serait d’environ 1500. Toutefois, en raison du risque de réorganisation des blocs L1, Arbitrum ne peut publier un lot à chaque bloc. Ce chiffre reste donc purement théorique.
En outre, avec l’adoption massive des wallets intelligents compatibles EIP-4337, le problème de disponibilité des données va s’aggraver. Ces wallets permettent des méthodes de vérification personnalisées (empreintes digitales, iris, etc.), ce qui augmente la taille des données par transaction. La faible bande passante d’Ethereum reste donc le principal frein aux performances des Rollups, problème qui persistera longtemps.
BSC, en revanche, peut traiter jusqu’à 2910 Ko/s de calldata, soit 18,6 fois plus qu’Ethereum. Autrement dit, si la couche d’exécution suit, le TPS théorique maximal d’un Layer2 dans l’écosystème BNB Chain peut atteindre environ 18 fois celui d’ARB ou d’OP. Ce calcul est basé sur une limite de 140 millions de gas par bloc et un temps de bloc de 3 secondes.
Autrement dit, le TPS cumulé maximal de tous les Rollups sous BNB Chain est aujourd’hui 18,6 fois supérieur à celui d’Ethereum (même en incluant les ZKRollups). Cela explique pourquoi tant de projets Layer2 choisissent des couches DA alternatives — l’écart est évident.
Mais le problème est plus complexe. Outre le débit, la stabilité de la couche L1 influence aussi les performances L2. Par exemple, la plupart des Rollups ne publient un lot de transactions que toutes les quelques minutes, car les blocs L1 peuvent être réorganisés. Une telle réorganisation affecterait le registre L2. Ainsi, après avoir publié un lot, le séquenceur attend que plusieurs nouveaux blocs L1 soient minés, réduisant ainsi le risque de rollback, avant de publier le lot suivant. Cela retarde la finalité des blocs L2, ralentissant la confirmation des grosses transactions (qui nécessitent une irréversibilité pour être sécurisées).
En résumé, une transaction L2 n’est irréversible qu’après avoir été publiée dans un bloc DA et que plusieurs nouveaux blocs DA soient ajoutés — un facteur clé limitant les performances des Rollups. Ethereum met 12 secondes par bloc. Si un Rollup publie un lot toutes les 15 blocs, il y a un intervalle de 3 minutes entre chaque publication, et chaque lot doit encore attendre plusieurs blocs supplémentaires pour devenir irréversible. Sur Ethereum, le délai entre initiation et irréversibilité est donc très long. BNB Chain, avec un bloc toutes les 3 secondes, atteint l’irréversibilité en seulement 45 secondes (15 blocs).
Avec les paramètres actuels, à nombre égal de transactions L2 et en tenant compte de la nécessité d’irréversibilité, opBNB peut publier des données jusqu’à 8,53 fois plus souvent qu’Arbitrum (toutes les 45 secondes contre toutes les 6,4 minutes). Ainsi, la vitesse de clôture des grosses transactions sur opBNB est nettement supérieure. De plus, la taille maximale des données publiées par opBNB est 4,66 fois supérieure à celle d’Ethereum (140M contre 30M de gas par bloc).
8,53 × 4,66 = 39,74 — c’est l’écart actuel entre opBNB et Arbitrum en termes de TPS maximal. (Actuellement, Arbitrum semble volontairement limiter son TPS pour des raisons de sécurité, mais théoriquement, il pourrait aller beaucoup plus loin.)
(Le séquenceur d’Arbitrum publie un lot toutes les 6 à 7 minutes)
(Le séquenceur d’opBNB publie un lot toutes les 1 à 2 minutes, voire toutes les 45 secondes)
Un autre point crucial concerne les frais de gaz de la couche DA. Chaque publication d’un lot L2 implique un coût fixe de 21 000 gas, indépendamment de la taille du calldata. Si les frais L1 sont élevés, le séquenceur réduit la fréquence de publication. En outre, dans le calcul des frais L2, le coût d’exécution est négligeable face au coût DA, qui domine donc largement.
En conclusion, bien que publier la même quantité de calldata consomme le même montant de gas sur Ethereum et BNB Chain, le prix du gaz sur Ethereum est actuellement 10 à plusieurs dizaines de fois supérieur, ce qui se traduit directement par des frais L2 10 à plusieurs dizaines de fois plus élevés sur Ethereum qu’opBNB. La différence entre opBNB et les Rollups optimistes d’Ethereum est donc marquée.
(Une transaction de 150 000 gas sur Optimism coûte 0,21 $)
(Une transaction de 130 000 gas sur opBNB coûte 0,004 $)
Toutefois, même en augmentant le débit de la couche DA, l’amélioration du TPS individuel d’un Rollup reste limitée si la couche d’exécution est trop lente. Même sans goulot DA, la vitesse d’exécution devient alors le nouveau frein. Si la couche L2 est trop lente, la demande excédentaire se répartira sur d’autres L2, fragmentant ainsi la liquidité. Il est donc crucial d’optimiser aussi la couche d’exécution, un autre seuil après la couche DA.
Avantage d’opBNB au niveau d’exécution : optimisation du cache
Quand on parle des goulots d’étranglement d’exécution, deux points reviennent souvent : l’exécution monofil (single-thread) de l’EVM, qui exploite mal les CPU multicœurs, et l’inefficacité de l’arbre Merkle Patricia Trie pour accéder aux données. Ce sont deux limites majeures. En résumé, les pistes de scaling consistent à mieux utiliser les ressources CPU et à accélérer l’accès aux données. Les optimisations de l’EVM et de l’arbre Merkle Patricia sont complexes et difficiles à mettre en œuvre. En revanche, les gains les plus rapides viennent souvent de l’optimisation du cache.
Ce sujet rejoint des principes classiques du Web2 et des manuels informatiques.
Typiquement, le CPU lit les données en mémoire centrale des centaines de fois plus vite que sur disque. Par exemple, lire 0,1 seconde depuis la RAM contre 10 secondes depuis le disque. Réduire les accès disque — c’est-à-dire optimiser le cache — devient donc indispensable pour améliorer les performances d’exécution.
Sur Ethereum et la plupart des blockchains, la base de données des états des adresses est stockée intégralement sur disque. L’arbre World State trie n’en est qu’un index, un annuaire. À chaque exécution de contrat, l’EVM doit récupérer les états associés. Si chaque donnée doit être extraite du disque, la vitesse d’exécution chuterait drastiquement. Ainsi, ajouter un système de cache entre la base de données et l’EVM est une mesure incontournable pour accélérer le traitement.
opBNB adopte directement la solution de cache utilisée par BNB Chain. Selon NodeReal, partenaire d’opBNB, la version initiale de BSC a mis en place trois niveaux de cache entre l’EVM et la base LevelDB, selon un principe similaire au cache CPU à trois niveaux. Les données les plus fréquemment consultées sont placées en cache, permettant au CPU de les récupérer rapidement. Si le taux de hit est élevé, le CPU dépend moins du disque, ce qui accroît fortement la vitesse d’exécution.
NodeReal a ensuite ajouté une fonctionnalité utilisant les cœurs CPU inactifs non utilisés par l’EVM pour précharger les données futures depuis la base de données vers le cache, permettant à l’EVM de les récupérer directement. Cette fonction s’appelle « lecture anticipée d’état » (state prefetch).
Le principe est simple : les nœuds blockchain ont des CPU multicœurs, mais l’EVM fonctionne en monofil, utilisant un seul cœur. Les autres cœurs sont donc sous-utilisés. On peut donc les employer pour analyser la file des transactions non encore traitées par l’EVM, identifier les données nécessaires, puis les charger à l’avance depuis la base. Ces cœurs libres préchargent ainsi les données, réduisant le coût d’accès pour l’EVM et accélérant l’exécution.
Grâce à une optimisation poussée du cache et un matériel suffisant, opBNB a quasiment atteint la limite de performance de l’EVM standard : jusqu’à 100 millions de gas par seconde. Ce chiffre correspond au plafond théorique d’un EVM non modifié (selon des tests expérimentaux d’une blockchain célèbre).
En chiffres concrets, opBNB peut traiter jusqu’à 4761 transferts simples par seconde, 1500 à 3000 transferts ERC-20, ou 500 à 1000 swaps (données issues des explorateurs de blocs). En comparaison, le TPS maximal d’opBNB est 40 fois supérieur à Ethereum, plus de 2 fois BNB Chain, et plus de 6 fois Optimism.
Bien sûr, les Layer2 d’Ethereum, bridées par leur couche DA, ne peuvent exprimer pleinement leurs capacités d’exécution. En tenant compte du temps de bloc, de la stabilité et d’autres facteurs mentionnés, leurs performances réelles sont bien inférieures à celles de la couche d’exécution seule. Pour BNB Chain, doté d’une couche DA haute débit, un projet comme opBNB, offrant un gain de plus de 2x, est hautement pertinent — d’autant que BNB Chain peut en accueillir plusieurs.
Il est prévisible que BNB Chain intègre désormais opBNB et d’autres projets modulaires dans sa stratégie, envisageant même d’introduire des preuves ZK dans opBNB ou d’utiliser GreenField comme couche DA robuste, pour concurrencer ou coopérer avec l’écosystème Layer2 d’Ethereum. Dans cet âge où le scaling par modularité s’impose comme tendance, d’autres blockchains imiteront-elles BNB Chain en développant leurs propres Layer2 ? Le temps le dira. Une chose est sûre : la révolution des infrastructures vers une architecture modulaire est déjà en marche.
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
@godrealmx
