Cronograma de épocas

O que é um cronograma de épocas?

Um cronograma de épocas é o conjunto de regras de uma blockchain que divide o tempo da rede em épocas e unidades menores chamadas slots.

Ele determina como os slots são agrupados, quando uma época termina, quando a próxima começa e quando podem ocorrer eventos da rede baseados em épocas.

Dependendo da blockchain, esses eventos podem incluir designações de validadores, rotação de líderes, atualizações de staking, cálculo de recompensas, snapshots de governança, atualizações do protocolo e mudanças nos parâmetros de consenso.

Um cronograma de épocas geralmente é expresso no tempo do protocolo, e não em datas comuns do calendário.

Por exemplo, uma rede pode definir uma época como um número fixo de slots, em vez de afirmar que cada época dura exatamente dois dias.

A duração no mundo real pode diferir da estimativa quando a produção de slots é mais rápida ou mais lenta do que a taxa prevista.

O termo pode se referir à estrutura temporal geral de qualquer blockchain baseada em épocas.

Ele também tem um significado mais específico na Solana, onde o Epoch Schedule descreve parâmetros do cluster usados para mapear slots para épocas e coordenar cronogramas de líderes.

O que é uma época?

Uma época é um grupo definido de slots consecutivos da blockchain.

Redes Proof of Stake usam épocas para organizar a atividade dos validadores em períodos gerenciáveis.

Em vez de recalcular cada responsabilidade da rede após cada transação, o protocolo pode aplicar certas atualizações em limites de época previsíveis.

Uma época pode servir como período de referência comum para medir a participação dos validadores, calcular recompensas de staking, alterar o status de delegação, rotacionar comitês ou ativar regras do protocolo.

Normalmente, os números das épocas aumentam a partir do início da blockchain.

No entanto, um número de época só tem significado dentro da própria rede, pois a época 500 de uma blockchain não tem relação com a época 500 de outra.

O que é um slot?

Um slot é uma oportunidade curta, definida pelo protocolo, durante a qual se espera ou permite que um validador produza um bloco ou execute outra tarefa de consenso.

Vários slots são agrupados para formar uma época.

Um slot pode passar sem que um bloco seja produzido.

Isso pode ocorrer quando o validador selecionado está offline, o bloco chega tarde demais, a rede rejeita o bloco ou o design de consenso não exige que todo slot contenha um bloco.

Portanto, um número de slot nem sempre corresponde a um número de bloco.

Os aplicativos não devem presumir que cada slot corresponde a um bloco bem-sucedido.

Cronograma de épocas vs. número da época

Um número de época identifica uma época específica no histórico da blockchain.

Um cronograma de épocas define as regras usadas para calcular esse número e determinar os limites da época.

Por exemplo, o cronograma pode especificar quantos slots pertencem a cada época e se as épocas iniciais têm uma duração diferente.

Uma consulta da época atual informa a posição atual da rede.

Uma consulta do cronograma de épocas informa como a estrutura de épocas da rede está organizada.

Por que os cronogramas de épocas são importantes

Os cronogramas de épocas oferecem aos validadores e aplicativos uma estrutura previsível para atividades da blockchain que dependem do tempo.

Os validadores podem se preparar para as próximas tarefas de produção de blocos ou votação.

Quem faz staking pode estimar quando alterações de delegação ou cálculos de recompensas poderão entrar em vigor.

As carteiras podem mostrar o progresso até o limite de uma época.

Os sistemas de monitoramento podem medir o desempenho dos validadores em um período consistente.

Os desenvolvedores podem programar operações que dependam de um número de época ou intervalo de slots.

Os desenvolvedores do protocolo podem ativar algumas atualizações em um limite claramente definido, em vez de depender de um timestamp incerto do relógio convencional.

Como um cronograma de épocas é definido

Um cronograma de épocas geralmente inclui o número de slots por época e a relação entre slots absolutos e números de época.

Alguns cronogramas também descrevem um período de aquecimento no qual as primeiras épocas são mais curtas do que as épocas normais.

Um cronograma pode definir com quanta antecedência são calculadas as designações de liderança ou de comitês dos validadores.

Ele também pode incluir a primeira época e o primeiro slot que usam a duração normal completa.

