График эпох

Что такое график эпох?

График эпох — это набор правил блокчейна, определяющий, как сетевое время делится на эпохи и более мелкие единицы, называемые слотами.

Он определяет группировку слотов, момент завершения одной эпохи и начала следующей, а также время событий сети, привязанных к эпохам.

В зависимости от блокчейна к таким событиям могут относиться назначение валидаторов, смена лидеров, обновления стейкинга, расчет вознаграждений, снимки состояния для голосования, обновления протокола и изменение параметров консенсуса.

График эпох обычно выражается во времени протокола, а не в обычных календарных датах.

Например, сеть может определить эпоху как фиксированное количество слотов, а не указать, что каждая эпоха длится ровно два дня.

Фактическая продолжительность может отличаться от расчетной, если создание слотов происходит быстрее или медленнее целевого темпа.

Этот термин может обозначать общую структуру времени в любом блокчейне, использующем эпохи.

В Solana у него также есть более конкретное значение: Epoch Schedule описывает параметры кластера, используемые для сопоставления слотов с эпохами и координации графиков лидеров.

Что такое эпоха?

Эпоха — это определенная группа последовательных слотов блокчейна.

Блокчейны на Proof of Stake используют эпохи для организации работы валидаторов на управляемые периоды.

Вместо пересчета каждой сетевой обязанности после каждой транзакции протокол может применять определенные обновления в предсказуемые моменты между эпохами.

Эпоха может служить общим периодом для измерения участия валидаторов, расчета вознаграждений за стейкинг, изменения статуса делегирования, ротации комитетов или активации правил протокола.

Нумерация эпох обычно начинается с начала истории блокчейна и последовательно увеличивается.

Однако номер эпохи имеет значение только в пределах своей сети: эпоха 500 в одном блокчейне не связана с эпохой 500 в другом.

Что такое слот?

Слот — это короткий определенный протоколом промежуток, в течение которого валидатор может быть обязан или уполномочен создать блок либо выполнить другую задачу консенсуса.

Несколько слотов объединяются в одну эпоху.

Слот может пройти без создания блока.

Это может произойти, если выбранный валидатор отключен от сети, блок поступил слишком поздно, сеть отклонила его или механизм консенсуса не требует наличия блока в каждом слоте.

Поэтому номер слота не всегда совпадает с номером блока.

Приложениям не следует предполагать, что каждому слоту соответствует один успешно созданный блок.

График эпох и номер эпохи

Номер эпохи обозначает конкретную эпоху в истории блокчейна.

График эпох определяет правила расчета этого номера и границ эпох.

Например, график может указывать, сколько слотов входит в каждую эпоху и отличаются ли по длительности первые эпохи.

Запрос текущей эпохи сообщает приложению, на каком этапе находится сеть сейчас.

Запрос графика эпох сообщает приложению, как устроена структура эпох в сети.

Почему важен график эпох

График эпох дает валидаторам и приложениям предсказуемую основу для действий блокчейна, зависящих от времени.

Валидаторы могут готовиться к предстоящим обязанностям по созданию блоков или голосованию.

Участники стейкинга могут оценить, когда вступят в силу изменения делегирования или расчеты вознаграждений.

Кошельки могут показывать прогресс до границы эпохи.

Системы мониторинга могут оценивать работу валидаторов за единый период.

Разработчики могут планировать операции, зависящие от номера эпохи или диапазона слотов.

Разработчики протоколов могут активировать некоторые обновления в четко определенный момент, а не полагаться на неточную отметку обычного времени.

Как определяется график эпох

График эпох обычно включает количество слотов в одной эпохе и связь между абсолютными номерами слотов и номерами эпох.

Некоторые графики также описывают начальный период разгона, во время которого первые эпохи короче обычных.

График может определять, насколько заранее рассчитываются назначения лидеров или комитетов валидаторов.

В него также могут входить первая эпоха и первый слот, для которых применяется обычная полная продолжительность эпохи.

Эти параметры необходимо интерпретировать в соответствии с правилами конкретного блокчейна.

