BNB Smart Chain (BSC) a activé un nouveau mécanisme appelé Payment Lane sur son testnet, réservant 5 % de la limite de gaz de chaque bloc aux transactions de paiement éligibles. Cette fonctionnalité arrive avec BEP-703 dans le cadre du hardfork Jenner, désormais déployé sur le testnet de BSC, et est conçue pour protéger le trafic de paiement de la congestion causée par l'activité générale du réseau.

Les commerçants et les services de paiement sont fréquemment confrontés à une inclusion imprévisible des transactions lors des pics d'activité, et la nouvelle règle cible précisément ce problème. Pour les entreprises de paiement, une transaction qui reste en attente pendant un pic de congestion représente un règlement retardé plutôt qu'une simple question de frais abstraite, ce qui explique pourquoi la capacité de bloc garantie est devenue un critère de conception important. Les développeurs et les assembleurs de blocs peuvent désormais tester les intégrations sur le testnet avant tout déploiement potentiel sur le mainnet.

BNB Smart Chain est le réseau compatible avec la machine virtuelle Ethereum de BNB Chain, le BNB servant d'actif natif pour payer les frais de gaz. Le gaz est l'unité qui mesure le travail de calcul des transactions, et chaque bloc en contient une quantité maximale. Ce plafond faisant de l'espace de bloc une ressource finie, les transactions se disputent l'inclusion chaque fois que la demande est élevée — la situation que Payment Lane vise à atténuer.

Annonce sur X

BNB Chain Developers a indiqué sur X que les mécanismes de gouvernance pour CAS20 et Payment Lane ont été implémentés et vérifiés. Le hardfork Jenner apporte également les fondations de CAS20 et des horodatages à la milliseconde sur le testnet de BSC.

Governance mechanisms for CAS20 and Payment Lane have been implemented and verified. The Jenner hardfork now brings three key updates to BSC testnet: CAS20 functionality: Lays the groundwork for a new Compliant Asset Standard, with tools to manage token transfers, supply,… pic.twitter.com/gNUDLT2KsO

— BNB Chain Developers (@BNBChainDevs) 1er novembre 2026

Comment Payment Lane réserve la capacité des blocs

Payment Lane fonctionne comme une règle de comptabilisation du gaz appliquée lors de la validation des blocs, limitant la quantité de gaz que les transactions générales peuvent consommer. Les transactions de paiement et générales peuvent toujours apparaître dans n'importe quel ordre au sein d'un bloc.

Les transactions générales ne peuvent pas toucher au gaz réservé, même lorsque la demande de paiement est faible. Les paiements éligibles, quant à eux, peuvent puiser dans la réservation tout en continuant de se disputer la capacité restante selon les règles de frais existantes. La part de 5 % établit donc un minimum pour la capacité de paiement sans imposer de plafond à l'activité de paiement. À titre d'exemple, un bloc doté d'une limite de gaz de 100 millions réserverait 5 millions de gaz pour les paiements, laissant 95 millions pour les transactions générales.

Cette structure de plancher sans plafond est ce qui distingue une réservation d'un simple agrandissement de la limite de gaz des blocs : une limite plus élevée ajoute de la capacité pour tous les types de trafic à la fois, tandis qu'une réservation protège une part pour les paiements, quelle que soit l'intensité de l'activité générale.

Quelles transactions sont éligibles

Deux voies mènent à la classe de paiement. La première couvre les transactions envoyées directement à un contrat figurant sur la liste de paiement gérée par la gouvernance. La seconde couvre les transferts de BNB non nuls vers des comptes ne détenant aucun code.

Les deux voies exigent une adresse de destination et excluent les transactions système. Elles prennent en charge les types de transactions 0x00, 0x01 et 0x02. La création de contrats, les transactions blob et les transactions de type 0x04 comptent toutes comme du trafic général.

Pour les contrats listés, la classification dépend de l'adresse de destination, quelle que soit la fonction appelée. Un transfert de stablecoin envoyé directement à un contrat de jeton listé peut être éligible, tandis qu'une transaction envoyée à un routeur non listé ne l'est pas, même si le routeur déplace ensuite ce stablecoin. La liste des contrats de paiement commence vide. Tant que la gouvernance n'a pas ajouté les premiers contrats, la voie du transfert de BNB est le seul chemin vers la classe de paiement.

Règles de gouvernance et de validation

La gouvernance contrôle à la fois la liste des contrats de paiement et le ratio de réservation, qui est fixé par défaut à 5 % et comporte un maximum protocolaire de 10 %. Les nœuds lisent la configuration depuis l'état du bloc parent, ce qui signifie qu'une mise à jour ne peut pas modifier la classification en cours de bloc.

Les assembleurs de blocs doivent tenir compte de la réservation lors de l'assemblage des blocs, et les validateurs rejettent tout bloc dont l'allocation de gaz enfreint la règle. Dans le cadre du flux SendBidBlock de BEP-675, la vérification a lieu lors de l'import local après la diffusion, les violations étant traitées par le mécanisme de révocation des assembleurs.

Le gaz réservé non utilisé reste inutilisé par conception. Si les producteurs pouvaient le réaffecter, ils pourraient remplir les blocs de trafic général et exclure complètement les paiements.

Le mécanisme ne garantit ni l'inclusion, ni des frais fixes, ni des transferts gratuits. Les équipes peuvent utiliser le testnet pour vérifier les adresses de destination, les types de transactions et l'inscription via la gouvernance, et la réservation s'applique d'abord dans le bloc suivant immédiatement l'activation du fork. À partir de là, les indicateurs observables seront les décisions de gouvernance sur les contrats admis dans la liste de paiement, tout ajustement du ratio dans la limite protocolaire de 10 %, et le comportement du testnet avant tout déploiement potentiel sur le mainnet.

Reportage via Blockonomi.