Esses parâmetros devem ser interpretados de acordo com as regras da blockchain específica.

O mesmo nome de campo pode ter consequências operacionais diferentes em sistemas de consenso distintos.

Duração fixa e variável das épocas

Uma época de duração fixa sempre contém o mesmo número de slots após qualquer período inicial ou de aquecimento.

Um cronograma de duração variável pode alterar o número de slots de acordo com as regras do protocolo, as fases da rede ou um modelo de aumento gradual no início da rede.

Mesmo quando o número de slots é fixo, a duração no mundo real pode não ser perfeitamente fixa.

Uma blockchain com tempos de slot previstos pode apresentar diferenças de duração causadas pelas condições da rede e pelo desempenho dos validadores.

Por isso, os aplicativos devem diferenciar o número de slots por época de uma duração estimada em minutos, horas ou dias.

Limites de época

Um limite de época é a transição entre o último slot de uma época e o primeiro slot da próxima.

Os protocolos costumam usar esses limites como pontos de sincronização para mudanças relacionadas ao consenso.

O conjunto de validadores, a distribuição de staking, o estado das recompensas ou o cronograma de liderança podem ser atualizados no limite ou próximo dele.

Um aplicativo que dependa da transição de época deve usar dados on-chain, em vez de confiar apenas em uma contagem regressiva local.

Atrasos da rede e diferenças no nível de confirmação RPC podem fazer com que dois provedores de dados informem posições atuais ligeiramente diferentes perto de um limite.

Cronograma de épocas na Solana

Na Solana, uma época corresponde ao número de slots durante os quais um cronograma de líderes é válido.

O guia oficial de terminologia da Solana define uma época por sua relação com slots e com o cronograma de líderes.

A Solana disponibiliza um método RPC chamado

, que retorna os parâmetros do cronograma de épocas do cluster.

A documentação oficial de getEpochSchedule lista cinco campos de resposta.

Esses campos são

, , , e .

O método não exige parâmetros de solicitação.

Os desenvolvedores devem consultar o cluster pretendido, em vez de presumir que todas as redes Solana usam os mesmos valores de cronograma.

slotsPerEpoch

O campo

informa o número máximo de slots em uma época de duração normal.

Esse valor é essencial para calcular os limites das épocas após o período de aquecimento.

Se um cluster não usar épocas de aquecimento, a duração normal poderá se aplicar desde a primeira época.

Se o aquecimento estiver ativado, as épocas iniciais poderão conter menos slots antes de o cronograma atingir essa duração completa.

O campo representa uma contagem de slots, não um número garantido de blocos.

Alguns slots podem não produzir blocos aceitos.

leaderScheduleSlotOffset

O campo

descreve com quanta antecedência ao limite de uma época é determinado o cronograma de líderes da época correspondente.

Um cronograma de líderes associa validadores aos slots em que se espera que liderem a produção de blocos.

Determinar o cronograma com antecedência permite que os validadores se preparem para os slots atribuídos.

O deslocamento não deve ser confundido com o número de slots da época, mesmo quando ambos os campos têm o mesmo valor em determinado cluster.

warmup

O campo

é um valor booleano que indica se as primeiras épocas começam com durações menores e aumentam até atingir o tamanho normal.

O valor

significa que o cronograma inclui esse comportamento inicial.

O valor

significa que o cluster não usa épocas de aquecimento com durações crescentes.

Os parâmetros de aquecimento afetam principalmente o período inicial do histórico da rede.

Os aplicativos que calculam limites históricos de épocas devem levar o aquecimento em conta, em vez de aplicar a duração normal a todas as épocas iniciais.

firstNormalEpoch

O campo

identifica a primeira época que usa a contagem completa de slots normal.

Esse campo é especialmente relevante quando

está ativado.

As épocas anteriores a esse ponto podem ter durações progressivamente diferentes.

Os softwares que realizam cálculos históricos devem seguir as regras de aquecimento do cronograma, em vez de subtrair uma quantidade fixa de slots para cada época anterior.

firstNormalSlot

O campo

identifica o slot absoluto em que começa a primeira época de duração normal.

Ele fornece um ponto de referência para mapear números de slots posteriores em épocas normais.

