Calendario de épocas

¿Qué es un calendario de épocas?

Un calendario de épocas es el conjunto de reglas de una blockchain que divide el tiempo de la red en épocas y unidades más pequeñas denominadas slots.

Determina cómo se agrupan los slots, cuándo termina una época, cuándo comienza la siguiente y cuándo pueden producirse eventos de la red basados en épocas.

Según la blockchain, estos eventos pueden incluir asignaciones de validadores, rotación de líderes, actualizaciones de staking, cálculos de recompensas, snapshots de gobernanza, actualizaciones del protocolo y cambios en los parámetros de consenso.

Un calendario de épocas suele expresarse en tiempo de protocolo, no en fechas del calendario convencional.

Por ejemplo, una red puede definir una época como un número fijo de slots, en lugar de establecer que cada época dura exactamente dos días.

La duración real puede diferir de la estimada si la producción de slots es más rápida o más lenta que el ritmo previsto.

El término puede referirse a la estructura temporal general de cualquier blockchain basada en épocas.

También tiene un significado más específico en Solana, donde Epoch Schedule describe los parámetros del clúster utilizados para asignar slots a épocas y coordinar los calendarios de líderes.

¿Qué es una época?

Una época es un grupo definido de slots consecutivos de la blockchain.

Las redes Proof of Stake utilizan épocas para organizar la actividad de los validadores en periodos manejables.

En lugar de recalcular cada responsabilidad de la red después de cada transacción, el protocolo puede aplicar determinadas actualizaciones en límites de época previsibles.

Una época puede proporcionar un periodo de referencia común para medir la participación de los validadores, calcular recompensas de staking, cambiar el estado de delegación, rotar comités o activar reglas del protocolo.

Los números de época suelen aumentar desde el inicio de la blockchain.

Sin embargo, un número de época solo tiene significado dentro de su propia red: la época 500 de una blockchain no guarda relación con la época 500 de otra.

¿Qué es un slot?

Un slot es una oportunidad breve, definida por el protocolo, durante la cual se puede esperar o permitir que un validador produzca un bloque o realice otra tarea de consenso.

Varios slots se agrupan para formar una época.

Un slot puede transcurrir sin que se produzca un bloque.

Esto puede ocurrir si el validador seleccionado está desconectado, el bloque llega demasiado tarde, la red lo rechaza o el diseño de consenso no exige que todos los slots contengan un bloque.

Por tanto, el número de slot no siempre coincide con el número de bloque.

Las aplicaciones no deben suponer que cada slot corresponde a un bloque aceptado.

Calendario de épocas y número de época

Un número de época identifica una época concreta de la historia de la blockchain.

El calendario de épocas define las reglas para calcular ese número y determinar los límites de cada época.

Por ejemplo, el calendario puede especificar cuántos slots pertenecen a cada época y si las primeras épocas tienen una duración distinta.

Una consulta de la época actual indica a una aplicación en qué punto se encuentra la red.

Una consulta del calendario de épocas indica cómo está organizada la estructura de épocas de la red.

Por qué son importantes los calendarios de épocas

Los calendarios de épocas proporcionan a los validadores y las aplicaciones un marco previsible para la actividad de la blockchain que depende del tiempo.

Los validadores pueden prepararse para las próximas tareas de producción de bloques o votación.

Los participantes en staking pueden estimar cuándo podrían hacerse efectivos los cambios de delegación o los cálculos de recompensas.

Las wallets pueden mostrar el progreso hacia el límite de una época.

Los sistemas de supervisión pueden medir el rendimiento de los validadores en un periodo coherente.

Los desarrolladores pueden programar operaciones que dependan de un número de época o un rango de slots.

Los desarrolladores del protocolo pueden activar algunas actualizaciones en un límite claramente definido, en lugar de depender de una marca de tiempo de reloj incierta.

Cómo se define un calendario de épocas

Un calendario de épocas suele incluir el número de slots por época y la relación entre los slots absolutos y los números de época.

Algunos calendarios también describen un periodo de calentamiento durante el cual las primeras épocas son más cortas que las normales.

Un calendario puede definir con cuánta antelación se calculan las asignaciones de liderazgo de los validadores o de los comités.

También puede incluir la primera época y el primer slot que utilizan la duración normal completa.

Estos parámetros deben interpretarse según las reglas de la blockchain correspondiente.

