Confronto delle prestazioni delle catene

(Sezione Ecosistema e Rete)

1) Perché e cosa stiamo confrontando

• Velocità e ritardi: attivazione, finalizzazione, variabilità.
• Economia: costo delle transazioni e dei dati, stabilità delle commissioni.
• Stabilità: reorgi, livnese, degrado sotto carico.
• Disponibilità dei dati: larghezza di banda DA e costo del byte.
• Operazioni: requisiti per i nodi, dimensione dello stato, diversificazione dei clienti.

Risultato: KPI riepilogativi che consentono di selezionare le catene/domini in scenari specifici (pagamenti, giochi/micro-ivent, ponti, DA/pubblicazioni).

2) Tassonomia metriche (nucleo)

2. 1 Larghezza di banda e ritardi

Sostained TPS/QPS (larghezza di banda stabile)

Peak TPS (picco breve senza errori/drop)

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

Time-to-Finality (TTF) p50/p95/p99 (tenere conto delle conferme K/challenge)

Block Utilization% (riempimento blocco/batch)

Variance/Jitter ritardi (CV)

2. 2 Qualità e sostenibilità

Success Rate (% tx/events di successo)

Reorg/Orphan Rate (frequenza e profondità)

Liveness SLO Hit (esecuzione disponibilità target)

Degradation Grace (degrado controllato al posto del feel)

2. 3 Economia e DA

Fee p50/p95/p99 (in valuta nativa e USD)

Cost-per-kB (DA) - Prezzo di pubblicazione 1 kB

Cost-per-Tx Class - Prezzo «tipo di transazione»: traduzione semplice, chiamata di contratto, caldata di grandi dimensioni

Fee Volatility Index (stabilità delle commissioni finestre)

2. 4 Nodi e stato

Hardware Futprint (CPU/RAM/SSD/rete per Value/Archivio)

State Growth (aumento di stato/giorno)

Client Diversity Index (distribuzione client/verificatori)

Sync Time (sink veloce/archivio)

2. 5 specifiche L2

Batch TPS, Batch Size (kB)

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

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

Settlement Latency (finalizzazione L2→L1)

3) Tecnica di misurazione (neutra e riproducibile)

1. Piano di carico unico (TUP - Test Use Profiles):

TUP-Share - Traduzioni piccole (N = 70% semplice, 30% token).
TUP-Game: eventi brevi con calldata (fino a 2-8 kB).
TUP-DEX - Contratti con gas medio e picchi.
TUP-DA: grandi pubblicazioni (50-250 kB batch).

2. Livelli di carico: sfondo 60-80% dell'obiettivo SLO + impulsi 120-160% per 5-10 minuti ogni 30-60 minuti.

3. Geografia e rete: minimo 3 regioni, matrice RTT, iniezioni jitter/loss (0. 5–2%).

4. Diversificazione client: almeno 2 client di host per catena (se disponibili), le stesse versioni.

5. Raccolta di telemetria: corretta correlazione (trace-ID), sincronizzazione temporale (NTP/PTP), fissa configuri.

6. Finestre di finalizzazione: impostazione esplicita di K/finestra di discussione; TTF da contare in base alle regole della catena.

7. Semantico di errore: tassonomia di errore (gas/nonce/limite/DA-feel/overload), escludere gli errori «previsti» da Success Rate o evidenziare separatamente.

4) Normalizzazione e anti-spostamento

Cost Normalization: USD по курсу на `observed_at`; `fee_usd = fee_native × price_usd_at_t`.
Gas/Weight Equalence: confronto per «classi operative», non per «gas crudo».

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

Fair DA Compare: prezzo per 1 kB e p95 ritardo di pubblicazione.
Volatility Windows: finestre settimanali/mensili, mediana e IQR anziché record singole.
Cold vs Warm: riscaldamento della cache misurazioni dopo la stabilizzazione.
MEV/Commissione di punta: escludere «anomalie di mercato» o evidenziare una singola metrica.

5) Riepilogo KPI (risultati totali)

• Throughput (30%), Finality (25%), Cost (20%), Stability (15%), Uptime/Liveness (10%).
• I pesi vengono configurati per lo script (ad esempio, per i pagamenti di ↑Finality/Cost, per i giochi di ↑Throughput/Stability/DA).

Effettiva Throughput @ SLO è un TPS resistente in conformità a «TTF _ p95» X «,» Success Y% «,» Fee _ p95 «Z».
Cost-to-Serve per 1k Ops - Costo di elaborazione totale di 1000 operazioni di classe (compreso DA/settement).
Finality SLA Hit% è la percentuale di operazioni finalizzate alla finestra di destinazione.