Одно и то же название поля может иметь разные операционные последствия в разных системах консенсуса.

Фиксированная и переменная продолжительность эпох

После начального периода запуска или разгона эпоха с фиксированной продолжительностью всегда содержит одинаковое количество слотов.

В графике с переменной продолжительностью число слотов может меняться в соответствии с правилами протокола, этапами развития сети или механизмом постепенного разгона сети.

Даже при фиксированном количестве слотов фактическая продолжительность эпохи в календарном времени может быть непостоянной.

В блокчейне с целевым временем слота могут возникать отклонения из-за состояния сети и производительности валидаторов.

Поэтому приложениям следует различать количество слотов в эпохе и примерную продолжительность в минутах, часах или днях.

Границы эпох

Граница эпохи — это переход от последнего слота одной эпохи к первому слоту следующей.

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

Набор валидаторов, распределение стейка, состояние вознаграждений или график лидеров могут обновляться на границе эпохи или около нее.

Приложению, зависящему от перехода между эпохами, следует использовать ончейн-данные, а не только локальный таймер обратного отсчета.

Сетевые задержки и различия в уровне подтверждения RPC могут привести к тому, что два поставщика данных сообщат немного разные текущие позиции около границы эпохи.

График эпох в Solana

В Solana эпоха — это период, в течение которого действует график лидеров для определенного числа слотов.

Официальное руководство по терминологии Solana определяет эпоху через ее связь со слотами и графиком лидеров.

В Solana есть RPC-метод

, который возвращает параметры графика эпох кластера.

В официальной документации getEpochSchedule перечислены пять полей ответа.

Это поля

, , , и .

Методу не требуются параметры запроса.

Разработчикам следует запрашивать данные нужного кластера, а не предполагать, что во всех сетях Solana используются одинаковые значения графика.

slotsPerEpoch

Поле

указывает максимальное количество слотов в эпохе обычной продолжительности.

Это значение необходимо для расчета границ эпох после периода разгона.

Если в кластере нет эпох разгона, обычная продолжительность может применяться с первой эпохи.

Если разгон предусмотрен, в первых эпохах может быть меньше слотов, пока их количество не достигнет полного значения.

Поле содержит количество слотов, а не гарантированное число блоков.

Некоторые слоты могут пройти без включения блока в цепочку.

leaderScheduleSlotOffset

Поле

описывает, насколько заранее до границы эпохи определяется график лидеров для соответствующей эпохи.

График лидеров сопоставляет валидаторов со слотами, в которых они должны создавать блоки.

Заблаговременный расчет графика позволяет валидаторам подготовиться к назначенным слотам.

Это смещение не следует путать с количеством слотов в эпохе, даже если в конкретном кластере значения обоих полей совпадают.

warmup

Поле

— это булево значение, указывающее, начинаются ли ранние эпохи с меньшей продолжительности и постепенно увеличиваются ли они до обычного размера.

Значение

означает, что график предусматривает такое поведение на начальном этапе.

Значение

означает, что в кластере не используются эпохи разгона с постепенно увеличивающейся продолжительностью.

Параметры разгона в основном влияют на начальный период истории сети.

При расчете исторических границ эпох приложениям нужно учитывать разгон, а не применять обычную продолжительность ко всем ранним эпохам.

firstNormalEpoch

Поле

обозначает первую эпоху, в которой используется полное обычное количество слотов.

Это поле особенно важно, если для

задано значение .

До этого момента продолжительность эпох может постепенно меняться.

При исторических расчетах программному обеспечению следует использовать правила разгона, а не вычитать фиксированное количество слотов для каждой более ранней эпохи.

firstNormalSlot

Поле

обозначает абсолютный номер слота, с которого начинается первая эпоха обычной продолжительности.

Оно служит опорной точкой для сопоставления последующих номеров слотов с обычными эпохами.

Поля

и вместе отделяют период разгона от регулярной части графика.

Приложение может использовать эти поля, чтобы избежать ошибок при расчете исторических эпох.

Системная переменная EpochSchedule в Solana

Программы Solana могут получать сведения о графике эпох через системную переменную EpochSchedule, которую обычно называют sysvar.

