Comparação de desempenho das correntes

(Secção: Ecossistema e Rede)

1) Porquê e o que comparamos

• Velocidade e atrasos: inclusão, finalização, variabilidade.
• Economia: custos de transações e dados, estabilidade de comissões.
• Sustentabilidade: reorgues, livramento, degradação sob carga.
• Disponibilidade de dados: largura de banda DA e custo de byte.
• Operacionais: exigência de nódulos, tamanho do estado, diversificação de clientes.

Resultado: KPI resumido que permite a escolha de correntes/domínios sob cenários específicos (pagamentos, jogos/micro-eventos, pontes, DA/publicações).

2) Taxonomia métricas (núcleo)

2. 1 Banda larga e atrasos

Sustained TPS/QPS (capacidade estável)

Peak TPS (pico curto sem erros/drop)

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

Time-to-Finality (TTF) p50/p95/p99 (levar em conta as confirmações K/desafio-janela)

Block Utilization% (bloco cheio/batch)

Variance/Jitter atrasos (XVIs)

2. 2 Qualidade e sustentabilidade

Sucess Rate (% de sucesso tx/events)

Reorg/Orphan Rate (frequência e profundidade)

Liveness SLO Hit (execução da disponibilidade de destino)

Degradation Grace (degradação controlada em vez de feel)

2. 3 Economia e DA

Fee p50/p95/p99 (em moeda nativa e USD)

Cost-per-kB (DA) - preço de publicação de 1 kB de dados

Costa-para-Tx Class - preço do «tipo de transação»: tradução simples, chamada de contrato, grande calldata

Fee Volatility Index (estabilidade das comissões de janelas)

2. 4 Nós e estado

Hardware Footprint (CPU/RAM/SSD/rede para validador/site de arquivo)

State Growth (aumento de estado/dia)

Cliente Diversity Index (distribuição de clientes/verificadores)

Sinc Time (sink rápido/arquivo)

2. 5 L2-especificidades

Batch TPS, Batch Size (kB)

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

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

Masslement Latency (finalização L2→L1)

3) Metodologia de medição (neutra e reproduzível)

1. Plano de carga unificada (TUP - Teste Use Profiles):

TUP-Pay: traduções pequenas (N = 70% simples, 30% tocen).
TUP-Game: eventos curtos com calldata (até 2-8 kB).
TUP-DEX: contratos com gás médio e picos.
TUP-DA: grandes publicações (50-250 KB batchs).

2. Camadas de carga: fundo 60-80% do alvo SLO + impulsos 120-160% 5-10 minutos a cada 30-60 minutos.

3. Geografia e rede: pelo menos 3 regiões, matriz, injeções de jitter/loss (0. 5–2%).

4. Diversificação de clientes: pelo menos 2 clientes de nós por cadeia (se disponíveis), versões idênticas.

5. Coleta de telemetria: correlação correta (trace-ID), sincronização de tempo (NTP/PTP), fixação de configs.

6. Janelas de finalização: configuração explícita de K/janela de disputa; O TTF conta com as regras da cadeia.

7. Semântica de erros: taxonomia de falhas (gás/nonce/limite/DA-feel/overload), excluir erros «esperados» do Sucess Rate ou destacar separadamente.

4) Normalização e anti-deslocamento

Cost Normalization: USD по курсу на `observed_at`; `fee_usd = fee_native × price_usd_at_t`.
Gas/Weight Equivalence: comparação em «classes operacionais», não em «gases crus».

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

Fair DA Compare: preço de 1 kB e p95 atrasos de publicação.
Volatility Windows: janelas semanais/mensais, mediana e IQR em vez de «recordes individuais».
Cold vs Warm: Aquecimento de dinheiro; medições após a estabilização.
MEV/Comissões de pico: excluir «anomalias de mercado» ou destacar uma métrica separada.

5) KPI (resultados finais)

• Throughput (30%), Finality (25%), Cost (20%), Stability (15%), Uptime/Liveness (10%).
• Os valores de peso são ajustados a um cenário (por exemplo, para pagamentos de ↑Finality/Cost, para jogos de ↑Throughput/Stability/DA).

O Effective Throughput @ SLO é um TPS resistente com 'TTF _ p95 ≤ X', 'Sucess ≥ Y%', 'Fee _ p95 ≤ Z'.
Costa-to-Serve para 1k Ops - custo total de processamento de 1.000 operações de classe (incluindo DA/masslement).
Finality SLA Hit% é o percentual de operações finalizadas na janela de destino.