Un mismo nombre de campo puede tener distintas consecuencias operativas en diferentes sistemas de consenso.

Duración fija y variable de las épocas

Una época de duración fija siempre contiene el mismo número de slots después de cualquier periodo inicial o de calentamiento.

Un calendario de duración variable puede cambiar el número de slots conforme a las reglas del protocolo, las fases de la red o un diseño de puesta en marcha progresiva.

Aunque el número de slots sea fijo, la duración real no tiene por qué serlo exactamente.

Una blockchain con tiempos de slot objetivo puede experimentar variaciones temporales debido a las condiciones de la red y al rendimiento de los validadores.

Por tanto, las aplicaciones deben distinguir el número de slots de una época de su duración estimada en minutos, horas o días.

Límites de época

Un límite de época es la transición entre el último slot de una época y el primero de la siguiente.

Los protocolos suelen utilizar estos límites como puntos de sincronización para los cambios relacionados con el consenso.

El conjunto de validadores, la distribución del staking, el estado de las recompensas o el calendario de líderes pueden actualizarse en el límite o cerca de él.

Una aplicación que dependa de una transición de época debe utilizar datos on-chain, en lugar de basarse únicamente en una cuenta atrás local.

Cerca de un límite, los retrasos de la red y las diferencias en el nivel de compromiso de RPC pueden hacer que dos proveedores de datos comuniquen posiciones actuales ligeramente distintas.

Calendario de épocas en Solana

En Solana, una época es el periodo durante el que es válido un calendario de líderes para un determinado número de slots.

La guía oficial de terminología de Solana define la época en relación con los slots y el calendario de líderes.

Solana ofrece un método RPC denominado

que devuelve los parámetros del calendario de épocas del clúster.

La documentación oficial de getEpochSchedule enumera cinco campos de respuesta.

Estos campos son

, , , y .

El método no requiere parámetros de solicitud.

Los desarrolladores deben consultar el clúster previsto, en lugar de suponer que todas las redes Solana utilizan los mismos valores de calendario.

slotsPerEpoch

El campo

indica el número máximo de slots de una época de duración normal.

Este valor es fundamental para calcular los límites de las épocas una vez finalizado el periodo de calentamiento.

Si un clúster no utiliza épocas de calentamiento, la duración normal puede aplicarse desde la primera época.

Si el calentamiento está habilitado, las primeras épocas pueden tener menos slots antes de alcanzar la duración completa.

El campo representa un número de slots, no un número garantizado de bloques.

Es posible que algunos slots no produzcan bloques aceptados.

leaderScheduleSlotOffset

El campo

indica con cuánta antelación al límite de una época se determina el calendario de líderes de la época correspondiente.

Un calendario de líderes asigna validadores a los slots en los que se espera que lideren la producción de bloques.

Determinar el calendario con antelación permite que los validadores se preparen para los slots que tienen asignados.

Este desplazamiento no debe confundirse con el número de slots de la época, aunque ambos campos puedan tener casualmente el mismo valor en un clúster concreto.

warmup

El campo

es un valor booleano que indica si las primeras épocas comienzan con una duración menor y aumentan hasta alcanzar el tamaño normal.

El valor

significa que el calendario incluye este comportamiento inicial.

El valor

significa que el clúster no utiliza épocas de calentamiento con duraciones crecientes.

Los parámetros de calentamiento afectan principalmente a las primeras etapas de la historia de una red.

Las aplicaciones que calculen límites de épocas históricas deben tener en cuenta el calentamiento, en lugar de aplicar la duración normal a todas las épocas iniciales.

firstNormalEpoch

El campo

identifica la primera época que utiliza el número completo de slots normal.

Este campo es especialmente relevante cuando

está habilitado.

Las épocas anteriores pueden tener duraciones progresivamente diferentes.

El software que realice cálculos históricos debe aplicar las reglas de calentamiento del calendario, en lugar de restar un número fijo de slots por cada época anterior.

firstNormalSlot

El campo

identifica el slot absoluto en el que comienza la primera época de duración normal.

Proporciona un punto de referencia para asignar los números de slot posteriores a épocas normales.

En conjunto,

y separan la parte de calentamiento del calendario de la parte regular.

Una aplicación puede utilizar estos campos para evitar cálculos históricos de épocas incorrectos.