Sysvar предоставляет поддерживаемые сетью данные, доступные ончейн-программам во время выполнения.

В официальном справочнике системных вызовов Solana есть системный вызов для загрузки sysvar EpochSchedule в память программы.

Это позволяет ончейн-программе рассчитывать связь эпох и слотов, не полагаясь на офчейн-сайт.

При этом программе следует избегать необоснованных предположений о календарном времени, поскольку график выражен в слотах.

getEpochSchedule и getEpochInfo

возвращает структурные параметры, определяющие систему эпох кластера.

возвращает текущую позицию узла в эпохе и связанные счетчики.

В официальной документации getEpochInfo указаны текущая эпоха, абсолютный номер слота, индекс слота, количество слотов в текущей эпохе, высота блока и число транзакций, если эти данные доступны.

Поле

показывает текущую позицию внутри эпохи.

Поле

указывает количество слотов именно в этой эпохе.

Приложения могут использовать оба метода, чтобы понять структуру графика и отображать текущий прогресс.

График эпох и график лидеров

График эпох определяет, как слоты распределяются по эпохам.

График лидеров указывает, какой валидатор назначен лидером для конкретных слотов эпохи.

Эти понятия связаны, но не взаимозаменяемы.

Метод Solana getLeaderSchedule возвращает идентификаторы валидаторов и относительные индексы слотов, в которых они становятся лидерами, для выбранной эпохи.

Приложение для мониторинга может использовать график эпох, чтобы определить нужную эпоху, и график лидеров, чтобы узнать предполагаемого производителя блока.

Эпохи Solana и вознаграждения за стейкинг

В Solana эпохи служат периодами учета важных данных о стейкинге.

Сеть предоставляет через RPC-систему данные о вознаграждениях по эпохам.

Метод getInflationReward возвращает сведения о вознаграждениях за стейкинг или голосование, начисленных за указанную эпоху, если данные доступны.

Запись о вознаграждении за эпоху может содержать номер эпохи, эффективный слот, начисленную сумму, итоговый баланс и сведения о комиссии валидатора.

Вознаграждение за эпоху не следует считать гарантированной фиксированной выплатой.

Фактический результат стейкинга зависит от правил сети, работы валидатора, состояния стейка, комиссии и других условий протокола.

График эпох Ethereum

Ethereum также делит работу консенсуса Proof of Stake на слоты и эпохи.

В настоящее время в Ethereum используется 12-секундный интервал слота и 32 слота в одной эпохе.

Таким образом, расчетная продолжительность одной эпохи составляет 384 секунды, или примерно 6,4 минуты.

В официальной документации Ethereum о Proof of Stake объясняется, что для каждого слота выбирается один валидатор, предлагающий блок.

Комитеты валидаторов отправляют аттестации, и каждый активный валидатор обычно получает обязанность по аттестации в течение каждой эпохи.

Слот может остаться пустым, если выбранный предлагающий блок валидатор не опубликует принятый блок.

Отсчет слотов и эпох продолжается, даже если блок пропущен.

Эпохи Ethereum и финализация

Ethereum использует контрольные точки эпох в процессе финализации Proof of Stake.

Валидаторы голосуют за связи между контрольными точками с помощью аттестаций.

При нормальных условиях достаточная поддержка валидаторов позволяет обосновать и финализировать контрольные точки на протяжении последовательных эпох.

Финализация дает пользователям высокую уверенность в том, что блок не будет удален без серьезного сбоя консенсуса и существенных экономических последствий.

Граница эпохи не означает, что каждая транзакция предыдущей эпохи сразу становится финализированной.

Финализация зависит от участия валидаторов и правил протокола для контрольных точек.

Эпохи Ethereum и обязанности валидаторов

Ethereum распределяет обязанности валидаторов по слотам и эпохам.

Валидатор обычно отправляет аттестацию один раз за эпоху.

Валидатор также может быть выбран для предложения блока или участия в sync-комитете.

Своевременное выполнение обязанностей важно, поскольку опоздания или пропуски могут уменьшить вознаграждения.

