La route de BNB Chain vers les grands pâtés de maisons

La route des grands blocs sur la chaîne BNB

À l'instar de Solana, Heco et d'autres chaînes publiques soutenues par des bourses, la chaîne publique BNB Smart Chain (BSC) de BNB Chain recherche depuis longtemps de hautes performances. Depuis son lancement en 2020, BSC a fixé la limite de capacité de gaz pour chaque bloc à 30 millions, avec un intervalle de bloc stable de 3 secondes. Avec de tels paramètres, BSC a atteint un TPS maximum (TPS avec différentes transactions mélangées) de plus de 100. En juin 2021, la limite de gaz du bloc de BSC a été portée à 60 millions. Cependant, en juillet de la même année, un jeu de chaîne appelé CryptoBlades a explosé sur BSC, faisant passer le volume de transactions quotidien à plus de 8 millions et faisant grimper les frais en flèche. Il s'est avéré que le goulot d'étranglement de BSC en termes d'efficacité était encore évident à l'époque.

(Source : BSCscan)

Pour résoudre les problèmes de performance du réseau, BSC a de nouveau relevé la limite de gaz pour chaque bloc, qui est restée stable entre 80 et 85 millions pendant longtemps. En septembre 2022, la limite de gaz par bloc de BSC Chain a été portée à 120 millions, et à la fin de l'année, elle était passée à 140 millions, soit près de cinq fois plus qu'en 2020. Auparavant, BSC avait prévu de porter la limite de capacité des blocs de gaz à 300 millions, mais compte tenu de la lourde charge qui pèse sur les nœuds Validator, la proposition pour des blocs de cette taille n'a pas été mise en œuvre.

source : YCHARTS

Plus tard, BNB Chain a semblé se concentrer davantage sur la piste modulaire/Layer2 au lieu de persister dans l'extension Layer1. Cette intention est devenue de plus en plus évidente lors du lancement de zkBNB au second semestre de l'année dernière et de GreenField au début de cette année. S'intéressant vivement à la blockchain modulaire/Layer2, l'auteur de cet article utilisera OpBnB comme objet de recherche afin de révéler les problèmes de performances du Rollup en le comparant à Ethereum Layer2.

L'augmentation du haut débit de BSC par rapport à la couche DA d'OpBnB

Comme nous le savons tous, Celestia a résumé quatre éléments clés du flux de travail de la blockchain modulaire : la couche d'exécution : exécute le code du contrat et effectue les transitions d'état ; la couche de règlement : gère les preuves de fraude et de validité et résout les problèmes de passerelle entre la L2 et la L1. Niveau de consensus : parvient à un consensus sur l'ordre des transactions. Data Availability Layer (DA) : publie des données liées au registre de la blockchain, permettant aux validateurs de télécharger ces données.

