L2 sequencer: остановка и восстановление
Ценовой ответ прошёл проверки единиц и возраста. Но библиотека работает в L2, где остановка и последующее восстановление sequencer могут требовать дополнительного ограничения действий. В уроке отделим состояние упорядочивающего компонента от свежести цены и подготовим правило периода восстановления.
Используем первичную модель Chainlink Sequencer Uptime Feeds, изученную 12 октября 2026 года. Мы не выбираем реальный адрес и не читаем действительную сеть. Grace period ниже условный; пример документации с одним часом не является обязательным универсальным параметром каждой сети.
Два независимых источника
Ценовой feed сообщает предусмотренное значение внешних данных. Uptime feed сообщает состояние sequencer по своей модели. Даже если оба имеют похожий интерфейс round data, смысл answer различается. В ценовом BTC/USD-примере требовалось положительное число; в uptime-модели значение 0 означает доступный sequencer, 1 — остановку.
Поэтому нельзя передать uptime-ответ в прежнюю функцию проверки положительной цены. Она отвергла бы допустимый ноль и могла бы принять единицу как «положительное значение». Разбор начинается с назначения источника. Программа сохраняет разные типы данных и разные причины отказа, а не универсальный объект price для любого feed.
После допустимого uptime-состояния ценовой ответ всё равно проверяется отдельно. Доступный sequencer не гарантирует свежую котировку. Свежая котировка не отменяет текущую остановку предусмотренного сетевого компонента.
Время смены состояния
Для uptime-feed startedAt сообщает время последней смены состояния в соответствии с документацией. При восстановлении используется именно этот смысл, а не просто дата получения HTTP-ответа или время обновления цены. Если оператор прочитал запись позже, событие восстановления не становится новым автоматически.
Текущее руководство отдельно описывает инициализацию: нулевой startedAt возможен на Arbitrum до инициализации соответствующего uptime-контракта. Для других рассмотренных в руководстве L2 начальное поведение отличается. Нельзя сделать ноль общей ожидаемой датой для всех сетей и сразу считать длительный период восстановления пройденным.
Наш прикладной guard отвергает неподходящие временные значения перед вычитанием. Конкретный профиль объясняет, какие состояния неизвестны или недопустимы. Это предотвращает случайное принятие неинициализированной записи по огромной разнице с текущим временем.
Период восстановления
После перехода в состояние up приложение может подождать согласованный grace period перед определённым действием. Это даёт пользователям и зависимым данным возможность восстановить допустимый рабочий контекст по выбранной модели. Точный параметр определяется текущей сетью и назначением приложения.
Для условной библиотеки зададим now 10 000, startedAt 9 400 и grace 600. Если правило требует пройти период строго полностью, разница ровно 600 ещё не разрешает действие; при now 10 001 разница 601 проходит временное условие. Это граничное решение нашей модели, не измерение публичной сети.
// Модель проверки; реальные feeds не вызываются.
function requireRecovered({ status, startedAt, now, grace }) {
if (status !== 0n) throw new Error('Sequencer unavailable');
if (grace < 0n || startedAt <= 0n || startedAt > now) throw new Error('Unknown recovery');
if (now - startedAt <= grace) throw new Error('Recovery period');
}Код предполагает bigint-секунды и предварительно разобранный uptime-профиль. Он не является универсальным адаптером любой L2. Для конкретной интеграции источник, сетевой контекст и поддерживаемые параметры будут закреплены отдельно.
Какое действие останавливается
Библиотека может приостановить создание нового ценового предложения в неподходящем состоянии. Это не обязательно должно закрывать публичные уроки или исторический архив. Политика связывается с конкретным действием и последствиями, а не одной общей кнопкой выключения сайта.
Исходный фиксированный Bitcoin-счёт на 30 000 сатоши имеет собственный маршрут наблюдения. Uptime другой сети не должен автоматически отменять его, если он не был зависим от неё по договору. Если продукт действительно связал выдачу ключа с L2-состоянием, эта зависимость вводится и объясняется явно.
Публичное чтение курса может показывать последнее известное объявление с меткой свежести. При отсутствии допустимого состояния система не утверждает, что новая запись успешно принята. Так библиотека сохраняет доступность контента, не обещая выполненного административного действия.
Согласованное наблюдение
Для нескольких чтений полезно сохранять контекст, чтобы не смешать старый uptime и новую цену из несовместимых наблюдений. Конкретный клиент может поддерживать чтение в выбранной точке сетевого состояния; способ зависит от API и задачи. Наш досье фиксирует основание каждой проверки.
Если между двумя чтениями произошла смена состояния, прикладное решение требует предусмотренного пересмотра. Один сохранённый результат guard не является вечным разрешением для всех последующих действий. Перед новой необратимой операцией используется её собственный актуальный контекст.
Для серверного предложения важен также срок фиксации. Успешная подготовка счёта сохраняется вместе с исходными данными и политикой; она не превращается в постоянную гарантию состояния сети. Дальнейшее использование определяется договором этого конкретного счёта.
Отказ источника и диагностика
Если uptime не удалось получить, это не то же самое, что подтверждённое значение down. Пользовательский интерфейс может приостановить действие в обоих случаях, но операторская причина различается. Отсутствие наблюдения не должно переписывать историческую запись об остановке, которой мы не видели.
В диагностике сохраняем выбранный feed, сетевой контекст, raw status, временные поля и решение политики без лишних персональных данных. Это позволяет исследовать неподдерживаемый статус или ошибочную конфигурацию. Автоматическая подстановка up при исключении разрушила бы смысл ограничения.
Если несколько источников показывают разные данные, сначала сверяют адреса и контекст. Голосование двух несогласованных JSON не заменяет предусмотренный процесс uptime. Поддержка резервного маршрута также имеет явный профиль.
В условном сценарии sequencer снова up, период пройден, но ценовой updatedAt старше допустимого maxAge. Новый расчёт всё равно останавливается по ценовой причине. В обратном сценарии цена свежая, а uptime down — срабатывает сетевое ограничение. Такие случаи показывают независимость двух источников лучше одного примера «всё хорошо». Операторская запись сохраняет оба входа и итоговое решение. Это позволяет исследовать, какая зависимость блокировала создание предложения, не отключая все проверки одновременно ради успешной кнопки.
Итог L2-ограничения
Ожидаемые случаи включают up после достаточного периода, up на границе, down, неизвестную инициализацию, будущую дату и ошибку чтения. Ни один из них не исполнен. Досье связывает uptime и цену только на стадии принятия выбранного прикладного действия.
Точные семантики приведены в L2 Sequencer Uptime Feeds. После урока библиотека не путает нулевой технический статус с нулевой ценой и не принимает восстановление за мгновенное универсальное разрешение. Следующий шаг — управление конфигурацией этих источников во времени.