BNB Chain 的 BEP 还写着 Draft，改动在主网生效了吗

在 BNB Chain 的 GitHub 仓库里打开一条 BEP（BNB Chain Evolution Proposal，BNB Chain 的改进提案），页头会有一行 Status。这一行说明提案在编辑流程里走到了哪一步，并不说明改动哪天在主网生效。决定“从哪个区块起，我的 Gas 和销毁记录按新规则算”的，是另外两样东西：硬分叉类改动的主网激活时间，以及参数类改动在链上治理中被执行的时间。

2026 年 10 月 7 日打开仓库，正好有一个现成的例子。Pasteur 升级的元提案 BEP-673 页头仍写着 Status: Draft；BNB Chain 文档的升级公告则写明，主网激活时间是 2026-08-25 02:30 UTC。两处都是官方来源，只是回答的不是同一个问题。

BEP 的 Draft、Review、Candidate、Enabled 各是什么意思

流程本身也写在一条 BEP 里。BEP-1（状态为 Living）把正常路径分成五步：

• Idea：先在论坛或社区频道讨论，此时还没有编号。
• Draft：按格式写成文档、提交 PR，经 BEP 编辑审阅合并后成为正式 BEP，PR 编号就是 BEP 编号。作者之后仍可以继续改。
• Review（vote）：社区评审。改动涉及共识机制、经济模型或用户体验兼容性这类关键部分时，需要治理投票；小修补可以不投票。
• Candidate：评审通过，提案被接受。
• Enabled：已在 BNB Chain 主网启用；如果是硬分叉，表示分叉的高度或时间已经到达。

此外还有三个例外状态：Living 表示长期维护；Stagnant 表示超过 6 个月没有更新；Withdrawn 表示放弃、不会实施，通常是因为前提条件不再成立。

BEP-1 里还有一句容易漏读的话：只要还没 Enabled，BEP 就可以继续修改。Draft 或 Candidate 阶段写着的参数，可能在启用前被改掉，不宜直接记进费用预算。

为什么 README 还写着 Draft，主网却已经按时间表升级了

按 BEP-1 的定义，Pasteur 激活以后，相关条目应该改成 Enabled。可状态字是文件里的一行文字，要有人提交修改才会变。2026-10-07 查看 BEPs 仓库的 README 索引表，BEP-673、BEP-682、BEP-695、BEP-675 四行都还是 Draft；与此同时，BNB Chain 文档公告栏把 Pasteur 放在 “Passed”（已经过去）一组，Pasteur 升级页和 BSC 节点 v1.7.7 的发布说明都写着主网时间 2026-08-25 02:30 UTC。

上一次升级的元提案 BEP-658（Osaka/Mendel）在同一张表里已经是 Enabled。同一个仓库，有的条目补改了，有的还没有。合理的读法是把状态字当线索，再去公告页找时间；不要拿一行 Draft 去否定一份写着具体激活时间的公告。

反方向的情况也有。BEP-95（实时销毁机制）的文件开头没有 Status 元数据块，只在第 3 节写了一句 “This BEP is already implemented.”，README 表格里则标为 Enabled。早期提案的格式和现在不一样，文件里缺了这个字段，不能推出它没有生效。

硬分叉类提案：先找激活时间，再看交易落在哪一边

改动 EVM 规则、区块结构或费用计算的 BEP，通常被打包进一次有名字的硬分叉，由一条标题为 “Hardfork Meta-名称” 的元提案列出清单。分界线是激活时间：之前打包的区块走旧规则，之后走新规则。

以 Mendel 为例。BNB Chain 文档写明测试网 2026-03-24 02:30 UTC、主网 2026-04-28 02:30 UTC 激活。随它启用的 BEP-652 给单笔交易的 Gas 用量设了协议上限 16,777,216（2 的 24 次方），超过的交易在校验阶段就被拒绝。落到填写 Gas 上限这件事上：

• 4 月 28 日之前，单笔交易的上限还没有这条单独的约束，主要受区块容量等其他规则限制；
• 4 月 28 日之后，同一笔交易若把上限填成 20,000,000，会在校验阶段被拒。被拒的交易不进区块，链上也就没有这笔 Gas 费用（来龙去脉见失败交易那篇的第一种情况）。

