Comparaison des performances des circuits

(Section : Écosystème et réseau)

1) Pourquoi et ce que nous comparons

• Vitesses et retards : inclusion, finalisation, variabilité.
• Économies : coût des transactions et des données, stabilité des commissions.
• Résistances : réorgues, livrées, dégradations sous charge.
• Disponibilité des données : bande passante DA et coût de l'octet.
• Opérations : exigences de nœuds, taille de l'état, diversification des clients.

Le résultat est un KPI consolidé qui vous permet de sélectionner des circuits/domaines pour des scénarios spécifiques (paiements, jeux/micro-événements, ponts, DA/publications).

2) Taxonomie des métriques (noyau)

2. 1 Bande passante et retards

TPS/QPS (bande passante stable)

Peak TPS (pic court sans erreur/drop)

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

Time-to-Finality (TTF) p50/p95/p99 (prendre en compte les confirmations K/challenge)

Utilisation du bloc % (remplissage du bloc/batch)

Variation/Jitter des retards (σ, CV)

2. 2 Qualité et durabilité

Taux de réussite (% de succès tx/events)

Taux Reorg/Orphan (fréquence et profondeur)

Liveness SLO Hit (exécution de la disponibilité cible)

Degradation Grace (dégradation contrôlée au lieu de feel)

2. 3 Économie et DA

Fee p50/p95/p99 (en monnaie native et en USD)

Cost-per-kB (DA) - prix de publication de 1 kB de données

Classe Cost-per-Tx - prix « type transaction » : traduction simple, appel de contrat, calldata majeure

Indice de volatilité de Fee (stabilité des commissions de fenêtre)

2. 4 Nœuds et état

Hardware Footprint (CPU/RAM/SSD/réseau pour le site de validation/archivage)

Croissance de l'État (gain de fortune/jour)

Indice de diversité des clients (distribution des clients/vérificateurs)

Sync Time (sink rapide/archivé)

2. 5 spécificités L2

Batch TPS (chez le sentier), Batch Size (kB)

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

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

Settlement Latency (finalisation L2→L1)

3) Méthode de mesure (neutre et reproductible)

1. Plan de charge unique (TUP - Test Use Profiles) :

TUP-Pay : petits transferts (N = 70 % simple, 30 % token).
TUP-Game : événements courts avec calldata (jusqu'à 2-8 kB).
TUP-DEX : contrats à gaz moyen et surtensions.
TUP-DA : grandes publications (50-250 kB de trampoline).

2. Couches de charge : fond 60-80 % de SLO + cibles impulsions 120-160 % pendant 5-10 minutes toutes les 30-60 minutes.

3. Géographie et réseau : minimum 3 régions, matrice RTT, injections jitter/loss (0. 5–2%).

4. Diversification client : Au moins 2 clients nœuds par chaîne (si disponible), les mêmes versions.

5. Collecte de télémétrie : corrélation correcte (trace-ID), synchronisation temporelle (NTP/PTP), fixation de configues.

6. Fenêtres de finalisation : Personnalisation explicite de la fenêtre de litige ; TTF compte compte tenu des règles de la chaîne.

7. Sémantique des erreurs : taxonomie des erreurs (gaz/nonce/limite/DA-fail/overload), supprimer les erreurs « attendues » du taux de réussite ou les isoler séparément.

4) Normalisation et anti-déplacement

Cost Normalization: USD по курсу на `observed_at`; `fee_usd = fee_native × price_usd_at_t`.
Gas/Weight Equivalence : comparaison par « classes opératoires » et non par « gaz bruts ».

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

Fair DA Compare : prix pour 1 kB et p95 publication retardée.
Volatilité Windows : fenêtres hebdomadaires/mensuelles, médiane et IQR au lieu de « records ponctuels ».
Cold vs Warm : réchauffer les caches ; mesures après stabilisation.
MEV/Peak Commission : exclure les « anomalies du marché » ou allouer une métrique distincte.

5) KPI consolidés (totaux)

• Throughput (30%), Finality (25%), Cost (20%), Stability (15%), Uptime/Liveness (10%).
• Les coefficients de pondération sont configurés pour le script (par exemple, pour les paiements ↑Finality/Cost, pour les jeux ↑Throughput/Stability/DA).

Effective Throughput @ SLO est un TPS stable en respectant 'TTF _ p95 ≤ X', 'Success ≥ Y %', 'Fee _ p95 ≤ Z'.
Cost-to-Serve per 1k Ops est le coût total de traitement de 1000 opérations de classe (y compris DA/settlement).
Finality SLA Hit % est la proportion d'opérations finalisées dans la fenêtre cible.