Sysvar Epoch Schedule de Solana

Los programas de Solana pueden acceder a la información del calendario de épocas mediante la variable del sistema EpochSchedule, conocida habitualmente como sysvar.

Una sysvar proporciona información mantenida por la red que los programas on-chain pueden leer durante la ejecución.

La referencia oficial de syscalls de Solana incluye una syscall para cargar la sysvar EpochSchedule en la memoria del programa.

Esto permite que un programa on-chain calcule las relaciones entre épocas y slots sin depender de un sitio web off-chain.

Aun así, un programa debe evitar hacer suposiciones innecesarias sobre el tiempo de reloj, ya que el calendario se expresa en slots.

getEpochSchedule frente a getEpochInfo

devuelve los parámetros estructurales que definen el sistema de épocas del clúster.

devuelve la posición actual del nodo dentro de una época y los contadores relacionados.

La documentación oficial de getEpochInfo incluye la época actual, el slot absoluto, el índice del slot, los slots de la época actual, la altura del bloque y, cuando están disponibles, el número de transacciones.

El campo

muestra la posición actual dentro de la época.

El campo

indica el número de slots de esa época concreta.

Las aplicaciones pueden combinar ambos métodos para comprender el calendario y mostrar el progreso actual.

Calendario de épocas frente a calendario de líderes

El calendario de épocas define cómo se dividen los slots en épocas.

El calendario de líderes identifica qué validador tiene asignado liderar determinados slots de una época.

Ambos conceptos están relacionados, pero no son intercambiables.

El método getLeaderSchedule de Solana devuelve las identidades de los validadores y sus índices relativos de slots de liderazgo para una época seleccionada.

Una aplicación de supervisión puede utilizar el calendario de épocas para localizar la época y el calendario de líderes para identificar quién debería producir el bloque.

Épocas y recompensas de staking en Solana

En Solana, las épocas proporcionan un periodo contable para información importante sobre staking.

La red ofrece datos de recompensas por época mediante su sistema RPC.

El método getInflationReward devuelve información sobre las recompensas de staking o votación acreditadas para una época concreta, cuando los datos están disponibles.

Un registro de recompensas de una época puede incluir el número de época, el slot efectivo, la cantidad acreditada, el saldo resultante y la información sobre la comisión del validador.

Una recompensa asociada a una época no debe interpretarse como un pago fijo garantizado.

Los resultados reales del staking dependen de las reglas de la red, el rendimiento del validador, el estado del staking, las comisiones y otras condiciones del protocolo.

Calendario de épocas de Ethereum

Ethereum también organiza el consenso Proof of Stake en slots y épocas.

Actualmente, Ethereum utiliza slots de 12 segundos y 32 slots por época.

Esto supone una duración programada de 384 segundos por época, es decir, aproximadamente 6,4 minutos.

La documentación oficial de Proof of Stake de Ethereum explica que se selecciona un validador para proponer un bloque en cada slot.

Los comités de validadores envían attestations y normalmente cada validador activo tiene una tarea de attestation en cada época.

Un slot puede quedar vacío si el proponente seleccionado no publica un bloque aceptado.

La cronología de slots y épocas continúa aunque se pierda un bloque.

Épocas y finalidad en Ethereum

Ethereum utiliza puntos de control de época como parte de su proceso de finalidad Proof of Stake.

Los validadores votan sobre las relaciones entre puntos de control mediante sus attestations.

En condiciones normales de red, el apoyo suficiente de los validadores puede justificar y finalizar puntos de control en épocas sucesivas.

La finalidad ofrece a los usuarios una gran confianza en que un bloque no se eliminará sin que se produzca un fallo importante del consenso y consecuencias económicas significativas.

El límite de una época no significa que todas las transacciones de la época anterior pasen a estar finalizadas al instante.

La finalidad depende de la participación de los validadores y de las reglas del protocolo para los puntos de control.

Épocas y tareas de los validadores en Ethereum

Ethereum distribuye las responsabilidades de los validadores entre slots y épocas.

Normalmente, un validador realiza una attestation por época.

También puede seleccionarse a un validador para proponer un bloque o participar en un comité de sincronización.

El cumplimiento puntual es importante, ya que las tareas tardías o no realizadas pueden reducir las recompensas.

