Тізбектердің өнімділігін салыстыру

(Бөлім: Экожүйе және Желі)

1) Неге және нені салыстырамыз

• Жылдамдықтар мен кідірістер: қосу, аяқтау, вариативтілік.
• Экономика: транзакциялар мен деректер құны, комиссиялардың тұрақтылығы.
• Орнықтылығы: реорги, ливнес, жүктеме астындағы тозу.
• Деректердің қолжетімділігі: DA өткізу қабілеті және байт құны.
• Операциялық: тораптарға қойылатын талаптар, жай-күйінің мөлшері, клиенттерді әртараптандыру.

Нәтижесі - нақты сценарийлерге (төлемдер, ойындар/микро-ивенттер, көпірлер, DA/жарияланымдар) арналған тізбектерді/домендерді таңдауға мүмкіндік беретін жиынтық KPI.

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. Жүктеме қабаттары: мақсатты SLO-дан 60-80% фон + әрбір 30-60 минут сайын 5-10 минутқа 120-160% импульстер.

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 үшін баға жарияланымның кешігуі.
Windows Volatility: апталық/айлық терезелер, медиана және 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 - 'TTF _ p95 ≤ X', 'Success ≥ Y%', 'Fee _ p95 ≤ Z' сақтаған кезде тұрақты TPS.
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: optimistic үшін 'Settle _ p95 ≤ 10m' (ZK )/« челлендж-терезе ».

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), әйтпесе салыстыру дұрыс емес.
Тізбекаралық операциялар: К/DA/challenge ескере отырып, көпірлік сценарийлер үшін 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) Есептілік және визуализация

Сценарийлер бойынша жиынтық кесте: 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-ден үлкен» жарысы емес, пән: бірыңғай сценарийлер, құн мен деректерді әділ қалыпқа келтіру, ақырғы және орнықтылық есебі, мөлдір конфигалар және ойнатылатын тестілер. Осы фреймворкқа сүйене отырып, экожүйе салыстырмалы, шешім қабылдауға жарамды метриканы алады - өнім үшін алаңды таңдаудан бастап тізбекаралық архитектураны жоспарлауға дейін.