Как настроить валидатор Solana

Терминология: что такое валидатор Solana?

Набор инструментов Solana CLI содержит исполняемый файл solana-validator, который может:

• Подключаться к кластеру Solana и синхронизировать текущее состояние кластера
• Создавать, получать и передавать снимки и другие данные кластера для поддержания актуального состояния
• Голосовать за подтверждение новых блоков в рамках консенсуса кластера
• Обрабатывать входящие транзакции и создавать новые блоки
• Предоставлять RPC и событийные API для запросов данных кластера и отправки новых транзакций

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

RPC-нода — это валидатор Solana без стейка и права голоса, который отслеживает всю информацию сети. Такая нода только отвечает на запросы данных и не участвует в консенсусе.

Термин «валидатор Solana» также может означать участника экосистемы Solana, который управляет валидатором Solana со стейком и правом голоса и участвует в консенсусе.

Подробнее о различиях между RPC, поставщиками RPC и валидаторами читайте здесь.

Начало работы: подготовьте серверное оборудование

Вам потребуется мощный компьютер, предназначенный исключительно для работы валидатора, и второй компьютер, если вы хотите запускать валидаторы одновременно в testnet и mainnet. Текущая минимальная рекомендация: 12 ядер/24 потока, 256 ГБ ОЗУ, 2 SSD-диска по 1 ТБ (желательно с RAID0) и интернет-соединение со скоростью 10 Гбит/с. Подробные требования к оборудованию приведены здесь.

Если вы хотите сократить расходы и работать только в mainnet, учтите: для участия в Solana Foundation Delegation Program (SFDP) необходимо запустить валидатор testnet.

Вы можете купить оборудование и управлять им самостоятельно либо арендовать его у поставщика услуг дата-центра. Мы рекомендуем TeraSwitch. Можно также арендовать ресурсы у поставщика облачных вычислений, но мы не рекомендуем этот вариант: обычно он слишком дорог и чаще вызывает проблемы с производительностью. Solana Foundation Server Program упрощает для операторов валидаторов аренду оборудования у операторов дата-центров. Подробнее здесь.

Чтобы помочь децентрализовать сеть, рассмотрите ASN и города, где пока мало нод или стейка Solana. Некоторые пулы стейкинга и SFDP вознаграждают за децентрализацию по ASN и городам.

Список ведущих дата-центров доступен здесь.

Установите Solana CLI локально

Настоятельно рекомендуем установить инструменты локально. Так вы сможете локально создать все необходимые ключи и не хранить ключ вывода средств на сервере валидатора. Инструкции по локальной настройке Solana CLI доступны здесь.

Когда инструменты станут доступны в локальной командной строке, настройте их так, чтобы по умолчанию использовалась testnet:

$ solana config set --url https://api.testnet.solana.com

Для mainnet можно указать стандартную конечную точку:

$ solana config set --url https://api.mainnet-beta.solana.com

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

$ solana config set --url https://mainnet.helius-rpc.com/?api-key=<YOUR-HELIUS-API-KEY>

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

$ mkdir -p ~/.config/solana
$ solana-keygen new --outfile ~/.config/solana/id.json
$ solana airdrop 1 ~/.config/solana/id.json

Настоятельно рекомендуем использовать разные кошельки для testnet и mainnet. Формат ключей одинаков, поэтому одни и те же ключи можно использовать в обеих сетях, но не поддавайтесь этому искушению. Если использовать одинаковые ключи для пополненных кошельков в testnet и mainnet, можно случайно выполнить в mainnet команды, предназначенные для testnet.

Подробнее о создании ключей и более безопасных методах их генерации.

Настройте аккаунт голосования

Аккаунт голосования валидатора создается с помощью команды solana create-vote-account и трех пар ключей:

1. Пара ключей идентификации — валидатор использует эту пару ключей, чтобы идентифицировать себя в сети и отправлять транзакции, например голоса. Закрытый ключ должен храниться на сервере. Для максимальной безопасности не храните на нем больше SOL, чем требуется для транзакций голосования — примерно 1 SOL в день.
2. Пара ключей аккаунта голосования — эта пара ключей относится к самому аккаунту голосования. Она используется для поиска аккаунта голосования и делегирования ему стейка. Команде create-vote-account закрытый ключ нужен только для подтверждения, что необходимый ключ принадлежит вам. После создания аккаунта голосования требуется только открытый ключ. Изменить его нельзя.
3. Пара ключей вывода средств — эта пара ключей служит главным ключом аккаунта голосования. Она используется для вывода вознаграждений, изменения ключа идентификации или вывода средств и других операций с аккаунтом. Это самый важный из трех ключей. Не создавайте и не копируйте его на сервер. Для mainnet используйте бумажный или аппаратный кошелек либо мультиподпись.

