---
id: 18
title: 性能指标词典：TPS、BPS、确认延迟、最终性、冲突率
slug: performance-metrics-glossary
date: 2026/09/08
summary: TPS、BPS、确认延迟、最终性、冲突率，这些高频出现却常被混用的性能术语，到底该怎么定义和测量？本文给出一份可复用的性能指标词典。
keywords: TPS,确认延迟,最终性,冲突率,区块链性能指标
heroImage: /images/community-bg.png
---

区块链行业最擅长的营销动作之一，是甩出一个足够大的数字。65000、100000、160000，这些标注在项目官网首页的TPS数字看起来足以让所有竞争对手黯然失色，但如果拆开看它们的统计口径，往往会发现完全不是一回事。

Chainspect的研究显示，Solana官方宣称的65000 TPS与其实时统计的292.45 TPS相差222倍；Arbitrum宣称的40000 TPS与实测的12.43 TPS相差超过3000倍。这不是哪条链在撒谎，而是"理论峰值"和"真实处理量"本来就是两个不同的指标，只是行业习惯把它们混着用。对于一个正在评估高性能公链、尤其是并行EVM赛道项目的读者来说，如果不能先把TPS、BPS、确认延迟、最终性、冲突率这几个词的准确含义和常见误用方式厘清，后面看到的所有对比数据都可能是在拿苹果比橙子。

这篇文章的目的不是介绍某一条具体的链，而是把这套度量体系讲清楚，为后面系列F要展开的横向对比和基准测试建立一个统一、可核查的口径基础。

### TPS：一个数字，至少三种算法

TPS的字面意思是每秒处理的交易数量，但这个看似简单的数字，在实际统计中至少对应三种截然不同的口径，彼此之间的差距可以达到数十倍甚至上千倍。

白皮书和融资材料里最常出现的，是理论峰值（max theoretical TPS）：假设网络带宽、硬件性能、区块大小全部达到设计上限，且不存在任何冲突或重执行开销，系统在数学上能够达到的吞吐上限。这个数字之所以最受青睐，恰恰是因为它最大，代价则是它几乎从未在真实网络中被持续达到过。

比理论峰值更贴近现实、却依然带着表演性质的，是历史峰值（max recorded TPS），指网络在某一个极短时间窗口内曾经达到过的最高实测值。这类数字往往产生于专门设计的压力测试，比如Solana在2025年进行的100k TPS压力测试，或者某次异常的链上活动高峰期，它比理论峰值更有说服力，但同样不能代表网络的常态处理能力。

真正贴近用户体验的，是实时TPS（real-time TPS）：在正常运行状态下，某个统计窗口内实际完成的交易数除以时间。这是最能反映日常使用感受的指标，也是Chainspect等第三方监测平台重点披露的口径。

比这三种口径差异更容易被忽略的，是交易的构成问题。以Solana为例，其网络中包含大量验证者用于投票确认区块的系统交易（vote transactions），这类交易本质上是共识层的内部通信，而非用户发起的经济活动。据报道，Solana网络中约三分之二的交易属于投票交易，若将其计入总TPS，会显著推高统计数字。据BingX与Crypto Briefing报道，剔除投票交易后，Solana的"非投票"实际吞吐量在2026年年中经常超过2500 TPS，峰值可达6000 TPS以上，这个数字虽然远低于65000的宣传口径，但更能反映网络真实承载的用户活动。Chainspect在披露方法论时特别说明，其统计不计入系统交易和共识层内部通信，也不计入Layer 2向Layer 1提交的系统性交易。

这里没有绝对的对错，Solana官方的解释是投票交易本身也消耗网络资源、支付手续费，因此纳入统计有其逻辑；但对于跨链对比而言，一个不区分交易构成的TPS数字，几乎注定会造成误导。任何严肃的性能声明，都应当说明统计口径覆盖的时间窗口、是否包含系统交易、是否为持续负载下的平均值还是短时峰值。

### BPS与出块间隔：另一个容易被忽略的变量

BPS（Blocks Per Second）指网络每秒产出的区块数量，它与出块间隔（block time）互为倒数关系，也与区块大小共同决定了理论TPS上限：TPS大致等于BPS乘以每个区块能容纳的交易数。

这个指标经常被单独拿出来做营销素材，比如"出块时间400毫秒"听起来比"12秒"快得多，但出块快不等于交易确认快，也不等于最终性快。一条链完全可以做到出块间隔极短，但因为共识层需要多轮投票才能锁定一个区块，用户感知到的确认延迟依然可能是若干个区块之后才出现。因此BPS本身只是一个中间变量，不能脱离共识机制单独作为吞吐或体验的证明。

### 确认延迟与最终性：两个经常被混为一谈的概念

确认延迟（confirmation latency）指用户提交交易到该交易被网络确认所经过的时间，而最终性（finality）指该交易此后不可被回滚或重组的确定性程度。这两个概念听起来接近，但对用户体验和资产安全的含义完全不同：一笔交易可以很快被"确认"，但距离真正不可逆的"最终"还有很长的等待期，这中间的落差正是很多支付、交易所充值场景里最容易踩的坑。