В руководстве Ethereum по вознаграждениям и штрафам описаны вознаграждения за своевременные голоса source, target и head, предложение блоков и участие в sync-комитетах.

Операторам валидаторов следует отслеживать время слотов, а не считать эпоху одним общим сроком.

График эпох Cardano

Механизм консенсуса Cardano на Proof of Stake также делит время на эпохи и слоты.

В актуальной документации узла Cardano указано, что один слот длится одну секунду, а в одной эпохе содержится 432,000 слотов.

Расчетная продолжительность эпохи составляет пять дней.

Согласно механизму консенсуса Cardano в каждом слоте может быть выбрано ноль или несколько узлов, создающих блоки.

Сети не требуется создавать блок в каждом односекундном слоте.

В руководстве Cardano по консенсусу объясняется, что группировка слотов в эпохи поддерживает выбор лидеров с учетом меняющегося распределения стейка.

Графики эпох различаются в разных блокчейнах

У всех криптовалют нет общей продолжительности эпох.

Эпохи Ethereum длятся минуты, тогда как в других сетях их продолжительность может измеряться часами или днями.

В одних сетях эпохи тесно связаны с финализацией и ротацией комитетов.

В других они используются преимущественно для графиков лидеров, учета стейкинга, обновления делегирования или распределения вознаграждений.

Кошельку или приложению для стейкинга нельзя применять допущения об эпохах одного блокчейна к другому.

Основным источником данных следует считать документацию соответствующего протокола и данные работающих узлов.

Эпохи и выбор валидаторов

В блокчейнах на Proof of Stake данные о стейке часто влияют на распределение обязанностей между валидаторами.

До начала действия обязанностей протокол может делать снимок списка подходящих валидаторов или стейка.

Это помогает предотвратить мгновенное изменение стейка участниками после того, как им станет известно о выгодном назначении.

График эпох может задавать временную основу для снимка, расчета назначений и периода выполнения обязанностей.

Точная задержка между изменением стейка и началом действия новых обязанностей различается в разных блокчейнах.

Эпохи и активация стейкинга

Делегированные активы или активы в стейкинге могут активироваться не сразу после подтверждения транзакции.

Протокол может отложить активацию до будущей эпохи или использовать очередь активации.

Такая задержка позволяет сети упорядоченно обновлять записи о валидаторах и стейке.

Выход из стейкинга также может требовать перехода между эпохами, очереди выхода, периода ожидания или задержки вывода.

Пользователям следует различать подтверждение транзакции и активацию стейкинга или право на вывод.

Транзакция стейкинга может быть финализирована ончейн, даже если связанный с ней стейк остается ожидающим в соответствии с правилами эпох.

Эпохи и расчет вознаграждений

Во многих системах Proof of Stake участие и вознаграждения рассчитываются за эпохи.

В течение периода сеть может учитывать назначенные обязанности, успешные голоса, создание блоков, делегированный стейк, штрафы и комиссии.

Вознаграждения могут рассчитываться на границе эпохи, но зачисляться позднее.

В одних системах вознаграждения распределяются автоматически, в других необходимо запросить их или выполнить операцию обновления.

Расчетное вознаграждение за эпоху не является гарантированной ставкой, поскольку эффективность валидатора и условия сети могут меняться.

Пользователям также следует учитывать комиссии операторов, изменение цены токена, налоги и условия вывода.

Эпохи и обновления протокола

Граница эпохи может служить точной точкой активации обновления блокчейна.

Все совместимые узлы могут определить этот момент по одному и тому же графику протокола.

Зачастую это надежнее, чем использовать номер блока в сети, где интервалы между блоками меняются.

Обновление, назначенное на определенную эпоху, активируется, когда сеть достигает этой эпохи в принятой цепочке.

Операторам узлов необходимо установить совместимое программное обеспечение до момента активации.

После активации клиент, использующий старые правила, может перестать синхронизироваться или отклониться от сети.

Графики эпох и управление

В некоторых системах управления криптопроектами эпохи используются как периоды подачи предложений, голосования, исполнения решений или делегирования.

