通过量（Throughput）与确认延迟（Latency）的权衡：高TPS公链为何往往最终确认时间更长

在加密行业里，TPS（Transactions Per Second，每秒交易数）几乎成了“高性能公链”最响亮的营销词。Solana 宣称数万 TPS，Sui 和 Aptos 动辄十几万 TPS，各种模块化、并行化、分片方案更是把“百万 TPS”挂在路线图首页。但如果你真正用过这些链，或者仔细看过它们的浏览器确认数据，会发现一个反直觉的现象：很多高 TPS 公链的“最终确认时间”反而比以太坊这类低 TPS 主链更长，或者至少没有想象中那么短。

这不是偶然，也不是工程团队不够努力。它背后是分布式系统里一个根本性的权衡：通过量（Throughput）与确认延迟（Latency）之间，存在结构性的张力。 你不可能同时无限提升两者，尤其是在去中心化、安全性和网络不确定性约束下。今天我们就来拆解这个矛盾，看看为什么“高 TPS”常常意味着“更长的最终确认”。

先厘清两个容易混淆的概念：出块时间 ≠ 最终确认时间

很多公链宣传“1 秒出块”“400 毫秒确认”，用户就以为交易 1 秒内不可逆转。但这里混淆了三个层次：

1. 出块时间（Block Time）

矿工或验证者打包一个区块的间隔。Solana 大约 400 毫秒，BNB Chain 约 3 秒，以太坊约 12 秒。出块快，只代表交易被“塞进”了某个区块，不代表它不会被回滚。

2. 概率确认（Probabilistic Finality）

在工作量证明或某些最长链规则下，交易被打包后，随着后续区块增加，被推翻的概率指数下降。比特币社区常说“6 个确认”，大约 1 小时，才认为足够安全。这是概率性的，不是绝对的。

3. 最终确认（Finality）

交易被协议层保证不可逆转。以太坊 PoS 的 Casper FFG 大约 12-15 分钟达到最终确认（两个 epoch），但很多用户只等 1-2 个 slot 就认为“差不多安全了”。而一些高 TPS 链采用单槽最终确认或流水线 BFT，理论上几秒内最终确认，但实际网络环境下常常拉长到几十秒甚至几分钟。

问题就出在这里：高 TPS 链为了追求吞吐，往往把“最终确认”的判定条件设计得更复杂、更依赖全网状态同步，结果反而在真实网络里延迟更高。

为什么高通过量会推高最终确认延迟？

我们从五个核心机制来看。

1. 区块空间越大，验证者同步越慢

假设一条链把出块时间压到 400 毫秒，每个区块塞几千笔交易。那么一个区块的数据量可能达到几 MB 甚至几十 MB。验证者节点需要在下一个区块到来之前，完成接收、验证、执行、状态更新，并把投票/证明广播出去。

但网络带宽和磁盘 I/O 不是无限的。当区块生产速度超过大多数验证者的处理速度时，就会出现“区块堆积”。节点为了追上最新高度，不得不跳过某些验证步骤，或者延迟对旧区块的最终确认。最终确认需要绝大多数验证者对某个检查点达成一致，而如果大家连最新状态都没同步完，投票自然被推迟。

Solana 就多次因为区块过大、验证者跟不上而导致网络停滞，最终确认时间从理论上的几秒变成几十分钟。这不是 Solana 独有的问题，任何高吞吐链都会遇到“状态膨胀 vs 同步延迟”的矛盾。

2. 并行执行带来状态冲突与回滚成本

高 TPS 的常见手段是并行执行交易。比如 Solana 的 Sealevel、Aptos 的 Block-STM、Sui 的 Narwhal/Bullshark。思路是：如果两笔交易不碰同一个账户，就同时执行。

但并行执行有一个隐藏代价：当冲突发生时，需要回滚和重新执行。 在高负载下，冲突概率上升，验证者需要做大量“乐观执行—检测冲突—回滚—重放”的工作。这增加了单个区块的处理时间，也增加了节点之间状态不一致的窗口。

