Ipinatupad ng BNB Chain ang BEP-675 upgrade sa kanyang BSC Testnet noong Agosto 7, na nagpataas ng throughput mula sa 1,237 na transaksyon bawat segundo patungo sa 2,324 TPS. Ito ay isang pagtaas ng 88%, na natamo nang hindi nagbago ang block interval o gas limit.
Paano gumagana ang BEP-675
Bago sa pag-upgrade na ito, ang proseso ng pagbuo ng BSC block ay may malaking problema sa pagkakaroon ng sobrang pagkakapareho. Ang mga block builder ay nag-aassemble at nagpapatakbo ng mga transaksyon, pagkatapos ay muli nilang pinapatakbo ng mga validator ang mga transaksyon na iyon upang patotohanan.
Ang BEP-675 ay naglalayong magdagdag ng isang bagong mekanismo na tinatawag na SendBidBlock, na nagpapahintulot sa mga block builder na sumumita ng mga fully executed blocks nang direkta. Maaari ngang i-skip ng mga validator ang redundant na re-execution step, at manatili sa pagtitiwala sa mga pre-executed resulta habang pinapanatili ang security model ng chain.
Ang mga pagpapabuti sa performance mula sa pag-alis ng redundancy ay malaki. Bumaba ang oras ng pagpapatupad ng critical path validator mula sa halos 125ms patungo sa lamang 15ms. Para magkaroon ng pananaw, ang hakbang na pagpapatupad na dati ay kumakain ng higit sa isang kuarto ng bawat 450ms na block interval, ngayon ay kumakain lamang ng halos 3% nito.
Ang nagkalayong headroom ay direktang nagdudulot ng mas mataas na paggamit ng gas. Ang median paggamit ng gas bawat block ay tumalon mula sa 29.49M hanggang sa 98.99M, na nangangahulugan na ang mga block na dati ay gumagamit ng mas mababa sa isang ikatlo ng kanilang 100M gas limit ay ngayon ay puno-muna halos buo. Parehong laki ng block, parehong oras ng block, nangungunang higit na aktwal na computation bawat block.
Ang upgrade ay unang isinulat bilang isang propuesta noong Abril 10 at ginawang aktibo sa testnet nang humigit-kumulang apat na buwan pagkatapos. Ang mga legacy na SendBid flows ay patuloy na suportado para sa backward compatibility, bagaman ang mga builder na gustong gamitin ang bagong SendBidBlock mechanism ay kailangang mag-operate ng isang full node.
Ang setup ng pagsubok at ano ang susunod
Ginamit ng BNB Chain ang testnet evaluation gamit ang isang internal cross-region QANet setup na disenyo upang magsimula ng tunay na mainnet topology. Sa pamamagitan ng pagpapakita ng mga kondisyon sa cross-region, ang 2,324 TPS figure ay dapat na mas malapit sa pagtatantiya kung ano ang maaaring magdala ng mainnet.
Ang pagsubok ay nakapokus sa iba’t ibang mga workload ng transaksyon kaysa sa simpleng pag-transfer ng token.
Ang BEP-675 ay nasa loob ng mas malawak na technical roadmap para sa H2 2026 ng BNB Chain. Ang chain ay nasa agresibong landas ng pag-scall, na nakamit na ang pagbawas ng block intervals sa 450ms at pagpapalapit sa benchmark throughput sa malapit sa 5,200 TPS sa mga nakaraang yugto noong 2025 at unang bahagi ng 2026. Ang susunod na layunin ay ang pagdobleng pagtaas ng mainnet throughput, kasama ang mas mahabang panahon na layunin na makamit ang 10x pagpapabuti kumpara sa kasalukuyang baseline performance.
Susunod sa matagumpay na testnet phase, ang mga karagdagang hakbang ay kasama ang mainnet-scale validation. Ang roadmap ay nagtatawag din para sa karagdagang pagpapabuti kabilang ang FOCIL (na may kaugnayan sa forced inclusion lists, isang mekanismo na disenyo upang pigilan ang pag-censor sa antas ng block production) at Block-Level Access Lists, na maaaring paigingin ang efficiency ng execution.
Bakit mahalaga ang MEV dito
Ang BEP-675 ay nagpapababa ng operational overhead na idinudulot ng MEV infrastructure sa critical path ng chain. Ipinakilala ng BNB Chain ang upgrade bilang solusyon sa mga bottleneck na dulot ng mga inefficiencies ng MEV. Sa pamamagitan ng pag-redesign ng submission mechanism kung saan ang mga builder ay nagdadala ng fully executed blocks, nalilipas ang redundant na re-execution step na bahagi ng epekto ng mga assumptions sa pagkakatiwala na nakapaloob sa MEV-aware architectures.
Kung tumutugma ang mainnet deployment sa mga resulta ng testnet, magkakaroon ang BNB Chain ng halos dobleng praktikal na throughput nang hindi kailangang baguhin ng mga user o dapp developers ang anumang bagay tungkol sa kanilang pag-interact sa network. Ang finality guarantees at block timing ay nananatiling pareho.