Право голоса может рассчитываться по снимку состояния на определенную эпоху или слот.

Предложение может оставаться открытым в течение заданного числа эпох, а не фиксированного календарного периода.

Это упрощает проверку сроков управления ончейн.

Однако пользователям важно понимать график, поскольку дедлайн, выраженный только номером эпохи, может быть непонятен с точки зрения обычного календарного времени.

Может ли график эпох измениться?

График эпох может измениться только в том случае, если протокол блокчейна и процесс управления допускают такие изменения.

Некоторые параметры графика фиксируются при создании сети.

Другие сети могут изменять время слотов, продолжительность эпох или правила выполнения обязанностей с помощью согласованного обновления протокола.

Изменение должны единообразно внедрить совместимые узлы, чтобы избежать расхождений в консенсусе.

Приложениям не следует навсегда задавать параметры времени, если сеть предоставляет авторитетный API или системную переменную.

Как оценить время до конца эпохи

Приложение может оценить оставшееся до конца эпохи время, умножив число оставшихся слотов на целевую продолжительность слота.

Базовая оценка рассчитывается как количество оставшихся слотов, умноженное на целевое время одного слота.

В сетях, где фактическая скорость появления слотов может меняться, это лишь примерная оценка.

Пропуск блока не обязательно останавливает нумерацию слотов, поскольку слоты могут проходить независимо от успешного создания блоков.

Таймер обратного отсчета следует обновлять на основе актуальных данных узла и при необходимости помечать как приблизительный.

Номер эпохи и высота блока

Номер эпохи обозначает группу слотов протокола.

Высота блока — это количество принятых блоков в истории цепочки.

Эти значения могут увеличиваться с разной скоростью, поскольку некоторые слоты проходят без создания блоков.

Кроме того, протокол может создать несколько кандидатов на блок в одном слоте, хотя консенсус в итоге принимает одну историю цепочки.

Разработчикам следует использовать подходящее значение для каждой задачи и не пересчитывать высоту блока в эпоху, исходя из предположения, что каждому слоту соответствует один блок.

Номер эпохи и временная отметка

Номер эпохи — это нативная для протокола ссылка на время.

Временная отметка представляет календарное время.

Блокчейн может оценить временную отметку, соответствующую границе эпохи, но оценка может зависеть от времени слотов и принятой цепочки.

Смарт-контрактам не следует считать расчетное время завершения эпохи точным временем офчейн-события, если протокол не гарантирует такую связь.

Для ясности интерфейсы могут показывать и номер эпохи, и примерную локальную дату.

Данные графика эпох и доверие к RPC

Публичная RPC-точка доступа предоставляет удобный способ получать сведения об эпохах, однако пользователь доверяет ей точность этих данных.

Недоступная, задерживающаяся или вредоносная точка доступа может передавать устаревший или неверный статус эпохи.

Если информация критически важна для безопасности, приложения могут сравнивать данные нескольких узлов или запускать собственный узел.

Также необходимо выбирать подходящий уровень подтверждения или финализации для запрашиваемых данных.

Значение, полученное при низком уровне подтверждения, может относиться к состоянию цепочки, которое позднее изменится.

Использование данных об эпохах в смарт-контрактах

Ончейн-программа должна использовать одобренный протоколом источник данных об эпохах или времени.

Она не должна без проверки доверять пользователю, который передает текущий номер эпохи.

В правилах, зависящих от эпох, нужно точно определить, что происходит на ее границе.

Разработчикам следует тестировать последний слот одной эпохи и первый слот следующей.

Если приложение выполняет исторические расчеты, следует также тестировать ранние эпохи разгона.

Ошибка на единицу может привести к началу или завершению периода стейкинга, управления или начисления вознаграждений на слот раньше или позже.

Риски безопасности логики, зависящей от эпох

Неправильный расчет эпох может привести к ошибкам в вознаграждениях, голосовании, выводе средств или контроле доступа.

Контракт может использовать неверный график после развертывания в другой сети.

Приложение может применять обычную продолжительность эпох во время периода разгона.