更麻烦的是，最终确认往往要求所有验证者对“哪些交易成功、哪些失败、状态根是什么”达成完全一致。并行执行让状态根的计算变得复杂，一旦有节点计算出不同结果，就需要额外的共识轮次来纠正。这直接拉长了最终确认时间。

3. 共识机制从“链式”转向“有向无环图”或“流水线 BFT”后，确认规则更复杂

比特币和以太坊的确认规则很简单：最长链 + 概率最终性。虽然慢，但规则清晰，节点只需比较链工作量或投票权重。

而高 TPS 链常用 DAG（有向无环图）或流水线 BFT。比如 Fantom 的 Lachesis、Hedera 的 Hashgraph、Sui 的 Narwhal。这些结构允许交易并行确认，吞吐上去了，但“最终确认”的定义变得模糊：

• 是某个超级多数投票？
• 是 DAG 中所有相关事件都被锚定？
• 还是需要等待一个全局检查点？

在实际实现中，为了安全，这些链往往采用“保守最终确认”：必须等到某个检查点被足够多的验证者签名，而检查点的生成又依赖于之前所有区块的排序完成。在高吞吐下，排序本身可能成为瓶颈，最终确认被推迟到几十个区块之后。

4. 验证者集合扩大与通信开销

去中心化程度越高，验证者越多，共识通信开销越大。高 TPS 链为了保持去中心化，往往需要数百甚至上千个验证者。每轮共识需要 O(n²) 的消息交换（如 PBFT 类协议）。当 n 很大时，通信延迟急剧上升。

为了维持高 TPS，这些链不得不缩短出块时间，但缩短出块时间又意味着验证者没有足够时间完成 O(n²) 通信。结果是：区块一个接一个出，但最终确认的投票一直凑不齐超级多数。 用户看到交易被包含，但不确定是否最终确认。浏览器上显示的“确认数”可能长时间停在 0 或 1。

Solana 的 Gulf Stream 和 Turbine 试图通过提前转发和区块传播优化来缓解，但 2022-2023 年多次宕机表明，通信瓶颈仍然存在。

5. 状态存储与历史数据访问拖慢确认

最终确认需要验证者检查交易是否合法，包括账户余额、nonce、合约状态等。高 TPS 链在短时间内产生海量状态变更，状态数据库（如 RocksDB）的读写压力巨大。

更严重的是，许多高 TPS 链采用“无状态”或“轻状态”设计，验证者不保存完整历史，只保存最近状态。当需要最终确认一个较老的区块时，验证者可能要从归档节点或网络其他部分拉取历史数据。这引入了额外延迟。

以太坊虽然 TPS 低，但每个节点保存完整状态，最终确认时不需要额外获取历史数据。这种“笨重”的设计反而让最终确认路径更短、更可预测。

真实案例：Solana、BNB Chain 与以太坊的对比

Solana：理论 400ms 出块，实际最终确认常达 12-30 秒

Solana 使用 PoH（历史证明）+ Tower BFT。理论上，一个区块被 2/3 以上验证者投票后即可最终确认。但在网络拥堵时，验证者需要处理大量交易，投票延迟。2024 年初一次拥堵中，Solana 浏览器显示交易“已确认”但“最终确认”状态持续了 20 多秒。原因就是验证者忙于执行交易，没空投票。

BNB Chain：3 秒出块，但最终确认约 15 秒

BNB Chain 使用 PoSA（权益权威证明），21 个验证者。出块快，但最终确认需要等待一个“epoch”结束，通常 15 秒左右。如果某个验证者掉线，确认时间会更长。高 TPS 下，验证者之间的状态同步压力导致 epoch 边界经常延迟。

以太坊：12 秒出块，但 12-15 分钟最终确认