Создайте пары ключей

Создайте пары ключей для testnet следующим образом:

$ solana-keygen new -o identity.json
$ solana-keygen new -o vote.json
$ solana-keygen new -o withdraw.json

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

Бумажный кошелек — это записанная на листе бумаги фраза из 12 или 24 слов. Когда ключ нужен для подписи, фразу вводят с клавиатуры. Если вы не планируете настраивать мультиподпись, дополнительная защита подходит для ключа вывода средств mainnet, поскольку он предоставляет полный доступ к аккаунту голосования. Выполните эту команду:

$ solana-keygen new --no-outfile

Запишите показанную фразу на листе бумаги. Также можно записать открытый ключ, точную команду, использованную для создания ключа, и solana-keygen --version. Учтите, что существуют разные схемы преобразования парольной фразы в закрытый ключ. Прежде чем убрать лист, убедитесь, что с его помощью можно получить доступ к ключу:

$ solana-keygen verify <PUBKEY> ASK

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

Необязательно: подберите запоминающийся ключ для аккаунта голосования

Некоторые валидаторы используют запоминающиеся открытые ключи идентификации или аккаунта голосования. Например, у валидатора Helius ключ идентификации — HEL1USMZKAL2odpNBj2oCjffnFGaYwmbGmyewGv1e2TU, а ключ аккаунта голосования — he1iusunGwqrNtafDtLdhsUQDFvo13z9sUa36PauBtk. Такие ключи создаются подкомандой grind следующим образом:

$ solana-keygen grind --starts-with PREF1X:1

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

Ключ аккаунта голосования изменить нельзя, особенно после его публикации и начала делегирования стейка. Если вам нужен запоминающийся ключ, создайте его сейчас.

Создайте аккаунт голосования из пар ключей

Когда пары ключей будут готовы, создайте аккаунт голосования следующим образом:

$ solana create-vote-account --fee-payer ~/.config/solana/id.json vote_account.json identity.json withdrawal.json

Здесь vote_account.json — пара ключей аккаунта голосования, identity.json — пара ключей идентификации валидатора, withdrawal.json — пара ключей полномочий на вывод средств, а ~/.config/solana/id.json — кошелек с SOL для оплаты создания аккаунта голосования.

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

$ solana create-vote-account --fee-payer ~/.config/solana/id.json vote_account.json identity.json ASK

Проверить этот или любой другой аккаунт голосования можно следующей командой:

$ solana vote-account <PUBKEY>

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

Подробнее об аккаунтах голосования читайте здесь.

Необязательно: установите комиссию

Команда create-vote-account принимает комиссию как необязательный параметр. По умолчанию она равна 100%, то есть ваш валидатор считается приватным. Если вы хотите привлечь внешний стейк к валидатору mainnet, вероятно, потребуется выбрать более низкую комиссию.

Предположим, открытый ключ нашего аккаунта голосования — <VOTE_ACCT_PUBKEY>, оплатить изменение нужно с пополненного кошелька id.json, ключ вывода средств хранится в бумажном кошельке, а комиссию нужно установить на уровне 8%. Это можно сделать так:

$ solana vote-update-commission --fee-payer ~/.config/solana/id.json <VOTE_ACCT_PUBKEY> 8 ASK

Необязательно: добавьте мультиподпись

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

Squads — инструмент мультиподписи для Solana с функциями для совместного управления валидаторами. Чтобы настроить валидатор в Squads:

1. Установите в браузере поддерживаемый плагин кошелька Solana, например Backpack
2. Откройте dApp Squads
3. Настройте группу с нужными участниками и параметрами валидатора
4. Перейдите в Developers > Validators и выполните шаги по добавлению валидатора
5. Система попросит вставить закрытый ключ вывода средств. Он будет использован для замены текущего ключа вывода средств на общий ключ группы
6. Проверьте обновленный открытый ключ вывода средств с помощью solana vote-account