Parmi elles, la couche DA est souvent associée à la couche consensus. Par exemple, les données du DA d'Optimistic Rollup contiennent un lot de séquences de transactions en blocs L2. Lorsque les nœuds complets L2 obtiennent des données DA, ils connaissent l'ordre de chaque transaction de ce lot. (C'est pourquoi la communauté Ethereum pense que la couche DA et la couche consensus sont liées lors de la superposition du Rollup.)

Cependant, pour Ethereum Layer2, le débit de données de la couche DA (Ethereum) est devenu le principal obstacle aux performances du rollup. Cela est dû au fait que le débit de données actuel d'Ethereum est trop faible, ce qui oblige Rollup à supprimer son TPS autant que possible afin d'éviter que le réseau principal d'Ethereum ne puisse pas supporter les données générées par la L2. Dans le même temps, le faible débit de données met en attente un grand nombre d'instructions de transaction sur le réseau Ethereum, ce qui fait grimper les frais de gaz à des niveaux extrêmement élevés et augmente encore le coût de la publication des données pour Layer2. Enfin, de nombreux réseaux de couche 2 doivent adopter des couches DA en dehors d'Ethereum, comme Celestia, et OpBnB, qui est proche de l'eau, a choisi d'utiliser directement le haut débit de BSC pour implémenter DA afin de résoudre le problème de goulot d'étranglement lié à la publication des données. Pour faciliter la compréhension, présentons la méthode de publication des données DA pour Rollup. En prenant Arbitrum comme exemple, la chaîne Ethereum contrôlée par l'adresse EOA du séquenceur Layer2 envoie périodiquement des transactions vers le contrat spécifié. Dans les paramètres de saisie calldata de cette instruction, les données de transaction packagées sont écrites et les événements correspondants en chaîne sont déclenchés, laissant une trace permanente dans les journaux des contrats.

Ainsi, les données de transaction de Layer2 sont stockées dans des blocs Ethereum pendant longtemps. Les personnes capables de gérer des nœuds L2 peuvent télécharger les enregistrements correspondants et analyser les données correspondantes, mais les nœuds Ethereum eux-mêmes n'exécutent pas ces transactions L2. Il est facile de constater que L2 ne stocke les données de transaction que dans des blocs Ethereum, ce qui entraîne des coûts de stockage, tandis que les coûts de calcul liés à l'exécution des transactions sont supportés par les nœuds L2 eux-mêmes. Ce qui précède est la méthode d'implémentation du DA d'Arbitrum, tandis qu'Optimism utilise une adresse EOA contrôlée par le séquenceur pour la transférer vers une autre adresse EOA spécifiée, contenant un nouveau lot de données de transaction de couche 2 dans les données supplémentaires. En ce qui concerne OpBnB, qui utilise l'OP Stack, sa méthode de publication des données DA est à peu près la même que celle d'Optimism.

Il est évident que le débit de la couche DA limitera la taille des données que Rollup peut publier par unité de temps, limitant ainsi le TPS. Étant donné qu'après l'EIP1559, la capacité de gaz de chaque bloc d'ETH se stabilise à 30 millions et que le temps de blocage après la fusion est d'environ 12 secondes, Ethereum ne peut gérer qu'un maximum de 2,5 millions de gaz par seconde. La plupart du temps, le gaz consommé en hébergeant les données de transaction L2 par octet dans les données d'appel est de 16. Ethereum peut donc gérer une taille maximale de données d'appel de 150 Ko par seconde seulement. En revanche, la taille moyenne maximale des données d'appel traitées par seconde par BSC est d'environ 2 910 Ko, soit 18,6 fois celle d'Ethereum. La différence entre les deux en tant que couches DA est évidente.

Pour résumer, Ethereum peut transporter environ 150 Ko de données de transactions L2 par seconde. Même après le lancement de l'EIP 4844, ce chiffre ne changera pas beaucoup, il ne fera que réduire les frais de DA. Combien de données de transactions peuvent donc être incluses dans environ 150 Ko par seconde ? Ici, nous devons expliquer le taux de compression des données du Rollup. Vitalik s'est montré trop optimiste en 2021, estimant qu'Optimistic Rollup peut réduire la taille des données de transaction à 11 % par rapport à la taille initiale. Par exemple, un transfert ETH de base, qui occupait à l'origine une taille de données d'appel de 112 octets, peut être compressé à 12 octets par Optimistic Rollup, les transferts ERC-20 peuvent être compressés à 16 octets et les transactions Swap sur Uniswap peuvent être compressées à 14 octets. Selon ses estimations, Ethereum peut enregistrer environ 10 000 transactions L2 par seconde (avec différents types mélangés). Cependant, selon les données divulguées par l'équipe Optimism en 2022, le taux de compression réel des données ne peut atteindre qu'un maximum d'environ 37 %, soit 3,5 fois moins que l'estimation de Vitalik.

(L'estimation de l'effet d'évolutivité du Rollup par Vitalik est très différente des conditions réelles)

(Taux de compression réels obtenus grâce à différents algorithmes de compression dévoilés par Optimism)

Donnons donc un chiffre raisonnable : même si Ethereum atteint sa limite de débit, le TPS maximum de tous les cumuls optimistes combinés n'est que légèrement supérieur à 2 000. En d'autres termes, si les blocs Ethereum étaient entièrement utilisés pour transporter les données publiées par Optimistic Rollups, telles que celles distribuées entre Arbitrum, Optimism, Base et Boba, le TPS combiné de ces Optimistic Rollups n'atteindrait même pas 3 000, même avec les algorithmes de compression les plus efficaces. De plus, il faut tenir compte du fait qu'après l'EIP1559, la capacité de gaz de chaque bloc n'est en moyenne que de 50 % de la valeur maximale. Le chiffre ci-dessus doit donc être réduit de moitié. Après le lancement de l'EIP4844, bien que les frais de transaction liés à la publication des données soient considérablement réduits, la taille maximale des blocs d'Ethereum ne changera pas beaucoup (car trop de changements affecteraient la sécurité de la chaîne principale des ETH). La valeur estimée ci-dessus n'augmentera donc pas beaucoup.

Selon les données d'Arbiscan et Etherscan, un lot de transactions sur Arbitrum contient 1 115 transactions, consommant 1,81 million de gaz sur Ethereum. Par extrapolation, si la couche DA est remplie dans chaque bloc, la limite TPS théorique d'Arbitrum est d'environ 1 500. Bien entendu, compte tenu de la réorganisation des blocs L1, Arbitrum ne peut pas publier de lots de transactions sur chaque bloc Ethereum. Les chiffres ci-dessus ne sont donc que théoriques pour le moment. De plus, avec l'adoption généralisée de portefeuilles intelligents liés à l'EIP 4337, le problème du DA ne fera que s'aggraver. Parce que grâce à la prise en charge de l'EIP 4337, la façon dont les utilisateurs vérifient leur identité peut être personnalisée, par exemple en téléchargeant des données binaires d'empreintes digitales ou d'iris, ce qui augmentera encore la taille des données occupées par les transactions régulières. Par conséquent, le faible débit de données d'Ethereum constitue le principal obstacle à l'efficacité du Rollup, et ce problème risque de ne pas être résolu correctement avant longtemps. En revanche, dans la chaîne BNB de la chaîne publique BSC, la taille moyenne maximale des données d'appel traitées par seconde est d'environ 2 910 Ko, soit 18,6 fois celle d'Ethereum. En d'autres termes, tant que la couche d'exécution peut suivre le rythme, la limite supérieure théorique du TPS de la couche 2 au sein de l'écosystème BNB Chain peut atteindre environ 18 fois celle de l'ARB ou de l'OP. Ce chiffre est calculé sur la base de la capacité de gaz maximale de 140 millions de dollars de la chaîne BNB actuelle, avec un temps de blocage de 3 secondes.

En d'autres termes, la limite TPS globale actuelle pour tous les rollups de l'écosystème BNB Chain est 18,6 fois supérieure à celle d'Ethereum (même si l'on considère zkRollup). De ce point de vue, il est facile de comprendre pourquoi tant de projets de couche 2 utilisent la couche DA de la chaîne Ethereum pour publier des données, car la différence est flagrante. Cependant, le problème n'est pas si simple. Outre le problème du débit de données, la stabilité de la couche 1 elle-même peut également affecter la couche 2. Par exemple, la plupart des Rollups attendent souvent plusieurs minutes avant de publier un lot de transactions sur Ethereum, compte tenu de la possibilité d'une réorganisation des blocs de couche 1. Si un bloc de couche 1 est réorganisé, cela affectera le registre de la blockchain de la couche 2. Par conséquent, le séquenceur attendra que plusieurs nouveaux blocs de couche 1 soient publiés après chaque publication d'un lot de transactions de niveau 2, ce qui réduit considérablement la probabilité d'annulation des blocs, avant de publier le lot de transactions de niveau 2 suivant. Cela retarde en fait la confirmation finale des blocs L2, réduisant ainsi la vitesse de confirmation des transactions importantes (les transactions importantes nécessitent des résultats irréversibles pour des raisons de sécurité). En résumé, les transactions effectuées en L2 ne deviennent irréversibles qu'après avoir été publiées dans les blocs de la couche DA et lorsque la couche DA a généré un certain nombre de nouveaux blocs. C'est une raison importante qui limite les performances du Rollup. Cependant, la vitesse de génération de blocs d'Ethereum est lente, il faut 12 secondes pour produire un bloc. En supposant que Rollup publie un lot de transactions L2 tous les 15 blocs, il y aura un intervalle de 3 minutes entre les différents lots, et après la publication de chaque lot, il devra encore attendre que plusieurs blocs de couche 1 soient générés avant de devenir irréversible (à condition qu'ils ne soient pas contestés). De toute évidence, le délai entre le lancement et l'irréversibilité des transactions sur la couche 2 d'Ethereum est assez long, ce qui ralentit la vitesse de règlement ; alors que BNB Chain ne met que 3 secondes à produire un bloc, et les blocs deviennent irréversibles en 45 secondes seulement (le temps qu'il faut pour produire 15 nouveaux blocs). Sur la base des paramètres actuels, en supposant le même nombre de transactions L2 et compte tenu de l'irréversibilité des blocs L1, le nombre de fois qu'OpBnB peut publier des données de transaction par unité de temps peut atteindre 8,53 fois celui d'Arbitrum (une fois toutes les 45 secondes pour le premier, et une fois toutes les 6,4 minutes pour le second). De toute évidence, la vitesse de règlement des transactions importantes sur OpBnB est bien plus rapide que sur Layer2 d'Ethereum. De plus, la taille maximale des données publiées par OpBnB à chaque fois peut atteindre 4,66 fois celle de la couche 2 d'Ethereum (la limite de gaz des blocs L1 du premier est de 140 millions, tandis que celle du second est de 30 millions). 8,53 * 4,66 = 39,74. Cela représente l'écart entre OpBnB et Arbitrum en termes de limite de TPS dans la pratique (actuellement, pour des raisons de sécurité, ARB semble réduire activement le TPS, mais en théorie, si le TPS devait être augmenté, il serait tout de même bien inférieur à celui d'OpBnB).