6) SLI/SLO a confronto

• 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 )/« challenge »per ottimistic.

7) Dashboard (layout)

Perf Lens (real-time/ora): TTI/TTF p50/p95/p99, Block Utilization, Success Rate, Fee p95, Errore tassonomy.
Cost & DA: Cost/kB, Fee-volatility, DA throughput/latency, отказ DA.
Stability: Reorg Rate, Liveness SLO Hit, Burn-rate errori, farmacia centenser (L2).
Capacity Planning: Sustained vs Peak TPS, Hardware-Adjusted TPS, State Growth.

8) Schema dati e logica (pseudo-SQL)

Eventi crudi benchmark

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

Aggregazione del nucleo delle metriche

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;

Valutazione Effettiva 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) Indice composito (esempio di calcolo)

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 e caratteristiche intercorrenti

Ottimistico L2 - Specifica «doppio» TTF - prima dell'input L2 e prima della fine della finestra challenge.
ZK L2: separa l'ora di pubblicazione in L1 e il tempo di generazione/verifica dello stagno; Tenere conto della disponibilità dei laghetti.
Validium/DA-output: le metriche DA sono obbligatorie (throughput/cost/failure), altrimenti il confronto non è corretto.
Operazioni intercorrenti: conta E2E TTF per gli script di ponte (istochnik→tsel), tenendo conto di K/DA/challenge.

11) Anti-pattern di confronto (da evitare)

Confrontare il picco record di una catena con l'altra media.
Ignorare il costo dei dati e la volatilità delle commissioni.
Non considerare la finalizzazione (paragonare «inclusion» a «finality»).
Togliere le metriche su un nodo riscaldato e spostarle a freddo.
Miscelare diverse classi di operazioni senza normalizzazione.
Non fissare le versioni client/configi - Si perde la riproduzione.

12) Configurazioni e impostazioni dei test (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) Reporting e visualizzazione

Tabella di riepilogo degli script: Effettiva TPS, TTI/TTF p95, Fee p95, Cost/kB, Success%.
Elenco radar (per script): Throughput/Finality/Cost/Stability/Liveness.
File temporali: Fee-volatility, DA latitanza, Reorg spikes.
Matrice Catena x Classe operazione: Cost-to-Serve e TTF.

14) Processi e ruoli

Benchmark Owner: metodologia/strumenti, controllo delle versioni.
Infra Owner: nodi, client, confighi, regioni.
Data/BI: aggregazioni, verifica della correttezza, dashboard SLO.
Sicurezza/Compliance - Controllo della privacy e della correttezza dei fogli.
Governance - Pubblicazione dei risultati, modifica dei pesi dell'indice.

15) Playbook incidenti benchmark

La deriva di configurazioni/versioni è l'arresto immediato della serie, la fissazione di snapshot, il riavvio con le impostazioni corrette.
Anomalie di rete (al di fuori di quella pianificata) - Contrassegna la finestra come contaminata, ripetizione della serie.
Errore DA/stagno: evidenzia un singolo incidente, ripeti la serie DA/ZK.
La volatilità imprevista del prezzo è fissare la finestra USD mediana, allegare l'intervallo.

16) Assegno-foglio di implementazione

1. Approva script (TUP) e peso dell'indice di riepilogo.
2. Fissa i siti/client, le regioni e le condizioni di rete.
3. Realizzare la raccolta di telemetria con correlazione e sincronizzazione del tempo.
4. Configura la normalizzazione di fee/DA/classi di operazioni.
5. Allineare SLI/SLO e layout di dashboard.
6. Eseguire una serie pilota, incrociare la riproduzione, calibrare i carichi.
7. Pubblica report con un'applicazione completa di configurazioni, versioni e date.

17) Glossario

TTI/TTF - Tempo fino all'attivazione/finalizzazione.
DA - Livello di disponibilità dati (Data Availability).
Sostained/Peak TPS è una larghezza di banda sostenibile/di punta.
Liveness è la capacità della rete di confermare blocchi/batch.
Challenge Window - Finestra di contestazione ottimistica-rollap.
State Growth - Aumenta la dimensione della rete.
TPS Hardware-Adjusted: larghezza di banda in base al costo del sito.

In sintesi, un confronto corretto tra le prestazioni delle catene non è una corsa «chi è più grande di TPS», ma una disciplina: scenari unificati, una corretta normalizzazione dei costi e dei dati, la presa in considerazione della finalizzazione e della sostenibilità, conferme trasparenti e test riproduttivi. Seguendo questo framework, l'ecosistema ottiene metriche paragonabili e adatte alle decisioni, dalla scelta del sito per il prodotto alla pianificazione delle architetture intercorrenti.