Пользовательский интерфейс может показывать неверный дедлайн, если пересчитывает слоты в календарное время по устаревшей оценке.

Валидатор может пропустить свои обязанности из-за неверного расчета графика лидеров.

Система управления может принимать голоса за пределами установленного периода из-за ошибки на границе эпохи.

Код, зависящий от эпох, должен использовать расчеты с проверкой целочисленных значений, авторитетные данные сети и тесты граничных условий.

Как разработчикам использовать график эпох

Сначала определите, задает ли сеть фиксированное или переменное количество слотов в эпохе.

Затем получите график из официального API узла или системных данных.

Если они предусмотрены, учтите эпохи разгона и первую обычную эпоху.

Далее различайте абсолютные номера слотов и индексы слотов внутри эпохи.

Для отображения текущего прогресса используйте актуальные данные об эпохах.

Считайте время завершения по календарю приблизительным, если протокол не обеспечивает точного времени.

Проверьте каждый расчет около границ эпох.

Отслеживайте обновления протокола, которые могут изменить соответствующие правила.

Пример расчета графика эпох

Предположим, вымышленный блокчейн на Proof of Stake использует 10,000 слотов в эпохе после периода разгона.

Предположим также, что первая обычная эпоха — эпоха 5, а первый слот в ней имеет абсолютный номер 9,000.

Абсолютные слоты с 9,000 по 18,999 будут относиться к эпохе 5.

Абсолютный слот 19,000 станет началом эпохи 6.

Индекс слота 0 обозначает первый слот внутри эпохи.

Индекс слота 9,999 обозначает последний слот обычной эпохи.

Этот пример показывает, почему для расчета нужны и первый обычный слот, и количество слотов в эпохе.

Эти числа приведены только в качестве примера и не должны использоваться для расчетов в работающем блокчейне.

Распространенные ошибки при работе с графиком эпох

Одна из распространенных ошибок — считать, что эпоха длится одинаково во всех блокчейнах.

Другая ошибка — принимать номер слота за высоту блока.

Третья ошибка — предполагать, что в каждом слоте создается блок.

Четвертая ошибка — применять обычную продолжительность эпох к ранним эпохам разгона.

Пятая ошибка — путать график эпох с графиком лидеров-валидаторов.

Шестая ошибка — считать расчетное время окончания эпохи точной гарантией.

Седьмая ошибка — предполагать, что стейкинг активируется сразу после подтверждения транзакции.

Восьмая ошибка — жестко задавать параметры графика, не проверяя подключенную сеть.

Девятая ошибка — полагаться на одну непроверенную RPC-точку доступа при критически важном для безопасности расчете эпохи.

Десятая ошибка — не тестировать последний и первый слоты около границы эпохи.

FAQ

Что означает график эпох в криптовалютах?

График эпох — это набор правил блокчейна, определяющий группировку слотов в эпохи и время начала и завершения каждой эпохи.

Чем отличаются эпоха и слот?

Слот — это короткая единица времени консенсуса, а эпоха — группа последовательных слотов.

Содержит ли каждый слот блок?

Нет, слот может пройти без принятого блока, если выбранный производитель отключен от сети, опоздал или не справился с задачей.

Одинакова ли продолжительность эпох во всех блокчейнах?

Нет, продолжительность эпох и слотов определяется отдельно протоколом каждого блокчейна.

Что такое Epoch Schedule в Solana?

Это структура кластера, сопоставляющая слоты с эпохами и содержащая параметры обычной продолжительности эпох, поведения периода разгона и времени расчета графика лидеров.

Что возвращает getEpochSchedule?

Метод возвращает

, , , и .

Показывает ли getEpochSchedule текущую эпоху?

Нет, приложения Solana используют

, чтобы получить текущую эпоху и позицию внутри нее.

Что такое slotsPerEpoch?

Это максимальное количество слотов в обычной эпохе для запрошенного кластера.

Что такое эпоха разгона?

Эпоха разгона — это ранняя эпоха, в которой меньше слотов, чем предусмотрено обычной полной продолжительностью эпохи.

Что такое firstNormalEpoch?