Em conjunto,

e separam a parte de aquecimento do cronograma da parte regular.

Um aplicativo pode usar esses campos para evitar cálculos históricos incorretos de épocas.

Sysvar EpochSchedule da Solana

Programas da Solana podem acessar informações do cronograma de épocas por meio da variável de sistema EpochSchedule, comumente chamada de sysvar.

Uma sysvar fornece informações mantidas pela rede que programas on-chain podem ler durante a execução.

A referência oficial de syscalls da Solana inclui uma syscall para carregar a sysvar EpochSchedule na memória do programa.

Isso permite que um programa on-chain calcule a relação entre épocas e slots sem depender de um site off-chain.

Mesmo assim, um programa deve evitar suposições desnecessárias sobre o tempo convencional, pois o cronograma é expresso em slots.

getEpochSchedule vs. getEpochInfo

retorna os parâmetros estruturais que definem o sistema de épocas do cluster.

retorna a posição atual do nó na época e contadores relacionados.

A documentação oficial de getEpochInfo inclui a época atual, o slot absoluto, o índice do slot, os slots da época atual, a altura do bloco e a contagem de transações, quando disponíveis.

O campo

mostra a posição atual dentro da época.

O campo

informa o número de slots daquela época específica.

Os aplicativos podem combinar os dois métodos para compreender o cronograma e exibir o progresso atual.

Cronograma de épocas vs. cronograma de líderes

Um cronograma de épocas define como os slots são divididos em épocas.

Um cronograma de líderes identifica qual validador foi designado para liderar determinados slots durante uma época.

Os dois conceitos estão relacionados, mas não são intercambiáveis.

O método Solana getLeaderSchedule retorna identidades de validadores e seus índices relativos de slots de liderança para uma época selecionada.

Um aplicativo de monitoramento pode usar o cronograma de épocas para localizar a época e o cronograma de líderes para identificar o produtor de blocos esperado.

Épocas da Solana e recompensas de staking

Na Solana, as épocas são um período contábil para informações importantes de staking.

A rede disponibiliza dados de recompensas por época em seu sistema RPC.

O método getInflationReward retorna informações de recompensas de staking ou votação creditadas em uma época especificada, quando os dados estão disponíveis.

Um registro de recompensa de época pode incluir o número da época, o slot efetivo, o valor creditado, o saldo resultante e informações sobre a comissão do validador.

Uma recompensa associada a uma época não deve ser interpretada como um pagamento fixo garantido.

Os resultados reais de staking dependem das regras da rede, do desempenho do validador, do estado do staking, da comissão e de outras condições do protocolo.

Cronograma de épocas da Ethereum

A Ethereum também organiza o consenso Proof of Stake em slots e épocas.

Atualmente, a Ethereum usa slots de 12 segundos e 32 slots por época.

Isso corresponde a uma duração programada de 384 segundos por época, ou aproximadamente 6,4 minutos.

A documentação oficial de Proof of Stake da Ethereum explica que um validador é selecionado para propor um bloco em cada slot.

Comitês de validadores enviam atestações, e normalmente cada validador ativo recebe uma tarefa de atestação durante cada época.

Um slot pode ficar vazio quando seu proponente selecionado não publica um bloco aceito.

A linha do tempo de slots e épocas continua mesmo quando um bloco deixa de ser produzido.

Épocas da Ethereum e finalização

A Ethereum usa checkpoints de época como parte de seu processo de finalização Proof of Stake.

Os validadores votam nas relações entre checkpoints por meio de suas atestações.

Em condições normais de rede, o apoio suficiente dos validadores pode justificar e finalizar checkpoints em épocas sucessivas.

A finalização dá aos usuários forte confiança de que um bloco não será removido sem uma falha grave de consenso e consequências econômicas significativas.

O limite de uma época não significa que toda transação da época anterior se torna finalizada instantaneamente.

A finalização depende da participação dos validadores e das regras de checkpoint do protocolo.

Épocas da Ethereum e tarefas dos validadores

A Ethereum distribui as responsabilidades dos validadores entre slots e épocas.

Normalmente, um validador faz uma atestação por época.

Um validador também pode ser selecionado para propor um bloco ou participar de um comitê de sincronização.

