BNB Chain accélère les validateurs de 40 % avec BSC-Reth
📋 Résumé
BNB Chain affirme que la configuration la plus récente de BSC-Reth a augmenté d’environ 40 % le débit des validateurs lors de tests internes. Le client écrit en Rust devrait commencer à être adopté par les validateurs d’ici la fin de 2026, ce qui améliorera les performances et la diversité logicielle du réseau.
BNB Chain a présenté ce vendredi 6 de nouveaux résultats concernant BSC-Reth, un client d’exécution écrit en Rust et adapté aux conditions de forte charge de BNB Smart Chain. Selon l’équipe, la configuration basée sur Reth 2.5.1 a enregistré un débit supérieur d’environ 40 % à celui de la version précédente, qui utilisait TrieDB.
Ce gain provient encore de tests internes et non de mesures indépendantes en production. Le résultat reste néanmoins important, car le réseau prévoit de commencer la migration des validateurs vers BSC-Reth d’ici la fin de 2026. Concrètement, le projet vise à traiter les blocs plus efficacement sans dépendre uniquement du client basé sur Geth utilisé historiquement par BSC.
Pourquoi BSC a besoin d’un client plus rapide
D’après le rapport technique publié par BNB Chain, BSC réunit trois caractéristiques qui mettent à rude épreuve l’infrastructure des nœuds : un snapshot de 6,6 To, une moyenne observée de 246,7 transactions par seconde sur une période d’une heure et un intervalle de seulement 0,45 seconde entre les blocs. À titre de comparaison, l’équipe indique qu’Ethereum avait un snapshot de 1,6 To, 30,81 transactions par seconde et des blocs espacés de 12 secondes.
Ce profil réduit le temps disponible pour exécuter les transactions, calculer la racine d’état et persister les données avant le bloc suivant. La première étape de BSC-Reth avait déjà réduit de 34,9 % la latence p95 d’insertion des blocs et de 35,5 % la latence d’exécution par rapport à BSC-Geth. Cependant, la validation restait 23,8 % plus lente, ce qui révélait un goulot d’étranglement dans le calcul et la préparation de l’état.
L’équipe a alors intégré des fonctionnalités des versions 2.2.1 et 2.5.
📋 Résumé
BNB Chain affirme que la configuration la plus récente de BSC-Reth a augmenté d’environ 40 % le débit des validateurs lors de tests internes. Le client écrit en Rust devrait commencer à être adopté par les validateurs d’ici la fin de 2026, ce qui améliorera les performances et la diversité logicielle du réseau.
BNB Chain a présenté ce vendredi 6 de nouveaux résultats concernant BSC-Reth, un client d’exécution écrit en Rust et adapté aux conditions de forte charge de BNB Smart Chain. Selon l’équipe, la configuration basée sur Reth 2.5.1 a enregistré un débit supérieur d’environ 40 % à celui de la version précédente, qui utilisait TrieDB.
Ce gain provient encore de tests internes et non de mesures indépendantes en production. Le résultat reste néanmoins important, car le réseau prévoit de commencer la migration des validateurs vers BSC-Reth d’ici la fin de 2026. Concrètement, le projet vise à traiter les blocs plus efficacement sans dépendre uniquement du client basé sur Geth utilisé historiquement par BSC.
Pourquoi BSC a besoin d’un client plus rapide
D’après le rapport technique publié par BNB Chain, BSC réunit trois caractéristiques qui mettent à rude épreuve l’infrastructure des nœuds : un snapshot de 6,6 To, une moyenne observée de 246,7 transactions par seconde sur une période d’une heure et un intervalle de seulement 0,45 seconde entre les blocs. À titre de comparaison, l’équipe indique qu’Ethereum avait un snapshot de 1,6 To, 30,81 transactions par seconde et des blocs espacés de 12 secondes.
Ce profil réduit le temps disponible pour exécuter les transactions, calculer la racine d’état et persister les données avant le bloc suivant. La première étape de BSC-Reth avait déjà réduit de 34,9 % la latence p95 d’insertion des blocs et de 35,5 % la latence d’exécution par rapport à BSC-Geth. Cependant, la validation restait 23,8 % plus lente, ce qui révélait un goulot d’étranglement dans le calcul et la préparation de l’état.
L’équipe a alors intégré des fonctionnalités des versions 2.2.1 et 2.5.