GH GambleHub

Circuit Performance müqayisə

(Bölmə: Ekosistem və Şəbəkə)

1) Nə üçün və nəyi müqayisə edirik

Məqsəd müxtəlif zəncirlərin (L1, L2, app-chain, validium/rollap) performansını aşağıdakılarla müqayisə etmək üçün təkrar edilə bilən və neytral bir yol yaratmaqdır:
  • Sürət və gecikmələr: açma, sonlandırma, dəyişkənlik.
  • İqtisadiyyat: əməliyyatların və məlumatların dəyəri, komissiyaların sabitliyi.
  • Davamlılıq: reorges, livnes, yük altında deqradasiya.
  • Verilənlərin mövcudluğu: DA bant genişliyi və bayt dəyəri.
  • Əməliyyat: düyün tələbləri, dövlət ölçüsü, müştərilərin diversifikasiyası.

Nəticə - xüsusi ssenarilər (ödənişlər, oyunlar/mikro-tədbirlər, körpülər, DA/nəşrlər) üçün zəncir/domen seçməyə imkan verən məcmu KPI.

2) Metriklərin taksonomiyası (nüvə)

2. 1 Bant genişliyi və gecikmələr

Sustained TPS/QPS (sabit bant genişliyi)

Peak TPS (səhvsiz qısa pik/drop)

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

Time-to-Finality (TTF) p50/p95/p99 (K-təsdiq/challenge pəncərə nəzərə)

Block Utilization% (blok/batch doldurulması)

Variance/Jitter gecikmələr (σ, CV)

2. 2 Keyfiyyət və sabitlik

Success Rate (% uğurlu tx/events)

Reorg/Orphan Rate (tezlik və dərinlik)

Liveness SLO Hit (məqsədli mövcudluğu yerinə yetirmək)

Degradation Grace (saxta əvəzinə nəzarət deqradasiya)

2. 3 İqtisadiyyat və DA

Fee p50/p95/p99 (yerli valyutada və USD-də)

Cost-per-kB (DA) - nəşr qiyməti 1 kB məlumat

Cost-per-Tx Class - «əməliyyat növü» qiyməti: sadə tərcümə, müqavilə çağırışı, böyük calldata

Fee Volatility Index (pəncərə komissiyalarının sabitliyi)

2. 4 düyünlər və vəziyyət

Hardware Footprint (CPU/RAM/SSD/validator/arxiv qovşağı üçün şəbəkə)

State Growth (dövlət artımı/gün)

Client Diversity Index (müştərilərin/yoxlayıcıların paylanması)

Sync Time (sürətli/arxiv sink)

2. 5 L2 spesifikliyi

Batch TPS (sentenserdə), Batch Size (kB)

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

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

Settlement Latency (L2 → L1 finalı)

3) Ölçmə metodikası (neytral və təkrarlanabilir)

1. Vahid Yük Planı (TUP - Test Use Profiles):

TUP-Pay: kiçik köçürmələr (N = 70% simple, 30% token).
TUP-Game: calldata ilə qısa hadisələr (2-8 kB qədər).
TUP-DEX: orta qaz və partlayış müqavilələri.
TUP-DA: böyük nəşrlər (50-250 kB batch).

2. Yük qatları: 60-80% hədəf SLO + impuls 120-160% hər 30-60 dəqiqə 5-10 dəqiqə.

3. Coğrafiya və şəbəkə: ən azı 3 region, RTT matrisi, inyeksiya jitter/loss (0. 5–2%).

4. Müştəri diversifikasiyası: zəncir başına ən azı 2 müştəri qovşağı (əgər varsa), eyni versiyalar.

5. Telemetriya toplama: düzgün korrelyasiya (trace-ID), vaxt sinxronizasiyası (NTP/PTP), konfiqurasiya fiksasiyası.

6. Final pəncərələri: K/mübahisə pəncərələrinin aydın konfiqurasiyası; TTF zəncir qaydaları nəzərə alaraq hesab.

7. Səhvlərin semantikası: uğursuzluqların taksonomiyası (qaz/nonce/limit/DA-feyl/overload), «gözlənilən» səhvləri Success Rate-dən çıxarmaq və ya ayrıca ayırmaq.

