Порівняння продуктивності ланцюгів

(Розділ: Екосистема та Мережа)

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. Вікна фіналізації: явне налаштування К/вікна спору; 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 для мостових сценаріїв (istochnik→tsel), з урахуванням 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», а дисципліна: єдині сценарії, чесна нормалізація вартості і даних, облік фіналізації і стійкості, прозорі конфіги і відтворювані тести. Слідуючи цьому фреймворку, екосистема отримує порівняні, придатні до прийняття рішень метрики - від вибору майданчика під продукт до планування міжчіпних архітектур.