O desempenho no momento correto é importante, pois tarefas atrasadas ou não cumpridas podem reduzir as recompensas.

O guia de recompensas e penalidades da Ethereum descreve recompensas por votos de source, target e head enviados no prazo, propostas de blocos e participação em comitês de sincronização.

Os operadores de validadores devem monitorar o tempo dos slots, em vez de tratar uma época como um único prazo amplo.

Cronograma de épocas da Cardano

O consenso Proof of Stake da Cardano também divide o tempo em épocas e slots.

A atual documentação do nó Cardano afirma que cada slot dura um segundo e cada época contém 432.000 slots.

Isso corresponde a uma duração programada de cinco dias por época.

Segundo o design de consenso da Cardano, zero ou mais nós produtores de blocos podem ser selecionados em um slot.

A rede não precisa produzir um bloco em cada slot de um segundo.

O guia de consenso da Cardano explica que agrupar slots em épocas dá suporte à seleção de líderes com base na distribuição de staking, que pode mudar.

Os cronogramas de épocas variam entre blockchains

Não existe uma duração universal de época compartilhada por todas as criptomoedas.

As épocas da Ethereum duram minutos, enquanto outras redes podem usar períodos medidos em horas ou dias.

Algumas redes vinculam estreitamente as épocas à finalização e à rotação de comitês.

Outras as usam principalmente para cronogramas de líderes, contabilidade de staking, atualizações de delegação ou distribuição de recompensas.

Uma carteira ou um aplicativo de staking nunca deve aplicar a uma blockchain as suposições sobre épocas de outra.

A documentação do protocolo pertinente e os dados de nós ativos devem ser considerados fontes de referência.

Épocas e seleção de validadores

Redes Proof of Stake costumam usar informações de staking para influenciar quais validadores recebem tarefas.

O protocolo pode tirar um snapshot de validadores elegíveis ou do staking antes que as tarefas sejam ativadas.

Isso ajuda a impedir que os participantes alterem o staking instantaneamente depois de conhecer uma designação favorável.

Um cronograma de épocas pode fornecer a estrutura temporal para o snapshot, o cálculo das designações e o período das tarefas.

O intervalo exato entre alterações de staking e tarefas ativas varia entre blockchains.

Épocas e ativação de staking

Ativos delegados ou em staking podem não se tornar ativos imediatamente após a confirmação de uma transação.

O protocolo pode aguardar até uma época futura ou aplicar uma fila de ativação.

Esse atraso permite que a rede atualize seus registros de validadores e de staking de forma ordenada.

O unstaking também pode exigir uma transição de época, fila de saída, período de espera ou atraso de saque.

Os usuários devem diferenciar a confirmação da transação da ativação do staking ou da elegibilidade para saque.

Uma transação de staking pode ser finalizada on-chain enquanto o staking associado ainda está pendente segundo as regras baseadas em épocas.

Épocas e cálculo de recompensas

Muitos sistemas Proof of Stake medem a participação e calculam recompensas por épocas.

A rede pode contabilizar tarefas atribuídas, votos bem-sucedidos, produção de blocos, staking delegado, penalidades e comissões durante o período.

As recompensas podem ser calculadas no limite de uma época e creditadas posteriormente.

Alguns sistemas distribuem recompensas automaticamente, enquanto outros exigem uma solicitação de resgate ou uma operação de atualização.

Uma recompensa estimada por época não é uma taxa garantida, pois o desempenho dos validadores e as condições da rede podem variar.

Os usuários também devem considerar taxas do operador, variações no preço do token, impostos e condições de saque.

Épocas e atualizações de protocolo

O limite de uma época pode oferecer um ponto de ativação preciso para uma atualização da blockchain.

Todos os nós compatíveis podem determinar o ponto de ativação com base no mesmo cronograma do protocolo.

Isso costuma ser mais previsível do que usar um número de bloco em uma rede com tempos de bloco variáveis.

Uma atualização anunciada para determinada época entra em vigor quando a rede alcança essa época na cadeia aceita.

Os operadores de nós devem instalar software compatível antes do ponto de ativação.

Um cliente que continue seguindo as regras antigas pode parar de sincronizar ou divergir da rede após a ativação.