La guía de recompensas y penalizaciones de Ethereum describe las recompensas por los votos timely source, target y head, las propuestas de bloques y la participación en comités de sincronización.

Los operadores de validadores deben supervisar la temporización de los slots, en lugar de considerar la época un único plazo amplio.

Calendario de épocas de Cardano

El consenso Proof of Stake de Cardano también divide el tiempo en épocas y slots.

La documentación actual de Cardano Node establece que cada slot dura un segundo y que cada época contiene 432.000 slots.

Esto corresponde a una duración programada de cinco días por época.

Según el diseño de consenso de Cardano, en un slot se pueden seleccionar cero o más nodos productores de bloques.

La red no necesita producir un bloque en cada slot de un segundo.

La guía de consenso de Cardano explica que agrupar los slots en épocas permite seleccionar líderes según una distribución de staking cambiante.

Los calendarios de épocas varían entre blockchains

No existe una duración de época universal compartida por todas las criptomonedas.

Las épocas de Ethereum duran minutos, mientras que otras redes pueden utilizar periodos de horas o días.

Algunas redes vinculan estrechamente las épocas con la finalidad y la rotación de comités.

Otras las utilizan principalmente para los calendarios de líderes, la contabilidad del staking, las actualizaciones de delegación o la distribución de recompensas.

Una wallet o aplicación de staking nunca debe aplicar a una blockchain las suposiciones sobre épocas de otra.

La documentación del protocolo correspondiente y los datos de los nodos en tiempo real deben considerarse la fuente de referencia.

Épocas y selección de validadores

Las redes Proof of Stake suelen utilizar la información del staking para influir en la asignación de tareas a los validadores.

El protocolo puede tomar una instantánea de los validadores elegibles o del staking antes de que se activen las tareas.

Esto ayuda a impedir que los participantes cambien el staking al instante después de conocer una asignación favorable.

Un calendario de épocas puede establecer el marco temporal para la instantánea, el cálculo de las asignaciones y el periodo de las tareas.

El retraso exacto entre los cambios de staking y la activación de las tareas varía según la blockchain.

Épocas y activación del staking

Es posible que los activos delegados o en staking no se activen inmediatamente después de confirmarse una transacción.

El protocolo puede esperar hasta una época futura o aplicar una cola de activación.

Este retraso permite que la red actualice ordenadamente sus registros de validadores y staking.

La retirada del staking también puede requerir una transición de época, una cola de salida, un periodo de espera o un retraso en la retirada.

Los usuarios deben distinguir entre la confirmación de la transacción y la activación del staking o la elegibilidad para retirar.

Una transacción de staking puede estar finalizada on-chain mientras el staking asociado sigue pendiente conforme a las reglas basadas en épocas.

Épocas y cálculo de recompensas

Muchos sistemas Proof of Stake miden la participación y calculan las recompensas por épocas.

Durante el periodo, la red puede contabilizar las tareas asignadas, los votos correctos, la producción de bloques, el staking delegado, las penalizaciones y las comisiones.

Las recompensas pueden calcularse en el límite de una época, pero abonarse más adelante.

Algunos sistemas distribuyen las recompensas automáticamente, mientras que otros requieren una reclamación o una operación de actualización.

La recompensa estimada de una época no es una tasa garantizada, porque el rendimiento de los validadores y las condiciones de la red pueden variar.

Los usuarios también deben tener en cuenta las comisiones de los operadores, los cambios en el precio del token, los impuestos y las condiciones de retirada.

Épocas y actualizaciones del protocolo

El límite de una época puede proporcionar un punto de activación preciso para una actualización de la blockchain.

Todos los nodos compatibles pueden determinar el punto de activación a partir del mismo calendario del protocolo.

Esto suele ser más previsible que utilizar el número de bloque en una red con tiempos de bloque variables.

Una actualización anunciada para una época concreta se activa cuando la red alcanza esa época en la cadena aceptada.

Los operadores de nodos deben instalar software compatible antes del punto de activación.

Un cliente que siga reglas antiguas puede dejar de sincronizarse o divergir de la red tras la activación.

Calendarios de épocas y gobernanza

Algunos sistemas de gobernanza cripto utilizan épocas como periodos para propuestas, votaciones, ejecución o delegación.

El poder de voto puede medirse en una instantánea de una época o slot concreto.