普通转账用 21,000 Gas，离 16,777,216 还差将近 800 倍，日常操作碰不到这条线。需要留心的是批量调用、部署大合约这类重交易：以前能填的上限，现在可能直接被拒。

同一次升级里，不同 BEP 的启用方式也可能不同。BEP-673 把 BEP-682、BEP-695 列为“需要硬分叉”，把 BEP-675 列为“不需要硬分叉”，并注明验证者一侧的 SendBidBlock 路径要等 Pasteur 激活后才开放，开关通过 RPC 接口控制。换句话说，分叉时间到了，这条路径用没用上，还取决于节点运营方有没有打开。

公告栏里排在 “Upcoming” 的 Jenner 升级也是这种写法。它的元提案 BEP-718 说，BEP-702 的代码随硬分叉进入每个节点，但某个网络上何时能创建这类代币，由 BEP 中规定、经治理任命的激活开关决定。硬分叉只是第一道门。

参数类改动：投票通过后，还要等执行延迟

不是每项改动都需要硬分叉。有些规则在提案里就被设计成可治理的参数，BEP-95 的 burnRatio 就是一例：每个区块结束时，验证者把收取的 Gas 费存入 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 开始投票，7 天后、即 11-09 00:00 投票结束；就算立刻满足执行条件，也还要经过 1 天的延迟，最早 11-10 00:00 之后才能执行。新参数的起点是那笔执行交易所在的区块，不是投票结束的那一刻。文档没有说明投票开始前是否另有等待期，所以核对真实提案时，用链上提案记录里的起止区块，不要只套这两个天数。

这对销毁核对有直接影响：一段统计区间如果跨过了一次 burnRatio 的调整，前后两段要分开算，不能用一个比例从总销毁量倒推 Gas 费。两种销毁怎样按时间段对齐，Auto-Burn 与 BEP-95 那篇有专门的记录方法。

哪些 BEP 会改到你的 BNB Gas 或销毁数字

仓库里多数 BEP 讲的是节点、共识或开发者接口，和持币者的费用账关系不大。下面四条与费用、供应和销毁直接相关，适合拿来练习读法：

• BEP-95：实时销毁，Gas 费按 burnRatio 进入销毁地址，影响销毁统计。
• BEP-226：在 BSC 上启用 EIP-1559 的交易与区块头格式，但 base fee 固定为 0，不随拥堵调整。提案给的理由是 BSC 已经有 BEP-95 的销毁机制，不需要再烧 base fee。在 BSC 的交易详情里看到 EIP-1559 字段时，不要套用以太坊“base fee 被烧掉”的算法。
• BEP-652：单笔交易 Gas 上限 16,777,216，随 Mendel 在主网启用，影响 Gas 上限怎么填。
• BEP-619：出块间隔从 0.75 秒缩短到 0.45 秒，README 状态为 Enabled。它的“向后兼容”一节单列了“季度 Auto-Burn”，但 2026-10-07 查看时这一节的内容只有 TBD（待定）。出块间隔变化是否影响季度销毁的算法，这条提案自己还没有给出答案；看到相关说法时，要另找官方公告核对。

自己核对一条 BEP 是否已经生效：六步查法

1. 在 BEPs 仓库 README 的索引表里找到编号，记下标题、类型（Standards、Information 或 Process）和状态。
2. 打开 BEP 文件读页头。有的文件会在 Description 里直接写启用信息；BEP-1 给的格式示例就是 “enabled by BSC Euler upgrade, block height 18907621, Jun-22-2022”。
3. 在 README 里查它被列进哪一条 “Hardfork Meta-” 元提案。元提案会把清单分成“需要硬分叉”和“不需要硬分叉”两组。
4. 到 BNB Chain 文档的 Announcements 栏打开同名升级页，记下测试网与主网的激活时间（UTC）。节点软件的发布说明可以当第二个来源。
5. 不需要硬分叉、或者带开关和可治理参数的，再找治理提案记录或运营方说明，确认开关何时打开、参数何时执行。
6. 把结论写成一句带日期的话，例如：“BEP-652：README 状态 Enabled；Mendel 主网激活 2026-04-28 02:30 UTC；核对日期 2026-10-07。”

第 6 步看似多余，复查时最省事。状态字会被补改，公告页会被重新排版；记下原文位置和核对日期，下一次打开时就知道变的是哪一处。