---
title: "Tiempo de bloque"
description: "El tiempo de bloque puede ser un slot programado, un intervalo objetivo de prueba de trabajo o la separación observada entre bloques canónicos. Aprende a medir cada reloj sin confundir inclusión, confirmaciones y finalidad."
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.

# Tiempo de bloque

> Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

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

## Respuesta directa

El tiempo de bloque no es un cronómetro universal. En prueba de trabajo suele ser un objetivo a largo plazo de un proceso aleatorio de llegada. En prueba de participación por slots puede ser la duración programada de una oportunidad de propuesta. La separación observada entre bloques canónicos es otra magnitud; inclusión, profundidad de confirmación y finalidad tienen relojes distintos.

En la red principal de Ethereum hay `12-second slots` y `32 slots` por epoch. Un proponente puede perder un slot, por lo que dos bloques producidos pueden distar `24 seconds`, `36 seconds` o más aunque el slot siga durando `12 seconds`. En Bitcoin, `600 seconds` es el intervalo medio objetivo del sistema de dificultad, no un plazo para el siguiente bloque.

Declara cadena, red, bifurcación, ventana y reloj. La marca de tiempo de cabecera es dato del protocolo, no necesariamente la recepción por todos los nodos. Un intervalo nominal menor puede adelantar la primera oportunidad de inclusión, pero no garantiza por sí solo más rendimiento, menos comisiones, menos reorganizaciones ni finalidad más rápida.

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

## Cómo funciona

1. Fija cadena, red, capa, bifurcación activa, cabeza canónica, nodo o RPC y ventana UTC. Registra hashes; la altura sola no es única.
2. Define la métrica: intervalo objetivo, duración de slot, diferencia entre marcas de bloques canónicos, diferencia de recepción local, latencia de inclusión, profundidad o tiempo de finalidad.
3. Recoge hash, padre, altura o slot, timestamp del protocolo y recepción monótona local. Conserva slots perdidos, bloques obsoletos y reorganizados como estados explícitos.
4. Recorre la ascendencia canónica, calcula intervalos y publica muestra, ventana, media, mediana, percentiles, mínimo, máximo y tasa de slots perdidos. Una media no describe una distribución sesgada.
5. Aplica el consenso. En Ethereum distingue slots, epochs, head, safe y finalized. En Bitcoin distingue `600-second target`, llegadas aleatorias según hashrate, chainwork, ventana de `2,016-block` y reglas de timestamp.
6. Descompón la latencia en difusión, espera en mempool o secuenciador, propuesta, propagación, inclusión canónica, confirmaciones, estado safe/finalized y procesamiento de puentes, plataformas o aplicaciones.
7. Contrasta nodos independientes y somete a estrés desfase de reloj, huecos RPC, proponentes perdidos, cambios de hashrate, particiones, reorganizaciones, retrasos de finalidad, caídas del secuenciador y cambios de parámetros antes de fijar un SLA.

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

## Ejemplos

- Ethereum produce bloques en los slots `1,000` y `1,003`. La separación programada es `(1,003 - 1,000) * 12 = 36 seconds`; se perdieron `1,001` y `1,002`. La altura avanza un bloque producido y el slot avanza tres.
- En `300 slots`, la ventana es `300 * 12 = 3,600 seconds`. Si se producen `294 canonical blocks`, hay `6 missed slots`, proporción `294 / 300 = 98%` y tasa `294 / 3,600 = 0.0816666667 blocks/second`, cuyo recíproco es `12.2448979592 seconds/block`. Es estadística, no promesa.
- Un epoch es `32 * 12 = 384 seconds = 6.4 minutes`; dos duran `768 seconds = 12.8 minutes`. Los votos y la participación determinan la finalidad, por lo que no es un SLA fijo; Ethereum describe hoy una finalidad normal de unos `15 minutes`.
- Con un modelo exponencial de Bitcoin de media `600 seconds`, la probabilidad de ningún bloque en `1,200 seconds` es `e^(-1,200/600) = e^-2 = 13.5335283237%`, y la de al menos uno `86.4664716763%`. La ventana objetivo es `2,016 * 600 = 1,209,600 seconds = 14 days`; ninguna cifra programa un bloque individual.

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

## Riesgos

- Usar cadena, red, capa, bifurcación o parámetro histórico incorrectos.
- Comparar slot programado, objetivo PoW e intervalo observado.
- Tratar objetivo o media como espera máxima garantizada.
- Elegir una ventana corta, tranquila o sesgada.
- Tratar timestamp de cabecera como hora exacta de producción o recepción.
- Mezclar relojes locales no sincronizados.
- Omitir slots perdidos o confundirlos con bloques vacíos.
- Incluir bloques obsoletos o reorganizados en la serie canónica.
- Contar alturas sin verificar hashes, padres y ascendencia.
- Ocultar huecos RPC, indexador, websocket o registro como conducta de red.
- Informar media sin mediana, percentiles, rango y muestra.
- Confundir espera en mempool o secuenciador con producción.
- Confundir primera inclusión o una confirmación con finalidad económica.
- Convertir confirmaciones en minutos deterministas.
- Tratar el `10-minute target` de Bitcoin como SLA.
- Ignorar cambios de hashrate, retraso de dificultad y límites de timestamps.
- Ignorar presión de propagación, validación y bifurcaciones temporales.
- Tratar el `12-second slot` de Ethereum como bloque no vacío garantizado.
- Tratar un bloque L2 como publicación, liquidación o finalidad L1.
- Inferir TPS, comisiones, seguridad o descentralización solo del tiempo de bloque.

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

## Errores comunes

- **Cada slot de Ethereum contiene un bloque.** El slot es una oportunidad; el proponente o la propagación pueden fallar.
- **Bitcoin produce exactamente un bloque cada diez minutos.** Es objetivo de dificultad y media; cada espera varía.
- **El timestamp es cuando todos los nodos recibieron el bloque.** Timestamp y recepción local proceden de relojes y actores distintos.
- **Reducir a la mitad el tiempo duplica los TPS seguros y divide comisiones o finalidad.** Capacidad, carga, demanda, propagación y votos siguen siendo restricciones independientes.
- **Un bloque L2 rápido ya tiene finalidad de Ethereum.** Inclusión del secuenciador, publicación L1, inclusión canónica y finalidad son estados distintos.

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

## Temas relacionados

- [Confirmaciones de bloque](/es/crypto/block-confirmation/)
- [Reorganización de cadena](/es/crypto/chain-reorg/)
- [Finalidad](/es/crypto/finality/)

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

## Fuentes

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

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