Compararea performanțelor circuitului

(Secțiunea: Ecosistem și rețea)

1) De ce și ce comparăm

• Viteze și întârzieri: incluziune, finalizare, variabilitate.
• Economie: costul tranzacțiilor și al datelor, stabilitatea comisioanelor.
• Stabilitate: reorgs, dușuri, degradare sub sarcină.
• Disponibilitatea datelor: lățimea de bandă DA și costul octetului.
• Sisteme de operare: cerințe pentru noduri, dimensiunea de stat, diversificarea clienților.

Rezultatul este KPI-uri consolidate care vă permit să selectați lanțuri/domenii pentru scenarii specifice (plăți, jocuri/micro-evenimente, poduri, DA/publicații).

2) Taxonomia metricii (nucleul)

2. 1 Debit și latență

TPS/QPS sustinut

Vârf TPS (vârf scurt fără eroare/cădere)

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

Time-to-Finality (TTF) p50/p95/p99

Bloc de utilizare%

Variația/Jitter de întârzieri (σ, CV)

2. 2 Calitatea și durabilitatea

Rata de succes (% de succes tx/evenimente)

Rata Reorg/Orfan (frecvență și adâncime)

Liveness SLO Hit

Degradare Grace (degradare controlată în loc de eșec)

2. 3 Economie și DA

Taxa p50/p95/p99 (în moneda nativă și în USD)

Cost-per-kB (DA) - preț de publicare de 1 kB de date

Cost-per-Tx Class - preț „tip tranzacție”: transfer simplu, apel contract, calldata mare

Indicele de volatilitate a taxelor

2. 4 Noduri și stare

Amprenta hardware (CPU/RAM/SSD/rețea pentru validator/nod de arhivă)

Creșterea de stat

Indicele diversității clienților

Sincronizare timp

2. Specificitatea 5 L2

TPS (la santinela), Dimensiunea lotului (kB)

Timp de includere în lot и fereastră de timp până la probă (ZK )/provocare (optimistă)

DA Throughput (МБ/с) и Rata de eșec DA

Latența decontării (finalizare L2→L1)

3) Procedura de măsurare (neutră și reproductibilă)

1. Profiluri de utilizare a testelor (TUP):

TUP-Pay: transferuri mici (N = 70% simplu, 30% token).
TUP-Game: evenimente scurte cu calldata (până la 2-8 kB).
TUP-DEX: Contracte mid-gaz și supratensiune.
TUP-DA: publicații mari (50-250 kB batchami).

2. Straturi de încărcare: fundal 60-80% din țintă SLO + impulsuri 120-160% timp de 5-10 minute la fiecare 30-60 minute.

3. Geografie și rețea: cel puțin 3 regiuni, matrice RTT, injecții cu jitter/pierdere (0. 5–2%).

4. Diversificarea clientului: cel puțin 2 clienți nod pe circuit (dacă este disponibil), versiuni identice.

5. Colectarea telemetriei: corelație corectă (trace-ID), sincronizare în timp (NTP/PTP), configurații de fixare.

6. Ferestre de finalizare: setarea explicită a litigiului K/fereastră; Citiți TTF ținând cont de regulile circuitului.

7. Semantica erorilor: taxonomia eșuării (gaz/nonce/limit/DA-file/supraîncărcare), excluderea erorilor „așteptate” din Rata de succes sau evidențierea separată.

4) Normalizare și anti-părtinire

Normalizarea costurilor: USD

Echivalența gaz/greutate: comparație prin „clase de funcționare” mai degrabă decât „gaze brute”.

TPS ajustat hardware: 'TPS _ per _ $ = Sustained_TPS/( Monthly_Node_Cost_USD)'

Fair DA Compare: prețul pe 1kB și întârzierea publicării p95.
Volatilitate Windows: ferestre săptămânale/lunare, mediane și IQR în loc de „înregistrări unice”.
Rece vs Cald: încălzirea cache-urilor; măsurători după stabilizare.
Comisioane MEV/Vârf: excludeți „anomalii de piață” sau evidențiați o metrică separată.

5) KPI rezumat (totaluri)

• Debit (30%), Finalitate (25%), Cost (20%), Stabilitate (15%), Uptime/Liveness (10%).
• Factorii de ponderare sunt stabiliți în cadrul scenariului (de exemplu, pentru plăți ↑Finality/Cost, pentru jocuri ↑Throughput/Stability/DA).

Throughput @ SLO - stabil TPS sub rezerva „TTF _ p95 ≤ X”, „Succes ≥ Y%”, „Fee _ p95 ≤ Z”.
Cost-to-Serve per 1k Ops - costul total al procesării operațiunilor de clasă 1000 (inclusiv DA/decontare).
Finalitate SLA Hit% - ponderea operațiunilor finalizate în fereastra țintă.

6) SLI/SLO pentru comparație