(Le séquenceur d'Arbitrum publie un lot de transactions toutes les 6 à 7 minutes)

(Le séquenceur d'OpBnB publie un lot de transactions toutes les 1 à 2 minutes, le plus rapide ne prenant que 45 secondes). Bien entendu, il y a une autre question cruciale à prendre en compte, à savoir les frais de gaz dans la couche DA. Chaque fois que L2 publie un lot de transactions, il y a un coût fixe de 21 000 gaz, sans rapport avec la taille des données d'appel, ce qui représente une dépense. Si les frais de gaz pour la couche DA/L1 sont élevés, ce qui fait que le coût fixe de la publication d'un lot de transactions sur la couche L2 reste élevé, le séquenceur réduira la fréquence de publication des lots de transactions. De plus, si l'on considère les composantes des frais L2, le coût de la couche d'exécution est très faible et peut souvent être ignoré, en se concentrant uniquement sur l'impact des coûts du DA sur les frais de transaction. En résumé, alors que la publication de données d'appels de la même taille consomme la même quantité de gaz sur Ethereum et BNB Chain, le prix du gaz facturé par Ethereum est environ 10 à dizaines de fois plus élevé que celui de BNB Chain. Traduits en frais de transaction L2, les frais de transaction actuels des utilisateurs sur Ethereum Layer2 sont également 10 à dizaines de fois plus élevés que ceux d'OpBnB. Dans l'ensemble, les différences entre OpBnB et Optimistic Rollup sur Ethereum sont assez apparentes.

(Une transaction consommant 150 000 essence sur Optimism coûte 0,21 dollar)

(Une transaction consommant 130 000 gaz sur OpBnB coûte 0,004 dollars) Cependant, l'augmentation du débit de données de la couche DA, bien que cela puisse améliorer le débit global du système Layer2, n'a qu'un impact limité sur l'amélioration des performances des cumuls individuels. Cela est dû au fait que la couche d'exécution ne traite souvent pas les transactions assez rapidement. Même si les limites de la couche DA peuvent être ignorées, la couche d'exécution devient le prochain goulot d'étranglement qui affectera les performances du Rollup. Si la vitesse d'exécution de la couche d'exécution de la couche 2 est lente, le dépassement de la demande de transactions s'étendra aux autres couches 2, ce qui finira par entraîner une fragmentation des liquidités. Par conséquent, il est également crucial d'améliorer les performances de la couche d'exécution, car elle constitue un seuil supplémentaire au-dessus de la couche DA.

L'amélioration de la couche d'exécution par OpBnB : optimisation du cache

Lorsque la plupart des gens parlent des problèmes de performances liés aux couches d'exécution de la blockchain, ils mentionnent inévitablement deux problèmes importants : l'exécution en série d'un seul thread de l'EVM qui n'utilise pas pleinement le processeur, et la recherche inefficace des données du Merkle Patricia Trie adopté par Ethereum. Les stratégies de mise à l'échelle de la couche d'exécution visent essentiellement à utiliser plus efficacement les ressources du processeur et à faire en sorte que le processeur puisse accéder aux données le plus rapidement possible.

Les solutions d'optimisation pour l'exécution d'EVM en série et Merkle Patricia Trie sont souvent complexes et difficiles à mettre en œuvre, tandis que les efforts les plus rentables ont tendance à se concentrer sur l'optimisation du cache. En fait, l'optimisation du cache nous ramène à des points fréquemment abordés dans les contextes Web2 traditionnels et même dans les manuels scolaires.

En général, la vitesse à laquelle le processeur extrait les données de la mémoire est des centaines de fois plus rapide que celle des données du disque. Par exemple, la récupération de données depuis la mémoire peut ne prendre que 0,1 seconde, alors que l'extraction depuis le disque peut prendre 10 secondes. Par conséquent, la réduction de la surcharge générée par les lectures et les écritures sur disque, c'est-à-dire l'optimisation du cache, devient un aspect essentiel de l'optimisation de la couche d'exécution de la blockchain.

Dans Ethereum et dans la plupart des autres chaînes publiques, la base de données qui enregistre les états des adresses de la chaîne est entièrement stockée sur disque, alors que ce que l'on appelle le World State trie n'est qu'un index de cette base de données, ou un répertoire utilisé pour la recherche de données. Chaque fois que l'EVM exécute un contrat, elle doit accéder aux états d'adresse pertinents. Extraire les données de la base de données sur disque une par une ralentirait considérablement l'exécution des transactions. Par conséquent, la mise en place d'un cache en dehors de la base de données/du disque est un moyen nécessaire pour accélérer.

OpBNB adopte directement la solution d'optimisation du cache utilisée par BNB Chain. Selon les informations divulguées par le partenaire d'OpBnB, NodeReal, la première chaîne BSC a mis en place trois couches de cache entre l'EVM et la base de données LevelDB stockant l'état. Le concept de conception est similaire à celui des caches à trois niveaux traditionnels, dans lesquels les données ayant une fréquence d'accès plus élevée sont stockées dans le cache. Cela permet au processeur de rechercher d'abord les données requises dans le cache. Si le taux d'accès au cache est suffisamment élevé, le processeur n'a pas besoin de trop compter sur le disque pour récupérer les données, ce qui se traduit par une amélioration significative de la vitesse d'exécution globale.

Plus tard, NodeReal a ajouté une fonctionnalité qui exploite les cœurs de processeur inutilisés pour lire de manière préventive les données que l'EVM devra traiter à l'avenir à partir de la base de données et les stocker dans le cache. Cette fonctionnalité s'appelle « préchargement par état ».

Le principe du préchargement par état est simple : les processeurs des nœuds blockchain sont multicœurs, tandis que l'EVM fonctionne en mode d'exécution série à thread unique, utilisant un seul cœur de processeur, laissant les autres cœurs sous-utilisés. Pour y remédier, les cœurs du processeur qui ne sont pas utilisés par l'EVM peuvent vous aider dans ses tâches en prédisant les données dont l'EVM aura besoin à partir de la séquence de transactions qui n'a pas encore été traitée. Ces cœurs de processeur extérieurs à l'EVM extrairont ensuite les données dont l'EVM aura besoin dans la base de données, ce qui aidera l'EVM à réduire les frais liés à la récupération des données et à accélérer ainsi son exécution.

Grâce à l'optimisation du cache et à des configurations matérielles suffisantes, OpBnB a réussi à augmenter les performances de la couche d'exécution de son nœud à un niveau proche de la limite de l'EVM, traitant jusqu'à 100 millions de gaz par seconde. Ces 100 millions de gaz constituent essentiellement le plafond de performance de l'EVM non modifié, comme le démontrent les données de tests expérimentaux réalisés par une importante chaîne publique.

Pour résumer, OpBnB peut traiter jusqu'à 4 761 transferts simples par seconde, 1 500 à 3 000 transferts de jetons ERC20 par seconde et environ 500 à 1 000 opérations SWAP par seconde, sur la base des données de transaction observées sur les explorateurs de chaînes de blocs. Si l'on compare les paramètres actuels, la limite TPS d'OpBNB est 40 fois supérieure à celle d'Ethereum, plus de 2 fois celle de BNB Chain et plus de 6 fois celle d'Optimism.

Bien entendu, pour les solutions Ethereum Layer2, en raison des limites sévères de la couche DA elle-même, les performances sont considérablement réduites en fonction des performances de la couche d'exécution, si l'on tient compte de facteurs tels que le temps de génération des blocs de la couche DA et la stabilité.

Pour BNB Chain dotée d'une couche DA à haut débit comme OpBNB, le double effet de la mise à l'échelle est précieux, surtout si l'on considère que BNB Chain peut héberger plusieurs projets de mise à l'échelle de ce type. On peut prévoir que BNB Chain a déjà intégré des solutions Layer2 basées sur OPBNB à ses plans stratégiques et qu'elle continuera à intégrer des projets de blockchain plus modulaires, notamment en introduisant des preuves ZK dans OpBNB et en fournissant des couches DA à haute disponibilité avec des infrastructures complémentaires telles que GreenField, dans le but de concurrencer ou de coopérer avec l'écosystème Ethereum Layer2.

À l'ère où la mise à l'échelle par couches est devenue la tendance, il reste à savoir si d'autres chaînes publiques se dépêcheront également de soutenir leurs propres projets de couche 2, mais il ne fait aucun doute que le changement de paradigme vers une infrastructure blockchain modulaire est déjà en cours.

Avertissement：

1. Cet article est reproduit depuis [Web3]. Tous les droits d'auteur appartiennent à l'auteur original [Faust, web3]. En cas d'objection à cette réimpression, contactez l'équipe de Gate Learn, elle s'en occupera rapidement.
2. Avertissement en matière de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas un conseil d'investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.