Перенос с одной ноды на другую
Иногда ваша машина для ноды больше не способна выполнять свою работу, и вам необходимо перейти на другую. Это может произойти, если вы, например, обновляете вашу ноду, или если вы переходите с облачной ноды на локально размещённую на выделенном оборудовании, или даже если ваша нода испытывает катастрофический аппаратный сбой и вам нужно запустить ваши валидаторы на резервной машине. Независимо от случая, это руководство поможет вам понять, как безопасно перенести ваш кошелёк и ключи валидаторов с одной ноды на другую без получения слэшинга.
Слэшинг и база данных слэшинга
Основная причина, по которой мы призываем вас проявлять такую осторожность при переносе вашего кошелька с одной машины на другую или восстановлении вашего кошелька на другой машине, заключается в риске слэшинга. Слэшинг происходит, когда один или несколько ваших ключей валидатора делают что-то, что нарушает правила Beacon Chain и выглядит так, как будто вы пытаетесь атаковать сеть. В ответ цепь принудительно выведет ваш валидатор и наложит серьёзный штраф — размер штрафа зависит от того, сколько валидаторов также получили слэшинг в течение двухнедельного периода от вашего, но в настоящее время минимум составляет 1 ETH, а максимума нет.
Хотя существует несколько условий, которые могут быть интерпретированы как "атака на сеть", реалистично единственное, что происходит случайно, это двойная аттестация (или двойное предложение). Это происходит, когда ваш валидатор отправляет две аттестации (или два предложения блока) для одного и того же слота с разными голосами (например, он голосует за два разных блока-кандидата для конкретного слота вместо того, чтобы выбрать один).
Для борьбы с этим ваш Validator Client хранит так называемую базу данных слэшинга. База данных слэшинга — это просто запись голосов вашего валидатора (то есть слот каждого голоса и хэш блока, за который был этот голос), чтобы он знал, что не голосовать за то, за что он уже голосовал.
Как избежать слэшинга
Каждый Validator Client поддерживает базу данных слэшинга, чтобы гарантировать, что ваша нода никогда не сделает двойную аттестацию или двойное предложение. Проблема же возникает в ситуациях, когда вы начинаете валидировать без базы данных слэшинга и, следовательно, не имеете записи о том, за что ваши валидаторы ранее голосовали. Это может произойти в нескольких ситуациях:
- Вы только что сменили Consensus клиенты, и новый клиент не переносит базу данных слэшинга из старого (чего Smartnode не делает при смене клиента).
- У вас кошелёк загружен на одной машине, и вы активно аттестуете с ней, а затем загружаете ваш кошелёк на вторую машину пока первая машина всё ещё активно аттестует.
- Вы прекращаете валидировать на одной машине и загружаете ваш кошелёк на вторую машину, но вы не подождали достаточно долго, чтобы текущая эпоха была финализирована, поэтому ваша вторая машина аттестует для слотов, для которых ваши валидаторы уже аттестовали.
Стандартный способ избежать слэшинга — это подождать как минимум 15 минут после вашей последней успешной аттестации перед запуском вашего Validator Client и аттестацией снова, и убедиться, что ваши ключи валидатора присутствуют только на одной единственной машине.
Более конкретно, план заключается в том, чтобы подождать, пока ваш валидатор намеренно пропустит аттестацию, и этот пропуск был финализирован. Как только финализация достигнута, ваш валидатор больше не может голосовать за финализированную эпоху, и безопасно снова начать аттестовать с ним.
15-минутное ожидание исходит из эмпирического правила, что при нормальной работе (например, с нормальным консенсусом) Beacon Chain занимает около 7 минут для финализации эпохи. Ожидание 15 минут гарантирует, что вы пропустили как минимум одну эпоху и подождали достаточно долго, чтобы эта эпоха была финализирована, с небольшим запасом для безопасности.
Чек-лист переноса ноды
С учётом вышеуказанного контекста, вот полезный чек-лист, которому вы можете следовать при переносе вашей ноды, чтобы гарантировать, что вы не получите слэшинг. Он разработан для максимальной безопасности, поэтому, хотя вы можете думать, что некоторые из шагов не нужны, мы настоятельно рекомендуем выполнить их все до конца.
-
Подготовьте новую ноду, следуя этим руководствам, начиная с раздела "Подготовка ноды" и заканчивая, как только у вас установлен Smartnode и синхронизируются Execution и Consensus клиенты.
- :warning: НЕ инициализируйте новый кошелёк или восстанавливайте ваш старый кошелёк на ноде. Позвольте ей синхронизировать клиенты без присутствия кошелька.
-
ПОДОЖДИТЕ, пока ваши клиенты полностью синхронизируются на новой ноде.
-
Подтвердите, что вы правильно записали вашу мнемоническую фразу, запустив
rocketpool wallet test-recoveryна вашей новой машине. Это симулирует восстановление ключей, чтобы подтвердить, что кошелёк вашей ноды и все ключи валидаторов ваших minipool могут быть восстановлены правильно, но не будет на самом деле восстанавливать их и сохранять на диск, поэтому нет риска слэшинга.- Если Smartnode не удаётся восстановить кошелёк вашей ноды, используя предоставленную вами мнемоническую фразу, то ваша мнемоническая фраза может быть недействительной. ОСТАНОВИТЕ прохождение этого процесса; удаление ключей с вашей старой ноды означает, что они могут быть потеряны навсегда.
- В этой ситуации мы рекомендуем выйти из ваших валидаторов и вывести ваш капитал как можно скорее, чтобы вы могли начать заново с новой нодой, для которой у вас есть рабочая мнемоническая фраза.
-
Остановите валидацию на вашей старой ноде (например, используя
rocketpool service stop, чтобы выключить клиент валидатора). -
Удалите ваши ключи с вашей старой ноды (например, используя
rocketpool wallet purge).- ПРОВЕРЬТЕ, что ключи были удалены, посмотрев на папку
dataвашей ноды (по умолчанию это~/.rocketpool/data/validators/) — каждый Consensus клиент будет иметь свою собственную папку под этой папкой данных со своей копией ключей. - Пожалуйста, смотрите раздел Проверка удаления ключей ниже для инструкций о том, как это сделать.
- Убедитесь, что все из них были удалены.
- ПРОВЕРЬТЕ, что ключи были удалены, посмотрев на папку
-
Выключите вашу старую ноду и отключите её от Интернета, удалив кабель Ethernet или модуль Wi-Fi.
-
Сотрите SSD с вашей старой ноды, используя один из следующих методов:
- Используйте загрузочный USB-накопитель с установкой Linux (например, популярный GParted) и используйте его для стирания диска.
- Физически извлеките его из вашей старой ноды, подключите его к другой машине, используя USB-конвертер, и используйте инструмент, такой как GParted, для стирания диска.
- Физически извлеките его из вашей старой ноды и ударьте его молотком, чтобы сломать его и убедиться, что он никогда не будет использоваться снова.
-
ПОДОЖДИТЕ как минимум 15 минут перед продолжением. Используйте обозреватель блоков, такой как https://beaconcha.in, чтобы посмотреть на запись аттестации вашего валидатора. Подождите, пока как минимум одна аттестация будет записана как пропущенная и соответствующая эпоха была финализирована.
- ПРИМЕЧАНИЕ: если у вас несколько minipool, вы должны убедиться, что все они пропустили как минимум одну аттестацию, которая была финализирована.
-
Восстановите кошелёк вашей ноды на новой машине, следуя инструкциям в Импорт / Восстановление существующего кошелька.
-
Перезапустите ваш Validator Client, чтобы убедиться, что ваши ключи валидатора загружены (например, с помощью
docker restart rocketpool_validator).
Ключи вашего валидатора теперь будут загружены на вашей новой ноде, и вы можете безопасно начать аттестовать с ней.
Проверка удаления ключей
Ключи валидатора хранятся на вашем диске в форме файлов json.
Они хранятся в папке data вашей ноды.
По умолчанию вы можете найти их здесь:
Если вы изменили ваш каталог data, используя TUI service config (например, вы используете ключ Aegis и установили его как вашу папку data, вышеуказанный путь должен быть изменён на <ваша папка data>/validators.)
Каждый клиент будет иметь свою копию ключей, так как каждый клиент ожидает их в другом формате или конфигурации.
Чтобы найти ключи на диске, выполните следующую команду:
Например, на машине с двумя minipool, вывод будет выглядеть так:
Это показывает пример, где ключи не были удалены и всё ещё находятся в файловой системе.
Если ваши ключи были удалены, вы не должны видеть никаких шестнадцатеричных строк (больших строк, начинающихся с 0x) в каких-либо папках для любого из клиентов в выводе этой команды.