Comparación del rendimiento de los circuitos

(Sección: Ecosistema y Red)

1) Por qué y qué comparamos

• Velocidades y retrasos: encendido, finalización, variabilidad.
• Economías: valor de las transacciones y los datos, estabilidad de las comisiones.
• Sustentabilidad: reorgías, duchas, degradación bajo carga.
• Disponibilidad de datos: ancho de banda de DA y costo de bytes.
• Operaciones: requisitos de nodos, tamaño del estado, diversificación del cliente.

El resultado son KPIs resumidos que permiten seleccionar circuitos/dominios para escenarios específicos (pagos, juegos/micro eventos, puentes, DA/publicaciones).

2) Taxonomía de métricas (núcleo)

2. 1 Ancho de banda y latencia

TPS/QPS sostenidos (ancho de banda estable)

Peak TPS (pico corto sin errores/drop)

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

Time-to-Finality (TTF) p50/p95/p99 (tenga en cuenta las confirmaciones K/ventana de desafío)

Utilidad de bloques% (llenado de bloques/batch)

Demoras Variance/Jitter (σ, CV)

2. 2 Calidad y sostenibilidad

Tasa de éxito (% de tx/eventos exitosos)

Tasa de Reorg/Orphan (frecuencia y profundidad)

Hit de SLO de vida (ejecución de la disponibilidad de destino)

Degradation Grace (degradación controlada en lugar de fail)

2. 3 Economía y DA

Fee p50/p95/p99 (en moneda nativa y en USD)

Costo-por-kB (DA) - precio de publicación de 1 kB de datos

Costo-por-Tx Clase - el precio de «tipo de transacción»: simple transferencia, llamada de contrato, gran calldata

Fee Volatility Index (estabilidad de las comisiones por ventana)

2. 4 Nodos y estado

Hardware Football (CPU/RAM/SSD/red para validador/nodo de archivo)

Crecimiento del estado (aumento de estado/día)

Índice de diversidad del cliente (distribución de clientes/verificadores)

Tiempo de sincronización (azul rápido/archivado)

2. 5 L2-especificación

Batch TPS (centenser), Batch Size (kB)

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

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

Settlement Latency (Finalización L2→L1)

3) Técnica de medición (neutral y reproducible)

1. Plan único de carga (TUP - Perfiles de uso de prueba):

TUP-Pay: pequeñas transferencias (N = 70% simple, 30% token).
TUP-Game: eventos cortos con calldata (hasta 2-8 kB).
TUP-DEX: contratos de gas medio y ráfagas.
TUP-DA: grandes publicaciones (50-250 kB batches).

2. Capas de carga: fondo 60-80% del SLO objetivo + pulsos 120-160% durante 5-10 minutos cada 30-60 minutos.

3. Geografía y red: mínimo 3 regiones, matriz RTT, inyecciones de jitter/loss (0. 5–2%).

4. Diversificación de clientes: al menos 2 clientes de nodos por circuito (si están disponibles), las mismas versiones.

5. Recopilación de telemetría: corrección correcta (trace-ID), sincronización de tiempo (NTP/PTP), fijación de configuraciones.

6. Ventanas de finalización: configuración explícita de K/ventana de disputa; TTF contar teniendo en cuenta las normas de la cadena.

7. Semántica de Errores: La taxonomía de fallas (gas/nonce/limit/DA-fail/overload), excluye los errores «esperados» de la Tasa de Éxito o resalta por separado.

4) Normalización y anti-desplazamiento

Cost Normalization: USD по курсу на `observed_at`; `fee_usd = fee_native × price_usd_at_t`.
Equivalencia de Gas/Peso: comparación por «clases de operaciones» y no por «gases crudos».

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

Fair DA Compare: precio por 1 kB y p95 retraso de publicación.
Volatility Windows: ventanas semanales/mensuales, mediana e IQR en lugar de «registros únicos».
Cold vs Warm: calentamiento de cachés; mediciones después de la estabilización.
MEV/Comisiones máximas: descartar «anomalías de mercado» o destacar con una métrica separada.

5) KPI combinados (totales)

• Throughput (30%), Finality (25%), Cost (20%), Stability (15%), Uptime/Liveness (10%).
• Los coeficientes de ponderación se ajustan al escenario (por ejemplo, para pagos de ↑Finality/Cost, para juegos de ↑Throughput/Stability/DA).

Effective Throughput @ SLO es un TPS sostenible cuando se cumple con 'TTF _ p95 ≤ X', 'Éxito ≥ Y%', 'Fee _ p95 ≤ Z'.
Costo-a-Serve per 1k Ops - el costo total de procesar 1000 operaciones de clase (incluyendo DA/settlement).
Finality SLA Hit% es la proporción de operaciones finalizadas en la ventana de destino.

