電路性能比較

（部分： 生態系統和網絡）

1）為什麼，我們比較什麼

• 速度和延遲：啟用，最終化，變異性。
• 經濟學：交易和數據的成本，傭金的穩定性。
• 彈性：重生，暴雨，負荷降解。
• 數據可用性：DA帶寬和字節成本。
• 運營：節點要求，財富規模，客戶多元化。

結果-匯總的KPI，允許根據特定場景（支付，遊戲/微觀活動，橋梁，DA/出版物）選擇鏈/域。

2）分類學指標（內核）

2.1個吞吐量和延遲

持續的TPS/QPS（穩定帶寬）

Peak TPS（無錯誤短峰值）

Time-to-Inclusion (TTI) p50/p95/p99

時間到最終性（TTF）p50/p95/p99（考慮到K確認/挑戰窗口）

Block Utilization% （Block/Batch填充）

Variance/Jitter延遲（σ, CV）

2.2質量和可持續性

成功率（%成功的tx/events）

Reorg/Orphan Rate（頻率和深度）

Liveness SLO Hit（執行目標可用性）

降級恩典（控制降解而不是fail）

2.3經濟學和DA

Fee p50/p95/p99（本幣和美元）

Cost-per-kB （DA）-1 kB數據發布價格

Cost-per-Tx Class-「交易類型」價格： 簡單翻譯，合同調用，大呼喚

Fee Volatility Index（窗口傭金穩定性）

2.4節點和狀態

硬件Footprint（CPU/RAM/SSD/驗證器/存檔節點網絡）

State Growth（財富增長/日）

客戶多元化指數（客戶/驗證者分布）

同步時間（快速/存檔合成器）

2.5 L2特殊性

Batch TPS（具有哨兵），Batch Size（kB）

Time-to-Batch Inclusion и Time-to-Prove (ZK) / Challenge Window (optimistic)

DA Throughput (МБ/с) и DA Failure Rate

Settlement Latency（L2→L1決賽）

3）測量技術（中性和可復制）

1.單一負載計劃（TUP-測試使用配置文件）：

TUP-Pay：小額轉賬（N=70% simple, 30% token）。
TUP-Game：簡短的calldata事件（最高2-8 kB）。
TUP-DEX：中型氣體和高峰期合同。
TUP-DA：大型出版物（50-250 kB batcham）。

2.負載層：背景60-80%為目標SLO+脈沖120-160%每30-60分鐘5-10分鐘。

3.地理和網絡： 最少3個區域，RTT矩陣，噴射器/輸液（0。5–2%).

4.客戶多元化：每條鏈條至少有2個節點客戶端（如果可用）,版本相同。

5.遙測收集：正確相關（trace-ID），時間同步（NTP/PTP），密碼固定。

6.最終化窗口：明確設置K/爭議窗口；TTF計入電路規則。

7.錯誤語義：故障分類法（gas/nonce/limit/DA-feil/overload）,從「成功率」中排除「預期」錯誤或單獨分配。

4）正常化和反偏差

Cost Normalization: USD по курсу на `observed_at`; `fee_usd = fee_native × price_usd_at_t`.

天然氣/重量均衡：比較「操作類別」而不比較「原始氣體」。

Hardware-Adjusted TPS: `TPS_per_$ = Sustained_TPS / (Monthly_Node_Cost_USD)`

Fair DA Compare：1 kB和p95延遲出版的價格。
Volatility Windows：每周/每月窗口，中位數和IQR代替「一次性記錄」。
Cold vs Warm：加熱緩存；穩定後的測量。
MEV/峰值傭金：排除「市場異常」或分配一個單獨的指標。

5）總計KPI（總數）

• Throughput (30%), Finality (25%), Cost (20%), Stability (15%), Uptime/Liveness (10%).
• 加權系數可根據腳本（例如，用於支付↑Finality/Cost，用於↑Throughput/Stability/DA遊戲）進行調整。

Effective Throughput@SLO是一種可持續的TPS，同時遵守「TTF_p95 ≤ X」，「成功≥ Y%」，「Fee_p95 ≤ Z」。
1k Ops的Cost-to-Serve per 1k Ops-處理1000類操作（包括DA/定位）的全部成本。
Finality SLA Hit%-在目標窗口中完成的操作比例。

