Que change le hard fork Jenner de BNB Chain ?

BNB
capacité de gas par blochard fork JennerPayment Lanetestnet BSCBNB ChainBEP-703CAS20
il y a 1 heureSource: crypto.news
Que change le hard fork Jenner de BNB Chain ?

BNB Chain a activé le hardfork Jenner sur son testnet BNB Smart Chain, introduisant un nouveau mécanisme de traitement des paiements qui réserve 5 % de la capacité de gas des blocs pour les transactions éligibles pendant les périodes de congestion du réseau.

Résumé

  • BNB Chain a activé le hardfork Jenner sur le testnet BSC, introduisant Payment Lane ainsi que des horodatages de blocs à la milliseconde et des fonctionnalités pour le nouveau standard d'actifs CAS20.
  • Le mécanisme Payment Lane réserve 5 % de la capacité de gas de chaque bloc pour les paiements éligibles, empêchant le trafic général du réseau de consommer l'espace réservé pendant les périodes de congestion.
  • Les transactions éligibles incluent les transferts natifs de BNB vers des comptes sans code déployé et les transactions envoyées directement à des contrats de paiement approuvés par la gouvernance du réseau.
  • La gouvernance peut ajuster l'allocation de gas réservée jusqu'à un maximum de 10 %, tandis que les paiements éligibles continueront de rivaliser selon les règles de frais de transaction existantes.

Selon l'annonce du 29 octobre de BNB Chain, la mise à niveau introduit Payment Lane, des horodatages de blocs à la milliseconde pour les contrats intelligents, et des fonctionnalités pour CAS20, un nouveau standard d'actifs conforme.

Payment Lane est la principale caractéristique de la mise à niveau et est conçu pour maintenir une partie de chaque bloc disponible pour les paiements admissibles lorsque d'autres transactions se disputent la capacité du réseau.

Le hardfork fonctionne actuellement sur le testnet, le déploiement sur le mainnet étant initialement prévu pour fin novembre.

BNB Chain introduit une capacité de bloc réservée pour les paiements

Le nouveau mécanisme Payment Lane est introduit via le BEP-703, qui établit des règles de comptabilisation du gas distinctes pour les paiements éligibles et les transactions générales.

Pendant les périodes de forte activité du réseau, les transactions se disputent l'espace de bloc disponible selon les règles de frais existantes du réseau. Payment Lane modifie cet arrangement en réservant une partie de chaque bloc que les transactions générales ne peuvent pas utiliser.

BNB Chain a fixé la réservation par défaut à 5 % de la limite de gas d'un bloc, bien que les paiements admissibles ne soient pas limités à cette allocation.

Par exemple, dans un bloc hypothétique avec une limite de gas de 100 millions, 5 millions de gas seraient réservés aux paiements éligibles, laissant jusqu'à 95 millions disponibles pour les transactions générales.

Si les transactions de paiement consomment 8 millions de gas, elles peuvent utiliser une capacité au-delà de la réservation, laissant 92 millions pour les autres transactions.

Cependant, la capacité réservée non utilisée ne peut pas être réaffectée au trafic général. Si les paiements éligibles ne consomment que 2 millions de gas, les 3 millions restants demeurent inutilisés même lorsque d'autres transactions sont en attente.

BNB Chain a expliqué que cette restriction empêche les producteurs de blocs de remplir tout le bloc avec des transactions générales tout en excluant les paiements admissibles.

La mise à niveau fait suite à l'activation du hardfork Pasteur en août, qui a introduit des changements dans la vérification des ponts, l'autorisation des validateurs et la construction des blocs.

Comme crypto.news l'a précédemment rapporté, Pasteur a introduit un processus optionnel de construction de blocs sous le BEP-675 qui permet aux validateurs de signer et de diffuser les blocs proposés avant de terminer les vérifications complètes d'exécution.

Quelles transactions sont admissibles à Payment Lane ?

Selon les nouvelles règles, BNB Chain reconnaît deux catégories de transactions pouvant accéder à la capacité de gas réservée.