4) Normallaşma və anti-yerdəyişmə

Cost Normalization: USD по курсу на `observed_at`; `fee_usd = fee_native × price_usd_at_t`.
Gas/Weight Equivalence: «xam qazlar» yox, «əməliyyat sinifləri» ilə müqayisə.

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

Fair DA Compare: 1 kB üçün qiymət və p95 nəşr gecikməsi.
Windows Volatility: həftəlik/aylıq pəncərələr, media və IQR əvəzinə «birdəfəlik rekordlar».
Cold vs Warm: cache qızdırılması; sabitləşmədən sonra ölçmə.
MEV/Pik komissiyalar: «bazar anomaliyaları» istisna və ya ayrı metrika ilə seçin.

5) Məcmu KPI (yekun göstəricilər)

Core Performance Score (CPS) - 0.. 100, çəki miqdarı:
  • Throughput (30%), Finality (25%), Cost (20%), Stability (15%), Uptime/Liveness (10%).
  • Çəki dərəcələri ssenariyə uyğunlaşdırılır (məsələn, ödənişlər üçün ↑ Finality/Cost, oyunlar üçün ↑ Throughput/Stability/DA).

Effective Throughput @SLO - 'TTF _ p95 ≤ X', 'Success ≥ Y%', 'Fee _ p95 ≤ Z' uyğun sabit TPS.
Cost-to-Serve per 1k Ops - 1000 sinif əməliyyatlarının (DA/settlement daxil olmaqla) tam emal dəyəri.
Finality SLA Hit% - hədəf pəncərəyə daxil edilmiş əməliyyatların payı.

6) müqayisə üçün SLI/SLO

SLO nümunələri (ssenari üzrə):
  • 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 üçün 'Settle _ p95 ≤ 10m' (ZK )/« çağırış pəncərəsi ».

7) Daşbordlar (referens-maketlər)

Perf Lens (real-time/saat): 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 səhvləri, sentenser aptaym (L2).
Capacity Planning: Sustained vs Peak TPS, Hardware-Adjusted TPS, State Growth.

8) Verilənlər və məntiq sxemi (psevdo-SQL)

Xam bençmark hadisələri

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
);

Metrik nüvənin yığılması

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 qiymətləndirilməsi @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) Kompozit indeks (hesablama nümunəsi)

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
💡 'normalize (x, p10, p90)' - üzlüklərdə [0,1] xətti çevirmə; 'invert (y) = 1 − y'.

10) L2 və intercycle xüsusiyyətləri

Optimistic L2: «ikiqat» TTF - L2-inklüziyaya qədər və challenge pəncərəsinin sonuna qədər.
ZK L2: L1 nəşr vaxt bölmək və pruf istehsal/yoxlama vaxt; pruverlərin uğursuzluğa davamlılığını nəzərə almaq.
Validium/DA-autsors: DA-metriklər tələb olunur (throughput/cost/failure), əks halda müqayisə düzgün deyil.
Zəncirlərarası əməliyyatlar: K/DA/challenge nəzərə alınmaqla, körpü ssenariləri üçün TTF E2E saymaq (mənbə → məqsəd).

11) Anti-nümunə müqayisə (nə qarşısını almaq)

Bir zəncirin «rekord zirvəsi» ilə digərini müqayisə edin.
Məlumatların dəyərinə və komissiyaların dəyişkənliyinə məhəl qoymayın.
Finalizasiyanı nəzərə almayın ("inclusion 'u" finality "kimi müqayisə edin).
Metrikləri «qızdırılan» qovşaqda çıxarın və soyuqda köçürün.
Normallaşma olmadan müxtəlif əməliyyat siniflərini qarışdırın.
Müştərilərin/konfiqaların versiyalarını qeyd etməyin - reproduktivlik itirilir.

12) Konfiqurasiya və test parametrləri (psevdo-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) Hesabat və vizuallaşdırma