以太坊的最终确认时间确实长，但它的“概率确认”很快：1 个 slot（12 秒）后交易被回滚概率已经很低。用户和交易所通常等 2-3 个 slot 就认为安全。而真正的最终确认（Casper FFG）虽然要 12 分钟，但这是确定性最终确认，一旦达成不可逆转。关键是：以太坊的最终确认延迟是可预测的，不会因为 TPS 升高而突然恶化。

对比下来，高 TPS 链的“最终确认”往往更不稳定：网络空闲时几秒，网络繁忙时几十秒甚至几分钟。这种不确定性对支付、交易所充提、跨链桥来说非常危险。

那为什么还要追求高 TPS？因为场景不同

看到这里，你可能会问：既然高 TPS 导致最终确认更长，为什么还要做高 TPS？

答案在于：不是所有应用都需要快速最终确认。

• 高频交易、游戏、社交应用：需要高吞吐，但对最终确认不敏感，只要交易被包含且大概率不会被回滚即可。它们可以接受“概率确认”，甚至接受偶尔回滚。
• 支付、跨链桥、交易所结算：需要快速且确定的最终确认。它们宁愿 TPS 低一点，也要 1-2 秒内不可逆转。
• Rollup 和模块化区块链：把执行和确认分开。Rollup 负责高 TPS 执行，以太坊主链负责最终确认。这样既获得了高吞吐，又利用了主链的强最终性。但代价是用户需要等待主链确认，延迟反而更高。

所以，高 TPS 和低最终确认延迟，本质上是服务于不同需求的。一条链不可能同时做到“十万 TPS”和“1 秒最终确认”，除非牺牲去中心化或安全性。

有没有可能打破这个权衡？

学术界和工程界一直在尝试。几个方向：

1. 分离共识与执行

比如 Celestia、EigenDA 提供数据可用性，执行交给 Rollup。Rollup 内部可以高 TPS，最终确认交给以太坊。但用户要等以太坊确认，延迟没有消失，只是转移了。

2. 异步共识 + 流水线最终确认

比如 Aptos 的 Block-STM + Jolteon，试图让共识和执行的流水线重叠。但实际测试中，高负载下最终确认仍然会延迟，因为冲突回滚和状态同步无法完全隐藏。

3. 硬件加速与专用网络

Solana 的 Firedancer 客户端、Monad 的并行 EVM、Sei 的并行化，都在尝试用更高效的代码和网络协议来压缩延迟。但物理定律和网络抖动无法消除。当 TPS 达到十万级，即使 1% 的丢包也会导致确认延迟指数上升。

4. 概率最终确认 + 经济惩罚

一些链采用“乐观最终确认”：先假设交易最终，如果出现回滚，则惩罚验证者。这可以缩短用户感知的确认时间，但安全性依赖于经济假设，不是密码学保证。对于大额交易，用户仍然会等待更长时间。

目前来看，没有银弹。高 TPS 与低最终确认延迟之间的权衡，是分布式系统的物理约束，不是单纯靠工程优化就能消除的。

对开发者和用户的启示

如果你正在选择公链，不要只看 TPS 数字。问几个问题：

• 这条链的“最终确认”定义是什么？是概率确认还是确定性确认？
• 在网络拥堵时，最终确认时间会恶化到什么程度？
• 你的应用能否容忍交易回滚？如果不能，你需要等待多少个确认？
• 跨链桥和交易所支持这条链的最终确认吗？它们等多少个区块？

对于普通用户，一个实用的经验法则是：高 TPS 链适合小额、高频、可容忍回滚的场景；大额、低频、不可逆的场景，还是选择最终确认更可预测的链，或者耐心等待更多确认。

加密世界喜欢造神，也喜欢造数字。但最终确认时间不会因为营销而缩短。理解通过量与延迟的权衡，能帮你避开很多坑，也能让你更理性地看待那些“百万 TPS”的承诺。

毕竟，在分布式系统里，你得到一些东西，就必然要放弃另一些东西。高 TPS 的代价，往往就是更长的、更不确定的最终确认。这不是缺陷，而是设计选择的结果。