# BNB New L1：排序很快，结果很慢

## New L1 是什么

BNB Chain 正在开发一条新的 EVM L1，面向对延迟敏感的场景：交易、支付和 AI agent。它 200 ms 出块，没有全局内存池，按声明的 gas limit 收费，并原生支持账户抽象和隐私池。

它还处在很早期：目前只有一个内部 devnet，没有公开 RPC，没有测试网和主网，链 ID 也没定，对外公开的只有[官方文档](https://docs.bnbchain.org/newl1/get-started/network-info/)。下面的内容都来自这批文档，核对于 2026-10-26。

一句话概括它的设计：​**共识来自 BSC，执行模型来自 Monad，账户抽象来自 Tempo。**​前两者分别决定了交易多快落地、结果多快被看到。而这两件事，其实是两个不同的数字。


## 共识：BSC 的 Parlia，不是 MonadBFT

New L1 沿用了 BNB Smart Chain 的 Parlia（PoSA）共识，再加上 BLS 快速最终性。

-   最多 64 个验证者轮流当出块者，每人连出 16 个区块（一轮 3.2 s）。
-   验证者对链头（head）区块投 BLS 票。集齐三分之二的票后，下一个出块者把这些票聚合成一份证明，写进自己的区块头。
-   通常，一个区块在下一个区块到达时进入 justified 状态，再过一个区块进入 finalized 状态；按 200 ms 出块算，全程约 0.5 s。
-   投票只针对区块内交易的「顺序」，不针对执行结果。

所以它是更快的 BSC，而不是 Monad。[MonadBFT](https://docs.monad.xyz/monad-arch/consensus/monad-bft) 是 HotStuff 一系的流水线 BFT 协议：每一轮按质押权重换 leader，两轮（600 ms）即可最终确定。Parlia 则不同：同一个出块者连续出若干区块，最终性由单独的投票环节完成。

BNB 表示，Parlia 只是目前的默认方案。它还在评估 [Minimmit](https://arxiv.org/abs/2508.10862) 作为「共识 2.0」。Minimmit 由 Commonware 提出，两轮即可最终确定。Tempo 采用的 Simplex 共识同样出自 Commonware；如果换过去，New L1 的共识就会向 Tempo 这一系靠拢。

|  | New L1 | BSC | Monad | Tempo |
| --- | --- | --- | --- | --- |

| 共识 | Parlia PoSA + BLS | Parlia PoSA + BLS | MonadBFT | Simplex BFT |

| 出块者 | 轮值，每人连出 16 个区块 | 轮值 | 每轮更换 leader | VRF 随机选 leader |

| 出块间隔 | 200 ms | 0.45 s | 最短 300 ms | 约 600 ms |

| 最终性 | 约 0.5 s | 约 2 个区块内 | 600 ms | 确定性，亚秒级 |

| 执行 | 异步，滞后 D 个区块 | 同步 | 异步，滞后 3 个区块 | — |

| 计费 | 按声明的 limit | 按实际用量 | 按声明的 limit | 用稳定币支付 |


## 执行：Monad 的做法

在执行层面，New L1 和 [Monad](https://docs.monad.xyz/monad-arch/consensus/asynchronous-execution) 几乎一模一样：

-   共识只负责排序，不执行交易。
-   EVM 随后执行第 N 个区块，执行结果（状态根、回执、日志）写进第 N+D 个区块的区块头。
-   D 在 1 和治理设定的上限之间自适应，每个区块最多变化 1：链空闲时贴近 1，负载上来就变大。上限是多少，BNB 没有公布；Monad 则把 D 固定为 3。
-   出块者排序时并不知道交易实际会用掉多少 gas，所以你按 `tip × gas_limit` 付费，跟 EVM 实际消耗多少无关，也不退款。Monad 按 limit 收费，原因相同。
-   准入检查看的是你的余额扣掉所有在途交易开销后还剩多少，相当于 Monad 的 reserve balance 规则。

换来的是吞吐量：出块从不等执行，区块 gas 上限也不必迁就最慢验证者的执行速度。


## 一笔交易的时间线

一笔交易被打包进第 N 个区块后，会依次经历这些阶段：

| 阶段 | 时机 | 距第 N 个区块的时间 |
| --- | --- | --- |

| 预确认（pre-confirmed） | 出块者推送包含该交易的签名子块 | 约 20 ms，可撤销 |

| 已排序（ordered） | 第 N 个区块被导入 | 同一区块内 |

| 排序最终确定（order-finalized） | 第 N+2 个区块 | 约 0.5 s |

| 已执行（executed） | 你的节点执行完第 N 个区块 | 落后最新区块 D 个区块 |

| 执行最终确定（execution-finalized） | 第 N+D 个区块在第 N+D+2 个区块时最终确定 | 约 (D + 2) × 200 ms |

最后一行是我根据文档里的设计推算出来的，不是官方数字：D 为 1 时约 0.6 s，D 为 3 时约 1 s。负载越高，这个时间越长，而且没有公开上限。

排序最终确定得很快，结果却来得很慢。


## t+0 落地是可能的

如果你的策略是跟着链上事件做交易，关键问题就是：你的交易能不能和触发它的那笔交易落在同一个区块里。在 Solana 上这是常态：机器人读取 leader 的 shred，在同一个 slot 内就能上链。

在 New L1 上，一笔交易要落地，只需要进入排序；而排序只做几项轻量检查——签名、nonce，以及前面提到的余额检查，不用等执行。所以 t+0 落地是可能的，前提是你能在同一个 200 ms 区块内看到那笔触发交易。能不能看到，取决于你从哪里看：

-   **标准 RPC** 返回的都是已执行状态：​`eth_getLogs` 查询、回执，以及 `latest` 标签，都比已排序的最新区块落后 D 个区块。靠它读数据的机器人，最早也只能在 t+D 落地，比 BSC 还慢。
-   **子块流**​则不同：订阅 `newl1_subscribeSubBlocks`​，出块者打包那笔触发交易后约 20 ms，你就能看到它。机器人只要根据触发交易的 calldata 做决定，不等状态更新，直接把交易发给当前出块者，就能紧跟在它后面落地。子块只追加、不重排，而且同一个出块者会连续出块 3.2 s，不用担心目标换人。

没有公开的内存池，所以这一切都得经过出块者。


## 但还没人能读到结果

t+0 落地，不代表别人在 t+0 就能用上这笔交易。它的回执、日志，以及它改动的余额，都要等执行完成——也就是 D 个区块之后——才能在 RPC 上看到。钱包如果等回执，就会在链上实际确定结果之后几百毫秒才显示成功。机器人如果想先确认买入成功再卖出，也一样得等。

有两点能缓和这一点：

1.  **排序一确定，结果也就定了。**​执行是确定性的：第 N 个区块的排序一旦最终确定，结果就不会再变，只是还没有公布。自己跑一套执行器的玩家可以立刻知道结果，只有依赖公共 RPC 的客户端才要等上 D 个区块。
2.  **可以直接连发，不用等结果。**​发下一笔交易时，不需要先拿到上一笔的结果。排序保证它在上一笔之后执行；如果上一笔失败，它就会回滚。代价是：即使回滚，交易也照样按整个 gas limit 收费。另外，上一笔交易本该收到的 BNB 不能拿来付下一笔的 gas——因为准入检查只扣在途支出，不计在途收入。

于是设计上就出现了一种不对称：自己跑执行的玩家在 t+0 就能看到结果，用标准 RPC 的人却要晚 D 个区块。在 Solana 和 BSC 上，出块者打包时就执行交易，交易一上链，结果就已经有了。Monad 和 New L1 也有同样的落差。


## 对开发者意味着什么

-   **钱包：**​预确认或已排序，都不等于成功。「已打包」和「已成功」要分开显示；资金要等执行最终确定后，才算到账。
-   **机器人：**​盯子块，别盯日志。需要比 RPC 更早拿到结果，就自己跑执行。gas limit 要给紧——多留的额度照样全额收费。
-   **从 BSC 迁过来的合约：**​`block.number` 每秒前进约 5 次，​`block.timestamp` 大约连续 5 个区块保持不变，​`block.prevrandao` 是时间戳的毫秒部分，不是随机数。
-   **延迟测量：**​要报两个数。一个是交易何时落地（按已排序链头算 t+N），另一个是结果何时可见（按已执行链头算 t+N，或者按回执时间）。一个在 t+0 就能落地的产品，对只看 RPC 的用户来说仍可能显得慢。


## 账户抽象来自 Tempo

`0x76` 是 New L1 原生账户抽象交易的类型，字段与 [Tempo](https://tempo.xyz/developers/docs/protocol/transactions/spec-tempo-transaction.md) 相同，包括 `calls`​、​`nonce_key`​、​`key_authorization`​、​`fee_payer_signature` 四个字段，以及 `valid_after` 和 `valid_before` 这两个有效期字段。支持的签名方式也一样（secp256k1、P256、WebAuthn），预编译合约也沿用了 Tempo 的命名，比如 `AccountKeychain` 和 `SignatureVerifier`​。不同之处在于：New L1 强制 `nonce_key` 为 0，gas 以 BNB 而非稳定币支付，预编译地址不同，而且去掉了 7702 式委托。详见官方文档里的[限制表](https://docs.bnbchain.org/newl1/core-concepts/account-abstraction/#limits)。


## 未解答的问题

-   真实负载下 D 会涨到多大？结果要晚多久全看它，而 BNB 还没公布上限。
-   吞吐量如何？文档既没给出 TPS，也没给出每秒能处理多少 gas，并行执行也还在设计中。
-   一个区块里，交易最晚在什么时刻到达还能被出块者收下？到出块者的网络延迟又有多大？这决定了 t+0 是真能落地，还是只停留在纸面上。
-   出块者能看到订单流，如何防止它抢跑？文档只提到没有全局内存池，没有说明对出块者有什么约束。

在公开网络上线之前，这些都无从测量。


## 参考资料

-   BNB Chain New L1：[Consensus](https://docs.bnbchain.org/newl1/core-concepts/consensus/)、[Async Execution](https://docs.bnbchain.org/newl1/core-concepts/async-execution/)、[Pre-confirmation](https://docs.bnbchain.org/newl1/core-concepts/tx-preconfirmation/)、[Transaction Lifecycle](https://docs.bnbchain.org/newl1/developers/transaction-lifecycle/)、[Migrating from BSC](https://docs.bnbchain.org/newl1/get-started/migrate-from-bsc/)
-   Monad：[MonadBFT](https://docs.monad.xyz/monad-arch/consensus/monad-bft)、[Asynchronous Execution](https://docs.monad.xyz/monad-arch/consensus/asynchronous-execution)、[Gas Pricing](https://docs.monad.xyz/developer-essentials/gas-pricing)
-   BSC：[Introduction](https://docs.bnbchain.org/bnb-smart-chain/introduction/)、[亚秒最终性](https://www.bnbchain.org/en/blog/how-bsc-achieved-sub-second-finality-a-70x-leap-from-45s-to-0-65s)
-   Tempo：[Consensus](https://tempo.xyz/developers/docs/protocol/blockspace/consensus.md)、[Tempo Transaction](https://tempo.xyz/developers/docs/protocol/transactions/spec-tempo-transaction.md)
-   [Minimmit: Fast Finality with Even Faster Blocks](https://arxiv.org/abs/2508.10862)