BNB Smart Chain (BSC) активировала в тестнете новый механизм под названием Payment Lane, резервирующий 5% лимита газа каждого блока для подходящих платежных транзакций. Функция представлена в рамках BEP-703 как часть хардфорка Jenner, который уже работает в тестнете BSC, и призвана защитить платежный трафик от перегрузки, вызванной общей сетевой активностью.

Магазины и платежные сервисы нередко сталкиваются с непредсказуемым включением транзакций в периоды всплесков активности, и новое правило нацелено именно на эту проблему. Для платежных компаний транзакция, ожидающая в очереди во время скачка нагрузки, — это отложенный расчет, а не абстрактный вопрос комиссий, поэтому гарантированная емкость блока стала значимым фактором при проектировании. Разработчики и сборщики блоков теперь могут тестировать интеграции в тестнете до возможного развертывания в мейннете.

BNB Smart Chain — это совместимая с Ethereum Virtual Machine сеть экосистемы BNB Chain, где BNB служит нативным активом для оплаты комиссий за газ. Газ — это единица измерения вычислительной работы транзакций, и каждый блок имеет максимальный объем газа. Поскольку этот потолок делает пространство блоков конечным ресурсом, при высоком спросе транзакции конкурируют за включение — именно эту ситуацию Payment Lane призван смягчить.

Анонс в X

BNB Chain Developers сообщили в X, что механизмы управления для CAS20 и Payment Lane реализованы и проверены. Хардфорк Jenner также приносит в тестнет BSC основу для CAS20 и миллисекундные метки времени.

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) 1 ноября 2026 г.

Как Payment Lane резервирует емкость блоков

Payment Lane работает как правило учета газа, применяемое при валидации блоков и ограничивающее объем газа, который могут потреблять обычные транзакции. Платежные и обычные транзакции по-прежнему могут располагаться в блоке в любом порядке.

Обычные транзакции не могут использовать зарезервированный газ, даже когда спрос на платежи низок. При этом подходящие платежи могут задействовать резерв и по-прежнему конкурировать за оставшуюся емкость по действующим правилам комиссий. Таким образом, доля в 5% устанавливает минимум для платежной емкости, не устанавливая потолок для платежной активности. Для примера: блок с лимитом газа в 100 миллионов зарезервировал бы 5 миллионов газа для платежей, оставив 95 миллионов для обычных транзакций.

Именно структура «пол, а не потолок» отличает резервирование от простого увеличения лимита газа блока: больший лимит добавляет емкость для всех типов трафика сразу, тогда как резервирование защищает долю для платежей независимо от того, насколько интенсивной становится общая активность.

Какие транзакции соответствуют требованиям

В платежный класс ведут два пути. Первый охватывает транзакции, отправленные напрямую на контракт, включенный в управляемый governance список платежных контрактов. Второй охватывает ненулевые переводы BNB на аккаунты, не содержащие кода.

Оба пути требуют адреса назначения и исключают системные транзакции. Поддерживаются типы транзакций 0x00, 0x01 и 0x02. Создание контрактов, blob-транзакции и транзакции типа 0x04 считаются обычным трафиком.

Для включенных в список контрактов классификация зависит от адреса назначения независимо от вызываемой функции. Перевод стейблкоина, отправленный напрямую на включенный в список токен-контракт, может соответствовать требованиям, тогда как транзакция, отправленная на невключенный роутер, не соответствует, даже если роутер впоследствии перемещает этот стейблкоин. Список платежных контрактов изначально пуст. Пока governance не добавит первые контракты, путь через перевод BNB остается единственным способом попасть в платежный класс.

Правила governance и валидаторов

Governance управляет как списком платежных контрактов, так и коэффициентом резервирования, который по умолчанию составляет 5% и имеет максимум в 10% на уровне протокола. Узлы считывают конфигурацию из состояния родительского блока, поэтому обновление не может изменить классификацию в середине блока.

Сборщики блоков должны учитывать резервирование при формировании блоков, а валидаторы отклоняют любой блок, распределение газа в котором нарушает правило. В рамках потока SendBidBlock из BEP-675 проверка выполняется при локальном импорте после трансляции, а нарушения направляются через механизм отзыва сборщика.

Неиспользованный зарезервированный газ по замыслу остается незадействованным. Если бы производители могли переназначать его, они могли бы заполнять блоки обычным трафиком и полностью исключать платежи.

Механизм не гарантирует включение транзакций, фиксированные комиссии или бесплатные переводы. Команды могут использовать тестнет для проверки адресов назначения, типов транзакций и включения в список через governance, а резервирование впервые применяется в блоке, следующем сразу за активацией форка. Далее наблюдаемыми ориентирами станут решения governance о том, какие контракты войдут в платежный список, любые корректировки коэффициента в пределах максимума в 10% на уровне протокола, а также поведение тестнета до возможного развертывания в мейннете.

Материал подготовлен на основе Blockonomi.