BNB Chain 正在开发并行 EVM 兼容 Layer 1：以速度换取部分以太坊惯例

BNB Chain 正在开发一个并行的 EVM 兼容 Layer 1 网络，该网络将 BNB 保留为其原生资产，公共测试网预计将于 2026 年底上线。在该新架构下，交易费用将基于声明的 gas 上限而非实际消耗量进行收取，这将彻底改变开发者和用户管理执行成本的方式。新的状态存储模型移除了对标准以太坊状态证明的支持，而计划中的跨链桥则引入了独立的安全依赖。

超越性能指标：重新定义执行与存储管道

BNB Chain 正在筹备第二条 Layer 1 区块链，即“New L1”，其优先考虑的是交易速度，而非以太坊兼容网络的某些传统惯例，包括 Gas 退款、常规状态证明和同步执行。该网络目前被称为 New L1，将与 BNB Smart Chain (BSC) 并行运行，并使用 BNB 支付交易手续费、验证者质押及治理投票。其开发目标包括实现 200 毫秒的区块生成时间、约 20 毫秒的前置确认（pre-confirmations），以及超过每秒 100,000 笔交易（TPS）的处理吞吐量。

这一架构的意义远超 headline 上的性能数字。开发者正在替换通常限制 EVM 吞吐量的执行和存储管道部分，并为交易定价、结算和基础设施兼容性引入了不同的假设。根据 BNB Chain 的技术文档，内部多验证者 devnet 已在运行中。公共测试网的目标时间是 2026 年底，主网计划于 2027 年初推出。目前尚无可供独立进行生产规模基准测试的公开网络。

解决执行瓶颈：从同步到异步执行

BNB Smart Chain 已通过连续升级缩短了区块间隔。其 2026 年 7 月的路线图报告称，区块间隔已减少至 450 毫秒，基准吞吐量约为每秒 5,200 笔交易。New L1 采用了截然不同的架构。

在传统的同步执行模式下，验证者在完成区块验证之前，需处理交易并建立 resulting state（结果状态）。New L1 将交易排序与执行分离，允许共识进程在执引擎处理先前已排序的交易时继续推进。验证者使用增强版的 Parlia 权益授权共识机制（Proof-of-Staked-Authority），并通过跨区块的 BLS 投票来快速确立交易排序的最终性。

这意味着，区块的排序可以在与其交易相关的执行承诺被验证和最终确定之前变为最终状态。应用程序不能安全地将早期的排序确认视为交易成功或转账结算完成的证据。网络还引入了由验证者签名的前置确认，这些确认在最终性达成之前可以被撤回或被覆盖。对于交易所和支付处理器而言，前置确认可用于告知用户界面或监控交易，但资金或资产的不可逆交付仍需依赖执行最终性。BNB Chain 在其交易生命周期规范中明确区分了这两者。

Gas 模型变革：高估交易成本的新代价

New L1 最具影响力的变化之一涉及交易费用。在以太坊和 BSC 上，用户通常按实际消耗的 Gas 付费，并受网络退款规则约束。而 New L1 改为在提交交易时，按声明的全部 Gas 上限收费。

原因在于异步执行。区块是在交易执行之前组装的，因此验证者根据声明的 Gas 而非测量的执行消耗来预留容量。协议为此预留空间收费，包括未使用的容量。例如，一笔需要 70,000 Gas 的交易，如果钱包提交的 Gas 上限为 500,000，New L1 将对整个 500,000 Gas 收费。这大约是底层执行所需 Gas 的 7.14 倍。在示例 Gas 价格为 1 gwei 的情况下，这笔交易的差额将为 0.00043 BNB。实际成本取决于 prevailing gas price（当前 Gas 价格），此例仅供参考。

在执行失败的提议收费模型下，也可能消耗声明的 Gas 分配额。对于自动做市商、交易机器人和支付应用而言，过大的安全边际变成了直接的运营支出，而非大部分未被利用的容量。开发者迁移指南警告不要盲目沿用常规的 Gas 填充做法，建议采用更精确的估算，并指出 `newl1_estimateGas` 是网络特定的工具。更快的排序随之而来的是对准确预测执行需求的更大责任。

扁平化状态存储：移除标准以太坊证明机制

New L1 还用扁平键值数据库和 LtHash 累加器取代了传统的 Merkle-Patricia trie 状态承诺方法。以太坊风格的状态树支持密码学证明，证明特定账户或存储值属于已承诺的状态。维护和更新这些结构会引入计算和存储开销，特别是当应用程序频繁修改大量状态条目时。

BNB Chain 提出的系统维护了一个累积状态承诺，可以随着单个条目的更改而更新。根据状态数据库规范，承诺更新的成本不会随现有账户总数的增长而增长。这消除了状态承诺开销的一个来源，尽管它并未消除数据库读写或交易间的争用问题。