不同共识机制在这个问题上给出的答案差异很大。比特币采用的是概率性最终性（probabilistic finality）：交易被打包进区块后，随着后续区块不断累加，被恶意重组的概率呈指数级下降，业界惯例是等待6个区块确认（即所谓"六区块规则"）才认为交易足够安全，这个等待窗口大约需要一小时。

以太坊在完成合并（The Merge）转向权益证明后，采用了一套基于epoch的最终性机制。一个epoch包含32个slot，每个slot约12秒，因此一个epoch约6.4分钟。当超过三分之二质押的验证者对某个检查点投票，该检查点进入"已证明"（justified）状态；当下一个检查点在其基础上也被证明，前一个检查点才真正进入"已最终"（finalized）状态。这意味着以太坊主网的经济最终性通常需要两个epoch、约12.8分钟才能达成。此后如果要回滚一个已最终化的区块，攻击者必须让至少三分之一的质押ETH被销毁（slashing），代价极高。

Tendermint一类的BFT共识则提供了"即时最终性"：当一个区块获得超过三分之二验证者的precommit签名，它在该轮内即被视为最终，不存在概率性的等待过程，Cosmos生态的链通常能在1到6秒内完成这个过程。这是BFT类共识相对于中本聪共识最大的体验优势，代价是验证者集合通常需要维持在可管理的规模，以保证通信复杂度可控。

Solana采用的是介于两者之间的"乐观确认"（optimistic confirmation）机制：当超过三分之二质押权重的验证者对某个区块投票，该区块即被标记为"confirmed"，这个过程大约耗时400毫秒；据Solana官方文档记录，自创世以来还没有一个经过乐观确认的区块被回滚过。但完整的最终性（即区块达到最大锁定深度，需要32次连续投票、锁定期指数增长）通常需要额外的时间才能完成。这意味着"confirmed"和"finalized"在Solana的语境下是两个不同的承诺等级，钱包和交易所在展示"到账"提示时具体引用的是哪一个，会直接影响用户对资金安全性的判断。

这几种机制没有绝对的高下，但作为读者和评估者，至少要能区分清楚一条链宣传的"确认时间"，到底对应的是软确认还是硬最终性。

### 冲突率：并行执行语境下的新指标

对于乐观并行执行的系统而言，还有一个前几种共识机制不需要面对的指标：冲突率（conflict rate），有时也称重执行率或中止率（abort rate）。

在Aptos团队发表的Block-STM论文中，冲突率被定义为并发执行的交易访问同一状态数据、从而产生依赖冲突的频率；而中止率则指因为验证阶段检测到冲突，导致交易被中止并重新执行的比例。论文中特别指出，得益于运行时写集预估（write-set estimation）和低开销的协作调度器，Block-STM在真实工作负载下的中止率相当低，并且论文的实验显示，当账户规模达到千级别时，其相对传统锁机制的加速比可达25倍，说明系统对冲突并不敏感。

冲突率的意义在于，它是乐观并行执行系统吞吐能力的真正瓶颈所在。一条并行EVM链的理论TPS再高，如果实际负载下的冲突率居高不下，大量交易需要反复重执行，最终体现在用户端的吞吐和延迟表现会与理论值相去甚远。因此评估一条乐观并行链时，仅看TPS峰值是不够的，还需要追问：这个吞吐数字对应的测试负载，冲突率处在什么水平？是接近无冲突的转账压测，还是高竞争的DeFi组合场景？

### 为什么这些定义值得较真

Messari、Delphi Digital、L2beat这类行业研究机构在做链间对比时，通常会要求披露测试负载的具体构成、硬件规格、节点数量、统计时间窗口，正是因为TPS、确认延迟这类指标本身的定义弹性太大，脱离披露条件的单一数字几乎没有比较价值。

对于并行EVM这个赛道而言，这套词典尤其重要。因为无论是确定性并行（如Solana Sealevel）还是乐观并行（如Aptos Block-STM、Monad、Sei，也包括Bitroot这样的项目），厂商公布的性能数字几乎都会同时涉及TPS统计口径、确认延迟对应的最终性等级、以及冲突率这三重变量。任何一条链在对外宣传时，如果只给出一个不带任何测试条件的TPS数字，读者都有理由要求补充：这是理论峰值还是实测均值？是否含系统交易？对应的最终性是软确认还是硬最终？测试负载的冲突率处在什么区间？

这套追问方式，正是本系列后续对比与基准测试（第79至88篇）要用到的分析工具，也是本文希望留给读者的最终收获：不是记住几个术语的定义，而是养成看到任何性能数字时先问清楚统计口径的习惯。

## 延伸阅读

- 前置阅读：[《谁该读并行 EVM：合约开发、客户端工程、研究员三条路径》](/zh/blog/who-should-read-parallel-evm)
- 下一篇：[《去中心化与性能的张力：验证者门槛、硬件与地理分布》](/zh/blog/decentralization-performance-tradeoff)

数据来源：Chainspect《Unveiling Blockchain Performance: Real-Time TPS vs. Max TPS Claims》；BingX与Crypto Briefing关于Solana非投票TPS的报道；Aptos Labs《Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing》（arXiv:2203.06871）；ethereum.org与Vitalik Buterin关于信标链最终性机制的说明；Solana官方文档《Optimistic Confirmation and Slashing》；Helius《Solana Commitment Levels》；Nansen《What Is Tendermint》