公链叙事里最常见的动作之一，是甩出一个足够大的吞吐数字。同一张海报上的「峰值 TPS」与链上实时可观测吞吐，往往根本不是同一个统计量。第三方监测机构公开比较过宣称峰值与实测吞吐的差距：在部分网络上，二者可以相差两个数量级以上。这通常不是「谁在撒谎」这么简单，而是「理论峰值」与「观测窗口内的实际处理量」被习惯性混用。
对评估高性能、尤其是并行 EVM 路线的读者，若不能先对齐 TPS、BPS、确认延迟、最终性、冲突率的含义，后面所有对比都可能是苹果比橙子。前文 《谁该读并行 EVM》 按角色分了阅读路径；本文提供公共度量词汇。文中引用的外部数字均为公开披露口径的示例，用于说明测量差异，不构成对任何项目的评价或投资建议。
TPS：一个缩写，至少三种算法
TPS（transactions per second）字面是每秒交易数，实操里至少有三种口径：
- 理论 / 实验室峰值：在指定硬件、指定客户端版本、指定交易构成（常见是简单转账或合成低冲突负载）下测到的上限。数字最大，外推到主网最弱。
- 可持续吞吐：在设定的延迟与失败率约束下，系统能稳定维持的处理速率。对支付与结算场景，这个数字往往比峰值更有意义。
- 观测窗口吞吐：在某一时间段内，链上实际被包含并（按所选最终性定义）确认的交易数除以秒数。它反映真实需求与真实拥堵，不等于能力上限。
并列追问三项，否则无法比较：交易如何计数（是否含投票 / 系统内务交易）？失败或回滚交易是否计入？测量窗口多长、硬件与客户端版本是什么？并行 EVM 还有第四问：测试负载的冲突率或热点分布是什么？没有冲突分布的峰值，参考价值有限——这一点在 《冲突热点与工作负载》 会展开。
同一条链也可以同时诚实披露三种 TPS：实验室峰值说明上限，可持续吞吐说明产品可用区间，观测窗口说明当下需求是否打满能力。把三者印成一个数字，才是误导的开始。阅读材料时，遇到「最高可达」应默认归入峰值类，并寻找可持续与观测两类对照。
BPS：别把「区块变快」直接翻译成「用户变快」
本文中的 BPS 指 blocks per second（每秒区块数），描述出块频率。提高 BPS 可以降低「等待下一个区块」的平均时间，但用户感知延迟还取决于：交易何时进入提议者内存池、执行与冲突重做耗时、以及协议定义的最终性还要几个区块或几轮投票。
因此 BPS 是共识与打包节奏的指标，不是端到端体验的充分统计量。一条链可以把 BPS 做高，却在高冲突执行阶段堆积重执行队列，用户仍感到慢。阅读材料时，应把 BPS 与确认延迟、最终性分开记录，而不是用出块变快替代全部性能叙事。若某份文档把 BPS 写成其他含义（例如字节相关吞吐），应以该页定义为准，并避免与本文口径混比。
确认延迟：从发到「我看见了」
确认延迟通常指：用户（或钱包）发出交易起，到交易被网络按某一「可接受确认」规则承认止的时间。关键在于「可接受」的定义必须写明——是「出现在最新提议区块」，还是「经过 k 个后续区块」，还是「满足 BFT 式提交条件」。
实用阅读法：
- 看 p50 / p95 / p99，不要只看平均值；长尾决定客服工单与套利窗口。
- 看负载条件：空链上的延迟与拥堵期延迟不是同一指标。
- 对并行执行，额外看冲突重试是否把部分交易的延迟分布拉宽。
- 区分「本地节点已执行」与「网络已最终确认」：钱包 UI 有时显示前者，结算场景往往需要后者。
披露完整的确认延迟，应同时给出确认定义、百分位、负载描述与客户端采样方式。缺任一项，数字就难以复现。支付与商户结算尤其依赖可预期的延迟上界；只有平均值、没有尾部的材料，对这类场景几乎没有决策价值。
最终性：经济最终性与协议最终性不要混称
最终性描述「交易结果再被推翻的代价有多高 / 是否在协议上已不可逆」。两类常见用法经常被混谈：
- 协议最终性（deterministic finality）：BFT 类共识在收集到足够投票后，区块进入提交状态，诚实节点按协议不再回滚。延迟往往可用「几轮消息」刻画。
- 经济 / 概率最终性：如最长链或某些滚动确认规则下，随着后续区块增加，重组概率下降，但理论上仍可能被更长链取代；「最终」是风险阈值问题。
把概率最终性下的「N 个确认」直接写成「最终确定」，会造成跨链比较失真。评估结算与跨链桥场景时，应明确用的是哪一种最终性，以及对应的时间与假设（敌手算力 / 质押比例 / 网络同步假设等）。Bitroot 技术叙述中的 Pipeline BFT 属于追求快速协议最终性的设计方向之一，细节见 《Pipeline BFT 与多引擎协同》；是否达到某条产品材料宣称的秒级最终性，仍应以该次测试的披露条件为准，而不是把设计目标当成已验证的主网事实。
最终性时间与确认延迟相关但不等同：用户可能在「软确认」后就更新 UI，而桥与托管方仍等待协议最终性。比较两条链时，应先对齐比较的是哪一档「够用」。
冲突率：并行 EVM 特有的「隐藏分母」
冲突率描述在乐观并行设定下，因读写集冲突而需要回滚或串行化重做的交易比例（具体定义应写明：按交易计数还是按 Gas、冲突粒度是账户还是槽）。它不是传统单线程链海报上的常客，却是解释「为何转账基准很快、AMM 基准变慢」的关键分母。
粗略直觉：
- 冲突率接近 0：并行加速比有机会接近执行引擎数量（仍受调度与状态访问开销约束）。
- 冲突率升高：有效吞吐滑向「串行执行 + 回滚成本」，CPU 很忙，用户仍可能等很久。
因此，并行 EVM 的诚实基准至少应报告两组数字：低冲突负载与高冲突（或真实合约混合）负载，并标注冲突定义。只发布转账峰值，等于把分母藏起来。冲突率也应与 Gas 加权版本对照：少量高 Gas 的热点交易，可能比大量轻量冲突交易更能打穿吞吐。
阅读基准测试的最小披露清单
看到任何性能表，建议按清单打勾：
| 披露项 | 为什么需要 |
|---|---|
| 硬件（CPU / 内存 / 磁盘 / 网络）与节点数 | 否则无法判断是否用极端机器堆出来的峰值 |
| 客户端版本与配置 | 同协议不同实现，数字可以差一截 |
| 交易构成与冲突率定义 | 并行场景下决定数字可否外推 |
| TPS 口径（峰值 / 可持续 / 观测） | 避免三种算法互比 |
| 确认延迟定义与百分位 | 避免「平均很快、长尾很慢」被掩盖 |
| 最终性类型（协议 / 经济） | 避免跨模型误比 |
| 是否主网、测试网或实验室 | 测试网数字不等于生产稳定表现 |
缺项越多，数字的可引用性越低。这与「数字越大越好」的海报逻辑相反，却是工程与研究上唯一可复现的读法。把它与下一篇的去中心化维度一起看：同一峰值若只在少量高配机器、同城部署上成立，外推含义会再缩一圈。
收束
性能指标不是用来装饰首页的形容词，而是一组必须带附件的测量结果。TPS 没有单一真值，BPS 不能替代用户延迟，确认与最终性必须先定义再比较，冲突率则是并行 EVM 阅读材料里不该再缺席的分母。对齐这套词典之后，再进入去中心化与硬件门槛的讨论，以及热点负载下的吞吐退化，才不会被单一峰值带跑。若只能记一件事：看到任何 TPS，先问「峰值、可持续还是观测」，再问「冲突率披露了没有」。两问都能回答，数字才值得进入你的对比表；两问都答不上，海报再大也可以先放下。
若只能记一件事：看到任何 TPS，先问「峰值、可持续还是观测」，再问「冲突率披露了没有」。两问都能回答，数字才值得进入你的对比表；两问都答不上，海报再大也可以先放下。把这份词典钉在对比表表头，比把某一条链的峰值抄进幻灯片更有用。
同一份基准若换了交易生成器或冲突注入方式，数字可以大幅跳动；因此对比两条链时，优先对齐负载生成方法，而不是对齐形容词。