BNB Chain a activé le hard fork Pasteur sur le réseau principal de BNB Smart Chain à 02:30 UTC le 25 août, introduisant trois changements axés sur la sécurité des ponts, l'autorisation des validateurs et la capacité des blocs.
Résumé
- BNB Chain a activé Pasteur sur le réseau principal BSC à 02:30 UTC le 25 août 2026, avec succès.
- Trois propositions renforcent la vérification des ponts, l'autorisation des validateurs et la construction de blocs sans réduire davantage les temps de bloc.
- BEP-682 rejette les validateurs en double lors des vérifications de blocs légers inter-chaînes, protégeant ainsi les exigences d'approbation de supermajorité authentiques sur la chaîne.
- Les benchmarks QANet ont augmenté le débit de 88 %, passant de 1 237 à 2 324 transactions par seconde dans des conditions contrôlées.
- Les opérateurs de nœuds devaient avoir la version client 1.7.7 et supprimer EnableBAL avant l'activation du réseau principal mardi.
Le réseau a confirmé que Pasteur était en ligne après son activation prévue. BSC a continué à produire des blocs à son intervalle existant de 450 millisecondes, sans perturbation majeure signalée publiquement immédiatement après la mise à niveau.
Pasteur combine BEP-682, BEP-695 et BEP-675 dans le cadre du plan de mise à niveau plus large BEP-673. Les changements avaient fonctionné sur le testnet Chapel de BSC depuis le 21 juillet avant d'atteindre le réseau principal.
BNB Chain Pasteur renforce la vérification des ponts
BEP-682 modifie la manière dont BSC vérifie les blocs légers soumis via l'infrastructure inter-chaînes. Avant Pasteur, le processus de vérification ne rejetait pas explicitement les entrées en double dans une liste de validateurs soumise.
Une demande conçue pouvait donc inclure le même validateur plus d'une fois. Compter ces entrées séparément risquait de faire apparaître une approbation de pont comme ayant le soutien de plus de validateurs indépendants qu'elle n'en avait réellement.
Pasteur rejette les entrées de validateurs répétées avant de calculer si le seuil de vote requis a été atteint. Chaque approbation doit maintenant provenir d'un validateur distinct pour que le bloc léger satisfasse à l'exigence de supermajorité.
BNB Chain n'a pas signalé que des attaquants avaient exploité la faille ni attribué de pertes d'actifs antérieures à celle-ci. Le changement est une correction préventive de la vérification des ponts plutôt qu'une réponse à un vol divulgué.
L'infrastructure inter-chaînes reste une préoccupation majeure en matière de sécurité dans les réseaux décentralisés. Dans une couverture connexe, les attaques de ponts ont causé des pertes cumulées de plusieurs milliards de dollars via des clés compromises, des failles de contrats et une vérification de messages faible.
Les anciennes clés de validateur perdent leur autorité
BEP-695 comble les lacunes concernant la rotation des clés de validateur, les pénalités et la gouvernance. Lorsqu'un validateur remplace sa clé d'opérateur, l'ancienne clé perd désormais ses droits de gestion.
La proposition empêche également les validateurs d'échapper aux pénalités en attente en faisant tourner leurs clés. Les processus de slash et de retrait restent attachés au validateur plutôt que de disparaître lorsque son adresse d'opérateur change.
Pasteur bloque en outre les adresses restreintes pour qu'elles utilisent des signatures hors chaîne afin de participer à la gouvernance. BNB Chain empêchait déjà les adresses sur liste noire de voter directement, mais ces comptes pouvaient potentiellement signer des votes et avoir une autre adresse les soumettre.
Les contrats de gouvernance mis à jour vérifient le signataire d'origine avant de compter un vote délégué. Si ce signataire est restreint, le vote est rejeté quel que soit le compte qui le soumet.
Nouvelle route de bloc réduit l'exécution répétée
BEP-675 introduit une route optionnelle pour les constructeurs spécialisés afin de soumettre des blocs qu'ils ont déjà exécutés. Les validateurs vérifient le bloc proposé par rapport aux règles de consensus, le signent et le diffusent avant de terminer la vérification complète de l'exécution.
L'ancienne voie exigeait que le constructeur et le validateur exécutent les transactions avant que le validateur ne signe. Cette duplication consommait une partie de la courte fenêtre de bloc de BSC et pouvait laisser les blocs en dessous de leur capacité maximale pendant les périodes de forte demande.
Les constructeurs peuvent continuer à utiliser le processus précédent. La nouvelle voie doit être activée via l'interface d'appel de procédure à distance du réseau, donnant aux participants le temps de l'intégrer.
BNB Chain a déclaré que la voie pourrait intégrer plus de transactions dans chaque bloc, mais ses chiffres de performance publiés provenaient de tests contrôlés plutôt que de l'activité du réseau principal.
Les tests sur QANet, un environnement interne conçu pour refléter des validateurs géographiquement distribués, ont augmenté le débit de 1 237 à 2 324 transactions par seconde. La consommation moyenne de gaz par bloc est passée de 46,35 millions à 84,15 millions, tandis que la limite de gaz de 100 millions restait inchangée.
Les données du réseau principal testeront le gain de capacité de 88 %
Pasteur n'augmente pas la limite de gaz par bloc ni ne réduit l'intervalle de bloc de 450 millisecondes introduit par la mise à niveau Fermi. Ses gains de capacité dépendent de l'adoption de BEP-675 par les constructeurs et de la soumission de blocs plus complets.
BNB Chain a exigé que les opérateurs de nœuds installent la version 1.7.7 du client avant l'activation. Les opérateurs devaient également supprimer le champ EnableBAL obsolète, car le laisser dans le fichier de configuration empêcherait le client mis à jour de démarrer.
Comme rapporté précédemment, BNB Chain a averti les opérateurs de terminer la mise à jour obligatoire de Pasteur avant le fork. Les opérateurs exécutant un logiciel incompatible risquaient de se désynchroniser du réseau principal.
Les prochaines preuves viendront de l'utilisation des blocs en direct, du débit des transactions, des taux de blocs manqués et des performances des validateurs. Ces mesures montreront si l'amélioration de la capacité de QANet se répercute sur la demande soutenue du réseau principal.
