Содержание статьи
Пошаговое подробное руководство по установке и запуску:
- ноды Эфира,
- консенсус клиента,
- валидатора
Вводные данные:
- Ubuntu 20.04.4 LTS
- Клиент ноды — Geth
- Клиент консенсуса — Prysm
Предупрежу сразу — мануал будет длинный и подробный.
Дисклеймер
Данное руководство носит исключительно информационный характер и не является профессиональным советом. Автор не гарантирует точность информации в этой статье, и автор не несет ответственности за любой ущерб или убытки, понесенные в результате следования этой статье.
Системные требования
Требования для ноды и консенсуса можно посмотреть по этой ссылке . Скорость синхронизации напрямую зависит от Вашего оборудования.
Настройка сервера
Я не буду подробно описывать настройку сервера, остановлюсь только на синхронизации времени. Для правильной синхронизации блокчейна обязательно нужно настроить точное время. В Ubuntu встроена синхронизация времени. Проверяем.
1 | timedatectl |
Будет примерно как на скриншоте, в зависимости от настроек Вашего часового пояса
Нужно удостовериться, что NTP service — active. Если нет — включаем:
1 | sudo timedatectl set-ntp on |
Создаем JWT файл
Исполнительный клиент и клиент консенсуса для общения между собой используют защищенный механизм аутентификации JSON Web Token — JWT. В реальности это файл, который содержит случайно сгенерированную 32-байтовую шестнадцатеричную строку. Создадим этот файл.
Создаем папку для хранения файла:
1 | sudo mkdir -p /var/lib/jwtsecret |
Теперь создадим файл JWT, используя библиотеку openssl
openssl rand -hex 32 | sudo tee /var/lib/jwtsecret/jwt.hex > /dev/null
Проверим что получилось
1 | sudo cat /var/lib/jwtsecret/jwt.hex |
Файл готов и чуть позже путь к файлу мы укажем для исполнительного клиента и для клиента консенсуса.
Установка Geth
Для ноды я буду использовать папку /home — именно она расположена на быстром NvME диске. Создаю пользователя:
1 | sudo adduser geth |
Добавляю его в sudo
1 | usermod -G sudo geth |
Дальше уже от имени этого пользователя:
1 | su geth |
Ставим нужные пакеты, добавляем репозиторий и устанавливаем ethereum и geth
1 2 3 4 | sudo apt install software-properties-common sudo add-apt-repository -y ppa:ethereum/ethereum sudo apt update sudo apt install ethereum geth |
Проверяем версию:
1 | geth version |
Теперь сделаем конфиг файл для запуска ноды сервисом.
1 | sudo nano /lib/systemd/system/geth.service |
И добавим в него следующие строки
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | [Unit] Description=Ethereum go client After=syslog.target network.target [Service] Type=simple User=geth Group=geth ExecStart=/usr/bin/geth \ --http \ --http.addr "127.0.0.1" \ --authrpc.addr localhost \ --authrpc.port 8551 \ --authrpc.vhosts localhost \ --authrpc.jwtsecret /var/lib/jwtsecret/jwt.hex \ --syncmode "snap" \ --cache 4096 \ StandardOutput=syslog StandardError=syslog SyslogIdentifier=geth Restart=allways RestartSec=5 [Install] WantedBy=multi-user.target |
Я не указываю параметр datadir — потому что по умолчанию папка создастся в домашнем каталоге, как мне и надо.
Сохраняем, перечитываем systemd, стартуем сервис и проверяем его статус:
1 2 3 | sudo systemctl daemon-reload sudo systemctl start geth sudo systemctl status geth |
Нода запустилась и начнет синхронизироваться, как только консенсус клиент синхронизируется (до merge нода синхронизировалась сама, теперь же она даже не начнет до тех пор, пока свою часть не выполнит консенсус).
Если нужно что бы сервис запускался сам при старте системы — выполняем:
1 | sudo systemctl enable geth |
Выделяем лог файлы
Все логи ноды пойдут в syslog, а их будет много при синхронизации. Поэтому я выделяю их в отдельные файлы. Создаем конфиг для rsyslog:
1 | sudo nano /etc/rsyslog.d/40-geth.conf |
Добавим в него такие строки:
1 2 3 4 5 6 7 | if $programname == 'geth' then { if $msg contains 'error' then /var/log/geth/geth.err /var/log/geth/geth.log & ~ } |
И сразу сделаем конфиг для ротации логов:
1 | nano /etc/logrotate.d/geth |
Добавим в него такие строки:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | /var/log/geth/geth.log { daily rotate 7 missingok notifempty create 644 syslog adm } /var/log/geth/geth.err { daily rotate 7 missingok notifempty create 644 syslog adm } |
Сохраняем, перезапускаем rsyslog и logrotate
1 2 | sudo systemctl restart rsyslog.service sudo systemctl restart logrotate.service |
В результате этого у нас появится папка /var/log/geth в ней будут лог файлы ноды и они будут ежедневно ротироваться.
Не забывайте следить за актуальностью Geth, текущую стабильную версию можно проверять здесь. Идем дальше.
Консенсус клиент — prysm
Идем на сайт за актуальным релизом. На момент написания — v3.1.1 , скачиваем beacon-chain следующей командой:
1 | curl -LO https://github.com/prysmaticlabs/prysm/releases/download/v3.1.1/beacon-chain-v3.1.1-linux-amd64 |
Переименовываем файл, даем ему права на исполнение и копируем в папку /usr/local/bin :
1 2 3 | mv beacon-chain-v3.1.1-linux-amd64 beacon-chain chmod +x beacon-chain sudo cp beacon-chain /usr/local/bin |
Удаляем ненужную копию в текущей папке
1 | rm beacon-chain |
Когда потребуется обновление консенсус клиента — нужно будет просто повторить все эти действия (предварительно остановив сервис), скачав новый релиз.
Создадим пользователя, от которого будет работать сервис:
1 | sudo useradd --shell /bin/false prysmbeacon |
На текущий момент при полной синхронизации объем данных консенсус клиента составляет 112 Гигабайт, поэтому учитывайте это при указании datadir . Я буду хранить эти данные в домашней папке только что созданного пользователя. Создаем дерево папок и даем права этому пользователю:
1 2 | sudo mkdir -p /home/prysm/beacon sudo chown -R prysmbeacon:prysmbeacon /home/prysm/beacon |
Теперь создадим конфиг файл запуска сервиса
1 | sudo nano /etc/systemd/system/prysmbeacon.service |
И добавим такие строки:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | [Unit] Description=Prysm Consensus Client BN (Mainnet) Wants=network-online.target After=network-online.target [Service] User=prysmbeacon Group=prysmbeacon Type=simple Restart=always RestartSec=5 ExecStart=/usr/local/bin/beacon-chain \ --mainnet \ --datadir=/home/prysm/beacon \ --execution-endpoint=http://127.0.0.1:8551 \ --jwt-secret=/var/lib/jwtsecret/jwt.hex \ --suggested-fee-recipient=FeeRecipientAddress \ # --checkpoint-sync-url=CheckpointSyncURL \ # --genesis-beacon-api-url=CheckpointSyncURL \ --accept-terms-of-use [Install] WantedBy=multi-user.target |
Немного пояснений.
- 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, стартуем сервис и проверяем его статус:
1 2 3 | sudo systemctl daemon-reload sudo systemctl start prysmbeacon sudo systemctl status prysmbeacon |
Консенсус клиент запустился и начал синхронизацию. Нужно подождать. Для стейкинга нужно дождаться полной синхронизации и консенсус клиента и самой ноды Ethereum.
Если нужно что бы сервис запускался сам при старте системы — выполняем:
1 | sudo systemctl enable prysmbeacon |
А пока выделим логи и настроим их ротацию.
Выделяем лог файлы
Делаем конфиг файл для rsyslog:
1 | sudo nano /etc/rsyslog.d/42-prysm.conf |
Добавим в него такие строчки:
1 2 3 4 5 6 | if $programname == 'beacon-chain' then { if $msg contains 'error' then /var/log/prysm/beacon-chain.err /var/log/prysm/beacon-chain.log & ~ } |
Делаем конфиг для logrotate:
1 | sudo nano /etc/logrotate.d/prysm |
Добавим в него такие строчки:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | /var/log/prysm/beacon-chain.log { daily rotate 7 missingok notifempty create 644 syslog adm } /var/log/prysm/beacon-chain.err { daily rotate 7 missingok notifempty create 644 syslog adm } |
Сохраняем, перезапускаем rsyslog и logrotate
1 2 | sudo systemctl restart rsyslog.service sudo systemctl restart logrotate.service |
В результате этого у нас появится папка /var/log/prysm в ней будут лог файлы консенсуса и они будут ежедневно ротироваться.
Создадим данные для стейкинга
Пока идет синхронизация — подготовим все данные для валидатора. Необходимо создать специальные файлы данных, которые зависят от количества валидаторов, которые Вы хотите запустить и профинансировать. Стоит понимать, что для каждого валидатора необходим депозит 32 ETH, которые нужно будет перечислить на специальные адреса. Этот депозит можно будет вывести позднее, после отдельного обновления сети.
Staking Deposit CLI
Скачиваем инструмент — Staking Deposit CLI, который можно запускать как на Linux, так и на Windows. Помимо файлов данных для валидатора, эта программа генерирует мнемонический ключ, который понадобится для вывода депозита в недалеком будущем. Поэтому нужно быть очень аккуратными при генерации, что бы Ваши данные не попали в чужие руки. Есть два варианта:
- полностью чистая и изолированная от интернета система, на которую флешкой копируем бинарник Staking Deposit CLI, выполняем там все операции. И потом нужные файлы также флешкой переносим на машину с валидатором.
- запускаем программу на этой же машине, где мы делали все до этого. Но для этого рекомендуется отключить ее на это время от интернета.
Выбор за Вами.
Идем на сайт — и скачиваем актуальный релиз. На момент написания — v2.3.0. Выбираем дистрибутив для нужной платформы и скачиваем. Я делаю на этой же машине — качаю для Linux:
1 | curl -LO https://github.com/ethereum/staking-deposit-cli/releases/download/v2.3.0/staking_deposit-cli-76ed782-linux-amd64.tar.gz |
Распаковываем архив, переименовываем папку, удаляем скачанный архив и заходим в полученную папку:
1 2 3 4 5 | tar xvf staking_deposit-cli-76ed782-linux-amd64.tar.gz mv staking_deposit-cli-76ed782-linux-amd64 staking-deposit-cli rm staking_deposit-cli-76ed782-linux-amd64.tar.gz cd staking-deposit-cli ll |
В папке будет один файл:
Мне нужно данные для двух валидаторов, поэтому моя команда будет выгялдеть так:
1 | sudo ./deposit new-mnemonic --num_validators 2 --chain mainnet |
Будет два вопроса про язык самого приложения и затем язык мнемоники. Для выбора английского языка на первый вопрос отвечаем цифрой 3, на второй вопрос цифрой 4. После этого нас попросят создать пароль для хранилища ключей валидатора. Вводим два раза пароль и программа выдает нам мнемонический ключ. Ключ нужно сохранить в надежное место. После чего нажать любую клавишу и программа попросит нас ввести мнемонический ключ, для подтверждения что он у нас сохранен. Можно вводить только первые 4 символа каждого слова.
Если вводим правильно — генерируются ключи и мы увидим картинку, что все получилось.
Проверим что в папке:
- deposit_data-1664648110.json — файл содержит публичные ключи валидатора и этот файл будет использоваться на сайта уже когда нужно будет зачислять депозит.
- keystore-[..].json — файлы содержат зашифрованную информацию ключей валидатора. Один файл на каждого валидатора. Я делал два валидатора — два файла. Эти файлы будут импортированы в валидатор чуть позже.
У нас готовы данные для валидатора, переходим к его настройке и запуску.
Валидатор
Скачиваем актуальную версию (тоже с гитхаба prysmaticlabs) — на момент написания версия v3.1.1:
1 | curl -LO https://github.com/prysmaticlabs/prysm/releases/download/v3.1.1/validator-v3.1.1-linux-amd64 |
Переименовываем файл, даем ему права на исполнение и копируем в папку /usr/local/bin:
1 2 3 | mv validator-v3.1.1-linux-amd64 validator chmod +x validator sudo cp validator /usr/local/bin |
Удаляем ненужную копию в текущей папке
1 | rm validator |
Импорт данных в валидатор
Нам нужны файлы, которые мы подготовили и чуть раньше. Если Вы это делали на другой машине — скопируйте их сюда. У меня они уже находятся на этой машине:
Создадим папку, где будут храниться данные валидатора:
1 | sudo mkdir -p /var/lib/prysm/validator |
Выполняем команду импорта, указав путь до папки, где лежат файлы keystore-[..].json:
1 | sudo /usr/local/bin/validator accounts import --keys-dir=/home/sten/staking-deposit-cli/validator_keys --wallet-dir=/var/lib/prysm/validator --mainnet |
Появится предложение принять соглашение, нужно написать accept, после чего нас попросят создать пароль для кошелька. Это не тот же пароль, что мы создавали при генерации ключей. Это именно пароль от кошелька, который будет требоваться для запуска валидатора. Пароль должен быть не менее 8 символов. Сохраните его в надежном месте. После ввода пароля и его подтверждения появляется запрос пароля для импорта аккаунтов валидатора. Это как раз пароль, который мы создавали при генерации валидаторов, вводим его:
Если ввели правильный пароль — запускается процесс импорта. После чего система сообщит что все получилось, у меня импортировалось 2 аккаунта:
Для того, что бы запускать валидатор как сервис, потребуется сохранить пароль от кошелька в текстовый файл и прописать путь к этому файлу.
1 | sudo nano /var/lib/prysm/validator/password.txt |
Вставляем свой пароль от кошелька и сохраняем файл.
Создадим пользователя, от которого будет работать сервис:
1 | sudo useradd --no-create-home --shell /bin/false prysmvalidator |
При импорте данных мы указывали директорию /var/lib/prysm/validator — дадим новому пользователю права на эту директорию.
1 | sudo chown -R prysmvalidator:prysmvalidator /var/lib/prysm/validator |
Теперь создадим конфиг файл запуска сервиса
1 | sudo nano /etc/systemd/system/prysmvalidator.service |
И добавим в него следующие строки:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | [Unit] Description=Prysm Consensus Client Validator (Mainnet) Wants=network-online.target After=network-online.target [Service] User=prysmvalidator Group=prysmvalidator Type=simple Restart=always RestartSec=5 ExecStart=/usr/local/bin/validator \ --datadir=/var/lib/prysm/validator \ --wallet-dir=/var/lib/prysm/validator \ --wallet-password-file=/var/lib/prysm/validator/password.txt \ --suggested-fee-recipient=FeeRecipientAddress \ --graffiti="<yourgraffiti>" \ --accept-terms-of-use [Install] WantedBy=multi-user.target |
- FeeRecipientAddress — Ethereum адрес, на который Вы будете получать комиссию валидатора
- graffiti — Ваша уникальная строка. Не пишите сюда никакой конфиденциальной информации, это некий тег для Вас, что бы отыскать своего валидатора в списке.
Получится примерно следующее:
Сохраняем, перечитываем systemd, стартуем сервис и проверяем его статус:
1 2 3 | sudo systemctl daemon-reload sudo systemctl start prysmvalidator sudo systemctl status prysmvalidator |
Валидатор запустился. Сразу настроим его логи как обычно.
Выделяем лог файлы
Новый конфиг для rsyslog не будем делать, добавим строки в уже имеющийся конфиг для консенсус клиента:
1 | nano /etc/rsyslog.d/42-prysm.conf |
Добавим в него строки:
1 2 3 4 5 6 | if $programname == 'validator' then { if $msg contains 'error' then /var/log/prysm/validator.err /var/log/prysm/validator.log & ~ } |
Получится так:
Тоже самое для logrotate, добавим в имеющийся файл два блока:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | /var/log/prysm/validator.log { daily rotate 7 missingok notifempty create 644 syslog adm } /var/log/prysm/validator.err { daily rotate 7 missingok notifempty create 644 syslog adm } |
Получится так:
Сохраняем, перезапускаем rsyslog и logrotate
1 2 | sudo systemctl restart rsyslog.service sudo systemctl restart logrotate.service |
Если нужно что бы сервис запускался сам при старте системы — выполняем:
1 | sudo systemctl enable prysmvalidator |
Пополнение ключей валидатора
Итак, нужно убедиться что консенсус клиент и сама нода полностью синхронизировались и в логах валидатора появилось что-то типа «Waiting for deposit to be...», и после этого переходить к пополнению ключей валидатора. Я не буду описывать эти шаги — на сайте всё по-русски и очень подробно. Просто идете по порядку. Переходите на сайт — Панель запуска стейкинга (ethereum.org) и нажимайте кнопку «Стать валидатором». На 9 шаге будет список валидатора — не поленитесь открыть его в новом окне и проверить все пункты.
На одном из шагов потребуется выгрузить файл, который мы получили при генерации ключей, формата deposit_data-[timestamp].json , нужно просто через браузер загрузить его.
После этого уже нужно будет вносить депозит.
Посткриптум
В принципе, ничего сложного, главное все делать спокойно и аккуратно. Не забывайте поддерживать файлы ноды, консенсуса и валидатора в актуальном состоянии — следите за обновлениями на гитхабе. Если есть вопросы — задавайте в коментах, если нужна помощь — пишите, с удовольствием помогу.
Удачи!
Супер, спасибо! Давай еще больше на эту тему и подробнее. Что может случится и что делать в тех или иных случаях.
Десктопный вариант Ubuntu 22.04.1 для запуска валидатора не подойдёт?
Я думаю десктоп или нет — не так принципиально. Если железо позволяет и комп всегда будет в сети и запущен валидатор — почему бы и нет... Там просто наравне с комиссией полагаются и штрафы за отсутствие валидатора...
Я кстати тут пытался понять прибыльность данного мероприятия, оставлю ссылочки на сервисы, которыми пользовался.
beaconscan.com/staking-calculator
ethereumprice.org/staking/
Полезные ссылки. Спасибо.
Вознаграждение за staking как и slushing — это понятно, но где-то должно быть и вознаграждение (комиссия) за обработку транзакций. Или это единый, неделимый процесс.
Запустим, будем смотреть.
Шикарная статья. Большое спасибо за труды. Обязательно буду пробовать повторить. Правда в Linux-е не силён, но будем разбираться. Пробовал запускать под Win-10, но после «слияния» стало совсем ничего не понятно. Ваша статья немного прояснила ситуацию.
Вопрос: Если сгенерированы ключи для двух валидаторов, тогда каждый валидатор нужно запускать на отдельной (персональной) физической машине, или можно запустить на одном системнике?
Спасибо.
Оба валидатора могут быть на одной машине. Я описывал как раз эту ситуацию. Можно генерить ключи для двух валидаторов по отдельности — для каждого получать свою мнемонику и свой пароль. Нужно понимать ограничение — один ключ валидатора (или нескольких) может быть запущен только на одной машине. Эммм, мне кажется я еще больше запутал???
То есть, как я понял, на одной машине можно запустить более одного валидатора.
А по ограничениям «системы», чтобы не попасть под «слеширование», нельзя запускать одни и те же ключи на разных машинах (аппаратное дублирование).
Все верно! Именно так!
Спасибо за статью. Пока не очень понятно, конечно не хватает знаний. Но читать было интересно.