Mise à jour critique à venir sur les indicateurs de la chaîne BNB Chain avant le hard fork du 28 avril - U.Today

Le compte à rebours pour le hard fork Osaka/Mendel a commencé. À cette lumière, le compte X des développeurs de BNB Chain publie une annonce aux opérateurs de nœuds concernant une mise à jour obligatoire à effectuer avant le 28 avril.

Le hard fork Osaka/Mendel sera lancé sur le réseau principal BSC dans 16 jours, le 28 avril à 2 h 30 (UTC).

Avant le hard fork Osaka/Mendel, les opérateurs de nœuds doivent préparer leurs nœuds et effectuer la mise à niveau vers BSC v1.7.2. Il est également important de s’assurer que le remplacement binaire est correctement configuré et de supprimer tous les champs de configuration obsolètes. Ceci vise à empêcher leurs nœuds de perdre la synchronisation.

La mise à niveau du réseau principal Osaka intervient environ un mois après son lancement sur testnet. Le 24 mars, le hard fork Osaka/Mendel a été activé sur le BSC testnet au bloc 88,379,325. La mise à niveau a permis une construction de blocs plus fiable, une meilleure gestion des transactions à grande échelle, une stabilité du réseau renforcée et une exactitude d’exécution améliorée.

Hard fork Osaka/Mendel

Mendel introduit EIP-7825 via BEP-652, ce qui ajoute un plafond de limite de gaz pour les transactions au niveau du protocole.

BEP-652 suggère de mettre en œuvre une limite au niveau du protocole sur la consommation maximale de gaz pour chaque transaction sur BSC, en la plafonnant à 16,777,216 (ou 2^24).

Cela garantit que tous les nœuds rejettent uniformément les transactions dépassant la limite, ce qui peut mieux améliorer la stabilité et la fiabilité du réseau par rapport à l’approche précédente qui reposait sur un mécanisme de soft cap optionnel.

La mise à niveau du réseau Mendel englobe neuf BEP. Parmi les 13 EIP proposés dans le périmètre Fusaka d’Ethereum, BSC en a intégré sept. Cela a inclus six nécessitant un hard fork et un en tant que mise à jour RPC côté client. Les six autres EIP n’ont pas été adoptés, principalement en raison de divergences architecturales. En plus de cela, la mise à niveau apporte également deux améliorations propres à BSC. Par exemple, BEP-657 limite l’inclusion des transactions de type blob en fonction du numéro de bloc. BEP-648, quant à lui, vise à réduire la latence et à accélérer la finalité.