Skip to main content
La méthode RPC getEpochSchedule renvoie les informations du calendrier des époques à partir de la configuration initiale du cluster. Ces données définissent comment les époques sont structurées, y compris leur durée et comment le calendrier des leaders est déterminé par rapport au début d’une époque. Comprendre le calendrier des époques est crucial pour les applications qui doivent s’aligner sur les événements du réseau, prédire les limites des époques ou comprendre le mécanisme de rotation des leaders.

Cas d’utilisation courants

  • Prédiction des limites des époques : Déterminez le nombre de slots dans une époque pour estimer quand l’époque actuelle se terminera et la suivante commencera.
  • Calcul du calendrier des leaders : Comprendre leaderScheduleSlotOffset pour savoir combien de temps à l’avance les calendriers des leaders sont générés pour une époque à venir.
  • Analyse de l’initialisation du réseau : Observer warmup, firstNormalEpoch et firstNormalSlot pour comprendre la phase initiale de montée en régime de la durée des époques du cluster, le cas échéant.
  • Création d’outils de surveillance du réseau : Utilisez cette information pour afficher avec précision le timing et la progression des époques.

Paramètres de requête

Cette méthode ne prend aucun paramètre.

Structure de la réponse

Le champ result de la réponse JSON-RPC sera un objet contenant les champs suivants :
  • slotsPerEpoch (u64) : Le nombre maximum de slots dans chaque époque (après la période de rodage, le cas échéant).
  • leaderScheduleSlotOffset (u64) : Le nombre de slots avant le début d’une époque pour lesquels le calendrier des leaders pour cette époque est généré.
  • warmup (boolean) : Un booléen indiquant si le cluster a une période de rodage où les époques commencent plus courtes et augmentent progressivement en durée.
  • firstNormalEpoch (u64) : Le premier numéro d’époque qui a la durée complète slotsPerEpoch. Ceci est pertinent si warmup est vrai.
  • firstNormalSlot (u64) : L’index du slot du premier slot dans firstNormalEpoch. Ceci est pertinent si warmup est vrai.

Exemples

1. Obtenez le calendrier des époques pour le cluster

Cet exemple récupère le calendrier des époques.

Conseils pour les développeurs

  • Information statique : Le calendrier des époques est déterminé par la configuration initiale du cluster et ne change généralement pas à moins qu’il y ait une mise à niveau majeure du réseau ou le lancement d’un nouveau cluster avec des paramètres différents.
  • Mainnet vs. Testnet/Devnet : Le calendrier des époques, en particulier slotsPerEpoch et les paramètres de rodage, peut différer significativement entre Mainnet Beta, Testnet et Devnet. Interrogez toujours le cluster spécifique qui vous intéresse.
  • Période de rodage : Si warmup est true, les époques avant firstNormalEpoch auront moins de slots que slotsPerEpoch. Le calcul exact pour les durées des époques de rodage est 2^N * MINIMUM_SLOTS_PER_EPOCH où N est le numéro de l’époque (commençant à 0) jusqu’à ce que firstNormalEpoch soit atteint. MINIMUM_SLOTS_PER_EPOCH est généralement 32.
Ce guide fournit les informations nécessaires pour utiliser la méthode RPC getEpochSchedule pour comprendre la synchronisation fondamentale et la structure des époques au sein d’un cluster Solana.