---
title: "Tempo de bloco"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Tempo de bloco

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

<a id="answer"></a>

## 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.

<a id="mechanism"></a>

## 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.

<a id="example"></a>

## 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.

<a id="risks"></a>

## 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.

<a id="misconceptions"></a>

## 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.

<a id="related"></a>

## Tópicos relacionados

- [Confirmações de bloco](/pt-br/crypto/block-confirmation/)
- [Reorganização da cadeia](/pt-br/crypto/chain-reorg/)
- [Finalidade](/pt-br/crypto/finality/)

<a id="sources"></a>

## Fontes

- [Blocks](https://ethereum.org/developers/docs/blocks/) - Ethereum.org (acessado em: 2026-08-18)
- [Block proposal](https://ethereum.org/developers/docs/consensus-mechanisms/pos/block-proposal/) - Ethereum.org (acessado em: 2026-08-18)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (acessado em: 2026-08-18)
- [Single slot finality](https://ethereum.org/roadmap/single-slot-finality/) - Ethereum.org (acessado em: 2026-08-18)
- [Beacon Chain](https://ethereum.github.io/consensus-specs/specs/phase0/beacon-chain/) - Ethereum Consensus Specs (acessado em: 2026-08-18)
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (acessado em: 2026-08-18)
- [Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Developer Documentation (acessado em: 2026-08-18)
- [Block Chain Reference](https://developer.bitcoin.org/reference/block_chain.html) - Bitcoin Developer Documentation (acessado em: 2026-08-18)

Source: https://wiki.fcontext.com/pt-br/crypto/block-time/index.mdx