BNB Chain a déployé la mise à jour BEP-675 sur sa BSC Testnet le 7 août, augmentant le débit de 1 237 transactions par seconde à 2 324 TPS. Soit une hausse de 88 %, obtenue sans modifier l'intervalle de bloc ni la limite de gaz.
Comment fonctionne réellement BEP-675
Avant cette mise à jour, le processus de construction des blocs BSC présentait un problème de redondance significatif. Les constructeurs de blocs assemblaient et exécutaient les transactions, puis les validateurs réexécutaient les mêmes transactions pour les vérifier.
BEP-675 introduit un nouveau mécanisme appelé SendBidBlock, qui permet aux constructeurs de blocs de soumettre directement des blocs entièrement exécutés. Les validateurs peuvent alors sauter l'étape de réexécution redondante, en faisant confiance aux résultats préexécutés tout en préservant le modèle de sécurité de la chaîne.
Les gains de performance issus de la suppression de cette redondance sont considérables. Le temps d'exécution du validateur du chemin critique est passé d'environ 125 ms à seulement 15 ms. Pour y voir plus clair, l'étape d'exécution qui consommait auparavant plus d'un quart de chaque intervalle de bloc de 450 ms ne représente désormais qu'environ 3 % de celui-ci.
Ce gain de marge se traduit directement par une utilisation plus élevée du gaz. La consommation médiane de gaz par bloc est passée de 29,49 M à 98,99 M, ce qui signifie que les blocs qui utilisaient auparavant moins d'un tiers de leur limite de 100 M de gaz sont désormais presque entièrement remplis. Même taille de bloc, même temporisation, une quantité considérablement plus importante de calculs réels par bloc.
La mise à niveau a d'abord été rédigée sous forme de proposition le 10 avril et a été mise en ligne sur la testnet environ quatre mois plus tard. Les flux Legacy SendBid restent pris en charge pour la compatibilité ascendante, bien que les développeurs souhaitant utiliser le nouveau mécanisme SendBidBlock doivent faire fonctionner un nœud complet.
La configuration de test et ce qui suit
BNB Chain a effectué l'évaluation de la testnet en utilisant une configuration interne QANet multi-régions conçue pour reproduire la topologie réelle du mainnet. En simulant des conditions multi-régions, le chiffre de 2 324 TPS devrait constituer une approximation plus précise de ce que le mainnet pourrait réellement offrir.
Les tests ont couvert diverses charges de transaction, et non seulement des transferts de jetons simples.
BEP-675 s'inscrit dans une feuille de route technique plus large pour BNB Chain au H2 2026. La chaîne a suivi une trajectoire d'extension agressive, ayant déjà réduit les intervalles de bloc à 450 ms et poussé le débit de référence à près de 5 200 TPS lors des phases précédentes en 2025 et au début de 2026. Le prochain objectif est un nouveau doublement du débit du mainnet, avec un objectif à plus long terme d'atteindre une amélioration de 10 fois par rapport aux performances de référence actuelles.
Après la phase testnet réussie, les prochaines étapes immédiates incluent la validation à l'échelle du mainnet. La feuille de route prévoit également d'autres améliorations, notamment FOCIL (qui concerne les listes d'inclusion forcée, un mécanisme conçu pour prévenir la censure au niveau de la production de blocs) et les listes d'accès au niveau des blocs, qui pourraient encore optimiser l'efficacité d'exécution.
Pourquoi le MEV est important ici
BEP-675 réduit la charge opérationnelle que l'infrastructure MEV impose à la chaîne critique. BNB Chain a explicitement présenté cette mise à jour comme une réponse aux goulots d'étranglement causés par les inefficacités MEV. En repensant le mécanisme de soumission afin que les constructeurs livrent des blocs entièrement exécutés, l'étape redondante de ré-exécution, qui était en partie une conséquence des hypothèses de confiance intégrées aux architectures sensibles à MEV, est éliminée.
Si le déploiement sur le mainnet correspond aux résultats de la testnet, BNB Chain aura presque doublé son débit pratique sans exiger que les utilisateurs ou les développeurs de dapps modifient quoi que ce soit dans leur interaction avec le réseau. Les garanties de finalité et le temporisation des blocs restent identiques.