Una propuesta puede permanecer abierta durante un número determinado de épocas, en lugar de durante un periodo fijo del calendario.

Esto facilita la verificación on-chain de los plazos de gobernanza.

Sin embargo, los usuarios deben comprender el calendario, ya que un plazo expresado solo como número de época puede no resultar claro en tiempo de calendario convencional.

¿Puede cambiar un calendario de épocas?

Un calendario de épocas solo puede cambiar si el protocolo de la blockchain y su proceso de gobernanza lo permiten.

Algunos parámetros del calendario quedan fijados cuando se crea la red.

Otras redes pueden modificar la duración de los slots, la duración de las épocas o las reglas de las tareas mediante una actualización coordinada del protocolo.

Los nodos compatibles deben implementar el cambio de forma coherente para evitar desacuerdos de consenso.

Las aplicaciones no deben codificar permanentemente supuestos temporales cuando la red proporciona una API o una variable del sistema de referencia.

Estimación del final de una época

Una aplicación puede estimar el tiempo que queda de una época combinando el número restante de slots con la duración objetivo de cada slot en la red.

La estimación básica consiste en multiplicar el número de slots restantes por el tiempo objetivo por slot.

Este cálculo es solo una estimación en redes donde el progreso real de los slots puede variar.

Los bloques omitidos no detienen necesariamente la numeración de los slots, ya que estos pueden transcurrir con independencia de que se produzcan bloques correctamente.

Las cuentas atrás deben actualizarse con datos de nodos en tiempo real e identificarse como aproximadas cuando corresponda.

Número de época frente a altura de bloque

Un número de época identifica un grupo de slots del protocolo.

La altura de bloque cuenta los bloques aceptados en la historia de la cadena.

Los valores pueden aumentar a ritmos diferentes porque algunos slots no producen bloques.

Un protocolo también puede crear más de un candidato a bloque en un slot, aunque el consenso acabe aceptando una sola historia de la cadena.

Los desarrolladores deben utilizar el valor correcto para cada tarea, en lugar de convertir la altura de bloque en una época suponiendo que se produce un bloque por slot.

Número de época frente a marca de tiempo

Un número de época es una referencia temporal propia del protocolo.

Una marca de tiempo representa el tiempo del calendario.

Una blockchain puede estimar la marca de tiempo asociada al límite de una época, pero la estimación puede depender de la temporización de los slots y de la cadena aceptada.

Los contratos inteligentes deben evitar tratar el final estimado de una época como una cita exacta fuera de la cadena, salvo que el protocolo garantice esa relación.

Las interfaces pueden mostrar tanto el número de época como una fecha local estimada para mayor claridad.

Datos del calendario de épocas y confianza en RPC

Un endpoint RPC público facilita el acceso a información sobre épocas, pero el usuario confía en que dicho endpoint comunique datos correctos.

Un endpoint no disponible, retrasado o malicioso puede devolver un estado de época obsoleto o incorrecto.

Las aplicaciones pueden comparar varios nodos u operar su propio nodo cuando la información sea crítica para la seguridad.

También deben seleccionar un nivel adecuado de compromiso o finalidad para los datos solicitados.

Un valor observado con un nivel de compromiso bajo puede corresponder a un estado de la cadena que cambie posteriormente.

Uso de datos de épocas en contratos inteligentes

Un programa on-chain debe utilizar la fuente de información de época o reloj aprobada por el protocolo.

No debe confiar en que un usuario cualquiera proporcione la época actual sin verificarla.

Las reglas basadas en épocas deben definir qué ocurre exactamente en un límite.

Los desarrolladores deben probar el último slot de una época y el primero de la siguiente.

También deben probar las épocas históricas de calentamiento cuando la aplicación realice cálculos históricos.

Los errores de desfase de una unidad pueden iniciar o finalizar un periodo de staking, gobernanza o recompensas un slot antes o después de lo previsto.

Riesgos de seguridad de la lógica basada en épocas

Los cálculos incorrectos de épocas pueden provocar errores en recompensas, votaciones, retiradas o controles de acceso.

Un contrato puede utilizar un calendario equivocado después de desplegarse en otra red.

Una aplicación puede suponer que las épocas de calentamiento tienen la duración normal.

Una interfaz puede mostrar un plazo engañoso si convierte los slots a tiempo de reloj utilizando una estimación desactualizada.

