BNB Chain a activé le hard fork Pasteur sur le réseau principal de la BNB Smart Chain le 25 août à 02h30 UTC, introduisant trois changements axés sur la sécurité des ponts, l'autorisation des validateurs et la capacité des blocs.
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 les BEP-682, BEP-695 et BEP-675 sous le 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.
BEP-682 modifie la façon 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 dupliquées dans une liste de validateurs soumise.
Une requête forgée pouvait donc inclure le même validateur plus d'une fois. Le fait de compter ces entrées séparément risquait de faire paraître qu'une approbation de pont avait 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 ou attribué des pertes d'actifs antérieures à celle-ci. Le changement est une correction préventive à 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é pour les réseaux décentralisés. Dans des articles connexes, les attaques de ponts ont causé des milliards de dollars de pertes cumulées en raison de clés compromises, de failles contractuelles et de vérification de messages faibles.
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, la clé précédente perd désormais ses droits de gestion.
La proposition empêche également les validateurs d'échapper aux pénalités en attente en faisant pivoter leurs clés. Les processus de slashing et de suppression 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 d'utiliser des signatures hors chaîne pour participer à la gouvernance. BNB Chain empêchait déjà les adresses mises sur liste noire de voter directement, mais ces comptes pouvaient potentiellement signer des votes et demander à une autre adresse de les soumettre.
Les contrats de gouvernance mis à jour vérifient le signataire original avant de comptabiliser un vote délégué. Si ce signataire est restreint, le vote est rejeté quelle que soit l'adresse qui le soumet.
BEP-675 introduit une route optionnelle permettant aux constructeurs spécialisés 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 compléter la vérification complète de l'exécution.
La route précédente 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 route doit être activée via l'interface d'appel de procédure distante du réseau, donnant aux participants le temps de l'intégrer.
BNB Chain a déclaré que la route pourrait insérer 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 est restée inchangée.
Pasteur n'augmente pas la limite de gaz des blocs et ne réduit pas l'intervalle de bloc de 450 millisecondes introduit par la mise à niveau Fermi. Ses gains de capacité dépendent des constructeurs qui adoptent BEP-675 et soumettent des blocs plus remplis.
BNB Chain a exigé des opérateurs de nœuds qu'ils installent la version client 1.7.7 avant l'activation. Les opérateurs devaient également supprimer le champ déprécié EnableBAL, car le laisser dans le fichier de configuration empêcherait le client mis à jour de démarrer.
Comme indiqué précédemment, BNB Chain a averti les opérateurs de terminer la mise à jour obligatoire de Pasteur avant la fourche. Les opérateurs exécutant un logiciel incompatible risquaient de se désynchroniser avec le réseau principal.
Les prochaines preuves proviendront de l'utilisation réelle des blocs, 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 traduit par une demande soutenue sur le réseau principal.