6) SLI/SLO pour comparaison

• 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 fenêtre »pour optimistic.

7) Dashboards (maquettes de référence)

Perf Lens (temps réel/heure) : TTI/TTF p50/p95/p99, Utilisation de bloc, Taux de réussite, Fee p95, Error taxonomy.
Cost & DA: Cost/kB, Fee-volatility, DA throughput/latency, отказ DA.
Stabilité : Reorg Rate, Liveness SLO Hit, bugs Burn-rate, aptyme centenser (L2).
Capacity Planning: Sustained vs Peak TPS, Hardware-Adjusted TPS, State Growth.

8) Schéma de données et logique (pseudo-SQL)

Evénements bruts de référence

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

Agrégation du noyau de métriques

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;

Évaluation efficace de 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 composite (exemple 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 et caractéristiques inter-chaînes

Optimistic L2 : indiquer « double » TTF - jusqu'à l'inclusion L2 et jusqu'à la fin de la fenêtre de défi.
ZK L2 : Diviser le temps de publication par L1 et le temps de génération/vérification du prouf ; tenir compte de la résistance aux pannes des étangs.
Validation/sous-traitance DA : les métriques DA sont obligatoires (throughput/cost/failure), sinon la comparaison est incorrecte.
Opérations inter-chaînes : compter le TTF E2E pour les scénarios de pont (istochnik→tsel), compte tenu du K/DA/challenge.

11) Anti-modèles de comparaison (à éviter)

Comparer le « pic record » d'une chaîne à la « moyenne » d'une autre.
Ignorer le coût des données et la volatilité des commissions.
Ne pas prendre en compte la finalisation (comparer « inclusion » à « finality »).
Enlever les métriques sur le nœud « chauffé » et les transférer au froid.
Mélanger différentes classes d'opérations sans normalisation.
Ne pas enregistrer les versions clients/configi - la reproductibilité est perdue.

12) Configurations et paramètres de 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 et visualisation

Tableau récapitulatif par scénario : TPS efficace, TTI/TTF p95, Fee p95, Cost/kB, Success %.
Carte radar (pour le scénario) : Throughput/Finality/Cost/Stability/Liveness.
Séries chronologiques : Fee-volatilité, DA latence, Reorg spikes.
Matrice « chaîne × classe d'opération » : Cost-to-Serve et TTF.

14) Processus et rôles

Benchmark Owner : méthodologie/outils, contrôle de version.
Infra Owner : nœuds, client, configi, régions.
Données/BI : agrégations, vérification de l'exactitude, SLO dashboards.
Sécurité/Conformité : contrôle de la confidentialité et de l'exactitude des logs.
Gouvernance : publication des résultats, variation des pondérations de l'indice.

15) Playbook des incidents de référence

Dérivation des configues/versions : arrêt immédiat de la série, fixation du snapshot, redémarrage avec des paramètres corrects.
Anomalies du réseau (au-delà de la planification) : marquage de la fenêtre comme « contraminé », répétition de la série.
Échec de DA/étrier : allouer un incident distinct, répéter la série DA/ZK.
Volatilité imprévue des prix : fixez la fenêtre médiane USD, attachez la gamme.

16) Chèque de mise en œuvre

1. Approuver les scripts (TUP) et le poids de l'index consolidé.
2. Fixez les connexions nœuds/clients, les régions et les conditions de réseau.
3. Réaliser une collecte de télémétrie avec corrélation et synchronisation temporelle.
4. Configurer la normalisation fee/DA/classes d'opérations.
5. Concilier le SLI/SLO et les maquettes de dashboards.
6. Effectuer une série pilote, vérifier la reproductibilité, calibrer les charges.
7. Publiez des rapports avec une application complète de configues, de versions et de dates.

17) Glossaire

TTI/TTF est le temps avant l'inclusion/finalisation.
DA est la couche de disponibilité des données (Data Availability).
Sustained/Peak TPS - bande passante stable/de pointe.
Liveness est la capacité du réseau à confirmer les blocs/batchs.
Challenge Window est une fenêtre de contestation dans les rouleaux optimistes.
State Growth - Augmentation de l'état du réseau.
Hardware-Adapted TPS - bande passante en fonction du coût du nœud.

Le résultat : une comparaison correcte des performances des chaînes n'est pas une course « qui est plus grand que TPS », mais une discipline : des scénarios uniques, une normalisation honnête des coûts et des données, la prise en compte de la finalisation et de la durabilité, des configues transparentes et des tests reproductibles. En suivant ce cadre, l'écosystème obtient des mesures comparables et décisionnelles - de la sélection du site pour le produit à la planification des architectures inter-chaînes.