6) SLI/SLO para comparação

• 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 Masslement: 'Setle _ p95 ≤ 10m' (ZK )/' challenge 'para optimistic.

7) Dashboards (layouts)

Perf Lens (real tempo/hora): TTI/TTF p50/p95/p99, Block Utilization, Sucess Rate, Fee p95, Erro taxonomy.
Cost & DA: Cost/kB, Fee-volatility, DA throughput/latency, отказ DA.
Statity: Reorg Rate, Liveness SLO Hit, Burn-rate erros, farmácia centenser (L2).
Capacity Planning: Sustained vs Peak TPS, Hardware-Adjusted TPS, State Growth.

8) Esquema de dados e lógica (pseudo-SQL)

Eventos brutos do 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
);

Agregação do 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;

Avaliação de Efetive 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 composto (exemplo 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) L2 e características entre cadeias

Optimistic L2: especifique «duplo» TTF - antes da inclusão L2 e antes do fim da janela challenge.
ZK L2: dividir o tempo de publicação em L1 e o tempo de geração/verificação do lago; Levar em conta a resistência a falhas.
Validium/DA-outdoors: as métricas DA são obrigatórias (throughput/cost/failure), senão a comparação não é correta.
Operações entre cadeias: considerar E2E TTF para cenários de ponte (istochnik→tsel), considerando K/DA/challenge.

11) Comparações anti-pattern (o que evitar)

Comparar o pico recorde de um circuito com o médio do outro.
Ignorar o valor dos dados e a volatilidade das comissões.
Ignorar finalização (comparar «inclusion» como «finality»).
Tirar as métricas no nó aquecido e transportá-las para o nó frio.
Misturar diferentes classes de operações sem normalização.
Não capturar versões de clientes/configs - perde a reprodutividade.

12) Configurações e configurações de testes (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) Relatórios e visualização

Tabela resumida de cenários: Efetive TPS, TTI/TTF p95, Fee p95, Cost/kB, Sucess%.
Lista de radar (para o cenário): Throughput/Finality/Costa/Statity/Liveness.
Fileiras de tempo: Fee-volatility, Latidão DA, Reorg spikes.

• 14) Processos e papéis

Benchmark Owner: metodologia/ferramentas, controle de versões.
Infra Owner: nós, clientes, configs, regiões.
Data/BI: agregações, verificação de correção, SLO dashboard.
Segurança/Compliance: controle de privacidade e correção dos logs.
Governance: publicação de resultados, alteração da balança do índice.

15) Playbook incidentes de benchmark

À deriva de configurs/versões: paragem imediata da série, fixação snapshot, reinício com configurações corretas.
Anomalias de rede (fora do padrão): marca a janela como «contaminado», repetindo a série.
Falha DA/Pragueiro: isolar o incidente, repetir a série DA/ZK.
A volatilidade inesperada do preço é fixar a janela USD mediana, anexar a faixa.

16) Folha de cheque de implementação

1. Aprovar cenários (TUP) e peso do índice resumido.
2. Fixar configs de nós/clientes, regiões e condições de rede.
3. Recolher telemetria com correlação e sincronização do tempo.
4. Ajustar a normalização fee/DA/classes de operações.
5. Alinhar SLI/SLO e layouts de dashboards.
6. Realizar uma série piloto, comparar reprodutividade, calibrar cargas.
7. Publicar relatórios com a aplicação completa de configurs, versões e datas.

17) Glossário

TTI/TTF - tempo até a inclusão/finalização.
DA - Camada de disponibilidade de dados (Data Availability).
O Sustained/Peak TPS é uma capacidade sustentável/de pico.
Liveness - capacidade da rede para confirmar blocos/batches.
O Challenge Window é uma janela de contestação nos rolos optimísticos.
State Growth - aumento do tamanho da rede.
Software-Adjusted TPS - largura de banda com base no custo do nó.

Resultado: uma comparação correta entre o desempenho das cadeias não é uma corrida «quem é maior que o TPS», mas sim uma disciplina: cenários unificados, normalização justa de custos e dados, contabilidade de finalização e estabilidade, configs transparentes e testes reprodutivos. Seguindo este quadro, o ecossistema recebe métricas comparáveis e decisivas, desde a escolha do local para o produto até o planejamento de arquiteturas entre cadeias.