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

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

Почему обязательные обновления пропускать нельзя

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

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

Схема из четырёх шагов: от проверки типа обновления до перезапуска
Схема из четырёх шагов: от проверки типа обновления до перезапуска

Сравнение стратегий обновления

Подход Когда применим
Сразу после выхода версии Для обязательных обновлений и критических исправлений безопасности
Через несколько дней после релиза Разумный компромисс: часть проблем выявляют другие операторы
Обновление на тестовом узле сначала Для крупных залогов, требует второго сервера и времени
Автоматическое обновление Удобно, но лишает контроля над моментом и версией

Пошаговый порядок обновления

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

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

Резервная копия перед обновлением

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

Где чаще всего ломается процесс

  • Обновление без чтения примечаний: пропущенное изменение формата конфигурации
  • Резкая остановка службы вместо штатной: повреждение базы данных
  • Установка версии для другой архитектуры или несовместимой с сетью
  • Отсутствие плана отката при неудачном обновлении

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

Окно обслуживания для валидатора

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

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

План отката

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

Где следить за выходом версий

Официальный репозиторий разработчиков и их канал объявлений — единственные надёжные источники. Сообщения о срочных обновлениях в чатах и личных сообщениях проверяйте по первоисточнику: рассылка «критического патча» со ссылкой на сторонний сайт остаётся рабочей схемой атаки на операторов узлов.

Обновления операционной системы

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

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

Вопросы и ответы

Стоит ли включать автообновление клиента?

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

Сколько ждать перед установкой новой версии?

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

Что делать, если узел не стартует после обновления?

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

Вердикт

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

Актуальные версии сверяйте напрямую. Руководство ethereum.org по самостоятельному стейкингу и инструкция по запуску полного узла биткоина содержат ссылки на официальные дистрибутивы и требования.

Иван Григорьев, автор Cryptium. Практикующий разбор майнинга и инфраструктуры. Больше материалов — в Telegram-канале t.me/cryptiumru.