Busca en todas las páginas de la documentación
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.
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:
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:
getEpochInfo devuelve la época actual y la posición dentro de ellagetEpochSchedule proporciona slotsPerEpoch (típicamente 432,000)| 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 |
// 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(())
}Clock proporciona slot, epoch, unix_timestamp.getBlockHeight frente a getSlot apropiadamente.Clock::unix_timestamp en los programas.confirmTransaction con un nivel de compromiso.| 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 |
Un slot es una ventana de tiempo (~400 ms objetivo) durante la cual un validador es designado líder y puede producir un bloque.
Aproximadamente 2 días. Una época contiene ~432,000 slots al tiempo objetivo de 400 ms por 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.
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.
const info = await rpc.getEpochInfo().send();
console.log(info.epoch);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.
Sí, a través de la sysvar Clock: Clock::get()?.slot.
En cada límite de época. El nuevo calendario se calcula a partir de la distribución de participación (stake) en ese momento.
El mismo objetivo (400 ms), pero devnet tiene menos validadores y más omisiones. No uses devnet para puntos de referencia de tiempo.
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.
El número de slots transcurridos desde que comenzó la época actual. Rango: 0 a slotsPerEpoch - 1.
Solo para estimaciones aproximadas. Usa el compromiso confirmado/finalizado para los estados de "transacción completada" dirigidos al usuario.
solana slotVersiones 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.
Revisado por Chris St. John·Última actualización: 16 jul 2026