Cronogramas de épocas e governança

Alguns sistemas de governança cripto usam épocas como períodos de propostas, votação, execução ou delegação.

O poder de voto pode ser medido em um snapshot de determinada época ou slot.

Uma proposta pode permanecer aberta por um número definido de épocas, em vez de um período fixo do calendário.

Isso facilita a verificação on-chain do cronograma de governança.

No entanto, os usuários precisam entender o cronograma, pois um prazo expresso apenas como número de época pode não ser claro no tempo comum do calendário.

Um cronograma de épocas pode mudar?

Um cronograma de épocas só pode mudar quando o protocolo da blockchain e o processo de governança permitem essa alteração.

Alguns parâmetros do cronograma são fixados quando a rede é criada.

Outras redes podem modificar a duração dos slots, das épocas ou as regras das tarefas por meio de uma atualização coordenada do protocolo.

A mudança deve ser implementada de forma consistente pelos nós compatíveis para evitar divergências de consenso.

Os aplicativos não devem codificar permanentemente as suposições de tempo quando a rede oferece uma API ou variável de sistema oficial.

Como estimar o fim de uma época

Um aplicativo pode estimar o tempo restante de uma época combinando a quantidade de slots restantes com a duração-alvo de cada slot na rede.

A estimativa básica é o número de slots restantes multiplicado pelo tempo-alvo de cada slot.

Esse cálculo é apenas uma estimativa em redes nas quais o avanço real dos slots pode variar.

A ausência de blocos não necessariamente interrompe a numeração dos slots, pois os slots podem passar independentemente da produção bem-sucedida de blocos.

Uma contagem regressiva deve ser atualizada com dados de nós ativos e identificada como aproximada quando apropriado.

Número da época vs. altura do bloco

Um número de época identifica um grupo de slots do protocolo.

A altura do bloco conta os blocos aceitos no histórico da cadeia.

Os valores podem aumentar em ritmos diferentes porque alguns slots não produzem blocos.

Um protocolo também pode criar mais de um candidato a bloco em um slot, embora o consenso acabe aceitando um histórico da cadeia.

Os desenvolvedores devem usar o valor correto para cada tarefa, em vez de converter a altura do bloco em época com base na suposição de que há um bloco por slot.

Número da época vs. timestamp

Um número de época é uma referência temporal nativa do protocolo.

Um timestamp representa o tempo do calendário.

Uma blockchain pode estimar o timestamp associado ao limite de uma época, mas a estimativa pode depender do tempo dos slots e da cadeia aceita.

Os contratos inteligentes devem evitar tratar o fim estimado de uma época como um compromisso exato fora da blockchain, a menos que o protocolo garanta essa relação.

As interfaces podem exibir o número da época e uma data local estimada para maior clareza.

Dados do cronograma de épocas e confiança em RPC

Um endpoint RPC público oferece acesso conveniente às informações de época, mas o usuário confia que esse endpoint forneça dados precisos.

Um endpoint indisponível, atrasado ou malicioso pode retornar um status de época desatualizado ou incorreto.

Os aplicativos podem comparar vários nós ou operar o próprio nó quando a informação for essencial para a segurança.

Também devem selecionar um nível adequado de confirmação ou finalização para os dados solicitados.

Um valor observado com baixo nível de confirmação pode refletir um estado da cadeia que mudará posteriormente.

Uso de dados de época em contratos inteligentes

Um programa on-chain deve usar a fonte aprovada pelo protocolo para obter informações de época ou de relógio.

Ele não deve confiar que um usuário forneça a época atual sem verificá-la.

As regras baseadas em épocas devem definir o que acontece exatamente em um limite.

Os desenvolvedores devem testar o último slot de uma época e o primeiro slot da seguinte.

Também devem testar épocas históricas de aquecimento quando o aplicativo fizer cálculos históricos.

Erros de uma unidade podem iniciar ou encerrar um período de staking, governança ou recompensas um slot antes ou depois do previsto.

Riscos de segurança da lógica baseada em épocas

Cálculos incorretos de épocas podem causar erros em recompensas, votação, saques ou controle de acesso.

Um contrato pode usar o cronograma errado depois de ser implantado em outra rede.