这种权衡在于兼容性。由于 LtHash 承诺不提供传统的 Merkle-Patricia 包含证明，标准的 `eth_getProof` 方法不受支持。快照同步也不可用。依赖以太坊风格存储证明的应用程序（包括某些轻客户端桥接器和验证系统）无法简单地迁移其现有的证明基础设施。BNB Chain 表示计划引入一种累加器原生的证明方案，但开发者目前不能将其视为可用功能。智能合约可能在无需修改的情况下部署，但索引器、桥接验证系统和依赖 RPC 的服务需要进行重大变更。

并行执行仍面临共享状态争用

BNB Chain 的高吞吐量野心部分取决于并发处理独立交易的能力。当交易修改不相关的账户或存储位置时，这种方法效果良好。但当许多交易争夺同一个流动性池、订单簿或合约状态时，难度就会增加。去中心化交易所提供了一个有用的例子：不相关钱包之间的数千笔转账可能并行执行；但对同一集中流动性池进行的数千次兑换未必能实现相同的扩展，因为每次兑换都可能依赖于前序交易产生的池状态。

即使交易工作负载高度相互依赖，执行引擎也必须保持确定性结果。因此，公布的 100,000+ TPS 目标不能被解释为复杂去中心化交易所交易能力的实证。性能测试需要区分简单转账和重度合约工作负载，测量状态争用下的持续吞吐量，并考虑验证者的硬件需求。

New L1 还通过其交易流式传输架构移除了传统的公共内存池（mempool），将交易路由向区块生产者。这可以减少暴露于公共内存池前端运行的风险，但并不能消除生产者或拥有特权连接参与者所持有的交易排序优势。关键问题不在于网络能多快地对交易进行排序，而在于网络能否在竞争性交易条件下提供可预测的执行质量。

BNB 效用扩展并不自动导致代币销毁

决定在两个网络中保留 BNB，避免了为新执行环境引入单独的原生代币。币安联合创始人 Changpeng Zhao（CZ）将此方法总结为“多条链，一枚币”。

对于 BNB 持有者来说，更重要的问题是额外的网络活动如何转化为代币需求和供应减少。BNB Smart Chain 已经在 BEP-95 下运行实时销毁机制，销毁一部分由治理定义的合格 Gas 费。然而，New L1 的公开文档并未规定所有 BSC 的费用分配和销毁规则都会自动且完全地适用于新网络。

其 devnet 配置指定基础费用为零，交易价格由优先费决定。零基础费用并不意味着交易免费，而是意味着费用结构与应对拥堵调整非零基础费用的网络不同。devnet 设置不一定是最终的主网政策。未来涉及 govBNB 的治理决策可能决定是否引入基础费用，以及是否通过类似 BEP-95 的机制燃烧任何部分的交易费。在这些规则最终确定之前，New L1 对 BNB 供应减少的贡献无法可靠估计。

更高的交易量可能会增加 BNB 的总体使用量，但如果交易价格保持低位，产生的费用收入可能相对微薄。相反，声明的 Gas 收费模式可能会增加某些工作负载的费用，即使实际的计算消耗没有同等增长。仅凭性能路线图无法量化这两种结果。

第二条 Layer 1 重新引入熟悉的桥接风险

BNB Chain 此前曾运营过双链架构。其原始的 BNB Beacon Chain 和 BSC 结构在 2024 年的 BNB Chain Fusion 中合并，部分目的是简化基础设施并降低安全风险。拟议的 New L1 恢复了通过原生桥接连接的两个独立执行环境。有三个考量尤为突出：

• 历史桥接漏洞：据 BNB Chain 的事件报告显示，2022 年 10 月，攻击者利用 BSC Token Hub 桥接器的伪造跨链证明，未经授权创建了约 200 万枚 BNB。该事件展示了跨链验证受损的后果，但这并不意味着 New L1 存在漏洞。
• 不同的状态证明架构：New L1 用 LtHash 取代了传统的 Merkle-Patricia 状态承诺。桥接开发人员不能自动重用依赖以太坊风格存储证明的验证系统，这使得最终的跨链身份验证设计尤为重要。
• 执行最终性与紧急控制：安全的桥接必须区分交易排序与已完成执行，验证跨链消息，并定义在发生事件时如何暂停转账。这些机制尚未在拟议网络中得到充分记录。

在桥接规范和实施可供独立评估之前，其安全假设仍是 BNB Chain 扩张中未解决的一部分。

2027 年的考验既是技术性的，也是经济性的

New L1 的公共测试网将提供首次在内部开发环境之外评估其拟议性能的机会。开发者将能够检查执行延迟、Gas 估算行为、RPC 兼容性以及在真实合约工作负载下的吞吐量。

对于 BNB 而言，更大的问题是第二条网络是否能吸引产生持续活动的应用程序，而不是仅仅重新分配已经在 BSC 上发生的交易。共享的原生资产简化了生态系统的代币结构，但它并没有消除维护两个网络的运营成本，也没有消除在它们之间转移资产的风险。BNB Chain 的下一阶段，将不仅仅由其最快的前置确认来衡量，更要看建立在之上的应用程序的可靠性、经济学和安全保障。