Ir para o conteúdo
Financial Context Wiki

Tempo de bloco

Tempo de bloco pode ser um slot programado, um intervalo-alvo de prova de trabalho ou o espaço observado entre blocos canônicos. Saiba medir cada relógio sem confundir inclusão, confirmações e finalidade.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Tempo de bloco não é um cronômetro universal. Em prova de trabalho, costuma ser a meta de longo prazo de um processo aleatório de chegada. Em prova de participação por slots, pode ser a duração programada de uma oportunidade de proposta. O intervalo observado entre blocos canônicos é outra medida; inclusão, profundidade e finalidade têm relógios separados.

Na Mainnet Ethereum há 12-second slots e 32 slots por época. Um proponente pode perder o slot, então blocos produzidos adjacentes podem distar 24 seconds, 36 seconds ou mais, embora o slot continue com 12 seconds. No Bitcoin, 600 seconds é o intervalo médio alvo do sistema de dificuldade, não prazo para o próximo bloco.

Declare cadeia, rede, fork, janela e relógio. O timestamp do cabeçalho é dado de protocolo, não necessariamente a recepção por todos os nós. Intervalo nominal menor pode antecipar a oportunidade de inclusão, mas não garante sozinho mais throughput, taxas menores, menos reorgs ou finalidade mais rápida.

Espera estimada
1.2 min
Intervalo ilustrativo
54s - 1.5 min

Os resultados são aproximações educacionais. Eles excluem regras de local, impostos, latência, comportamento do oráculo e outros parâmetros específicos do protocolo, a menos que sejam mostrados.

Como funciona

  1. Fixe cadeia, rede, camada, fork ativo, head canônico, nó ou RPC e janela UTC. Registre hashes; altura sozinha não é única.
  2. Defina a métrica: intervalo alvo, duração do slot, diferença entre timestamps canônicos, diferença de recepção local, latência de inclusão, profundidade ou tempo de finalidade.
  3. Colete hash, pai, altura ou slot, timestamp do protocolo e recepção monotônica local. Mantenha slots perdidos, blocos obsoletos e reorganizados como estados explícitos.
  4. Percorra a ancestralidade canônica, calcule intervalos e publique amostra, janela, média, mediana, percentis, mínimo, máximo e taxa de slots perdidos. Uma média não descreve distribuição assimétrica.
  5. Aplique o consenso. Na Ethereum, separe slots, épocas, head, safe e finalized. No Bitcoin, separe 600-second target, chegadas aleatórias conforme hashrate, chainwork, janela de 2,016-block e regras de timestamp.
  6. Decomponha latência em transmissão, espera no mempool ou sequenciador, proposta, propagação, inclusão canônica, confirmações, safe/finalized e processamento de ponte, plataforma ou aplicação.
  7. Cruze nós independentes e teste desvio de relógio, falhas RPC, proponentes perdidos, mudanças de hashrate, partições, reorgs, atrasos de finalidade, indisponibilidade do sequenciador e mudanças de parâmetros antes de definir SLA.

Exemplos

  • Ethereum produz blocos nos slots 1,000 e 1,003. O intervalo programado é (1,003 - 1,000) * 12 = 36 seconds; 1,001 e 1,002 foram perdidos. A altura avança um bloco produzido, enquanto o slot avança três.
  • Em 300 slots, a janela é 300 * 12 = 3,600 seconds. Com 294 canonical blocks, há 6 missed slots, proporção 294 / 300 = 98% e taxa 294 / 3,600 = 0.0816666667 blocks/second, cujo recíproco é 12.2448979592 seconds/block. É estatística, não promessa.
  • Uma época tem 32 * 12 = 384 seconds = 6.4 minutes; duas têm 768 seconds = 12.8 minutes. Votos e participação determinam a finalidade, então isso não é SLA fixo; a Ethereum descreve finalidade normal em cerca de 15 minutes.
  • No modelo exponencial do Bitcoin com média 600 seconds, a probabilidade de nenhum bloco em 1,200 seconds é e^(-1,200/600) = e^-2 = 13.5335283237%, e de ao menos um é 86.4664716763%. A janela alvo é 2,016 * 600 = 1,209,600 seconds = 14 days; nenhuma cifra agenda bloco individual.

Riscos

  • Usar cadeia, rede, camada, fork ou parâmetro histórico incorretos.
  • Comparar slot programado, alvo PoW e intervalo observado.
  • Tratar meta ou média como espera máxima garantida.
  • Selecionar janela curta, calma ou enviesada.
  • Tratar timestamp como hora exata de produção ou recepção.
  • Misturar relógios locais não sincronizados.
  • Omitir slots perdidos ou confundi-los com blocos vazios.
  • Incluir blocos obsoletos ou reorganizados na série canônica.
  • Contar alturas sem verificar hashes, pais e ancestralidade.
  • Ocultar falhas RPC, indexador, websocket ou logs como comportamento da rede.
  • Informar média sem mediana, percentis, faixa e amostra.
  • Confundir espera em mempool ou sequenciador com produção.
  • Confundir primeira inclusão ou uma confirmação com finalidade econômica.
  • Converter confirmações em minutos determinísticos.
  • Tratar o 10-minute target do Bitcoin como SLA.
  • Ignorar hashrate, atraso da dificuldade e limites de timestamps.
  • Ignorar pressão de propagação, validação e forks temporários.
  • Tratar o 12-second slot da Ethereum como bloco não vazio garantido.
  • Tratar bloco L2 como publicação, liquidação ou finalidade L1.
  • Inferir TPS, taxas, segurança ou descentralização só do tempo de bloco.

Erros comuns

  • Todo slot Ethereum contém bloco. O slot é uma oportunidade; proponente ou propagação podem falhar.
  • Bitcoin produz exatamente um bloco a cada dez minutos. É alvo de dificuldade e média; cada espera varia.
  • O timestamp é quando todos os nós receberam o bloco. Timestamp e recepção local usam produtores e relógios distintos.
  • Reduzir o tempo pela metade dobra TPS seguro e divide taxas ou finalidade. Capacidade, carga, demanda, propagação e votos são restrições independentes.
  • Um bloco L2 rápido já tem finalidade Ethereum. Inclusão do sequenciador, publicação L1, inclusão canônica e finalidade são estados separados.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...