Поле обозначает первую эпоху, в которой используется полное обычное количество слотов.

Что такое firstNormalSlot?

Поле обозначает абсолютный номер слота, с которого начинается первая эпоха обычной продолжительности.

Что такое leaderScheduleSlotOffset?

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

Совпадает ли график эпох с графиком лидеров?

Нет, график эпох определяет границы эпох, а график лидеров распределяет валидаторов по слотам создания блоков.

Сколько длится эпоха Ethereum?

В Ethereum сейчас 32 слота по 12 секунд, поэтому расчетная продолжительность эпохи составляет примерно 6,4 минуты.

Сколько длится эпоха Cardano?

Согласно актуальной документации Cardano, эпоха состоит из 432,000 односекундных слотов и длится пять дней.

Может ли эпоха завершиться, даже если не в каждом слоте создан блок?

Да, слоты продолжают сменяться, даже если в некоторых из них нет принятых блоков.

Начисляются ли вознаграждения за стейкинг на каждой границе эпохи?

Не обязательно: правила расчета, начисления, получения и вывода вознаграждений различаются в разных блокчейн-протоколах.

Может ли активация стейкинга зависеть от эпохи?

Да, во многих системах Proof of Stake изменения валидатора или делегирования применяются только после перехода между эпохами или другой установленной протоколом задержки.

Может ли измениться график эпох?

Он может измениться, если протокол блокчейна допускает согласованное обновление, однако некоторые параметры могут быть зафиксированы при создании сети.

Могут ли разработчики точно рассчитать время завершения эпохи?

Разработчики могут рассчитать количество оставшихся слотов, но оценка календарного времени может меняться, если фактическое время слотов отличается от целевого.

Почему для обновлений протокола используют номера эпох?

Номер эпохи задает детерминированный ончейн-момент активации, который совместимые узлы могут рассчитать по одним и тем же правилам консенсуса.

Могут ли смарт-контракты считывать график эпох?

Это зависит от блокчейна. В Solana программы могут обращаться к sysvar EpochSchedule с помощью поддерживаемых методов среды выполнения.

Совпадает ли номер эпохи с номером блока?

Нет, эпоха содержит множество слотов и блоков, причем в некоторых слотах блоки могут не создаваться.

Почему график эпох важен для валидаторов?

Он помогает валидаторам понимать периоды выполнения обязанностей, назначения лидеров, изменения стейкинга, учет вознаграждений и границы активации обновлений протокола.

Как безопаснее всего получать данные об эпохах?

Используйте официальные интерфейсы узлов, проверяйте подключенную сеть, выбирайте подходящий уровень подтверждения и сравнивайте независимые источники, если важна точность.

Заключение

График эпох — это структура протокола, которая делит время блокчейна на слоты и эпохи.

Он задает предсказуемые периоды для обязанностей валидаторов, смены лидеров, обновления стейкинга, вознаграждений, финализации, управления и обновлений сети.

Эпоха — это группа слотов, а слот — короткий промежуток для действий консенсуса, например создания блока или голосования.

Слоты и блоки — не одно и то же: слот может пройти без принятого блока.

В Solana Epoch Schedule — это также конкретная структура сети, содержащая данные об обычной продолжительности эпох, смещении графика лидеров, периоде разгона и опорных параметрах обычных эпох.

В Ethereum сейчас используется 32 двенадцатисекундных слота на эпоху, а в Cardano — 432,000 односекундных слотов.

Эти различия показывают, почему продолжительность эпох всегда нужно интерпретировать с учетом подключенного блокчейна.

Разработчикам следует получать данные графика из авторитетных интерфейсов узлов, учитывать период разгона и тестировать все расчеты границ эпох.

Если время слотов может меняться, пользователям следует считать календарный обратный отсчет приблизительным и не предполагать, что изменения стейкинга или вознаграждения становятся доступны сразу на каждой границе эпохи.

Понимание графика эпох помогает пользователям криптовалют интерпретировать время работы валидаторов, периоды вознаграждений, обновления сети, сроки голосования и ритм работы блокчейнов на Proof of Stake.