• Plăți: 'TTF _ p95 ≤ 10s',' Succes ≥ 99. 7% ',' Fee _ p95 ≤ $0. 01`.
• Jocuri/Evenimente: 'TTI _ p95 ≤ 500ms',' TTF _ p95 ≤ 3s ',' Succes ≥ 99. 5% ',' DA _ p95 ≤ 1s'.
• DA/Publishing: 'Cost _ per _ kB ≤ $0. 0005 ',' Publish _ p95 ≤ 2s', 'Finality _ p95 ≤ 60s'.
• Decontare L2:' Settle _ p95 ≤ 10m '(ZK )/” fereastră provocare„ pentru optimist.

7) Tablouri de bord (machete de referință)

Perf Lens (timp real/oră): TTI/TTF p50/p95/p99, bloc de utilizare, Rata de succes, Taxa p95, taxonomie de eroare.
Cost & DA: Cost/kB, Fee-volatility, DA throughput/latency, отказ DA.
Stabilitate: Reorg Rate, Liveness SLO Hit, erori Burn-rate, uptime sentenser (L2).
Planificarea capacității: Sustained vs vârf TPS, Hardware-ajustate TPS, Stat de creștere.

8) Schema de date și logica (pseudo-SQL)

Evenimente de referință brute

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

Agregarea kernel-ului metric

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;

Throughput eficient @ SLO Score

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) Indice compozit (exemplu de calcul)

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 și caracteristici inter-lanț

Optimist L2: indicați „dublu” TTF - înainte de L2-inclusion și înainte de sfârșitul ferestrei de provocare.
ZK L2: împărțiți timpul de publicare în L1 și timpul de generare/verificare a probei; ia în considerare toleranța la erori a probatorilor.
Validium/DA externalizează: sunt necesare măsurători DA (transfer/cost/eșec), în caz contrar comparația este incorectă.
Operațiuni în lanț încrucișat: citiți E2E TTF pentru scenarii de punte (istochnik→tsel), luând în considerare K/DA/provocare.

11) Modele anti-comparație (ce trebuie evitat)

Comparați „vârful record” al unui lanț cu „media” celuilalt.
Ignorați costurile datelor și volatilitatea comisioanelor.
Ignorați finalizarea (comparați „includerea” cu „finalitatea”).
Trage metrica pe un nod' cald' şi transferul la unul rece.
Se amestecă diferite clase de operații fără normalizare.
Nu comiteți versiuni/configurații client - reproductibilitatea este pierdută.

12) Configurații și parametri de testare (pseudo-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) Raportarea și vizualizarea

Tabel rezumativ după scenariu: TPS efectiv, TTI/TTF p95, Taxa p95, Cost/kB, Succes%.
Diagramă radar (per script): Throughput/Finality/Cost/Stability/Liveness.
Serii de timp: Fee-volatility, DA latency, Reorg spikes.
Cost × to-Serve și TTF lanț la clasa matrice.

14) Procese și roluri

Benchmark Owner: metodologie/instrumente, controlul versiunii.
Proprietar Infra: noduri, clienți, configurații, regiuni.
Date/BI: agregări, validare, tablouri de bord SLO.
Securitate/Conformitate: controlul confidențialității și corectitudinii jurnalelor.
Guvernanță: publicarea rezultatelor, modificarea ponderilor indicelui.

15) Playbook incidente de referință

Drift de configurații/versiuni: opriți imediat seria, faceți instantaneu, reporniți cu parametrii corecți.
Anomalii de rețea (în afara celor planificate): marcarea ferestrei ca fiind „contaminată”, repetarea seriei.
Eșecul DA/dover: separați un incident separat, repetați subseria DA/ZK.
Volatilitate neașteptată a prețurilor: fixați fereastra medie USD, atașați un interval.

16) Lista de verificare a implementării

1. Aprobarea scenariilor (TUP) și a ponderilor indicelui sumar.
2. Înregistrați configurațiile gazdă/client, regiunile și condițiile de rețea.
3. Implementați colecția de telemetrie cu corelație și sincronizare a timpului.
4. Stabilirea normalizării tarifelor/DA/clase de operare.
5. Sunt de acord cu privire la SLI/SLO și machete tabloul de bord.
6. Efectuați o cursă pilot, verificați reproductibilitatea, calibrați încărcăturile.
7. Publicați rapoarte cu aplicarea completă a configurațiilor, versiunilor și datelor.

17) Glosar

TTI/TTF - timp pentru a porni/finaliza.
DA - Stratul de disponibilitate a datelor.
TPS sustinut/varf - debit sustinut/varf.
Liveness - capacitatea rețelei de a confirma blocuri/loturi.
Challenge Window - o fereastră de provocare în rollups optimiste.
Creșterea statului - o creștere a dimensiunii statului de rețea.
Hardware-ajustate TPS - debit, luând în considerare costul nodului.

Linia de fund: compararea corectă a performanței în lanț nu este o rasă „care este mai mult TPS”, ci o disciplină: scenarii uniforme, normalizarea onestă a costurilor și datelor, contabilizarea finalizării și stabilității, configurații transparente și teste reproductibile. În urma acestui cadru, ecosistemul primește valori decizionale comparabile - de la alegerea unui site pentru un produs la planificarea arhitecturilor între lanțuri.