Статус на BEP предлог: Draft, Enabled и кога промената навистина важи

Секој BEP (BNB Chain Evolution Proposal – предлог за развој на BNB Chain) во GitHub складиштето на BNB Chain има ред Status на врвот. Тој ред кажува докаде стигнал предлогот во прегледот. Не кажува од кој момент промената се применува на главната мрежа (mainnet). Тој момент се наоѓа на друго место: во времето на активирање на хард форкот со кој промената е испорачана, или во блокот во кој е извршен предлог изгласан преку управувањето на мрежата.

На 7 октомври 2026 складиштето нудеше чист пример. BEP-673, мета-предлогот за надградбата Pasteur, сѐ уште имаше Status: Draft. Објавата во документацијата на BNB Chain наведуваше активирање на главната мрежа на 2026-08-25 во 02:30 UTC. И двата извора се официјални. Само одговараат на различни прашања.

Што значат Draft, Review, Candidate и Enabled кај BEP

И самата постапка е опишана во еден BEP. BEP-1, чиј статус е Living, ја дели во пет чекори:

• Idea – разговор на форумот или во каналите на заедницата; уште нема број.
• Draft – документ во пропишаниот формат се поднесува како pull request; кога уредниците на BEP ќе го прегледаат и спојат, станува BEP со бројот на тој PR. Авторот може и понатаму да го менува.
• Review (vote) – преглед од заедницата. Ако промената засега консензус, економскиот модел или компатибилноста за корисниците, потребно е гласање; ситни поправки може да го прескокнат.
• Candidate – прегледот е поминат и предлогот е прифатен.
• Enabled – вклучен на главната мрежа на BNB Chain; кај хард форк тоа значи дека е достигната висината или времето на форкот.

Покрај нив постојат три исклучителни статуси. Living значи долгорочно одржување. Stagnant значи дека нема промени повеќе од шест месеци. Withdrawn значи откажан, обично затоа што некој предуслов веќе не важи.

Една реченица во BEP-1 лесно се прескокнува: сѐ додека не е Enabled, предлогот може да се менува. Параметар прочитан во фаза Draft или Candidate може да се промени пред вклучувањето, па не му е место во буџетот за провизии.

Зошто README сѐ уште пишува Draft иако надградбата е поминала

Ако BEP-1 се чита буквално, ставките за Pasteur требаше да станат Enabled штом форкот се активира. Но статусот е ред текст во датотека и се менува само кога некој ќе ја внесе измената. На 2026-10-07 индексот во README на складиштето BEPs сѐ уште ги водеше BEP-673, BEP-682, BEP-695 и BEP-675 како Draft. Во исто време менито за објави во документацијата на BNB Chain го ставаше Pasteur под „Passed“ (поминати), а страницата за надградбата Pasteur и белешките за верзијата v1.7.7 на BSC јазолот го наведуваа главното активирање на 2026-08-25 во 02:30 UTC.

BEP-658, мета-предлогот за претходната надградба Osaka/Mendel, во истата табела веќе е Enabled. Некои редови се ажурираат, некои доцнат. Статусот користете го како трага, а времето барајте го во објавата. Застарен Draft не е причина да се отфрли објава што наведува точно време на активирање.

Несогласувањето може да оди и во обратна насока. BEP-95, механизмот за согорување во реално време, воопшто нема блок со Status во заглавието; во делот 3 стои само „This BEP is already implemented.“, а во README е означен како Enabled. Постарите предлози се пишувани пред сегашниот формат, па поле што недостасува не докажува дека промената не е воведена.

BEP-предлози со хард форк: прво времето на активирање, па на која страна паѓа трансакцијата

Предлозите што ги менуваат правилата на EVM, структурата на блокот или пресметката на провизиите обично се групираат во хард форк со име, а списокот го води мета-предлог насловен „Hardfork Meta-“ и името на форкот. Границата е времето на активирање: блоковите пред него се по старите правила, оние по него – по новите.

Да го земеме Mendel. Документацијата на BNB Chain наведува активирање на тест-мрежата на 2026-03-24 во 02:30 UTC и на главната мрежа на 2026-04-28 во 02:30 UTC. Со него е вклучен BEP-652, кој гасот што смее да го потроши една трансакција го ограничува на 16.777.216 (2 на 24-ти степен); сѐ над тоа се одбива уште при проверката. За тој што рачно го внесува лимитот на гас тоа значи:

• пред 28 април една трансакција немаше ваква посебна горна граница и беше ограничена главно од капацитетот на блокот и други правила;
• по 28 април истата трансакција со лимит од 20.000.000 се одбива при проверката. Одбиена трансакција не влегува во блок, па за неа не се наплаќа гас на синџирот (видете го првиот случај во текстот за неуспешни трансакции).

Обичен трансфер троши 21.000 гас, речиси 800 пати под границата, така што секојдневните операции не ни се доближуваат до неа. Внимание бараат тешките трансакции: групни повици или поставување голем договор, каде лимит што порано минуваше сега може веднаш да биде одбиен.

Во рамките на иста надградба, различни BEP-предлози може да се вклучуваат на различен начин. BEP-673 ги наведува BEP-682 и BEP-695 како предлози за кои е потребен хард форк, а BEP-675 како предлог без хард форк, со забелешка дека патеката SendBidBlock на страната на валидаторот се отвора дури по активирањето на Pasteur и се управува преку RPC интерфејси. Значи, кога ќе дојде времето на форкот, сѐ уште не е решено дали таа патека се користи; операторите на јазли треба да ја вклучат.

