Ethetreum. Стейкинг. Запуск валидатора

Автор: | 2 октября 2022

Пошаговое подробное руководство по установке и запуску:

  • ноды Эфира,
  • консенсус клиента,
  • валидатора

Вводные данные:

  • Ubuntu 20.04.4 LTS
  • Клиент ноды — Geth
  • Клиент консенсуса — Prysm

Предупрежу сразу — мануал будет длинный и подробный.

Дисклеймер

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

Системные требования

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

Настройка сервера

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

Будет примерно как на скриншоте, в зависимости от настроек Вашего часового пояса

Нужно удостовериться, что NTP service — active. Если нет — включаем:

Создаем JWT файл

Исполнительный клиент и клиент консенсуса для общения между собой используют защищенный механизм аутентификации JSON Web Token — JWT. В реальности это файл, который содержит случайно сгенерированную 32-байтовую шестнадцатеричную строку. Создадим этот файл.

Создаем папку для хранения файла:

Теперь создадим файл JWT, используя библиотеку openssl

openssl rand -hex 32 | sudo tee /var/lib/jwtsecret/jwt.hex > /dev/null

Проверим что получилось

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

Установка Geth

Для ноды я буду использовать папку /home — именно она расположена на быстром NvME диске. Создаю пользователя:

Добавляю его в sudo

Дальше уже от имени этого пользователя:

Ставим нужные пакеты, добавляем репозиторий и устанавливаем ethereum и geth

Проверяем версию:

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

И добавим в него следующие строки

Я не указываю параметр datadir — потому что по умолчанию папка создастся в домашнем каталоге, как мне и надо.

Сохраняем, перечитываем systemd, стартуем сервис и проверяем его статус:

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

Если нужно что бы сервис запускался сам при старте системы — выполняем:

Выделяем лог файлы

Все логи ноды пойдут в syslog, а их будет много при синхронизации. Поэтому я выделяю их в отдельные файлы. Создаем конфиг для rsyslog:

Добавим в него такие строки:

И сразу сделаем конфиг для ротации логов:

Добавим в него такие строки:

Сохраняем, перезапускаем rsyslog и logrotate

В результате этого у нас появится папка /var/log/geth в ней будут лог файлы ноды и они будут ежедневно ротироваться.

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

Консенсус клиент — prysm

Идем на сайт за актуальным релизом. На момент написания — v3.1.1 , скачиваем beacon-chain следующей командой:

Переименовываем файл, даем ему права на исполнение и копируем в папку /usr/local/bin :

Удаляем ненужную копию в текущей папке

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

Создадим пользователя, от которого будет работать сервис:

На текущий момент при полной синхронизации объем данных консенсус клиента составляет 112 Гигабайт, поэтому учитывайте это при указании datadir . Я буду хранить эти данные в домашней папке только что созданного пользователя. Создаем дерево папок и даем права этому пользователю:

Теперь создадим конфиг файл запуска сервиса

И добавим такие строки:

Немного пояснений.

  • FeeRecipientAddress — нужно указать действительный Ethereum адрес для получения комиссии валидатора
  • checkpoint-sync-url и genesis-beacon-api-url — у меня эти параметры закомментированы — я о них не знал на момент установки и запуска консенсус клиента. Они предназначены для ускорения синхронизации. Я не знаю насколько они ускорят — не пробовал, но опишу как надо настроить. Без этих опций синхронизация консенсуса у меня заняла немногим больше двух дней.
  • jwt-secret — указываем путь до файла JWT, как мы это делали для Geth

Получение CheckpointSyncURL

  • Идем на сайт — https://infura.io/ , регистрируемся (это бесплатно), и создаем новый ключ ETH2

  • На панели нажимаем кнопку «Manage Key». Нам нужен HTTPS URL сети mainnet, копируем его и вставляем его в оба параметра checkpoint-sync-url и genesis-beacon-api-url

Должно получиться примерно так:

Сохраняем, перечитываем systemd, стартуем сервис и проверяем его статус:

Консенсус клиент запустился и начал синхронизацию. Нужно подождать. Для стейкинга нужно дождаться полной синхронизации и консенсус клиента и самой ноды Ethereum.

Если нужно что бы сервис запускался сам при старте системы — выполняем:

А пока выделим логи и настроим их ротацию.

Выделяем лог файлы

Делаем конфиг файл для rsyslog:

Добавим в него такие строчки:

Делаем конфиг для logrotate:

Добавим в него такие строчки:

Сохраняем, перезапускаем rsyslog и logrotate

В результате этого у нас появится папка /var/log/prysm в ней будут лог файлы консенсуса и они будут ежедневно ротироваться.

Создадим данные для стейкинга

Пока идет синхронизация — подготовим все данные для валидатора. Необходимо создать специальные файлы данных, которые зависят от количества валидаторов, которые Вы хотите запустить и профинансировать. Стоит понимать, что для каждого валидатора необходим депозит 32 ETH, которые нужно будет перечислить на специальные адреса. Этот депозит можно будет вывести позднее, после отдельного обновления сети.

Staking Deposit CLI

