Slots, Bloques y Épocas
Solana organiza el tiempo en slots (ventanas de producción), bloques (lotes de transacciones confirmadas) y épocas (períodos del calendario de participación). Estas unidades impulsan la rotación de líderes, las recompensas de participación (staking) y el tiempo de confirmación del cliente.
Receta
Tarjeta de referencia rápida - lista para copiar y pegar.
solana slot
solana epoch
solana epoch-info
solana block-time $(solana slot)import { createSolanaRpc } from "@solana/kit";
const rpc = createSolanaRpc("https://api.devnet.solana.com");
const slot = await rpc.getSlot().send();
const epochInfo = await rpc.getEpochInfo().send();
console.log({ slot, epoch: epochInfo.epoch, slotIndex: epochInfo.slotIndex });Cuándo usar esto:
- Para estimar cuándo se activan las recompensas de participación (staking) (límites de época)
- Para correlacionar eventos en la cadena con el tiempo del reloj
- Para comprender por qué las transacciones se confirman en ~400 ms frente a ~12 segundos
- Para depurar omisiones de líderes durante la degradación de la red
- Para programar mantenimiento en torno a las transiciones de época
Ejemplo Funcional
import { createSolanaRpc } from "@solana/kit";
const rpc = createSolanaRpc("https://api.mainnet-beta.solana.com");
const epochInfo = await rpc.getEpochInfo().send();
const epochSchedule = await rpc.getEpochSchedule().send();
const slotsPerEpoch = epochSchedule.slotsPerEpoch;
const slotsRemaining = slotsPerEpoch - epochInfo.slotIndex;
const msPerSlot = 400; // objetivo, no garantizado
const estimatedMsRemaining = slotsRemaining * msPerSlot;
console.log({
currentEpoch: epochInfo.epoch,
slotInEpoch: epochInfo.slotIndex,
slotsPerEpoch,
slotsRemaining,
estimatedMinutesToNextEpoch: Math.round(estimatedMsRemaining / 60_000),
});Qué demuestra esto:
getEpochInfodevuelve la época actual y la posición dentro de ellagetEpochScheduleproporcionaslotsPerEpoch(típicamente 432,000)- El tiempo de slot es un objetivo, no una garantía; los slots omitidos extienden la duración en tiempo real
- Los límites de época afectan el calentamiento/enfriamiento de la participación (staking) y la rotación del calendario de líderes
Análisis Profundo
Cómo Funciona
- Los validadores rotan como líderes: un líder por slot produce un bloque.
- Las marcas de Prueba de Historial (Proof of History) dentro de cada slot proporcionan un reloj de ordenamiento verificable.
- Un bloque contiene las transacciones procesadas durante un slot (o abarca múltiples slots si el líder es lento).
- Al final de la época, se calcula un nuevo calendario de líderes a partir de la distribución de participación (stake) actual.
Referencia de Tiempos
| Concepto | Valor Típico | Notas |
|---|---|---|
| Tiempo de slot | ~400 ms | Objetivo; el real varía con las omisiones |
| Slots por época | 432,000 | ~2 días a 400 ms/slot |
| Tiempo de bloque | 400 ms - 1 s+ | Depende de la congestión y el líder |
| Finalidad (TowerBFT) | ~12-13 s | ~32 slots confirmados |
Calendario de Líderes
- La selección aleatoria ponderada por participación (stake) determina qué validador lidera cada slot.
- El calendario para una época se fija en el límite de la época.
- Si el líder asignado está desconectado, el slot se omite (sin bloque).
Notas de Rust
// Los programas generalmente no leen el slot/época directamente a menos que usen sysvars
use anchor_lang::prelude::*;
pub fn log_clock(ctx: Context<LogClock>) -> Result<()> {
let clock = Clock::get()?;
msg!("slot: {}, epoch: {}", clock.slot, clock.epoch);
Ok(())
}- La sysvar
Clockproporcionaslot,epoch,unix_timestamp. - No asumas una duración fija de slot en la lógica del programa; usa marcas de tiempo para los plazos.
Trampas Comunes
- Asumir exactamente 400 ms por slot: los slots omitidos y los líderes lentos añaden latencia. Solución: usa niveles de confirmación, no matemáticas de slots, para los temporizadores de la experiencia del usuario.
- Confundir slot con altura de bloque: la altura de bloque se incrementa solo cuando se produce un bloque; los slots siempre se incrementan. Solución: usa
getBlockHeightfrente agetSlotapropiadamente. - Sorpresas en la participación (staking) en los límites de época: los cambios de delegación tienen épocas de calentamiento/enfriamiento. Solución: planifica las operaciones de participación en torno a las transiciones de época.
- Usar el tiempo del reloj para plazos en la cadena: existen deriva del reloj y tiempos de slot variables. Solución: usa la sysvar
Clock::unix_timestampen los programas. - Consultar el slot para confirmación: ineficiente e impreciso. Solución: usa
confirmTransactioncon un nivel de compromiso. - Omisión de líder durante interrupciones: retrasos en la inclusión de transacciones, no fallos. Solución: reintenta con un blockhash fresco y tarifas de prioridad.
Alternativas
| Alternativa | Usar Cuando | No Usar Cuando |
|---|---|---|
Sondeo getSlot | Depurar problemas de tiempo | Experiencia del usuario de confirmación |
Niveles de compromiso (confirmed, finalized) | Confirmación de aplicación | Medir el estado de producción de bloques |
getBlockTime | Correlacionar slot con UTC | Temporizadores de cuenta regresiva en tiempo real |
Sysvar Clock en programas | Bloqueos de tiempo en cadena | Requisitos de precisión de subsegundo |
Preguntas Frecuentes
¿Qué es un slot en Solana?
Un slot es una ventana de tiempo (~400 ms objetivo) durante la cual un validador es designado líder y puede producir un bloque.
¿Cuánto dura una época?
Aproximadamente 2 días. Una época contiene ~432,000 slots al tiempo objetivo de 400 ms por slot.
¿Qué sucede cuando un líder omite un slot?
No se produce ningún bloque para ese slot. El número de slot sigue avanzando. Las transacciones esperan al próximo líder disponible.
¿Es el número de slot lo mismo que la altura de bloque?
No. El slot se incrementa cada ~400 ms independientemente de los bloques. La altura de bloque se incrementa solo cuando se produce realmente un bloque.
¿Cómo obtengo la época actual desde RPC?
const info = await rpc.getEpochInfo().send();
console.log(info.epoch);¿Por qué la finalidad tarda ~12 segundos si los slots son de 400 ms?
TowerBFT requiere una supermayoría de la participación (stake) para votar sobre una bifurcación. Esto típicamente toma ~32 slots de votación.
¿Pueden los programas acceder al slot actual?
Sí, a través de la sysvar Clock: Clock::get()?.slot.
¿Cuándo cambia el calendario de líderes?
En cada límite de época. El nuevo calendario se calcula a partir de la distribución de participación (stake) en ese momento.
¿Tiene devnet el mismo tiempo de slot que mainnet?
El mismo objetivo (400 ms), pero devnet tiene menos validadores y más omisiones. No uses devnet para puntos de referencia de tiempo.
¿Cómo se relacionan las recompensas de participación (staking) con las épocas?
Las recompensas se acreditan por época según el peso de la participación (stake) y la tasa de inflación. Las nuevas delegaciones tienen un período de calentamiento medido en épocas.
¿Qué es slotIndex en getEpochInfo?
El número de slots transcurridos desde que comenzó la época actual. Rango: 0 a slotsPerEpoch - 1.
¿Debería crear un temporizador de cuenta regresiva basado en slots?
Solo para estimaciones aproximadas. Usa el compromiso confirmado/finalizado para los estados de "transacción completada" dirigidos al usuario.
Relacionado
- Cómo Fluye una Transacción - ruta de confirmación a nivel de slot
- Clusters y Redes - tiempos por cluster
- Conceptos Básicos de Solana - uso de la CLI
solana slot
Versiones de Stack: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, y LiteSVM 0.6.x.