La première comprend les transactions envoyées directement à des contrats de paiement figurant sur une liste gérée par la gouvernance. La seconde couvre les transferts natifs de BNB impliquant un montant non nul envoyé à des comptes sans code déployé.

Les deux catégories doivent spécifier une adresse de destination et utiliser l'un des trois types de transactions pris en charge : 0x00, 0x01 ou 0x02.

La création de contrats, les transactions blob et les transactions de type 0x04 restent classées comme trafic général. Les transferts natifs de BNB vers des contrats intelligents ou des comptes avec code délégué ne sont pas admissibles dans la catégorie des transferts ordinaires.

Pour les stablecoins, l'éligibilité dépend de la présence ou non du contrat destinataire sur la liste de paiement approuvée.

Une transaction envoyée directement à un contrat de stablecoin répertorié peut être éligible, mais une transaction acheminée via un intermédiaire non répertorié ne bénéficie pas du même traitement simplement parce que l’intermédiaire transfère finalement le jeton.

La liste des contrats de paiement sera initialement vide. La gouvernance peut ensuite ajouter ou retirer des contrats éligibles, y compris des stablecoins et des jetons CAS20.

BNB Chain a précisé que le nom, le standard ou l’usage prévu d’un jeton pour les paiements ne rend pas automatiquement ses transactions éligibles.

Comment BNB Chain gérera-t-elle la capacité réservée ?

La gouvernance contrôlera à la fois la liste des contrats de paiement et le pourcentage de gas de bloc réservé aux transactions éligibles.

Bien que l’allocation par défaut soit de 5 %, le protocole permet à la gouvernance de porter la réservation à un maximum de 10 %.

La configuration est déterminée à l’aide de l’état du bloc parent, ce qui empêche les changements de gouvernance de modifier la classification des transactions pendant la construction d’un bloc individuel.

Les constructeurs de blocs doivent respecter les règles d’allocation lors de l’assemblage des transactions, tandis que les validateurs sont tenus de rejeter les blocs qui les enfreignent.

Dans le cadre du processus SendBidBlock de BEP-675, les contrôles d’exécution ont lieu lors de l’importation locale du bloc après la diffusion. Les violations sont traitées via le mécanisme de révocation du constructeur.

La réservation prend effet dans le bloc immédiatement suivant le bloc d’activation du hardfork.

Payment Lane ne garantit pas l’inclusion dans un bloc particulier et ne supprime pas les frais de transaction. Les paiements éligibles continueront de rivaliser entre eux, en particulier lorsque leur demande combinée dépasse la capacité réservée.

La mise à niveau Jenner suit l’activité croissante de BNB Chain

La dernière mise à niveau intervient après que BNB Chain a enregistré 1,51 milliard de transactions au cours du troisième trimestre 2026, soit une augmentation de 7,5 % par rapport au trimestre précédent.

Les revenus du réseau ont grimpé de 54 % pour atteindre 54,2 millions de dollars, tandis que le nombre moyen d’adresses actives quotidiennes a diminué de 14 % pour s’établir à 2,10 millions.

Un rapport trimestriel distinct sur l’écosystème a montré que les déploiements de contrats intelligents ont atteint 12,3 millions, contre 4,5 millions au trimestre précédent.

Au-delà de Payment Lane, Jenner introduit des horodatages de bloc à la milliseconde pour les contrats intelligents, offrant aux applications un accès à des informations temporelles plus précises.

La mise à niveau inclut des fonctionnalités pour CAS20, bien que BNB Chain ait indiqué que d’autres détails sur la disponibilité du standard seraient annoncés séparément.

Les développeurs et les fournisseurs de paiement peuvent désormais utiliser le testnet pour vérifier les destinations des transactions, les formats de transaction pris en charge et les exigences d’inscription à la gouvernance.

BNB Chain a orienté les opérateurs de nœuds vers la documentation de mise à niveau Jenner et les notes de version reth-bsc v0.1.3 pour les instructions pertinentes de mise à niveau du client.