Подробнее об использовании Squads для совместного управления валидаторами читайте здесь.

Настройте компьютер как сервер валидатора

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

• Последняя версия Ubuntu LTS, установленная и обновленная
  • Можно использовать и другие дистрибутивы Linux, например основанные на Debian, но все примеры рассчитаны на Ubuntu. Чем сильнее ваша система отличается от Ubuntu, тем больше команд придется изменить
• Настроенный пользовательский доступ по SSH
• Настроенный служебный пользователь sol
• Настроенные система и жесткие диски

Настройте систему и пользователя

Убедитесь, что система обновлена, и создайте служебного пользователя sol:

$ sudo apt update
$ sudo apt upgrade
$ sudo adduser sol

Можно также предоставить доступ к sudo. Это удобнее, но несколько снижает безопасность:

$ sudo adduser sol sudo

Настройте систему

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

Актуальные параметры настройки системы, рекомендованные Solana Labs, доступны здесь.

Настройте жесткие диски

Сейчас Solana Labs рекомендует использовать два физических SSD объемом не менее 1 ТБ: один для данных аккаунтов, другой для данных реестра. На втором диске также может находиться ОС. Из-за высокой нагрузки IOPS не рекомендуется хранить аккаунты и реестр на одном диске.

Здесь приведено руководство по настройке двух дисков.

Другой способ использовать несколько дисков для увеличения доступных IOPS — объединить их в один том RAID0. Тогда RAID-контроллер оптимизирует размещение полос по дискам, чтобы максимально использовать IOPS обоих накопителей. При необходимости в RAID можно добавить диски и дополнительно повысить IOPS. При работе валидатора в такой конфигурации мы пока не сталкивались с проблемами производительности.

Если вы используете один том RAID0, достаточно создать на нем каталоги данных валидатора. Это можно сделать прямо в домашнем каталоге пользователя sol:

$ sudo su sol
$ mkdir -p /home/sol/accounts
$ mkdir -p /home/sol/ledger
$ mkdir -p /home/sol/snapshots
$ mkdir -p /home/sol/logs

Установите Solana CLI на сервер валидатора

Повторите описанные выше шаги, чтобы установить Solana CLI на сервер валидатора от имени пользователя sol. Для сервера валидатора настоятельно рекомендуем собирать программу из исходного кода.

Если вы используете инструмент установки Solana, в дальнейшем обновляйтесь до новых версий командой solana-install. Обновления необходимы для продолжения участия в кластере.

Необязательно: установите клиент валидатора Jito

Jito Labs создала форк валидатора Solana и выпустила собственную версию с поддержкой Maximal Extractable Value (MEV). Концепция MEV предполагает добавление или изменение порядка транзакций в создаваемом блоке для получения прибыли. Jito создала рынок для тех, кто готов доплачивать за такую возможность — «поисковиков». Если вы используете валидатор Jito, компания будет отправлять вам пакеты MEV-транзакций, которые валидатор сможет включать в создаваемые блоки в обмен на дополнительные чаевые.

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

• Получение чаевых MEV и управление ими
• Задержка движка блоков Jito
• Возможный запуск ретранслятора Jito

Инструкции по установке клиента валидатора Jito доступны здесь.

Создайте скрипты запуска валидатора

Создайте shell-скрипт validator.sh

Сначала скопируйте пару ключей идентификации валидатора на удаленный сервер:

$ scp identity.json remoteuser@your.validator.host:/home/sol

Обычно конфигурацией валидатора управляют через shell-скрипт. Создайте начальный скрипт и сделайте его исполняемым:

$ sudo su sol
$ cat >/home/sol/validator.sh <<EOF
#!/bin/bash
PATH=/home/sol/.local/share/solana/install/active_release/bin:$PATH
exec solana-validator \
    --identity /home/sol/identity.json \
    --vote-account <VOTE_ACCOUNT_PUBKEY> \
    --known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on \
    --known-validator 7XSY3MrYnK8vq693Rju17bbPkCN3Z7KvvfvJx4kdrsSY \
    --known-validator Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN \
    --known-validator 9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv \
    --only-known-rpc \
    --log /home/sol/logs/solana-validator.log \
    --accounts /home/sol/accounts \
    --snapshots /home/sol/snapshots \
    --ledger /home/sol/ledger \
    --rpc-port 8899 \
    --dynamic-port-range 8000-8020 \
    --entrypoint entrypoint.testnet.solana.com:8001 \
    --entrypoint entrypoint2.testnet.solana.com:8001 \
    --entrypoint entrypoint3.testnet.solana.com:8001 \
    --expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY \
    --wal-recovery-mode skip_any_corrupted_record \
    --limit-ledger-size
