Skip to main content
Метод RPC getLeaderSchedule возвращает распределение ролей лидера по созданию блоков между валидаторами для определенной эпохи. Расписание лидеров можно использовать для анализа сети, прогнозирования того, какой валидатор будет создавать блоки в определенное время, а также в инструментах, взаимодействующих с конкретными лидерами.

Распространенные сценарии использования

  • Мониторинг сети: Отслеживайте распределение слотов лидеров между валидаторами в течение эпохи.
  • Маршрутизация транзакций (для продвинутых сценариев): Некоторые продвинутые приложения могут пытаться направлять транзакции текущему или следующему лидеру, хотя обычно этим занимаются сеть и узлы RPC.
  • Анализ производительности валидаторов: Сопоставляйте расписание лидеров с фактическим созданием блоков, чтобы оценивать время бесперебойной работы и производительность валидаторов.
  • Отслеживание хода эпохи: Узнавайте, какие валидаторы отвечают за создание блоков на протяжении эпохи.

Параметры запроса

Метод принимает до двух необязательных параметров:
  1. slot (u64, необязательный): Номер слота. Если он указан, будет получено расписание лидеров для эпохи, содержащей этот слот. Если указано значение null или параметр пропущен, будет получено расписание лидеров для текущей эпохи.
  2. config (объект, необязательный): Объект конфигурации, который может содержать:
    • commitment (строка, необязательный): Задает уровень подтверждения. Если параметр не указан, используется уровень подтверждения узла по умолчанию.
    • identity (строка, необязательный): Публичный ключ валидатора в кодировке base58. Если он указан, возвращаемое расписание будет содержать только слоты, назначенные этому валидатору.

Структура ответа

Поле result ответа JSON-RPC будет содержать:
  • null: Если эпоха, соответствующая запрошенному значению slot (или текущая эпоха, если слот не указан), не найдена либо ее расписание лидеров недоступно (например, для будущей, еще не рассчитанной эпохи).
  • Объект: Если расписание найдено. Этот объект представляет собой отображение, в котором:
    • Каждый ключ — это публичный ключ (идентификатор) валидатора в кодировке base58.
    • Соответствующее значение — это массив чисел. Каждое число представляет собой индекс слота относительно начала эпохи, в котором этот валидатор является лидером.
Например, если эпоха начинается со слота 1000, а расписание валидатора содержит [0, 1, 5], это означает, что данный валидатор является лидером для слотов 1000, 1001 и 1005.

Примеры

1. Получение расписания лидеров для текущей эпохи

В этом примере запрашивается полное расписание лидеров для текущей эпохи.

2. Получение расписания лидеров для определенного валидатора в определенной эпохе (по слоту)

В этом примере запрашивается расписание лидеров для валидатора с заданным идентификатором в эпохе, содержащей слот 200000.

Рекомендации разработчикам

  • Границы эпохи: Расписание лидеров фиксируется на всю эпоху. Чтобы определить начальный и конечный слоты эпохи, используйте getEpochInfo.
  • Будущие эпохи: Запрос расписания для далекой будущей эпохи может вернуть null, если сеть еще не рассчитала это расписание.
  • Относительные индексы слотов: Помните, что номера слотов в ответе указаны относительно первого слота запрошенной эпохи, а не являются абсолютными номерами слотов в блокчейне.
  • Большой ответ: Если запросить полное расписание эпохи без фильтра по идентификатору, ответ может быть большим и содержать список всех валидаторов и назначенных им слотов.
В этом руководстве представлена необходимая информация об использовании getLeaderSchedule для запроса распределения ролей производителей блоков в любой заданной эпохе сети Solana.

Связанные методы

getEpochInfo

Получение информации о текущей эпохе, включая границы слотов

getSlotLeaders

Получение лидеров для определенного диапазона слотов