---
id: 18
title: 效能指標詞典：TPS、BPS、確認延遲、最終性、衝突率
slug: performance-metrics-glossary
date: 2026/09/08
summary: TPS、BPS、確認延遲、最終性、衝突率經常被混用。本文給出可複用的定義、常見的誤用方式，以及閱讀基準測試時必須追問的披露項目——不構成任何投資建議。
keywords: TPS,BPS,確認延遲,最終性,衝突率,基準測試
heroImage: /images/community-bg.png
---

公鏈敘事裡最常見的動作之一，是甩出一個足夠大的吞吐數字。同一張海報上的「峰值 TPS」與鏈上即時可觀測的吞吐量，往往根本不是同一個統計量。第三方監測機構曾公開比較宣稱峰值與實測吞吐的差距：在部分網路上，二者可以相差兩個數量級以上。這通常不是「誰在說謊」這麼簡單，而是「理論峰值」與「觀測窗口內的實際處理量」被習慣性地混用。

對評估高效能、尤其是平行 EVM 路線的讀者來說，若不能先對齊 TPS、BPS、確認延遲、最終性、衝突率的含義，後面所有對比都可能是蘋果比橘子。前文 [《誰該讀平行 EVM》](/zh-Hant/blog/who-should-read-parallel-evm) 按角色分了閱讀路徑；本文提供公共的度量詞彙。文中引用的外部數字均為公開披露口徑的示例，用於說明測量差異，**不構成對任何專案的評價或投資建議**。

## TPS：一個縮寫，至少三種演算法

TPS（transactions per second）字面上是每秒交易數，實務上至少有三種口徑：

1. **理論 / 實驗室峰值**：在指定硬體、指定客戶端版本、指定交易組成（常見是簡單轉帳或合成的低衝突負載）下測到的上限。數字最大，外推到主網時最弱。
2. **可持續吞吐量**：在設定的延遲與失敗率約束下，系統能穩定維持的處理速率。對支付與結算場景，這個數字往往比峰值更有意義。
3. **觀測窗口吞吐量**：在某段時間內，鏈上實際被包含並（按所選最終性定義）確認的交易數除以秒數。它反映真實需求與真實壅塞，不等於能力上限。

並列追問三項，否則無法比較：交易如何計數（是否包含投票 / 系統內務交易）？失敗或回滾的交易是否計入？測量窗口多長、硬體與客戶端版本是什麼？平行 EVM 還有第四問：測試負載的衝突率或熱點分布是什麼？沒有衝突分布的峰值，參考價值有限——這一點在 [《衝突熱點與工作負載》](/zh-Hant/blog/parallel-evm-workload-hotspots) 會展開。

同一條鏈也可以同時誠實披露三種 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 與多引擎協同》](/zh-Hant/blog/bitroot-pipeline-bft)；是否達到某條產品材料宣稱的秒級最終性，仍應以該次測試的披露條件為準，而不是把設計目標當成已驗證的主網事實。

最終性時間與確認延遲相關但不等同：使用者可能在「軟確認」後就更新 UI，而橋與託管方仍等待協議最終性。比較兩條鏈時，應先對齊比較的是哪一檔「夠用」。

## 衝突率：平行 EVM 特有的「隱藏分母」

衝突率描述在樂觀平行的設定下，因讀寫集衝突而需要回滾或串列化重做的交易比例（具體定義應寫明：按交易計數還是按 Gas、衝突粒度是帳戶還是槽）。它不是傳統單執行緒鏈海報上的常客，卻是解釋「為何轉帳基準很快、AMM 基準變慢」的關鍵分母。

粗略的直覺：

- 衝突率接近 0：平行加速比有機會接近執行引擎的數量（仍受排程與狀態存取開銷約束）。
- 衝突率升高：有效吞吐量滑向「串列執行 + 回滾成本」，CPU 很忙，使用者仍可能等很久。

因此，平行 EVM 的誠實基準至少應報告兩組數字：低衝突負載與高衝突（或真實合約混合）負載，並標註衝突定義。只發布轉帳峰值，等於把分母藏起來。衝突率也應與 Gas 加權版本對照：少量高 Gas 的熱點交易，可能比大量輕量衝突交易更能打穿吞吐量。

## 閱讀基準測試的最小披露清單

看到任何效能表，建議按清單逐項打勾：

| 披露項目 | 為什麼需要 |
|------|------------|
| 硬體（CPU / 記憶體 / 磁碟 / 網路）與節點數 | 否則無法判斷是否用極端機器堆出來的峰值 |
| 客戶端版本與設定 | 同協議不同實作，數字可以差一截 |
| 交易組成與衝突率定義 | 平行場景下決定數字可否外推 |
| TPS 口徑（峰值 / 可持續 / 觀測） | 避免三種演算法互比 |
| 確認延遲定義與百分位 | 避免「平均很快、長尾很慢」被掩蓋 |
| 最終性類型（協議 / 經濟） | 避免跨模型誤比 |
| 是否為主網、測試網或實驗室 | 測試網數字不等於生產環境的穩定表現 |

缺項越多，數字可引用的程度就越低。這與「數字越大越好」的海報邏輯相反，卻是工程與研究上唯一可重現的讀法。把它與下一篇的去中心化維度一起看：同一峰值若只在少量高規格機器、同城部署上成立，外推的含義會再縮一圈。

## 收束

效能指標不是用來裝飾首頁的形容詞，而是一組必須帶附件的測量結果。TPS 沒有單一真值，BPS 不能替代使用者延遲，確認與最終性必須先定義再比較，衝突率則是平行 EVM 閱讀材料裡不該再缺席的分母。對齊這套詞典之後，再進入去中心化與硬體門檻的討論，以及熱點負載下的吞吐退化，才不會被單一峰值帶跑。

## 延伸閱讀

- 前置閱讀：[《誰該讀平行 EVM：合約開發、客戶端工程、研究員三條路徑》](/zh-Hant/blog/who-should-read-parallel-evm)
- 下一篇：[《去中心化與效能的張力：驗證者門檻、硬體與地理分布》](/zh-Hant/blog/decentralization-performance-tradeoff)
- 相關：[《衝突熱點與工作負載：平行 EVM 何時真的變快》](/zh-Hant/blog/parallel-evm-workload-hotspots)