回路性能の比較

（セクション： エコシステムとネットワーク）

1）なぜ、何を比較するか

• 速度と遅延：包含、最終化、可変性。
• 経済学：取引とデータのコスト、手数料の安定性。
• 安定性性orgs、シャワー、負荷の下の劣化。
• データの可用性：DA帯域幅とバイトコスト。
• オペレーティングシステム：ノードの要件、ステートサイズ、顧客の多様化。

その結果、特定のシナリオ（支払い、ゲーム/マイクロイベント、ブリッジ、DA/出版物）のチェーン/ドメインを選択できる統合KPIが得られます。

2）メトリクスの分類（コア）

2.1スループットとレイテンシ

持続的なTPS/QPS

ピークTPS（エラー/ドロップなしの短いピーク）

包含までの時間（TTI） p50/p95/p99

Time-to-Finality （TTF） p50/p95/p99

ブロック使用率％

遅延の分散/ジッタ（σ、履歴書）

2.2品質と持続可能性

成功率（成功したtx/イベントの％）

Reorg/Orphan Rate（周波数と深さ）

Liveness SLOヒット

劣化グレース（制御劣化の代わりに失敗）

2.3経済とDA

料金p50/p95/p99（ネイティブ通貨とUSD）

1 kBあたりのコスト（DA）-1 kBのデータの発行価格

Cost-per-Tx Class-「トランザクションタイプ」価格： シンプルな転送、コントラクト呼び出し、大きなコールデータ

料金ボラティリティインデックス

2.4ノードとステータス

ハードウェアフットプリント（バリデータ/アーカイブノード用CPU/RAM/SSD/ネットワーク）

ステートの成長

クライアント・ダイバーシティ・インデックス

［同期時間］

2.5 L2特異性

バッチTPS（センセンサー）、バッチサイズ（kB）

Time-to-Batch Inclusion （ZK）/チャレンジウィンドウ（楽観的）

DA Throughput （DAスループット）

決済レイテンシー（L2→L1ファイナライズ）

3）測定手順（中性、再現性）

1.テスト使用のプロフィール（TUP）：

TUP-Pay：小さな転送（N=70％シンプル、30％トークン）。
TUP-Game：コールデータ付きの短いイベント（最大2-8 kB）。
TUP-DEX：中間ガスおよびサージ契約。
TUP-DA：大きな出版物（50-250 kB batchami）。

2.負荷層：背景ターゲットSLOの60-80％+パルス120-160％の5-10分毎に30-60分。

3.地理とネットワーク： 少なくとも3つの領域、RTTマトリックス、ジッタ/ロスインジェクション（0。5–2%).

4.クライアントの多様化：回路ごとに少なくとも2つのノードクライアント（利用可能な場合）、同一のバージョン。

5.テレメトリーコレクション：正しい相関（trace-ID）、時間同期（NTP/PTP）、設定の修正。

6.確定ウィンドウ：紛争K/windowの明示的な設定。回路規則を考慮してTTFを読んでください。

7.エラーセマンティクス：失敗タクソノミ（gas/nonce/limit/DA-file/overload）、 「expected」エラーをSuccess Rateから除外するか、個別にハイライトします。

4）正規化および反バイアス

コストノーマライゼーション：USD 'observed_at'； 'fee_usd=fee_native × price_usd_at_t'。
ガス/重量等価性：「生のガス」ではなく「操作クラス」による比較。

ハードウェア調整済みTPS： 'TPS_per_$=Sustained_TPS/（ Monthly_Node_Cost_USD）'

Fair DA Compare： 1 1kBあたりの価格とP95の発行遅延。
ボラティリティウィンドウズ：ウィークリー/マンスリーウィンドウ、中央値、IQRの代わりに「ワンオフレコード」。
冷たいvs暖かい：キャッシュを暖めること；安定化後の測定。
MEV/ピーク手数料：「市場の異常」を除外するか、別のメトリックを強調表示します。

5） KPIの概要（合計）

• スループット（30％）、ファイナリティ（25％）、コスト（20％）、安定性（15％）、アップタイム/ライブネス（10％）。
• 重み付け要因はシナリオの下に設定されています（たとえば、Finality/Cost Paymentの場合は、Sluput/Stability/DAゲームの場合）。

