BNB Smart Chain (BSC) uruchomił na swoim testnecie nowy mechanizm o nazwie Payment Lane, rezerwujący 5% limitu gazu każdego bloku na kwalifikowane transakcje płatnicze. Funkcja została wprowadzona w ramach BEP-703 jako część hard forku Jenner, który jest już aktywny na testnecie BSC, i ma chronić ruch płatniczy przed przeciążeniami powodowanymi przez ogólną aktywność sieci.

Sprzedawcy i usługi płatnicze często mierzą się z nieprzewidywalnym włączaniem transakcji do bloków podczas nagłych wzrostów aktywności, a nowa reguła ma bezpośrednio rozwiązać ten problem. Dla firm płatniczych transakcja oczekująca podczas skoku przeciążenia oznacza opóźnione rozliczenie, a nie wyłącznie abstrakcyjną kwestię opłat, dlatego gwarantowana przepustowość bloku stała się istotnym elementem projektowym. Deweloperzy i twórcy bloków mogą teraz testować integracje na testnecie przed ewentualnym wdrożeniem w sieci głównej.

BNB Smart Chain to kompatybilna z Ethereum Virtual Machine sieć BNB Chain, w której BNB jest natywnym aktywem wykorzystywanym do opłacania opłat za gaz. Gaz jest jednostką mierzącą nakład obliczeniowy transakcji, a każdy blok ma jego maksymalną ilość. Ponieważ ten limit sprawia, że przestrzeń bloku jest ograniczonym zasobem, transakcje rywalizują o włączenie do bloku, gdy popyt rośnie — właśnie ten problem Payment Lane ma łagodzić.

Ogłoszenie na X

BNB Chain Developers poinformowali na X, że mechanizmy zarządzania dla CAS20 i Payment Lane zostały wdrożone i zweryfikowane. Hard fork Jenner wprowadza również podstawy CAS20 oraz znaczniki czasu z dokładnością do milisekund na testnecie 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) November 1, 2026

Jak Payment Lane rezerwuje przepustowość bloku

Payment Lane działa jako reguła księgowania gazu egzekwowana podczas walidacji bloku, ograniczając ilość gazu, którą mogą zużyć zwykłe transakcje. Transakcje płatnicze i zwykłe mogą nadal pojawiać się w dowolnej kolejności w obrębie bloku.

Zwykłe transakcje nie mogą wykorzystać zarezerwowanego gazu, nawet gdy popyt na płatności jest niski. Kwalifikowane płatności mogą natomiast korzystać z rezerwy i nadal rywalizować o pozostałą przepustowość zgodnie z obowiązującymi zasadami opłat. Udział wynoszący 5% ustanawia zatem minimum przepustowości dla płatności, ale nie wyznacza górnego limitu aktywności płatniczej. Przykładowo, blok z limitem 100 milionów gazu rezerwowałby 5 milionów gazu na płatności, pozostawiając 95 milionów gazu dla zwykłych transakcji.

Ta struktura, wyznaczająca dolny, a nie górny limit, odróżnia rezerwację od prostego zwiększenia limitu gazu bloku: wyższy limit zwiększa jednocześnie przepustowość dla każdego rodzaju ruchu, podczas gdy rezerwa chroni określony udział dla płatności niezależnie od natężenia ogólnej aktywności.

Które transakcje się kwalifikują

Do klasy płatności prowadzą dwie ścieżki. Pierwsza obejmuje transakcje wysyłane bezpośrednio do kontraktu znajdującego się na liście płatniczej zarządzanej przez system zarządzania. Druga obejmuje niezerowe transfery BNB na konta, które nie zawierają kodu.

Obie ścieżki wymagają adresu docelowego i wykluczają transakcje systemowe. Obsługują typy transakcji 0x00, 0x01 i 0x02. Tworzenie kontraktów, transakcje blob oraz transakcje typu 0x04 są zaliczane do zwykłego ruchu.

W przypadku wymienionych kontraktów klasyfikacja zależy od adresu docelowego, niezależnie od wywoływanej funkcji. Transfer stablecoina wysłany bezpośrednio do wymienionego kontraktu tokena może się kwalifikować, natomiast transakcja wysłana do routera, którego nie ma na liście, nie kwalifikuje się, nawet jeśli router następnie przeniesie tego stablecoina. Lista kontraktów płatniczych zaczyna się jako pusta. Do czasu dodania pierwszych kontraktów przez zarządzanie jedyną ścieżką do klasy płatności pozostaje transfer BNB.

Zasady zarządzania i walidacji

Zarządzanie kontroluje zarówno listę kontraktów płatniczych, jak i współczynnik rezerwy, który domyślnie wynosi 5%, a jego protokołowe maksimum to 10%. Węzły odczytują konfigurację ze stanu bloku nadrzędnego, co oznacza, że aktualizacja nie może zmienić klasyfikacji w połowie bloku.

Twórcy bloków muszą uwzględniać rezerwę podczas składania bloków, a walidatorzy odrzucają każdy blok, którego alokacja gazu narusza tę regułę. W ramach przepływu BEP-675 SendBidBlock sprawdzenie odbywa się podczas lokalnego importu po rozgłoszeniu, a naruszenia są kierowane do mechanizmu cofnięcia uprawnień twórcy.

Niewykorzystany zarezerwowany gaz pozostaje celowo bezczynny. Gdyby producenci mogli go ponownie przydzielać, mogliby wypełniać bloki zwykłym ruchem i całkowicie pomijać płatności.

Mechanizm nie gwarantuje włączenia transakcji do bloku, stałych opłat ani bezpłatnych transferów. Zespoły mogą korzystać z testnetu w celu weryfikacji adresów docelowych, typów transakcji i wpisów w zarządzanej liście, a rezerwa zaczyna obowiązywać w bloku bezpośrednio po aktywacji hard forku. Od tego momentu obserwowanymi wskaźnikami będą decyzje zarządzania dotyczące kontraktów dodawanych do listy płatniczej, ewentualne zmiany współczynnika w ramach jego protokołowego limitu wynoszącego 10% oraz zachowanie testnetu przed ewentualnym wdrożeniem w sieci głównej.

Relacja za pośrednictwem Blockonomi.