电路性能比较

（部分： 生态系统和网络）

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"竞赛,而是学科：单一场景、公平的成本和数据正常化、最终化和可持续性会计、透明的配对和可重复的测试。遵循此框架，生态系统将获得可比的，适合决策的度量-从选择产品下的站点到规划链间体系结构。