Надградбата Jenner, која во документацијата стои под „Upcoming“ (претстојни), е напишана на ист начин. Нејзиниот мета-предлог BEP-718 вели дека кодот на BEP-702 стигнува до секој јазол со хард форкот, а создавањето такви токени на одредена мрежа го отвора прекинувач за активирање, дефиниран во тој BEP и доделен преку управувањето. Хард форкот е само првата врата.

Промени на параметри: по изгласувањето има уште задоцнување

Не секоја промена бара форк. Некои правила се напишани како параметри што се менуваат со гласање. Во BEP-95 валидаторите ги уплаќаат провизиите за гас од секој блок во системскиот договор ValidatorSet, а burnRatio × провизијата оди на адресата за согорување. Предлогот поставил почетна вредност од 10% и напишал дека валидаторите можат да ја променат со гласање.

Затоа „колку согорува BEP-95“ не е константа запишана во предлогот. За секој период ви треба параметарот што навистина важел во тој период.

BEP-95 опишува гласање на BNB Beacon Chain, со депозит од 2.000 BNB и кворум од 50%. Денес документацијата за управување на BSC го опишува домашниот модул воведен со BEP-297, со други бројки:

• поднесување: најмалку 200 BNB во стејкинг и ниту еден отворен предлог од истиот делегатор;
• период на гласање: моментално 7 дена, со можност гласот да се смени;
• услов за извршување: гласале најмалку 10% од вкупниот стејкинг-кредит, а „за“ е најмалку 50% и не помалку од „против“;
• задоцнување (timelock): откако условите ќе се исполнат, уште 1 ден пред предлогот да може да се изврши.

Еве најраниот почеток што го дозволуваат овие бројки, со измислен датум само за пресметката. Да претпоставиме дека гласањето за еден параметар почнува на 2026-11-02 во 00:00 UTC. Гласањето завршува седум дена подоцна, на 2026-11-09 во 00:00. Дури и ако сите услови се исполнети во тој миг, еднодневното задоцнување значи дека извршувањето не може да биде пред 2026-11-10 во 00:00. Новата вредност важи од блокот во кој е трансакцијата за извршување, а не од крајот на гласањето. Документацијата не кажува дали постои чекање и пред почетокот на гласањето, па за вистински предлог земете ги почетниот и крајниот блок од неговиот запис на синџирот, наместо само да ги соберете овие два броја.

Ова е важно при усогласување на согорувањата. Ако периодот што го проверувате поминува преку промена на burnRatio, поделете го на два дела; со еден однос не може од вкупно согорениот BNB да се пресмета вкупниот гас. Како записите за согорување се порамнуваат по периоди, објаснува текстот за Auto-Burn и BEP-95.

Кои BEP-предлози ги менуваат вашиот гас во BNB или бројките за согорување

Повеќето BEP-предлози се однесуваат на јазли, консензус или интерфејси за развивачи и ретко ја допираат евиденцијата на провизии на еден имател. Овие четири директно се поврзани со провизии, понуда и согорување, па се добар материјал за вежбање:

• BEP-95 – согорување во реално време: провизиите за гас одат на адресата за согорување според burnRatio. Влијае врз статистиката на согорувања.
• BEP-226 – на BSC ги воведува трансакциите и заглавијата од EIP-1559, но со base fee фиксиран на 0, кој не се менува со гужвата. Наведената причина е дека BEP-95 веќе согорува, па нема потреба да се согорува base fee. Кога трансакција на BSC покажува полиња од EIP-1559, пресметката од Ethereum „base fee се согорува“ не важи.
• BEP-652 – горна граница од 16.777.216 гас по трансакција, вклучена на главната мрежа со Mendel. Влијае врз лимитот што може да се внесе.
• BEP-619 – интервалот меѓу блоковите го скратува од 0,75 на 0,45 секунди; статус во README: Enabled. Во делот за компатибилност има ставка насловена Quarterly Auto-Burn, но на 2026-10-07 под неа стоеше само „TBD“ (ќе се утврди). Самиот предлог уште не кажува дали побрзите блокови ја менуваат пресметката на кварталното согорување, па секое тврдење за тоа бара посебен официјален извор.

Како да проверите дали еден BEP навистина важи: шест чекори

1. Најдете го бројот во индексот на README во складиштето BEPs. Запишете наслов, тип (Standards, Information или Process) и статус.
2. Отворете ја датотеката и прочитајте го заглавието. Некои датотеки го наведуваат активирањето во полето Description; примерот за формат во BEP-1 гласи „enabled by BSC Euler upgrade, block height 18907621, Jun-22-2022“.
3. Во README побарајте во кој мета-предлог „Hardfork Meta-“ е наведен. Мета-предлозите ги делат списоците на предлози со хард форк и без хард форк.
4. Во делот Announcements на документацијата на BNB Chain отворете ја страницата за таа надградба и запишете ги времињата на активирање за тест-мрежата и главната мрежа (UTC). Белешките за верзиите на јазолот се добар втор извор.
5. За предлози без форк, или со прекинувачи и параметри што се менуваат со гласање, најдете го записот од гласањето или објавата на операторите што покажува кога е вклучен прекинувачот или извршен параметарот.
6. Запишете го заклучокот како една реченица со датум, на пример: „BEP-652: статус во README Enabled; Mendel активиран на главната мрежа 2026-04-28 во 02:30 UTC; проверено 2026-10-07.“

Шестиот чекор изгледа како формалност, но најмногу помага при следната проверка. Статусите се поправаат, страниците со објави се преуредуваат, а белешката каде и кога сте прочитале нешто покажува точно кој дел се променил.