BNBスマートチェーン(BSC)はテストネットで「Payment Lane」と呼ばれる新メカニズムを有効化し、各ブロックのガス上限の5%を適格な決済トランザクション用に確保した。この機能は、現在BSCテストネットで稼働しているJennerハードフォークの一環としてBEP-703のもとで導入されたものであり、一般のネットワーク活動が引き起こす混雑から決済トラフィックを保護することを目的としている。

決済業者や決済サービスは、活動が急増する期間にトランザクションの取り込みが予測不能になるという問題に頻繁に直面しており、新ルールはまさにこの問題を狙い撃ちにしたものだ。決済ビジネスにとって、混雑の急増の間待たされるトランザクションは抽象的な手数料の問題ではなく決済の遅延を意味するため、保証されたブロック容量は重要な設計上の検討事項となっている。開発者とブロックビルダーは、メインネット展開の可能性を前にして、テストネット上で統合のテストを行うことができる。

BNBスマートチェーンは、BNB ChainのEthereum Virtual Machine互換ネットワークであり、BNBがガス代の支払いに使用されるネイティブ資産として機能している。ガスとはトランザクションの計算作業量を測る単位であり、各ブロックには最大量が設定されている。この上限によりブロックスペースは有限のリソースとなるため、需要が高まるとトランザクションは取り込みを巡って競合する。Payment Laneはまさにこの状況を緩和するために設計された。

Xでの発表

BNB Chain DevelopersはX上で、CAS20とPayment Laneのガバナンスメカニズムが実装・検証済みであると発表した。Jennerハードフォークは、CAS20の基盤とミリ秒単位のタイムスタンプも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) 2026年11月1日

Payment Laneがブロック容量を確保する仕組み

Payment Laneは、ブロック検証時に強制されるガス会計ルールとして機能し、一般トランザクションが消費できるガス量を制限する。決済トランザクションと一般トランザクションは、ブロック内でどのような順序でも現れることが可能だ。

決済需要が低い場合でも、一般トランザクションは確保されたガスに触れることはできない。一方、適格な決済トランザクションは確保分を利用でき、既存の手数料ルールの下で残りの容量も引き続き競うことができる。したがって、5%の配分は決済容量の下限を設定するものであり、決済活動に上限を設けるものではない。例として、ガス上限1億のブロックでは500万のガスが決済用に確保され、9,500万が一般トランザクション用に残される。

この「上限ではなく下限」という構造こそが、単にブロックガス上限を拡大することとの違いである。上限の拡大はすべてのトラフィック種別の容量を同時に増やすのに対し、確保は一般活動がどれほど活発になっても決済のための割合を保護する。

対象となるトランザクション

決済クラスへの経路は2つある。1つ目は、ガバナンスが管理する決済リストに含まれるコントラクトへ直接送信されるトランザクションである。2つ目は、コードを保持しないアカウントへのBNBの非ゼロ送金である。

両経路とも宛先アドレスを必要とし、システムトランザクションは対象外となる。対応するトランザクションタイプは0x00、0x01、0x02である。コントラクトの作成、blobトランザクション、タイプ0x04のトランザクションは、いずれも一般トラフィックとして扱われる。

リスト登録済みコントラクトの場合、分類は呼び出される関数にかかわらず宛先アドレスによって決まる。リスト登録済みトークンコントラクトに直接送信されるステーブルコインの送金は対象となり得るが、未登録のルーターに送信されたトランザクションは、そのルーターが後からそのステーブルコインを移動させる場合でも対象とならない。決済コントラクトリストは初期状態では空である。ガバナンスが最初のコントラクトを追加するまで、BNB送金の経路が決済クラスに入る唯一の手段となる。

ガバナンスとバリデーターのルール

ガバナンスは決済コントラクトリストと確保比率の両方を管理しており、比率のデフォルトは5%、プロトコルの上限は10%である。ノードは親ブロックの状態から設定を読み込むため、更新によってブロックの途中で分類が変更されることはない。

ブロックビルダーはブロックを組み立てる際に確保分を考慮する必要があり、ガス配分がルールに違反するブロックはバリデーターに拒否される。BEP-675のSendBidBlockフローでは、チェックはブロードキャスト後のローカル取り込み時に実施され、違反はビルダー失格のメカニズムを通じて処理される。

未使用の確保ガスは設計上、遊休状態のままとなる。プロデューサーがこれを再割り当てできてしまうと、一般トラフィックでブロックを埋め立て、決済を完全に締め出すことが可能になってしまう。

このメカニズムは、トランザクションの取り込み、固定手数料、無料送金を保証するものではない。チームはテストネットを利用して宛先、トランザクションタイプ、ガバナンスによるリスト登録を検証でき、確保はフォーク有効化直後のブロックから初めて適用される。今後の注視点は、どのコントラクトが決済リストに入るかに関するガバナンスの決定、10%のプロトコル上限内での比率調整の有無、そしてメインネット展開の可能性を前にしたテストネットでの挙動である。

Blockonomi経由の報道。