実効スループット@SLO-'TTF_p95 ≤ X'、 'Success ≥ Y％'、 'Fee_p95 ≤ Z'の対象となる安定TPS。
1k Opsあたりのコスト・ツー・サーブ-1000クラスの処理コスト（DA/決済を含む）。
Finality SLA Hit％-ターゲットウィンドウで確定した操作の共有。

6）比較のためのSLI/SLO

• 支払い：'TTF_p95 ≤ 10s'、'成功≥ 99。7％'、'Fee_p95 ≤ $0。01`.
• ゲーム/イベント：'TTI_p95 ≤ 500ms'、 'TTF_p95 ≤ 3s'、'成功≥ 99。5％'、'DA_p95 ≤ 1s'。
• DA/Publishing： 'Cost_per_kB ≤ $0。0005'、'Publish_p95 ≤ 2s'、'Finality_p95 ≤ 60'。
• L2決済：「Settle_p95 ≤ 10m」 （ZK）/楽観的には「チャレンジウィンドウ」。

7）ダッシュボード（参照レイアウト）

Perfレンズ（リアルタイム/時間）：TTI/TTF p50/p95/p99、ブロック使用率、成功率、手数料p95、エラー分類。
コスト&DA： コスト/kB、手数料ボラティリティ、DAスループット/レイテンシ、DA。
安定性性org Rate、 Liveness SLO Hit、 Burn-rate errors、 uptime sentenser （L2）。
容量計画：持続TPS、ハードウェア調整TPS、ステート成長。

8）データスキーマとロジック（擬似SQL）

Rawベンチマークイベント

sql
CREATE TABLE bench_events (
id TEXT PRIMARY KEY,
chain_id TEXT, layer TEXT,     -- L1    L2    app scenario TEXT,           -- payments    game    dex    da sent_at TIMESTAMPTZ,
included_at TIMESTAMPTZ,
finalized_at TIMESTAMPTZ,
size_bytes INT,
status TEXT,            -- success    fail_gas    fail_da    fail_overload...
fee_native NUMERIC, fee_usd NUMERIC,
region TEXT, client TEXT, node_profile TEXT
);

メトリックカーネルアグリゲーション

sql
WITH base AS (
SELECT,
EXTRACT(EPOCH FROM (included_at - sent_at)) AS tti_s,
EXTRACT(EPOCH FROM (finalized_at - sent_at)) AS ttf_s
FROM bench_events
WHERE status LIKE 'success%'
)
SELECT chain_id, scenario,
PERCENTILE_CONT(0. 5) WITHIN GROUP (ORDER BY tti_s) AS tti_p50,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY tti_s) AS tti_p95,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY ttf_s) AS ttf_p95,
AVG(fee_usd) AS fee_avg_usd,
100. 0 SUM(CASE WHEN status='success' THEN 1 ELSE 0 END) / COUNT() AS success_rate
FROM bench_events
GROUP BY chain_id, scenario;

効果的なスループット@SLOスコア

sql
SELECT chain_id, scenario,
COUNT() / NULLIF(EXTRACT(EPOCH FROM (MAX(sent_at) - MIN(sent_at))),0) AS tps_effective
FROM bench_events
WHERE status='success'
AND EXTRACT(EPOCH FROM (finalized_at - sent_at)) <=:ttf_p95_slo
AND fee_usd <=:fee_p95_slo
GROUP BY chain_id, scenario;

9）複合インデックス（計算例）

yaml weights:
throughput: 0. 30 finality:  0. 25 cost:    0. 20 stability: 0. 15 liveness:  0. 10

scoring:
throughput: normalize(Sustained_TPS, p10, p90)
finality:  invert(normalize(TTF_p95, p10, p90))
cost:    invert(normalize(Fee_p95_usd, p10, p90))
stability: invert(normalize(Var_TTF, p10, p90) + normalize(ReorgRate, p10, p90)/2)
liveness:  SLO_hit_pct

10） L2およびチェーン間の特徴

楽観的なL2：チャレンジウィンドウのL2-inclusion前と終了前に「二重」TTFを示します。
ZK L2：パブリッシング時間をL1と証明の生成/検証時間に分割します。証明者のフォールトトレランスを考慮してください。
Validium/DAアウトソース：DAメトリックが必要です（スループット/コスト/故障）。そうでない場合は比較が正しくありません。
クロスチェーン操作：K/DA/チャレンジを考慮して、ブリッジシナリオ（istochnik→tsel）のTTF E2Eを読み込みます。