6）SLI/SLO進行比較

• Payments: `TTF_p95 ≤ 10s`, `Success ≥ 99.7%`, `Fee_p95 ≤ $0.01`.
• Games/Events: `TTI_p95 ≤ 500ms`, `TTF_p95 ≤ 3s`, `Success ≥ 99.5%`, `DA_p95 ≤ 1s`.
• DA/Publishing: `Cost_per_kB ≤ $0.0005`, `Publish_p95 ≤ 2s`, `Finality_p95 ≤ 60s`.
• L2設置：「Settle_p95 ≤ 10m」（ZK）/「挑戰窗口」用於優化。

7）Dashbords（參考模型）

Perf Lens （real time/hour）： TTI/TTF p50/p95/p99, Block Utilization, Success Rate, Fee p95, Error taxonomy.

Cost & DA: Cost/kB, Fee-volatility, DA throughput/latency, отказ DA.

Stability： Reorg Rate, Liveness SLO Hit, Burn-rate錯誤,aptime centenser （L2）。

Capacity Planning: Sustained vs Peak TPS, Hardware-Adjusted TPS, State Growth.

8）數據方案和邏輯（偽SQL）

原始基準事件

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和連鎖功能

Optimistic L2：指定「雙重」TTF-在L2包容之前和挑戰窗口結束之前。
ZK L2：將L1上的發布時間和pruf生成/驗證時間分開；考慮到pruver的容錯性。
Validium/DA輸出：DA度量是強制性的（throughput/cost/failure）,否則比較是不正確的。
連鎖操作：計數橋接場景的TTF E2E（istochnik→tsel），考慮到K/DA/挑戰。

11）反比較模式（避免什麼）

將一個鏈條的「記錄峰值」與另一個鏈條的「平均峰值」進行比較。
忽略數據成本和傭金波動性。
不考慮最終化（將「包容性」與「最終性」進行比較）。
在「加熱」節點上刪除度量並轉移到冷節點。
混合不同的操作類別而不進行標準化。
不要記錄客戶/configa版本-失去可重復性。

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）報告和可視化

情景匯總表：Effective TPS，TTI/TTF p95，Fee p95，Cost/kB，Success％。
雷達圖（每個腳本）：Throughput/Finality/Cost/Stability/Liveness。
時間序列：Fee-volatility，DA潛伏期，Reorg spikes。
「電路×操作類」矩陣：成本服務和TTF。

14）流程和角色

基準所有者：方法/工具，版本控制。
Infra Owner：節點,客戶,configies,地區。
數據/BI：聚合，正確性檢查，dashbords SLO。
安全/合規性：控制登錄的隱私和正確性。
施政：公布結果，改變索引權重。

15）基準事件劇本

Config/Version漂移：立即停止系列,固定snapshot,以正確的參數重新啟動。
網絡異常（超出計劃）：將窗口標記為「反向」，重播系列。
DA/Pruver故障：突出一個單獨的事件,重復下系列DA/ZK。
意外價格波動：固定窗口中位數USD，附帶範圍。

16）實施支票

1.批準腳本（TUP）和摘要索引權重。
2.捕獲節點/客戶端，區域和網絡條件的configs。
3.利用時間相關性和同步性實現遙測采集。
4.設置fee/DA/操作類正常化。
5.協調SLI/SLO和dashbords布局。

6.進行試點系列,驗證可重復性,校準負荷.

7.通過完整的config、版本和日期應用程序發布報告。

17）詞匯表

TTI/TTF-啟用/最終化之前的時間。
DA-數據可用性層。
可持續的/峰值TPS-穩定/峰值吞吐量。
Liveness-網絡確認塊/蹦床的能力。
挑戰窗口是優化滾動中的挑戰窗口。
State Growth-網絡狀態大小的增加。
Hardware-Adjusted TPS-基於節點成本的帶寬。

底線：正確的電路性能比較不是「誰比TPS」競賽,而是學科：單一場景、公平的成本和數據正常化、最終化和可持續性會計、透明的配對和可重復的測試。遵循此框架，生態系統將獲得可比的，適合決策的度量-從選擇產品下的站點到規劃鏈間體系結構。