EOF
$ chmod +x /home/sol/validator.sh

Эти параметры позволяют быстро и безопасно запустить валидатор в testnet. После завершения настройки вернитесь к этому скрипту, выполните solana-validator --help, чтобы увидеть полный список параметров конфигурации, и настройте его под свои требования.

Попробуйте запустить валидатор с помощью скрипта:

$ ./validator.sh

При первом запуске валидатору потребуется синхронизироваться с текущим состоянием кластера.

Проверьте правильность работы валидатора

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

$ solana catchup <IDENTITY_PUBKEY>

Внутренний прогресс можно просматривать из сеанса пользователя sol:

$ solana-validator --ledger /home/sol/ledger monitor

Подробнее о проверке подключения валидатора к кластеру читайте здесь.

Настройте валидатор как фоновый процесс

Создайте файл systemd unit, чтобы управлять валидатором как фоновым процессом:

$ sudo cat >/etc/systemd/system/sol.service <<EOF
[Unit]
Description=Solana Validator
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=1
User=sol
LimitNOFILE=1000000
LogRateLimitIntervalSec=0
ExecStart=/home/sol/validator.sh

[Install]
WantedBy=multi-user.target
EOF

Убедитесь, что ранее запущенный процесс ./validator.sh больше не работает, а затем запустите валидатор как фоновый процесс:

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now sol

Настройте мониторинг и безопасность

Отключите аутентификацию по паролю

В файле /etc/ssh/sshd_config можно запретить фоновому процессу SSH принимать входы по паролю или методу «запрос — ответ»:

...
PasswordAuthentication no
ChallengeResponseAuthentication no
...

Не забудьте перезагрузить фоновый процесс sshd с новой конфигурацией:

$ sudo systemctl reload sshd

Добавьте fail2ban и ufw

fail2ban сразу после установки блокирует соединения после нескольких неудачных попыток аутентификации:

$ sudo apt install fail2ban

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

$ sudo ufw allow 22/tcp
$ sudo ufw allow 8000:10000/tcp
$ sudo ufw allow 8000:10000/udp
$ sudo ufw enable

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

На практике большинство валидаторов хранят ключ идентификации на сервере валидатора. Благодаря этому скрипт валидатора может запускаться и перезапускаться без участия человека. Однако ключ идентификации можно передать валидатору через ASK или prompt://, чтобы не хранить его в файловой системе сервера. Это увеличивает операционные издержки и риски, поскольку человеку приходится заменять systemd и вручную управлять фоновым процессом, но такой вариант возможен.

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

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

Дополнительные рекомендации приведены на странице Solana Labs о безопасности валидаторов.

Настройте мониторинг с помощью Watchtower

solana-watchtower входит в набор инструментов Solana CLI. Он может оповещать о проблемах с вашим валидатором и кластером в целом. Его можно настроить и запустить аналогично валидатору, создав скрипт watchtower.sh.

В этом примере для оповещений используется PagerDuty, а журналы записываются в watchtower.log:

$ cat >watchtower.sh <<EOF
#!/bin/bash
PATH=/home/solana/.local/share/solana/install/active_release/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

exec &gt;>watchtower.log \\
  env PAGERDUTY_INTEGRATION_KEY=<PAGERDUTY_KEY> \\
solana-watchtower \\
  --validator-identity <IDENTITY_PUBKEY> \\
  --monitor-active-stake \\
  --interval 20 \\
  --minimum-validator-identity-balance 3 \\
  --url https://api.testnet.solana.com
EOF

У Solana Labs также есть пример настройки оповещений через Telegram.

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

В отличие от валидатора, watchtower не требует значительных ресурсов. Его можно запускать в облачной или бессерверной вычислительной среде, например AWS или GCP.

Необязательно: мониторинг силами сообщества

Многие участники сообщества Solana также отслеживают состояние кластера и готовы отправлять оповещения при условиях, аналогичных предлагаемым watchtower.

Stakewiz предлагает мониторинг валидаторов Solana через Telegram. Например, чтобы настроить оповещения для валидатора Helius, откройте его страницу, а затем нажмите «+ Создать оповещение».

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