Un validador puede incumplir tareas si calcula mal el calendario de líderes.

Un sistema de gobernanza puede aceptar votos fuera del periodo previsto debido a un error en los límites.

El código que dependa de épocas debe utilizar cálculos seguros con enteros, datos de red de referencia y pruebas que cubran las condiciones de los límites.

Cómo pueden utilizar los desarrolladores un calendario de épocas

El primer paso es determinar si la red define las épocas con un número fijo o variable de slots.

El segundo paso es obtener el calendario mediante las API oficiales de los nodos o los datos del sistema.

El tercer paso es tener en cuenta las épocas de calentamiento y la primera época normal, si las hay.

El cuarto paso es distinguir los números de slot absolutos de los índices de slot dentro de una época.

El quinto paso es utilizar información de la época actualizada para mostrar el progreso actual.

El sexto paso es tratar los tiempos de finalización expresados en tiempo de reloj como estimaciones, salvo que el protocolo ofrezca una temporización exacta.

El séptimo paso es probar todos los cálculos cerca de los límites de las épocas.

El octavo paso es supervisar las actualizaciones del protocolo que puedan modificar las reglas pertinentes.

Ejemplo de cálculo de un calendario de épocas

Supongamos que una blockchain Proof of Stake ficticia utiliza 10.000 slots por época después del periodo de calentamiento.

Supongamos que su primera época normal es la época 5 y que el primer slot de esa época es el slot absoluto 9.000.

Los slots absolutos del 9.000 al 18.999 pertenecerían a la época 5.

El slot absoluto 19.000 iniciaría la época 6.

Un índice de slot igual a cero identificaría el primer slot de una época.

Un índice de slot igual a 9.999 identificaría el último slot de una época normal.

Este ejemplo muestra por qué el software necesita tanto el primer slot normal como el número de slots por época.

Las cifras son ilustrativas y no deben aplicarse a una blockchain activa.

Errores habituales con los calendarios de épocas

Un error habitual es suponer que época significa lo mismo en todas las blockchains.

Otro error es tratar un número de slot como si fuera una altura de bloque.

Un tercer error es suponer que todos los slots contienen un bloque.

Un cuarto error es utilizar la duración normal de época para las primeras épocas de calentamiento.

Un quinto error es confundir el calendario de épocas con el calendario de líderes de los validadores.

Un sexto error es tratar la hora estimada de finalización de una época como una garantía exacta.

Un séptimo error es suponer que una transacción de staking se activa inmediatamente después de confirmarse.

Un octavo error es codificar valores del calendario sin comprobar la red conectada.

Un noveno error es confiar en un único endpoint RPC no verificado para un cálculo de época crítico para la seguridad.

Un décimo error es no probar el último y el primer slot en torno al límite de una época.

Preguntas frecuentes

¿Qué significa «calendario de épocas» en cripto?

Un calendario de épocas es el conjunto de reglas de una blockchain que determina cómo se agrupan los slots en épocas y cuándo empieza o termina cada una.

¿Cuál es la diferencia entre una época y un slot?

Un slot es una unidad breve de tiempo de consenso, mientras que una época es un grupo de slots consecutivos.

¿Todos los slots contienen un bloque?

No. Un slot puede transcurrir sin un bloque aceptado si el productor seleccionado está desconectado, llega tarde o no logra producirlo.

¿Todas las blockchains tienen épocas de la misma duración?

No. Cada protocolo blockchain define de forma independiente la duración de las épocas y de los slots.

¿Qué es el calendario de épocas de Solana?

Es la estructura del clúster que asigna slots a épocas y proporciona parámetros para la duración normal de las épocas, el comportamiento de calentamiento y la temporización del calendario de líderes.

¿Qué devuelve getEpochSchedule?

Devuelve

, , , y .

¿getEpochSchedule muestra la época actual?

No. Las aplicaciones de Solana utilizan

para obtener la época actual y la posición dentro de ella.

¿Qué es slotsPerEpoch?

Es el número máximo de slots de cada época de duración normal del clúster consultado.

¿Qué es una época de calentamiento?

Es una época inicial con menos slots que la duración normal completa definida por el calendario.

¿Qué es firstNormalEpoch?

Identifica la primera época que utiliza el número normal completo de slots.

¿Qué es firstNormalSlot?