Um aplicativo pode presumir que as épocas têm duração normal durante um período de aquecimento.

Uma interface pode exibir um prazo enganoso ao converter slots em tempo convencional usando uma estimativa desatualizada.

Um validador pode deixar de cumprir tarefas após calcular incorretamente o cronograma de líderes.

Um sistema de governança pode aceitar votos fora do período previsto devido a um erro de limite.

O código que depende de épocas deve usar cálculos seguros com números inteiros, dados oficiais da rede e testes que cubram as condições dos limites.

Como os desenvolvedores podem usar um cronograma de épocas

O primeiro passo é identificar se a rede define épocas com um número fixo ou variável de slots.

O segundo é obter o cronograma por meio de APIs oficiais de nós ou de dados do sistema.

O terceiro é levar em conta as épocas de aquecimento e a primeira época normal, quando existirem.

O quarto é diferenciar números absolutos de slots de índices de slots dentro de uma época.

O quinto é usar informações de época em tempo real ao exibir o progresso atual.

O sexto é tratar os horários de conclusão no relógio convencional como estimativas, a menos que o protocolo forneça horários exatos.

O sétimo é testar todos os cálculos nos limites entre épocas.

O oitavo é acompanhar as atualizações de protocolo que possam alterar as regras pertinentes.

Exemplo de cálculo de cronograma de épocas

Suponha que uma blockchain Proof of Stake fictícia use 10.000 slots por época após o período de aquecimento.

Suponha que sua primeira época normal seja a época 5 e que o primeiro slot dessa época seja o slot absoluto 9.000.

Os slots absolutos de 9.000 a 18.999 pertenceriam à época 5.

O slot absoluto 19.000 iniciaria a época 6.

Um índice de slot igual a zero identificaria o primeiro slot de uma época.

Um índice de slot igual a 9.999 identificaria o último slot de uma época normal.

Este exemplo mostra por que o software precisa conhecer o primeiro slot normal, além do número de slots por época.

Os números são ilustrativos e não devem ser aplicados a uma blockchain ativa.

Erros comuns sobre cronogramas de épocas

Um erro comum é presumir que “época” tem a mesma duração em todas as blockchains.

Outro é tratar um número de slot como altura do bloco.

Um terceiro é presumir que todo slot contém um bloco.

Um quarto é usar a duração normal da época para as primeiras épocas de aquecimento.

Um quinto é confundir um cronograma de épocas com um cronograma de líderes validadores.

Um sexto é tratar o horário estimado de fim da época como uma garantia exata.

Um sétimo é presumir que uma transação de staking se torna ativa imediatamente após a confirmação.

Um oitavo é codificar valores do cronograma sem verificar a rede conectada.

Um nono é depender de um único endpoint RPC não verificado para um cálculo de época essencial para a segurança.

Um décimo é não testar o último e o primeiro slots em torno do limite de uma época.

Perguntas frequentes

O que significa cronograma de épocas em cripto?

Um cronograma de épocas é o conjunto de regras da blockchain que determina como os slots são agrupados em épocas e quando cada época começa ou termina.

Qual é a diferença entre uma época e um slot?

Um slot é uma unidade curta de tempo de consenso, enquanto uma época é um grupo de slots consecutivos.

Todo slot contém um bloco?

Não. Um slot pode passar sem um bloco aceito se o produtor selecionado estiver offline, se atrasar ou não tiver sucesso.

Uma época tem a mesma duração em todas as blockchains?

Não. A duração das épocas e dos slots é definida separadamente por cada protocolo de blockchain.

O que é o Epoch Schedule da Solana?

É a estrutura do cluster que mapeia slots para épocas e fornece parâmetros para a duração normal da época, o comportamento de aquecimento e o momento do cronograma de líderes.

O que getEpochSchedule retorna?

Retorna

, , , e .

getEpochSchedule mostra a época atual?

Não. Os aplicativos da Solana usam

para obter a época atual e a posição dentro dela.

O que é slotsPerEpoch?

É o número máximo de slots em cada época de duração normal do cluster consultado.

O que é uma época de aquecimento?

É uma época inicial com menos slots do que a duração normal completa prevista no cronograma.

O que é firstNormalEpoch?

Identifica a primeira época que usa o número normal completo de slots.