Script icmal cədvəli: Effective TPS, TTI/TTF p95, Fee p95, Cost/kB, Success%.
Radar çartı (ssenari üzrə): Throughput/Finality/Cost/Stability/Liveness.
Zaman sıraları: Fee-volatility, DA gecikmə, Reorg spikes.
«Zəncir × əməliyyat sinfi» matrisi: Cost-to-Serve və TTF.

14) Proseslər və rollar

Benchmark Owner: metodologiya/alətlər, versiyası nəzarət.
Infra Owner: qovşaqlar, müştəri, konfiqlər, regionlar.
Data/BI: aqreqasiya, düzgün yoxlama, SLO dashboard.
Security/Compliance: qeydlərin məxfiliyinə və düzgünlüyünə nəzarət.
Governance: nəticələrin dərc edilməsi, indeksin çəkisinin dəyişdirilməsi.

15) Playbook hadisələri bençmark

Sürüklənmə konfiqurasiyaları/versiyaları: seriyanın dərhal dayandırılması, snapshot fiksasiyası, düzgün parametrlərlə yenidən başlamaq.
Şəbəkə anomaliyaları (planlaşdırılandan kənarda): pəncərəni «kontaminasiya» kimi qeyd etmək, seriyanı təkrarlamaq.
DA/Pruver uğursuzluğu: ayrı bir hadisəni vurğulayın, DA/ZK alt seriyasını təkrarlayın.
Gözlənilməz qiymət dəyişkənliyi: orta USD pəncərələri qeyd, bir sıra tətbiq.

16) Giriş çek siyahısı

1. Script təsdiq (TUP) və yığma indeks çəkisi.
2. Qovşaqların/müştərilərin, regionların və şəbəkə şərtlərinin konfiqlərini düzəldin.
3. Telemetriyanın korrelyasiya və zaman sinxronizasiyası ilə toplanmasını həyata keçirmək.
4. fee/DA/əməliyyat siniflərinin normallaşdırılmasını konfiqurasiya edin.
5. SLI/SLO və dashboard modelləri ilə razılaşın.
6. Pilot seriyası keçirmək, reproduktivliyi müqayisə etmək, yükləri kalibre etmək.
7. Hesabatları konfiqurasiya, versiya və tarixlərin tam tətbiqi ilə yayımlayın.

17) Lüğət

TTI/TTF - qoşulma/finala qədər vaxt.
DA - verilənlərin mövcudluğu təbəqəsi (Data Availability).
Sustained/Peak TPS - sabit/pik bant genişliyi.
Liveness - şəbəkənin blokları/batçları təsdiqləmək qabiliyyəti.
Challenge Window - optimist rollaplarda mübahisə pəncərəsi.
State Growth - şəbəkə vəziyyətinin artımı.
Hardware-Adjusted TPS - qovşağın dəyəri nəzərə alınmaqla bant genişliyi.

Nəticə: zəncir performansının düzgün müqayisəsi «kim daha çox TPS» yarışı deyil, nizam-intizamdır: vahid ssenarilər, dəyər və məlumatların ədalətli normallaşdırılması, finallaşma və sabitlik uçotu, şəffaf konfiqlər və təkrar edilə bilən testlər. Bu çərçivədən sonra ekosistem müqayisə edilə bilən, qəbul edilə bilən metrikləri əldə edir - məhsul üçün bir platforma seçməkdən tutmuş zəncirlərarası arxitekturaların planlaşdırılmasına qədər.

Contact

Bizimlə əlaqə

Hər hansı sualınız və ya dəstək ehtiyacınız varsa — bizimlə əlaqə saxlayın.Həmişə köməyə hazırıq!

Telegram
@Gamble_GC
İnteqrasiyaya başla

Email — məcburidir. Telegram və ya WhatsApp — istəyə bağlıdır.

Adınız istəyə bağlı
Email istəyə bağlı
Mövzu istəyə bağlı
Mesaj istəyə bağlı
Telegram istəyə bağlı
@
Əgər Telegram daxil etsəniz — Email ilə yanaşı orada da cavab verəcəyik.
WhatsApp istəyə bağlı
Format: ölkə kodu + nömrə (məsələn, +994XXXXXXXXX).

Düyməyə basmaqla məlumatların işlənməsinə razılıq vermiş olursunuz.