6) SLI/SLO para comparación

• 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-window' para optimistic.

7) Dashboards (diseños de referencia)

Perf Lens (tiempo real/hora): TTI/TTF p50/p95/p99, Utilidad de bloques, Tasa de éxito, Fee p95, Taxonomía de errores.
Cost & DA: Cost/kB, Fee-volatility, DA throughput/latency, отказ DA.
Stability: Reorg Rate, Liveness SLO Hit, Burn-rate errores, aptime centenaire (L2).
Capacity Planning: Sustained vs Peak TPS, Hardware-Adjusted TPS, State Growth.

8) Esquema de datos y lógica (pseudo-SQL)

Eventos de referencia crudos

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

Agregación del núcleo de métricas

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;

Evaluación de 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) Índice compuesto (ejemplo de cálculo)

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) Características de L2 y entre cadenas

Optimistic L2: especificar TTF «dual» - hasta la inclusión L2 y hasta el final de la ventana de desafío.
ZK L2: dividir el tiempo de publicación en L1 y el tiempo de generación/verificación del pruff; Tomar en consideración otkazoustoychivost pruverov.
Validium/DA-outsors: Las métricas DA son obligatorias (throughput/cost/failure), de lo contrario la comparación es incorrecta.
Operaciones entre cadenas: contar E2E TTF para escenarios de puente (istochnik→tsel), teniendo en cuenta K/DA/challenge.

11) Anti-patrones de comparación (qué evitar)

Comparar el «pico récord» de una cadena con las «medias» de otra.
Ignorar el costo de los datos y la volatilidad de las comisiones.
No tener en cuenta la finalización (comparar «inclusión» como «finalidad»).
Quitar las métricas en el nodo «calentado» y transferir a frío.
Mezclar diferentes clases de operaciones sin normalizar.
No registrar versiones de clientes/configuraciones: se pierde la reproducibilidad.

12) Configuraciones y parámetros de pruebas (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) Informes y visualización

Tabla dinámica por scripts: TPS eficaz, TTI/TTF p95, Fee p95, Costo/kB, Éxito%.
Lista de radares (por script): Throughput/Finality/Cost/Stability/Liveness.
Series temporales: Fee-volatility, DA latencia, Reorg spikes.
Matriz «cadena × clase de operación»: Costo-a-Serve y TTF.

14) Procesos y roles

Benchmark Owner: metodología/herramientas, control de versiones.
Infra Owner: nodos, clientes, configuraciones, regiones.
Data/BI: agregaciones, validación, SLO dashboards.
Seguridad/Compliance: control de la privacidad y la corrección de los registros.
Gobierno: publicar resultados, cambiar los pesos del índice.

15) Playbook incidentes de referencia

Derivación de configuraciones/versiones: detención inmediata de la serie, fijación de snapshot, reinicio con los parámetros correctos.
Anomalías de la red (más allá de las previstas): marca la ventana como «contaminada», repetición de la serie.
Falla de DA/Prouver: resaltar un incidente separado, repetir la sub-serie DA/ZK.
Volatilidad imprevista del precio: fijar la mediana de la ventana del USD, aplicar el rango.

16) Lista de verificación de implementación

1. Aprobar scripts (TUP) y pesos del índice de resumen.
2. Fijar las configuraciones de nodos/clientes, regiones y condiciones de red.
3. Implementar la recopilación de telemetría con correlación de tiempo y sincronización.
4. Configurar la normalización de las clases de operación fee/DA/.
5. Alinear SLI/SLO y los diseños de dashboards.
6. Llevar a cabo la serie piloto, taladrar la reproducibilidad, calibrar las cargas.
7. Publicar informes con la aplicación completa de configuraciones, versiones y fechas.

17) Glosario

TTI/TTF - tiempo antes de la inclusión/finalización.
DA es una capa de disponibilidad de datos (Data Availability).
Sustained/Peak TPS - Rendimiento constante/máximo.
Liveness - La capacidad de la red para confirmar bloques/batches.
El Challenge Window es una ventana de disputa en los optimistic-rollups.
Crecimiento del estado: aumento del tamaño del estado de la red.
Hardware-Adjusted TPS: ancho de banda basado en el costo del nodo.

En pocas palabras: la comparación correcta del rendimiento de los circuitos no es una carrera de «quién es más TPS», sino una disciplina: escenarios únicos, normalización honesta del costo y los datos, contabilidad de la finalización y la sostenibilidad, confecciones transparentes y pruebas reproducibles. Siguiendo este marco, el ecosistema obtiene métricas comparables y aptas para la toma de decisiones, desde la selección del sitio para el producto hasta la planificación de arquitecturas interencadenadas.