--- 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 を読むべきか](/ja/blog/who-should-read-parallel-evm)は役割別に読書パスを分けました。本稿は共有の測定語彙を供給します。以下で引用する外部の数値は、測定の違いを説明するために使う公開開示の例であり、**プロジェクトの格付けや投資助言ではありません**。 ## TPS：一つの略語、少なくとも三つの式 TPS は文字通り毎秒のトランザクション数です。実際には少なくとも三つの異なる計算があります。 1. **理論上／ラボのピーク**：特定のハードウェア、クライアントのバージョン、トランザクションの構成（しばしば単純な送金や合成の低コンフリクト負荷）の下での上限。最大の数値で、メインネットへの外挿が最も弱い。 2. **持続可能なスループット**：示されたレイテンシと失敗率の制約の下でシステムが維持できる速度。決済と決済処理では、ピークよりも意味があることがよくあります。 3. **観測ウィンドウのスループット**：ある時間窓で取り込まれ確認された（選んだ最終性の定義の下での）トランザクション数を秒で割ったもの。能力の上限ではなく、実際の需要と輻輳を反映します。 三つの問いを並行して尋ねないと比較は失敗します。トランザクションはどう数えられるか（票やハウスキーピングを含むか）。失敗した、あるいはロールバックされたトランザクションを含むか。ウィンドウはどれくらいで、どんなハードウェアとクライアントのバージョンか。並列 EVM は四つ目を加えます。テスト負荷のコンフリクト率やホットスポット分布は何か。コンフリクト分布のないピークは価値が限られます。[コンフリクトのホットスポットとワークロード](/ja/blog/parallel-evm-workload-hotspots)で掘り下げます。 同じチェーンが三つの TPS モードを正直に公開できます。上限のためのラボピーク、使用可能なプロダクト帯のための持続可能、今日需要が容量を満たしているかを見る観測ウィンドウ。それらを一つの数値として印刷するところから誤導が始まります。「最大」を見たら、既定でピークのバケツに入れ、持続可能と観測の対応物を探してください。 ## BPS：「より速いブロック」を「より速いユーザー」に直訳しない 本稿で BPS は**毎秒のブロック数**、ブロック生成の頻度を意味します。BPS を上げると次のブロックまでの平均待ちは短くなり得ますが、ユーザー体感のレイテンシは、トランザクションが提案者の mempool に入る時期、実行とコンフリクトの再試行にかかる時間、プロトコルの最終性がさらに何ブロックまたは投票ラウンドを要するかにも依存します。 したがって BPS はコンセンサスとパッキングのリズムの指標であり、エンドツーエンドの体験の十分統計量ではありません。高コンフリクトの実行が再実行キューを積み上げれば、チェーンは BPS を上げても遅く感じられます。資料を読むときは、BPS を確認レイテンシと最終性から分けて記録してください。速いブロック時間に性能の物語全体を代弁させないでください。ドキュメントが BPS を別の意味（例えばバイト指向のスループット）で使うなら、そのページの定義に従い、本稿の意味と混ぜないでください。 ## 確認レイテンシ：送信から「見えた」まで 確認レイテンシは通常、ユーザー（またはウォレット）がトランザクションを送信してから、ネットワークが何らかの「許容できる確認」のルールの下でそれを承認するまでの時間を意味します。重要なのは「許容できる」が何を意味するかを書き留めることです。最新の提案ブロックに現れることか、その後の k ブロックを生き延びることか、BFT 風のコミット条件を満たすことか。 実践的な読み方の習慣です。 - 平均だけでなく **p50／p95／p99** を優先する。テールがサポートのチケットと裁定の窓を左右します。 - 負荷を注記する。空のチェーンのレイテンシと輻輳期のレイテンシは別の指標です。 - 並列実行では、コンフリクトの再試行がレイテンシ分布の一部を広げないかも見る。 - 「ローカルノードで実行された」と「ネットワークによって最終化された」を分ける。ウォレットの UI は前者を示すことがあり、決済はしばしば後者を必要とします。 完全なレイテンシの開示は、確認の定義、パーセンタイル、負荷の記述、クライアントのサンプリング方法を述べます。どれかが欠けると数値は再現しにくくなります。支払いと加盟店の決済は特に予測可能なレイテンシの上限を必要とし、平均のみの資料はそうしたシナリオにとってほとんど意思決定の価値がありません。 ## 最終性：経済的最終性とプロトコル最終性を混同しない 最終性は、トランザクションの結果がなお覆され得るコスト、あるいはプロトコルによって覆されないかを表します。よくある二つの用法がしばしば混ざります。 - **プロトコル最終性（決定論的最終性）**：BFT 風のコンセンサスの下で、十分な票が集まるとブロックはコミット状態に入り、正直なノードはプロトコルの下でそれをロールバックしません。レイテンシはしばしばメッセージのラウンドで語られます。 - **経済的／確率的な最終性**：最長チェーンや一部のローリング確認のルールの下では、ブロックが積み上がるほど再編成の確率は下がりますが、理論上はより長いチェーンが履歴を置き換え得ます。「最終」はリスクの閾値です。 確率的最終性の下での「N 確認」を「最終化済み」と呼ぶと、クロスチェーン比較が歪みます。決済やブリッジのシナリオでは、どの最終性モデルが適用され、どの仮定（敵対者のハッシュパワー／ステーク比率／ネットワーク同期）の下かを述べてください。Bitroot の Pipeline BFT 周りの技術的な物語は高速なプロトコル最終性を狙います。[Pipeline BFT とマルチエンジンの相乗](/ja/blog/bitroot-pipeline-bft)を参照してください。サブ秒の最終性というプロダクトの主張が成り立つかは、依然としてそのテストの開示された条件に縛られます。設計目標は検証済みのメインネットの事実ではありません。 最終性の時間は確認レイテンシと関係しますが同一ではありません。ユーザーはソフトな確認の後に UI を更新しても、ブリッジとカストディアンは依然としてプロトコル最終性を待つことがあります。二つのチェーンを比較するときは、まずどの層の「十分」を比較しているのかを揃えてください。 ## コンフリクト率：並列 EVM の「隠れた分母」 コンフリクト率は、楽観的並列の下で、読み書き集合のコンフリクトのためにロールバックまたは直列に再実行されなければならないトランザクションの割合を表します（定義では、トランザクション数かガスか、アカウントかスロットの粒度かを述べるべきです）。古典的な単一スレッドのポスターにはめったに現れませんが、送金のベンチマークが速く見え AMM のベンチマークが遅くなる理由を説明する分母です。 おおまかな直感です。 - コンフリクト率がほぼ 0：並列の高速化は実行エンジンの数に近づき得ます（依然としてスケジューリングと状態アクセスのオーバーヘッドに制限されます）。 - コンフリクト率の上昇：実効スループットは「直列実行＋ロールバックコスト」へ滑ります。CPU は忙しいままなのにユーザーは待ち続けます。 したがって正直な並列 EVM のベンチマークは少なくとも二つの数値を報告します。低コンフリクト負荷と高コンフリクト（または現実的な混合コントラクト）負荷であり、コンフリクトの定義を明記します。送金のピークだけを公開すると分母が隠れます。ガス加重のコンフリクト率も比較してください。少数の重いホットスポットのトランザクションが、多くの軽いコンフリクトよりもスループットを穿孔し得ます。 ## ベンチマークを読むための最低限の開示チェックリスト 性能表を見たら、ボックスにチェックを入れてください。 | 開示項目 | なぜ重要か | |------|------------| | ハードウェア（CPU／RAM／ディスク／ネットワーク）とノード数 | そうでなければ、ピークが極端なマシンに積み上げられたかを判断できない | | クライアントのバージョンと設定 | 同じプロトコルでも実装が違えば数値も違う | | トランザクションの構成とコンフリクト率の定義 | 並列の数値が外挿できるかを決める | | TPS のモード（ピーク／持続可能／観測） | 三つの式を一つとして比較するのを防ぐ | | 確認の定義とパーセンタイル | 「平均は速くテールは遅い」が隠れるのを防ぐ | | 最終性の種類（プロトコル／経済） | モデルをまたぐ誤った比較を防ぐ | | メインネット、テストネット、ラボ | テストネットの数値は本番で安定した性能ではない | 欠ける項目が多いほど、その数値は引用しにくくなります。これは「大きいほど良い」というホームページの論理に反しますが、エンジニアリングと研究にとって唯一再現可能な読み方です。次の記事の分散化の次元と併せて読んでください。一つの都市の少数の高性能マシンだけで測定された同じピークは、外挿するとさらに縮みます。 ## 結び 性能指標はホームページの形容詞ではなく、添付資料を必要とする測定です。TPS に単一の真の値はなく、BPS はユーザーのレイテンシを置き換えられず、確認と最終性は比較の前に定義されなければならず、コンフリクト率はもはや並列 EVM の読み方から欠けていてはなりません。この用語集が揃えば、分散化とハードウェアの下限、そしてホットなワークロード下でのスループットの崩壊についての議論が、単一のピークに乗っ取られる可能性は低くなります。 ## 関連記事 - 前：[誰が並列 EVM を読むべきか：コントラクト開発者、クライアントエンジニア、研究者の三つのパス](/ja/blog/who-should-read-parallel-evm) - 次：[分散化と性能の緊張：バリデータ要件、ハードウェア、地理的分布](/ja/blog/decentralization-performance-tradeoff) - 関連：[コンフリクトのホットスポットとワークロード：並列 EVM が実際に効くとき](/ja/blog/parallel-evm-workload-hotspots)