Сравнение производительности цепей

(Раздел: Экосистема и Сеть)

1) Зачем и что сравниваем

• Скорости и задержек: включение, финализация, вариативность.
• Экономики: стоимость транзакций и данных, стабильность комиссий.
• Устойчивости: реорги, ливнес, деградации под нагрузкой.
• Доступности данных: пропускная способность DA и стоимость байта.
• Операционки: требования к узлам, размер состояния, диверсификация клиентов.

Результат — сводные KPI, позволяющие выбирать цепи/домены под конкретные сценарии (платежи, игры/микро-ивенты, мосты, DA/публикации).

2) Таксономия метрик (ядро)

2.1 Пропускная способность и задержки

Sustained TPS/QPS (стабильная пропускная способность)

Peak TPS (короткий пик без ошибок/дропа)

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

Time-to-Finality (TTF) p50/p95/p99 (учитывать K-подтверждений/челлендж-окно)

Block Utilization % (заполненность блока/батча)

Variance/Jitter задержек (σ, CV)

2.2 Качество и устойчивость

Success Rate (% успешных tx/events)

Reorg/Orphan Rate (частота и глубина)

Liveness SLO Hit (выполнение целевой доступности)

Degradation Grace (контролируемая деградация вместо фейла)

2.3 Экономика и DA

Fee p50/p95/p99 (в нативной валюте и в USD)

Cost-per-kB (DA) — цена публикации 1 кБ данных

Cost-per-Tx Class — цена «типа транзакции»: простой перевод, вызов контракта, крупный calldata

Fee Volatility Index (стабильность комиссий по окнам)

2.4 Узлы и состояние

Hardware Footprint (CPU/RAM/SSD/сеть для валидатора/архивного узла)

State Growth (прирост состояния/день)

Client Diversity Index (распределение клиентов/верификаторов)

Sync Time (быстрый/архивный синк)

2.5 L2-специфика

Batch TPS (у сентенсера), Batch Size (кБ)

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

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

Settlement Latency (L2→L1 финализация)

3) Методика измерений (нейтральная и воспроизводимая)

1. Единый план нагрузок (TUP – Test Use Profiles):

TUP-Pay: маленькие переводы (N=70% simple, 30% token).
TUP-Game: короткие события с calldata (до 2–8 кБ).
TUP-DEX: контракты со средним газом и всплесками.
TUP-DA: большие публикации (50–250 кБ батчами).

2. Слои нагрузки: фон 60–80% от целевого SLO + импульсы 120–160% на 5–10 минут каждые 30–60 минут.

3. География и сеть: минимум 3 региона, RTT-матрица, инъекции jitter/loss (0.5–2%).

4. Клиентская диверсификация: не менее 2 клиентов узлов на цепь (если доступны), одинаковые версии.

5. Сбор телеметрии: корректная корреляция (trace-ID), синхронизация времени (NTP/PTP), фиксация конфигов.

6. Окна финализации: явная настройка K/окна спора; TTF считать с учетом правил цепи.

7. Семантика ошибок: таксономия отказов (газ/nonce/лимит/DA-фейл/overload), исключить «ожидаемые» ошибки из Success Rate или выделять отдельно.

4) Нормализация и анти-смещение

Cost Normalization: USD по курсу на `observed_at`; `fee_usd = fee_native × price_usd_at_t`.
Gas/Weight Equivalence: сравнение по «классам операций», а не по «сырым газам».

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

Fair DA Compare: цена за 1 кБ и 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`, `Success ≥ Y%`, `Fee_p95 ≤ Z`.
Cost-to-Serve per 1k Ops — полная стоимость обработки 1000 операций класса (включая DA/settlement).
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 Settlement: `Settle_p95 ≤ 10m` (ZK) / «челлендж-окно» для optimistic.

7) Дашборды (референс-макеты)

Perf Lens (реал-тайм/час): 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 ошибок, аптайм сентенсера (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;

Оценка Effective Throughput @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-инклюзии и до окончания challenge-окна.
ZK L2: разделять время публикации на L1 и время генерации/проверки пруфа; учитывать отказоустойчивость пруверов.
Validium/DA-аутсорс: DA-метрики обязательны (throughput/cost/failure), иначе сравнение некорректно.
Межцепные операции: считать E2E TTF для мостовых сценариев (источник→цель), с учетом K/DA/challenge.

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) Отчетность и визуализация

Сводная таблица по сценариям: Effective TPS, TTI/TTF p95, Fee p95, Cost/kB, Success%.
Радар-чарт (на сценарий): Throughput/Finality/Cost/Stability/Liveness.
Временные ряды: Fee-volatility, DA латентность, Reorg spikes.
Матрица «цепь × класс операции»: Cost-to-Serve и TTF.

14) Процессы и роли

Benchmark Owner: методология/инструменты, контроль версий.
Infra Owner: узлы, клиента, конфиги, регионы.
Data/BI: агрегации, проверка корректности, SLO дашборды.
Security/Compliance: контроль приватности и корректности логов.
Governance: публикация результатов, изменение весов индекса.

15) Playbook инцидентов бенчмарка

Дрейф конфигов/версий: немедленная остановка серии, фиксация snapshot, перезапуск с корректными параметрами.
Аномалии сети (за пределами плановых): пометка окна как «контаминированного», повтор серии.
Сбой DA/прувера: выделить отдельный инцидент, повторить под-серию DA/ZK.
Непредвиденная волатильность цены: фиксировать медианный USD окна, приложить диапазон.

16) Чек-лист внедрения

1. Утвердить сценарии (TUP) и веса сводного индекса.
2. Зафиксировать конфиги узлов/клиентов, регионы и сетевые условия.
3. Реализовать сбор телеметрии с корреляцией и синхронизацией времени.
4. Настроить нормализацию fee/DA/классов операций.
5. Согласовать SLI/SLO и макеты дашбордов.
6. Провести пилотную серию, сверить воспроизводимость, откалибровать нагрузки.
7. Публиковать отчеты с полным приложением конфигов, версий и дат.

17) Глоссарий

TTI/TTF — время до включения/финализации.
DA — слой доступности данных (Data Availability).
Sustained/Peak TPS — устойчивая/пиковая пропускная способность.
Liveness — способность сети подтверждать блоки/батчи.
Challenge Window — окно оспаривания в optimistic-роллапах.
State Growth — прирост размера состояния сети.
Hardware-Adjusted TPS — пропускная способность с учетом стоимости узла.

Итог: корректное сравнение производительности цепей — это не гонка «кто больше TPS», а дисциплина: единые сценарии, честная нормализация стоимости и данных, учет финализации и устойчивости, прозрачные конфиги и воспроизводимые тесты. Следуя этому фреймворку, экосистема получает сравнимые, пригодные к принятию решений метрики — от выбора площадки под продукт до планирования межцепных архитектур.