Identifica el slot absoluto en el que comienza la primera época de duración normal.

¿Qué es leaderScheduleSlotOffset?

Indica con cuánta antelación al límite de una época se calcula el calendario de líderes de los validadores correspondiente.

¿El calendario de épocas es lo mismo que el calendario de líderes?

No. El calendario de épocas define los límites de las épocas, mientras que el calendario de líderes asigna validadores a los slots de producción de bloques.

¿Cuánto dura una época de Ethereum?

Actualmente, Ethereum utiliza 32 slots de doce segundos, por lo que la duración programada de una época es de aproximadamente 6,4 minutos.

¿Cuánto dura una época de Cardano?

La documentación actual de Cardano define 432.000 slots de un segundo por época, lo que corresponde a cinco días.

¿Puede terminar una época sin que todos sus slots produzcan un bloque?

Sí. Los slots pueden seguir avanzando aunque algunos no contengan bloques aceptados.

¿Se reciben recompensas de staking en cada límite de época?

No necesariamente. Las reglas de cálculo, abono, reclamación y retirada varían entre los protocolos blockchain.

¿La activación del staking puede depender de una época?

Sí. Muchos sistemas Proof of Stake aplican los cambios de validadores o delegación tras una transición de época u otro retraso definido por el protocolo.

¿Puede cambiar un calendario de épocas?

Puede cambiar si el protocolo de la blockchain permite una actualización coordinada, aunque algunos parámetros del calendario pueden quedar fijados al crear la red.

¿Pueden calcular los desarrolladores la hora exacta de finalización de una época?

Pueden calcular los slots restantes, pero la estimación en tiempo de calendario puede variar si la temporización real de los slots difiere de la prevista.

¿Por qué las actualizaciones del protocolo utilizan números de época?

Un número de época proporciona un punto de activación determinista on-chain que los nodos compatibles pueden calcular a partir de las mismas reglas de consenso.

¿Pueden los contratos inteligentes leer el calendario de épocas?

Depende de la blockchain. En Solana, los programas pueden acceder a la sysvar EpochSchedule mediante los métodos de runtime compatibles.

¿El número de época es lo mismo que el número de bloque?

No. Una época contiene muchos slots y bloques, y es posible que algunos slots no produzcan bloques.

¿Por qué es importante el calendario de épocas para los validadores?

Les ayuda a comprender los periodos de tareas, las asignaciones de líderes, los cambios de staking, la contabilidad de recompensas y los límites de activación del protocolo.

¿Cuál es la forma más segura de obtener datos de épocas?

Utiliza interfaces oficiales de nodos, verifica la red conectada, selecciona un nivel de compromiso adecuado y compara fuentes de datos independientes cuando la precisión sea crítica.

Conclusión

Un calendario de épocas es la estructura del protocolo que divide el tiempo de la blockchain en slots y épocas.

Crea periodos previsibles para las tareas de los validadores, la rotación de líderes, las actualizaciones de staking, las recompensas, la finalidad, la gobernanza y las actualizaciones de la red.

Una época es un grupo de slots, mientras que un slot es una oportunidad breve para realizar una actividad de consenso, como producir un bloque o votar.

Los slots y los bloques no son lo mismo, porque un slot puede transcurrir sin que se acepte un bloque.

En Solana, Epoch Schedule también es una estructura específica de la red que contiene la duración normal de las épocas, el desplazamiento del calendario de líderes, el estado de calentamiento y los campos de referencia de las épocas normales.

Actualmente, Ethereum utiliza 32 slots de doce segundos por época, mientras que Cardano utiliza 432.000 slots de un segundo por época.

Estas diferencias muestran por qué la temporización de las épocas debe interpretarse siempre según la blockchain conectada.

Los desarrolladores deben obtener datos del calendario de interfaces de nodos de referencia, tener en cuenta el calentamiento y probar todos los cálculos de límites de época.

Los usuarios deben tratar las cuentas atrás del calendario como estimaciones cuando la temporización de los slots pueda variar y no deben suponer que los cambios de staking o las recompensas están disponibles de inmediato en cada límite.

Comprender un calendario de épocas ayuda a los usuarios de criptomonedas a interpretar la temporización de los validadores, los periodos de recompensas, las actualizaciones de la red, los plazos de gobernanza y el ritmo operativo de las blockchains Proof of Stake.