Необязательно: собственный мониторинг через RPC-метод getHealth

Чтобы получать данные о состоянии непосредственно от валидатора, опрашивайте метод getHealth его интерфейса JSON RPC. Метод сообщает о работоспособности валидатора и обнаруженных проблемах.

Необязательно: сторонние решения для мониторинга

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

Добавьте стейк валидатору

Сеть Solana достигает консенсуса с помощью голосования на основе доказательства доли владения (PoS). Вес голоса валидатора пропорционален объему делегированного ему стейка SOL. Если считать SOL в стейке акциями, этот принцип напоминает работу акционерной компании. Кроме того, частота выбора валидатора лидером блока пропорциональна объему делегированных ему SOL.

Многие кошельки, dApp и другие инструменты упрощают делегирование SOL существующим валидаторам. Ниже приведены шаги для выполнения этой операции вручную через CLI:

1. Создайте 3 пары ключей с помощью solana-keygen new
2. Создайте аккаунт стейкинга из пар ключей с помощью solana create-stake-account
3. Переведите некоторое количество SOL на аккаунт стейкинга. В testnet это можно сделать с помощью solana aidrop
4. Делегируйте внесенный стейк валидатору с помощью solana delegate-stake
5. Дождитесь следующей эпохи, когда стейк активируется, и проверьте его с помощью solana stake-account

Создайте пары ключей и аккаунт стейкинга

Процесс создания пар ключей и аккаунта стейкинга похож на создание аккаунта голосования. Используются следующие три пары ключей:

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

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

Ниже приведен пример создания в testnet аккаунта стейкинга с 1 SOL. Для пар ключей используются файловые кошельки, аккаунт финансируется из кошелька id.json, а стейк делегируется новому валидатору:

$ solana-keygen new -o stake_auth.json
$ solana-keygen new -o stake_acct_1.json
$ solana-keygen new -o stake_withdrawal_auth.json
$ solana airdrop 1 ~/.config/solana/id.json
$ solana create-stake-account --from ~/.config/solana/id.json stake_acct_1.json 1 --stake-authority stake_auth.json --withdraw-authority stake_withdraw_auth.json --fee-payer ~/.config/solana/id.json
$ solana delegate-stake --stake-authority stake_auth.json <STAKE_ACCT_1_PUBKEY> <VOTE_ACCT_PUBKEY> --fee-payer ~/.config/solana/id.json

Теперь можно проверить, активируется ли стейк и в какой эпохе он станет активным:

$ solana stake-account <STAKE_ACCT_1_PUBKEY>

После начала следующей эпохи и активации стейка голоса валидатора начнут учитываться. Последние голоса можно просмотреть с помощью команды solana vote-account. Если вы добавили всего несколько SOL, как в примере, не ожидайте, что валидатор станет лидером блока.

Голосование стоит около 1–2 SOL в день. На момент написания статьи голосование в mainnet обошлось бы валидатору примерно в 200–300 долларов в день.

(Подробнее о делегировании стейка и управлении аккаунтами стейкинга).

Опубликуйте информацию о валидаторе

Если просмотреть популярные каталоги валидаторов Solana, например validators.app, можно заметить, что у всех валидаторов есть название, описание, логотип и другие метаданные. Эти данные публикуются ончейн для всех зарегистрированных валидаторов в каждом кластере. Просмотреть их можно командой solana validator-info get.

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

Простой пример публикации метаданных:

$ solana validator-info publish "My Awesome Validator" \
--website "https://awesome-validator.xyz/" \
--icon-url "https://awesome-validator.xyz/icon360x360.png" \
--keypair validator_identity.json \
--details "The best validator in the world!"

Созданная запись метаданных получит собственный ключ. Позже ее можно обновить с помощью аргумента --info-pubkey. Длина URL значка не может превышать 80 символов. Подробнее о публикации информации и метаданных валидатора читайте здесь.

Заключение

Поздравляем! Если вы выполнили все шаги и дошли до этого момента, ваш собственный валидатор Solana должен быть запущен. Добро пожаловать в сообщество валидаторов Solana!

Дополнительные ресурсы

• Обзор валидаторов Solana
• Документация валидаторов Solana
• Solana Foundation Delegation Program
• Solana Foundation — пулы стейкинга