O que é firstNormalSlot?

Identifica o slot absoluto em que começa a primeira época de duração normal.

O que é leaderScheduleSlotOffset?

Indica com quanta antecedência ao limite de uma época é calculado o cronograma de líderes validadores correspondente.

Um cronograma de épocas é igual a um cronograma de líderes?

Não. O cronograma de épocas define os limites das épocas, enquanto o cronograma de líderes associa validadores aos slots de produção de blocos.

Quanto dura uma época da Ethereum?

Atualmente, a Ethereum usa 32 slots de doze segundos, o que corresponde a uma duração programada de aproximadamente 6,4 minutos por época.

Quanto dura uma época da Cardano?

A documentação atual da Cardano define 432.000 slots de um segundo por época, o que corresponde a cinco dias.

Uma época pode terminar sem que todos os slots produzam um bloco?

Sim. O avanço dos slots pode continuar mesmo quando alguns não contêm blocos aceitos.

As recompensas de staking são pagas a cada limite de época?

Não necessariamente, pois as regras de cálculo, crédito, resgate e saque variam entre os protocolos de blockchain.

A ativação do staking pode depender de uma época?

Sim. Muitos sistemas Proof of Stake aplicam alterações de validadores ou delegação somente após uma transição de época ou outro atraso definido pelo protocolo.

Um cronograma de épocas pode mudar?

Ele pode mudar quando o protocolo da blockchain permite uma atualização coordenada, embora alguns parâmetros possam ser definidos na criação da rede.

Os desenvolvedores podem calcular um horário exato para o fim de uma época?

É possível calcular os slots restantes, mas a estimativa do horário no calendário pode variar quando o tempo real dos slots difere do previsto.

Por que as atualizações de protocolo usam números de época?

Um número de época fornece um ponto de ativação determinístico on-chain, que os nós compatíveis podem calcular com base nas mesmas regras de consenso.

Os contratos inteligentes podem ler o cronograma de épocas?

Isso depende da blockchain. Na Solana, os programas podem acessar a sysvar EpochSchedule por meio dos métodos de runtime compatíveis.

O número de uma época é igual ao número de um bloco?

Não. Uma época contém muitos slots e blocos, e alguns slots podem não produzir blocos.

Por que o cronograma de épocas é importante para os validadores?

Ele ajuda os validadores a entender períodos de tarefas, designações de liderança, alterações de staking, contabilidade de recompensas e limites de ativação de protocolos.

Qual é a forma mais segura de obter dados de época?

Use interfaces oficiais de nós, verifique a rede conectada, selecione um nível adequado de confirmação e compare fontes de dados independentes quando a precisão for essencial.

Conclusão

Um cronograma de épocas é a estrutura do protocolo que divide o tempo da blockchain em slots e épocas.

Ele cria períodos previsíveis para tarefas de validadores, rotação de líderes, atualizações de staking, recompensas, finalização, governança e atualizações da rede.

Uma época é um grupo de slots, enquanto um slot é uma oportunidade curta para atividades de consenso, como produção de blocos ou votação.

Slots e blocos não são a mesma coisa, pois um slot pode passar sem que haja um bloco aceito.

Na Solana, Epoch Schedule também é uma estrutura específica da rede que contém a duração normal da época, o deslocamento do cronograma de líderes, o status de aquecimento e os campos de referência para épocas normais.

Atualmente, a Ethereum usa 32 slots de doze segundos por época, enquanto a Cardano usa 432.000 slots de um segundo por época.

Essas diferenças mostram por que o tempo das épocas deve sempre ser interpretado de acordo com a blockchain conectada.

Os desenvolvedores devem obter dados do cronograma por meio de interfaces oficiais de nós, levar em conta o aquecimento e testar todos os cálculos de limites de época.

Os usuários devem tratar contagens regressivas do calendário como estimativas quando o tempo dos slots puder variar e não devem presumir que alterações de staking ou recompensas ficam disponíveis imediatamente em cada limite.

Compreender um cronograma de épocas ajuda os usuários de cripto a interpretar o tempo dos validadores, os períodos de recompensa, as atualizações de rede, os prazos de governança e o ritmo operacional das blockchains Proof of Stake.