11）反比較模様（避けるべきもの）

あるチェーンの「レコードピーク」と他のチェーンの「平均」を比較します。
データコストとコミッションのボラティリティを無視します。
最終決定を無視する（「inclusion」を「finality」と比較する）。
「暖かい」ノードでメトリックを撮影し、寒いノードに転送します。
ノーマライゼーションなしで異なるクラスの操作をミックスします。
クライアントバージョン/コンフィギュレーションをコミットしないでください。再現性が失われます。

12）テスト構成および変数（擬似YAML）

yaml benchmark:
scenarios:
- name: payments mix: { simple_transfer: 0. 7, token_transfer: 0. 3 }
slo: { ttf_p95_s: 10, success_pct: 99. 7, fee_p95_usd: 0. 01 }
- name: game mix: { small_event_2kb: 0. 6, medium_event_8kb: 0. 4 }
slo: { tti_p95_ms: 500, ttf_p95_s: 3 }
- name: da mix: { batch_50kb: 0. 5, batch_250kb: 0. 5 }
slo: { publish_p95_s: 2, cost_kb_usd: 0. 0005 }
load:
background_utilization_pct: 70 spikes: { multiplier: 1. 4, duration_min: 10, period_min: 45 }
regions: [eu-central, us-east, ap-south]
network_faults: { loss_pct: 1. 0, jitter_ms: 50 }
node_profiles:
validator: { cpu: "16c", ram_gb: 64, ssd_nvme_tb: 2, bw_gbps: 1 }
archive:  { cpu: "32c", ram_gb: 128, ssd_nvme_tb: 8, bw_gbps: 2 }

13）報告と可視化

シナリオ別サマリーテーブル：効果的なTPS、 TTI/TTF p95、手数料p95、 コスト/kB、成功％。
レーダーチャート（スクリプトごと）：スループット/ファイナリティ/コスト/安定性/Liveness。
時系列：手数料ボラティリティ、DAレイテンシー、Reorgスパイク。
コスト× to-ServeおよびTTFチェーン・ツー・クラス・マトリックス。

14）プロセスと役割

ベンチマークオーナー：方法論/ツール、バージョン管理。
Infra Owner：ノード、クライアント、構成、リージョン。
データ/BI：集計、検証、SLOダッシュボード。
セキュリティ/コンプライアンス：プライバシーの管理とログの正確性。
ガバナンス：結果の公開、インデックスの重みの変更。

15） Playbookベンチマークインシデント

configs/versionsのドリフト：直ちにシリーズを停止し、スナップショットをコミットし、正しいパラメータで再起動します。
ネットワークの異常（計画外）：ウィンドウを「汚染」としてマークし、シリーズを繰り返します。
DA/proverの失敗：別のインシデントをシングルアウトし、DA/ZKサブシリーズを繰り返します。
予期しない価格ボラティリティ：中央値のUSDウィンドウを修正し、範囲を取り付けます。

16）実装チェックリスト

1.シナリオ（TUP）とサマリーインデックスウェイトを承認します。
2.ホスト/クライアント構成、リージョン、およびネットワーク条件を記録します。
3.相関と時刻同期によるテレメトリコレクションを実装します。
4.料金/DA/操作クラスの正規化を設定します。
5.SLI/SLOとダッシュボードレイアウトに同意します。
6.パイロット走行を行い、再現性を確認し、負荷を校正します。
7.コンフィギュレーション、バージョン、日付の完全なアプリケーションでレポートを公開します。

17）用語集

TTI/TTF-オン/ファイナライゼーションの切り替え時間。
DA-データ可用性レイヤー。
持続/ピークTPS-持続/ピークスループット。
Liveness-ブロック/バッチを確認するネットワークの能力。
チャレンジウィンドウ-楽観的なロールアップのチャレンジウィンドウ。
State Growth-ネットワーク状態のサイズが大きくなります。
ハードウェア調整TPS-ノードのコストを考慮して、スループット。

ボトムライン：チェーン性能の正しい比較は「、誰がよりTPSであるか」レースではなく、規律です。均一なシナリオ、コストとデータの正直な正規化、確定と安定性の会計処理、透明な構成と再現性のあるテストです。このフレームワークの後、エコシステムは、製品のサイトの選択からチェーン間アーキテクチャの計画まで、比較可能な意思決定指標を受け取ります。