Um pequeno passo em direção a decisões de protocolo baseadas em dados – Métricas unificadas do SlowBlock entre clientes – Pesquisa da camada de execução

Documento e especificações da proposta original por @ rjl493456442: Métricas de desempenho Ethereum padronizadas – HackMD
Isso foi iniciado por Gary, quando ele implementou o registro lento de blocos no Geth. A partir daí, pensei que isso seria muito útil para muitas coisas listadas abaixo e colaborei com ele na padronização e na concretização dessa visão.

Na minha opinião, isso poderia ajudar nas reprecificações e nas faixas ScaleL1, bem como no bloatnet (meu foco atual). Embora eu ache que podemos fazer muito mais do que isso.

1. Introdução e motivação

Por que esta iniciativa existe

A filosofia multicliente da Ethereum é um ponto forte fundamental – mas cria um desafio: como comparamos o desempenho entre implementações?

Métricas de execução padronizadas resolvem isso permitindo:

• Comparação de desempenho entre clientes – Benchmarking justo e comparativo
• Monitoramento da integridade da rede — Identifique gargalos de execução antes que eles afetem o consenso
• Pesquisa de protocolo baseada em dados — Valide propostas EIP com dados reais de execução
• Detecção de anomalias — Detectar blocos incomuns (alto gás, padrões de acesso de estado complexos)

Exemplo do mundo real: análise EIP-7907

A análise EIP-7907 demonstra exatamente por que as métricas de execução padronizadas são críticas.

Usando métricas Geth, medi:

• Latência de leitura de código: 107ms a 904ms dependendo do tamanho do bytecode
• Dimensionamento de sobrecarga por chamada: 5,9µs a 49,9µs (aumento de 8,5x do menor para o maior contrato)
• Análise da execução do bloco: Isolando leituras de código, leituras de conta, execução de EVM e gravações de banco de dados

Todos esses insights ajudaram a tomar uma decisão muito mais informada. Agilizando assim muito o processo de tomada de decisão da ACD.

2. Métricas Básicas

As métricas são organizadas em categorias que abrangem o ciclo de vida de execução do bloco:

Definições de métricas

3. Formato JSON de bloco lento

Quando a execução do bloco excede um limite configurável (padrão: 1.000 ms), os clientes geram um log JSON estruturado:

{

"level": "warn"
"msg": "Slow block"
"block": {
    "number": 19234567
    "hash": "0x1234...abcd"
    "gas_used": 29500000
    "tx_count": 234
  }
"timing": {
    "execution_ms": 1250
        "state_read_ms": 320
    "state_hash_ms": 150
    "commit_ms": 75
    "total_ms": 1475
  }
"throughput": {
    "mgas_per_sec": 23.60
  }
"state_reads": {
    "accounts": 5420
    "storage_slots": 12340
    "code": 890
    "code_bytes": 456000
  }
"state_writes": {
    "accounts": 234
    "storage_slots": 1890
  }
"cache": {
    "account": { "hits": 4800, "misses": 620, "hit_rate": 88.60 }
    "storage": { "hits": 10200, "misses": 2140, "hit_rate": 82.68 }
    "code": { "hits": 870, "misses": 20, "hit_rate": 97.75 }
  }
}

Requisitos de campo

4. Status de implementação

5. Outras melhorias

Metas de médio prazo para uma análise de desempenho mais refinada:

Este post não quer apenas informar sobre isso, mas busca essencialmente feedback. Queremos saber o que mais seria interessante para equipes, pesquisadores e qualquer outra pessoa poder extrair/saber. Dados internos de clientes difíceis de coletar para eles, etc.

Além disso, gostaríamos de saber o que poderíamos fazer com isso, temos algumas ideias e listamos aqui mais alguns objetivos. Mas acreditamos que as pessoas terão muito mais ideias do que apenas nós.

Obrigado.