Скачиваем инструмент — Staking Deposit CLI, который можно запускать как на Linux, так и на Windows. Помимо файлов данных для валидатора, эта программа генерирует мнемонический ключ, который понадобится для вывода депозита в недалеком будущем. Поэтому нужно быть очень аккуратными при генерации, что бы Ваши данные не попали в чужие руки. Есть два варианта:

  • полностью чистая и изолированная от интернета система, на которую флешкой копируем бинарник Staking Deposit CLI, выполняем там все операции. И потом нужные файлы также флешкой переносим на машину с валидатором.
  • запускаем программу на этой же машине, где мы делали все до этого. Но для этого рекомендуется отключить ее на это время от интернета.

Выбор за Вами.

Идем на сайт — и скачиваем актуальный релиз. На момент написания — v2.3.0. Выбираем дистрибутив для нужной платформы и скачиваем. Я делаю на этой же машине — качаю для Linux:

Распаковываем архив, переименовываем папку, удаляем скачанный архив и заходим в полученную папку:

В папке будет один файл:

Мне нужно данные для двух валидаторов, поэтому моя команда будет выгялдеть так:

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

Если вводим правильно — генерируются ключи и мы увидим картинку, что все получилось.

Проверим что в папке:

  • deposit_data-1664648110.json — файл содержит публичные ключи валидатора и этот файл будет использоваться на сайта уже когда нужно будет зачислять депозит.
  • keystore-[..].json — файлы содержат зашифрованную информацию ключей валидатора. Один файл на каждого валидатора. Я делал два валидатора — два файла. Эти файлы будут импортированы в валидатор чуть позже.

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

Валидатор

Скачиваем актуальную версию (тоже с гитхаба prysmaticlabs) — на момент написания версия v3.1.1:

Переименовываем файл, даем ему права на исполнение и копируем в папку /usr/local/bin:

Удаляем ненужную копию в текущей папке

Импорт данных в валидатор

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

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

Выполняем команду импорта, указав путь до папки, где лежат файлы keystore-[..].json:

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

Если ввели правильный пароль — запускается процесс импорта. После чего система сообщит что все получилось, у меня импортировалось 2 аккаунта:

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

Вставляем свой пароль от кошелька и сохраняем файл.

Создадим пользователя, от которого будет работать сервис:

При импорте данных мы указывали директорию /var/lib/prysm/validator — дадим новому пользователю права на эту директорию.

Теперь создадим конфиг файл запуска сервиса

И добавим в него следующие строки:

  • FeeRecipientAddress — Ethereum адрес, на который Вы будете получать комиссию валидатора
  • graffiti — Ваша уникальная строка. Не пишите сюда никакой конфиденциальной информации, это некий тег для Вас, что бы отыскать своего валидатора в списке.

Получится примерно следующее:

Сохраняем, перечитываем systemd, стартуем сервис и проверяем его статус:

Валидатор запустился. Сразу настроим его логи как обычно.

Выделяем лог файлы

Новый конфиг для rsyslog не будем делать, добавим строки в уже имеющийся конфиг для консенсус клиента:

Добавим в него строки:

Получится так:

Тоже самое для logrotate, добавим в имеющийся файл два блока:

Получится так:

Сохраняем, перезапускаем rsyslog и logrotate

Если нужно что бы сервис запускался сам при старте системы — выполняем:

Пополнение ключей валидатора

Итак, нужно убедиться что консенсус клиент и сама нода полностью синхронизировались и в логах валидатора появилось что-то типа «Waiting for deposit to be...», и после этого переходить к пополнению ключей валидатора. Я не буду описывать эти шаги — на сайте всё по-русски и очень подробно. Просто идете по порядку. Переходите на сайт — Панель запуска стейкинга (ethereum.org) и нажимайте кнопку «Стать валидатором». На 9 шаге будет список валидатора — не поленитесь открыть его в новом окне и проверить все пункты.

На одном из шагов потребуется выгрузить файл, который мы получили при генерации ключей, формата deposit_data-[timestamp].json , нужно просто через браузер загрузить его.

После этого уже нужно будет вносить депозит.

Посткриптум

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

Удачи!

Ethetreum. Стейкинг. Запуск валидатора: 9 комментариев

  1. Александр

    Супер, спасибо! Давай еще больше на эту тему и подробнее. Что может случится и что делать в тех или иных случаях.

    1. Алексей Автор записи

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

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

      beaconscan.com/staking-calculator

      ethereumprice.org/staking/

      1. ДЕНИС

        Полезные ссылки. Спасибо.

        Вознаграждение за staking как и slushing — это понятно, но где-то должно быть и вознаграждение (комиссия) за обработку транзакций. Или это единый, неделимый процесс.

        Запустим, будем смотреть.

  2. ДЕНИС

    Шикарная статья. Большое спасибо за труды. Обязательно буду пробовать повторить. Правда в Linux-е не силён, но будем разбираться. Пробовал запускать под Win-10, но после «слияния» стало совсем ничего не понятно. Ваша статья немного прояснила ситуацию.

    Вопрос: Если сгенерированы ключи для двух валидаторов, тогда каждый валидатор нужно запускать на отдельной (персональной) физической машине, или можно запустить на одном системнике?

    Спасибо.

    1. Алексей Автор записи

      Оба валидатора могут быть на одной машине. Я описывал как раз эту ситуацию. Можно генерить ключи для двух валидаторов по отдельности — для каждого получать свою мнемонику и свой пароль. Нужно понимать ограничение — один ключ валидатора (или нескольких) может быть запущен только на одной машине. Эммм, мне кажется я еще больше запутал???

      1. ДЕНИС

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

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

  3. Сергей

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

*