Содержание:

Пул ликвидного стейкинга Marinade.Finance (далее Marinade) имеет важные взаимовыгодные отношения с сообществом валидаторов. Marinade нуждается в сильных и географически распределенных валидаторах для обеспечения децентрализации Solana, с другой стороны валидаторы могут получить дополнительный доход за счет привлечения стейка от Marinade. В данный момент Marinade распределяет стейк более чем на 450 валидаторов и стремится стимулировать рост количества валидаторов, которым будет распределен постоянно растущий пул SOL.

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

Общая стратегия делегирования кратко изложена в Документации Marinade:

Marinade.Finance следует стратегии распределения стейка Solana Foundation, в основе которой лежат следующие параметры валидатора: высокая производительность (основана на кредитах — прим. переводчика), низкая комиссия и низкая концентрация (в дата центре — прим. переводчика). Все это необходимо для повышения децентрализации и устойчивости к цензурированию сети.

Marinade.Finance следует стратегии распределения стейка Solana Foundation, в основе которой лежат следующие параметры валидатора: высокая производительность (основана на кредитах — прим. переводчика), низкая комиссия и низкая концентрация (в дата центре — прим. переводчика). Все это необходимо для повышения децентрализации и устойчивости к цензурированию сети.

*“Пользователи Marinade” — люди, которые внесли в стейкинг свои SOL через некастодиальный протокол ликвидного стейкинга Marinade.Finance.

Каким образом рассчитываются баллы делегирования валидаторов?

Для распределения стейка на лучших валидаторов вне «группы безопасности**» Marinade использует следующие параметры для расчета «баллов»:

• Производительность (APY)***
• Размер комиссии
• Состояние «delinquent»
• Локация / Децентрализация
• Версия ноды

Для расчета баллов используется открытый код, который является форком (копией с доработками — прим. переводчика) бота stake-o-matic. Бот stake-o-matic занимается распределением стейка Solana Foundation. Код бота Marinade опубликован на гитхабе Marinade, там же можно посмотреть и исторические данные по эпохам и увидеть, как были распределены стейки Marinade. Эти данные хранятся в базе данных на основе SQLite. Посмотреть на GitHub.

Целью оценки валидаторов и присвоение баллов является поддержание распределения пула Marinade в рамках целей, о которых было сказано выше: повышение децентрализации и обеспечение доходности для держателей mSOL. Бальная система оценки валидаторов используется в сочетании с некоторой дополнительной обработкой для автоматического распределения стейка валидаторам, пропорционально их баллам в конце каждой эпохи. По мере того, как пользователи Marinade вносят SOL в стейк и снимают их, система Marinade автоматически распределяет новые нераспределенные SOL на валидаторов, а также, при необходимости, снимает стейк в автоматическом режиме, если пользователи забирают свои стейки. Все это сделано для обеспечения надлежащего распределения стейков между валидаторами.

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

• Баллы подсчитываются для всех валидаторов в течение последних 5 эпох.
• Система выбирает 300 лучших валидаторов на основе количества баллов, всем остальным валидаторам присваивается 0 баллов. Топ 300 валидаторов меняется каждую эпоху из-за колебаний параметров, на основе которых начисляются баллы.
• Производительность (APY) текущей эпохи анализируется для 300 лучших валидаторов и используется для корректировки их баллов перед операциями стейка и анстейка.

Производительность валидатора основывается на следующих показателях:

• Количество кредитов, заработанных за эпоху (по отношению ко всем валидаторам в кластере)

— Если валидатор заработал за эпоху меньше 80% от среднего количества заработанных кредитов по кластеру, система забирает весь стейк, который был делегирован валидатору.

— Если валидатор заработал за эпоху меньше 90% от среднего количества заработанных кредитов по кластеру, то все его заработанные баллы делятся на 2.

• Состояние «delinquent», которое означает, что валидатор в данный момента находится в офф-лайне. Валидаторы, не синхронизированные с сетью, всегда теряют свой стейк вне зависимости от баллов, набранных за предыдущие эпохи. (проверка на «delinquent» проводится за 24 и 7 часов до предполагаемого конца каждой эпохи)
• APY с сайта https://stakeview.app/ также используется для анализа доходности валидатора, но только для информационных целей, чтобы дополнительно проверить, верно ли отрабатывает система.

Эти метрики используются для того, чтобы убедиться, что Marinade делегирует стейк высокопроизводительным валидаторам, а все «нарушители» стейка лишаются. Marinade обязан гарантировать, что его пользователи поддерживают хороших валидаторов, которые успешно голосуют за созданные блоки в сети и имеют приемлемую доходность. Вычисления, о которых было сказано выше (количество кредитов и состояние «delinquent»), проводятся дважды за каждую эпоху, за 24 и 7 часов до предполагаемого конца эпохи, полученные результаты загружаются в сеть.

**Валидаторы «группы безопасности» — это валидаторы, которые обладают самым большим стейком в сети Solana, и их отключение может остановить работу сети. Ознакомиться со стретегией Solana по отношениею к валидаторам “группы безопасности” можно в публикации Announcing the Solana Foundation Delegation Strategy. Так как эта группа динамическая, этих валидаторов можно увидеть тут.

***В системе Marinade доходность рассчитывается на основе кредитов, которые были заработаны валидатором в течение эпохи. Комиссия валидатора при этом не оказывает влияние на доходность.

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

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

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

Далее идет сравнение баллов с текущим стейком от Marinade. Если валидатор в новой эпохе получил оценку в 0 баллов, при этом у него по результатам оценки предыдущей эпохи имеется стейк от пула в размере более 0,45% от общего пула Marinade, то он будет лишен стейка.

Помимо этого, если размер стейка валидатора более 250% от того, что положено ему от пула на основе его баллов в текущей эпохе, то он также будет лишен всего стейка.

Но есть одно исключение из последних двух пунктов. Marinade не будет снимать стейк с тех валидаторов, у которых стейк от пула составляет более 20% от общей доли стейка. Это сделано для того, чтобы гарантировать валидатору положительную доходность и не лишить его экономической целесообразности из-за внезапного анстейка большей части SOL. Marinade хочет поддерживать валидаторов, а не усложнять им жизнь!

Также существуют определенные ограничения на стейк одному валидатору, он не может превышать 1,5% от пула Marinade. Еще Marinade использует специальный механизм, который помогает избежать больших изменений стейка у валидаторв в течение нескольких эпох. Сумма стейка, полученного валидатором за 1 эпоху, редко превышает 0,1% от общего пула, который делегирован в настоящее время всем валидаторам Marinade. Единственным исключением из этого правила является случай, когда валидатор оценивается таким количеством баллов, которые обеспечивают ему стейк от пула в два раза больше от текущего стейка Marinade. В этом случае его баллы корректируются на 80% от предыдущих и дают ему увеличение стейка от пула за 1 эпоху более чем на 0,1% от общего пула.

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

Как валидаторы могут оптимизировать свою работу для Marinade.Finance

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

Чтобы стать высокопроизводительным (высокодоходным — прим. переводчика) валидатором необходимо зарабатывать достаточное количество кредитов и иметь хороший итоговый APY. При этом валидаторам стоит соблюдать осторожность при установке ставок комиссии, поскольку высокая комиссия может полностью нивелировать большое количество зарабатываемых валидатором кредитов и снизить APY настолько, что это сильно повлияет на итоговую оценку валидатора. Кредиты, которые валидатор получает за голосование, являются ключевым показателем в системе Solana и определяют, какую часть общей инфляции (ежемесячного увеличения количества SOL — прим. переводчика) получит каждый валидатор. Стейки от независимых источников (речь идет о селф-стейке — прим. переводчика), в конечном итоге, повысят собственную доходность валидаторов, но Marinade измеряет доходность с помощью APY, поэтому маленькие стейки у новых валидаторов не являются показателем их качества при условии хороших показателей APY.

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

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

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

Маринад продолжает тесно сотрудничать с сообществом валидаторов и стремится учитывать их пожелания. Всем валидаторам предлагается присоединиться к каналу #Validator в дискорде Marinade для обсуждения стратегии делегирования и сотрудничества пула с валидаторами.

О Marinade.Finance

Marinade.Finance — это первый некастодиальный протокол ликвидного стейкинга, основанный на Solana. Размещайте свои SOL с помощью Marinade и получайте взамен токены mSOL (маринованные SOL), которые можно использовать в DeFi. mSOL — это наиболее широко используемая версия SOL, которая имеет реальное обеспечение. Цена mSOL повышается относительно SOL каждую эпоху, а вознаграждение зачисляется на стейк аккаунт пользователя.

Стратегия делегирования Marinade опирается на более чем 400 валидаторов, которые выбираются автоматически по справедливой формуле с открытым исходным кодом. Эта формула опирается на производительность (доходность — прим. переводчика), комиссию и децентрализацию.

Мануал почти готов, нашли ошибки - пишите мне в личку.

Какие гайды уже существуют?

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

1. Гайды от Димана (в формате видео)
1. Установка Ноды
2. Настройка RAM-диска
3. Raid-0 в дата-центре Hetzner
4. Установка мониторинга telegraf
2. Гайд по установке ноды от Артема (в формате текста)
3. Гайды от Абеза (в формате видео, плюс полезная информация по Solana)
1. Raid-0 в дата-центре OVH
4. Гайд по установке ноды от команды Let's Node (в формате текста)

Какой гайд использовать для установки ноды?

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

Итак, поехали.

У нас есть два варианта, как мы будем производить настройку сервера и дальнейшую установку ноды, мы можем это делать или под самым главным пользователем операционной системы Ubuntu - Root, или под любым другим пользователем, который уже создан в системе, например, у дата-центра OVH стандартная настройка сервера подразумевает работу под пользователем ubuntu, или под тем пользователем, которого вы создадите сами.

Подготовка к установке

Для того, чтобы исключить возможные проблемы после установки Соланы, нам необходимо провести тестирование железа и интернет-канала, очень часто бывают проблемы на новых серверах, связанные с коннектором для NVME дисков, в связи с этим скорость их записи и чтения становится недопустимо маленькой. Чтобы потом не мучиться и не писать в чат вопросы: "А почему у меня что-то не работает" мы и проводим все эти процедуры. Но для начала установим Raid 0 и операционную систему Ubuntu 20.04

Raid 0

Raid 0 представляет собой массив из двух или более дисков, запись на которые происходит параллельно, за счет этого скорость записи и считывания увеличивается в 2 и более раз (зависит от количества дисков, если 2 диска - в два раза, 3 - в три). Реальное увеличение скорости можно увидеть для записи/чтения больших файлов, но и при записи/чтении маленьких файлов скорость также увеличивает, но немного меньше.

Для чего это там нужно? Так как Солана достаточно требовательна к скорости вашего диска и команда рекомендует использовать NVME-диски, то оптимизировать их работу мы можем с помощью Raid 0.

Проверка дисков

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

И видим следующую информацию:

Обращаем внимание на скорость записи/чтения для файлов 4k, т.е. для файлов размером 4кб, так как основной объем работы Солана проделываем как раз с файлами такого размера. На скриншоте мы видим отличные показатели диска для работы Соланы. Если ваш диск покажет скорость меньше 500мб/с на запись/чтение, то с большей долей вероятности этот диск не подойдет для работы Соланы. Хотя, есть успешные истории людей, которые запускали Солану на HDD-дисках, в которых скорость еще меньше. Но мы люди не рисковые, делать будем все максимально безопасно, чтобы в будущем не хапнуть проблем.

Также хорошо бы посмотреть, новые нам дали диски или старые, хотя даже диски использованные на 50% могут работать отлично, при этом многие дата-центра не будут вам менять диски, если с ними все в порядке, но они не новые. Эта информация больше нужна нам самим, для понимания, с каким железом мы работаем, писать в саппорт с предъявами, что нам поставили старые диски смысла особо нет, но вы можете попробовать это сделать ).

Итак, сначала смотрим список всех дисков, которые установлены на нашем сервере, вводим команду:

И видим такую информацию:

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

apt install smartmontools

Далее смотрим информацию по первому диску:

smartctl -a /dev/nvme0n1

Видим следующее:

1. Модель нашего первого NVME диска
2. Объем нашего первого NVME диска
3. Критическая температура, выше которой нашему диску будет плохо

Спускаемся ниже и видим остальную информацию:

1. Текущую температуру первого NVME-диска (информация поступает с двух сенсоров)
2. Процент износа диска
3. Объем информации, который уже были записаны на наш первый NVME-диск
4. Объем информации, который был считан с нашего первого NVME-диска
5. Отсутсвие информации об ошибках

Исходя из этой информации, мы можем сделать для себя несколько выводов:

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

Возможно, вам пригодится еще команда, чтобы посмотреть свободное место на дисках, вот она:

Тут видим, что у нас из 1,9Тb занято системой (потому что сейчас на диск установлена только система) 2,4Gb, а свободно 1,8Тб. Этого для работы Соланы нам более чем достаточно.

Проверка интернета

Для Соланы необходим канал в 1Гбит, обычно она потребляет не больше 300мбит/сек входящего и 300мбит/сек исходящего трафика. Суммарно за месяц в тестнете тратится около 100Тб трафика (50Тб исходящий, 50 Тб входящий), если ваш дата-центр или провайдер ограничивает скорость при достижении порога в 50Тб или меньше, то вам этот провайдер или дата-центр не подойдет, возможно, придется докупать еще трафик дополнительно. Запускаем проверку скорости первым способом:

Получаем вот такой результат:

Как мы видим на скриншоте, на нашем сервере достаточно хороший интернет, для Соланы нам его однозначно хватит.

Обычно этого теста достаточно, чтобы понять, все ли у нас хорошо с интернетом или нет, но можно протестировать его еще этим способом, устанавливаем:

и запускаем:

Видим следующее:

И этот тест тоже говорит нам, что с каналом у нас все отлично.

Проверка памяти

Достаточно редкое явление, что вам подсунули в дата-центре плохую память, но такой дата-центр как Икула (ikoula.com) частенько подсовывает битую память своим клиентам, видимо она переходит от одного сервера к другому, вдруг арендатор сервера не заметит что с ней есть проблемы и будет работать на битой памяти. Видимо так они рассуждают. Поэтому проверить память точно будет не лишним, устанавливаем memtester:

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

И видимы мы следующую информацию:

1. Свободная оперативная память 61 619Мб
2. Доступная оперативная память 63 317Мб

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

Цифра 1 указывает на количество циклов, которые будет тестировать память программа memtester, в нашем случае 1 цикла будет достаточно.

61Gb = 61 * 1024 = 62 464Mb, так как это значение входит в доступную память, которая на момент проверки ровняется 63 317Мб, то у меня проверку запустить удалось. Если у вас запустить не получится и memtester выдаст ошибку, то запускайте проверку свободной оперативной памяти, в Гб это будет 61 619 / 1024 = 60Gb

В результате тестов увидим следующую информацию:

У нас все с памятью хорошо, все тесты пройдены.

Firewall

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

Устанавливаем фаирвол:

Проверка статуса фаирвола:

После этой команды (если вы еще не производили никаких настроек фаирвола) вы увидите ответ - Status: inactive, это значит, что в данный момент вы только установили фаирвол, но он у вас еще не активен.

Далее добавляем правила, по которым наш фаирвол будет фильтровать трафик:

Первая строка разрешает нам работать по 22 порту (по этому порту мы подключаемся к нашему серверу по SSH)

Далее мы открываем порты, по которым мы будем получать и отправлять трафик по протоколу TCP.

И нижняя строчка разрешает нам отправлять и получать трафик по протоколу UPD через порты с 8000 до 8020.

Далее запрещаем ноде отправлять трафик в приватные сети (куда нельзя посылать трафик лучше всего уточнить у вашего провайдера), в данном случае написаны правила для дата-центра Hetzner, у вас однозначно адреса подсетей будут другие:

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

И еще раз на всякий случай проверить его статус:

В ответ вы увидите список правил, который вы прописали для работы вашего фаирвола.

Root

Если вы решили устанавливать ноду под пользователем Root, а ваш дата-центр предпочитает выдавать клиентам пользователя с правами администратора (могут быть ограничения, по сравнению с пользователем Root), то вам нужно его включить и разрешить авторизоваться с помощью пользователя Root по SSH.

Вводим команда:

Видим следующее:

Вводим пароль для пользователя root, его нужно будет ввести дважды, видим такое сообщение:

Теперь нам нужно от отредактировать конфигурационный файл SSH, который позволит нам подключаться к серверу по SSH используя пользователя Root, вводим команду:

Видим следующее:

Нам интересна вот эта строка - #PermitRootLogin prohibit-password она запрещает пользователю Root авторизироваться в системе с помощью пароля.

Убираем решетку (#) из строчки PermitRootLogin, убираем значение prohibit-password и дописываем в конце yes, чтобы было вот так:

Нажимаем ctrl+c, сохраняем изменения (нажимаем y, потом enter)

Перезагружаем сервис SSH:

Далее система попросит ввести текущий пароль от пользователя, под которым вы подключены сейчас к серверу по SSH, вводим пароль.

После введения пароля системы ответит нам, что сервис SSH перезапустился.

Все, мы включили пользователя Root и разрешили ему подключаться к серверу по SSH, теперь нам нужно проверить, все ли нормально, для этого еще раз подключаемся к нашему серверу по SSH (не закрываем старое подключение), но теперь уже под пользователем root и паролем, который мы задали. Если подключение прошло успешно, то смело можем закрывать старое подключение под пользователем. Теперь у нас все работает под root. Мы молодцы)

Ram-диск

Что такое рамдиск?

Рамдиск представляет собой область в оперативной памяти, куда оперативная система может складывать файлы для хранения, словно они находятся на жестком диске.

Для чего он нужен и нужен ли нам он вообще?

В официальной документации Соланы написано, что если на вашем сервере много оперативной памяти, то вы можете использовать рамдиск для хранения на нем папки accounts. Что значит много?

• Если мы ставим ноду для тестнета, то там во время обычной работы сети Солана потребляет порядка 32Гб оперативной памяти, с возможными скачками до 64Гб, а в моменты стресс-тестов и 128Гб не хватает, спасает свап.
• Если мы говорим о майннет, то тут оперативной памяти Солана потребляет больше и 64ГБ тут минимальное значение с возможными скачками до 128Гб, но бывают момент, когда сеть нереально загружена и 128Гб оперативной памяти в майннете тоже не хватает, и тут опять же спасает свап.

Поэтому, если у вас 128Гб оперативной памяти, то и для тестнета и для майннета можно сделать рамдиск на 300Гб, при этом свап можно сделать 250-300Гб (я делаю 300Гб).

Что такое свап?

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

Если вы решили делать рамдиск (я делаю всегда), то вот инструкция:

1. Отключаем все файлы подкачки (свап):

2. Создаем новый свап-файл для хранения данных размером в 300Гб:

В результате создания увидим такую картину:

3. Задаем необходимые права для свап-файла:

4. Создаем свап из свап-файла:

Видим следующее:

5. Включаем файл подкачки (свап):

6. Проверить свап файл и память можно командой:

Видим следующее:

Вот и появился наш раздел с файлом подкачки.

7. В конфигурационный файл файловой системы fstab добавляем информацию о новом файле и комментируем старые файлы подкачки (свапы):

Комментируем решеткой, ищем строчки, где содержатся слова swap и их комментируем (выключаем) с помощью символа решетка - #, вот так:

Добавляем в конец файла 2 строчки:

В общем запись будет иметь такой вид:

Нажимаем на клавиатуре ctrl+x, затем y и enter

8. Создаем новую папку для рамдиска:

9. Монтируем папку в качестве нового раздела:

10. Проверяем созданный рамдиск командой:

Видим:

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

Установка ноды под Root

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

• Однозначно должен быть сделан Raid 0,
• Настроен Root (по желанию, но я делаю все только под рутом),
• Протестирован жесткий диск
• Протестирован интернет канал
• Протестирована оперативная память
• по желанию настроен фаирвол (можете его вообще не устанавливать, как я),
• создан рамдиск.

Теперь нам нужно узнать, какую на данный момент версию команда просит чтобы устанавливали валидаторы? Так как если вы зайдете на https://docs.solana.com/cli/install-solana-cli-tools, то с большей вероятностью вы увидите последнюю версию Соланы, которая еще не рекомендована для всех валидаторов, что в теснтете, что в майннет, поэтому нам нужно будет зайди в дискорд проекта и посмотреть анонсы:

1. Для майннета
2. Для тестнета

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

Видимо вот такой результат:

Солана просит нас или закрыть текущую сессию (отключиться от сервера) и подключиться снова или прописать нижнюю строчку в консоль, отключаться мы не будем, а просто выделим эту строчку и введем в консоль:

Потом смотрим, добавили ли мы в переменную PATH пути до Соланы, вводим:

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

Далее создаем папку solana, в которой у нас все (кроме папки accounts) будет храниться:

Переходим в эту папку:

Настройки конфига соланы

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

Для тестнета:

Увидим следующее:

Для майннета:

Сюда скриншот вставлять не буду, разница будет только в адресе и файле.

Создание ключей

Теперь мы будем или создавать ключи (если мы первый раз устанавливаем ноду и у нас вообще нет никаких ключей) или будем их копировать с нашего домашнего компьютера на сервер.

Создаем основной ключ валидатора:

И видим следующее:

Система предлагает нам добавить дополнительное слово в нашу стандартную мнемоническую фразу, которая состоит из 12 слов, если вы добавите это слово, то мнемоника вашего ключа будет состоять уже из 13 слов (точнее 12+1), вероятно, это уменьшает шансы на взлом вашего ключа, но я не использую дополнительной слово и просто нажимаю Enter, в результате система нам покажет нам:

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

Запрашиваем на свой основной ключ токены из тестовой сети, для этого идем на сюда и вводим публичный ключ своего основного ключа, жмем "show me the money!":

Ждем надписи на сайте Tokens sent! и проверяем баланс нашего кошелька:

И видим там 100 SOL:

Создаем ключ для воут-аккаунта:

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

Создаем ключ для ауторизед виздравера (Authorized Withdrawer Account):

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

Из ключа, который мы создали для воут-аккаунта, делаем это самый воут-аккаунт, и сразу в этой же команде назначаем ауторизет виздравером тот ключ, который мы для этого создали следующей командой:

И видим что у нас все получилось:

Если бы у нас не было SOL на основном ключе, то мы бы не смогли создать воут-аккаунт для нашего основного ключа, так как для этой операции нам нужны SOL для оплаты комисси, которая составляет около 0,026 SOL. Столько стоит эта операция хоть в тестнете, хоть в майннете.

Или после того, как вы сделали войт-аккаунт (без ауторизет виздравера), вот так:

Или после того, как вы сделали войт-аккаунт (с авторизет виздравером), вот так:

За место 81iuTYDaeJ71XFGkPXNUuQ8gNvHQfBxpU7Vj2hzJ9Q4e ставите пабкей своего воут-аккаунта.

Что это вообще за ключ такой ауторизет виздравер и зачем мы его создали?

Для повышения безопасности средств в Солане есть возможность дать права на распоряжение стейком-аккаунтом и на снятие ревардов с воут-аккаунта другому ключу, которому нет необходимости постоянно находиться на сервере. Раньше функцию ауторизет виздравера выполнял ключ validator-keypair.json, который всегда должен находиться на сервере, так как от его имени происходит голосование в сети и с этого же ключа списывается комиссия для голосования в сети. Но это не безопасно, так как если злоумышленник получит доступ к вашему серверу с нодой, то сможет забрать стейк и реварды и переслать на свой ключ. А если эти права передать другому ключу, который будет лежать у вас на домашнем компьютере, то даже с доступом к серверу он не сможет забрать ваши деньги. Поэтому теперь все ключи, которые являются и основным ключом валидатора и ауторизет виздравером, помечаются в сервисе validators.app желтым треугольником, вот таким:

Как его убрать, читаем тут.

Продолжаем установку Соланы.

Установка систюнера

Систюнер представляет собой набор настроек, которые оптимизируют операционную систему для работы Соланы. Так как систюнер уже встроен в Solana CLI, то мы можем или запускать его каждый раз перед запуском или рестартом Соланы вот так:

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

sudo bash -c "cat >/etc/sysctl.d/21-solana-validator.conf <<EOF
# Increase UDP buffer sizes
net.core.rmem_default = 134217728
net.core.rmem_max = 134217728
net.core.wmem_default = 134217728
net.core.wmem_max = 134217728

# Increase memory mapped files limit
vm.max_map_count = 1000000

# Increase number of allowed open file descriptors
fs.nr_open = 1000000
EOF"

sudo sysctl -p /etc/sysctl.d/21-solana-validator.conf

sudo bash -c "cat >/etc/security/limits.d/90-solana-nofiles.conf <<EOF
# Increase process file descriptor count limit
* - nofile 1000000
EOF"

Сервисный файл. Создание и настройка

Теперь создаем сервисный файл:

И записываем в этот файл следующее:

[Unit]
Description=Solana Node
After=network.target syslog.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=1
LimitNOFILE=1024000
Environment="SOLANA_METRICS_CONFIG=host=https://metrics.solana.com:8086,db=tds,u=testnet_write,p=c4fa841aa918bf8274e3e2a44d77568d9861b3ea"
ExecStart=/root/.local/share/solana/install/active_release/bin/solana-validator \
--entrypoint entrypoint.testnet.solana.com:8001 \
--entrypoint entrypoint2.testnet.solana.com:8001 \
--entrypoint entrypoint3.testnet.solana.com:8001 \
--known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on \
--known-validator 7XSY3MrYnK8vq693Rju17bbPkCN3Z7KvvfvJx4kdrsSY \
--known-validator Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN \
--known-validator 9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv \
--only-known-rpc \
--expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY \
--wal-recovery-mode skip_any_corrupted_record \
--identity /root/solana/validator-keypair.json \
--vote-account /root/solana/vote-account-keypair.json \
--ledger /root/solana/ledger \
--accounts /mnt/ramdisk/accounts \
--snapshot-interval-slots 500 \
--maximum-local-snapshot-age 1000 \
--maximum-snapshots-to-retain 1 \
--minimal-snapshot-download-speed 20485760 \
--limit-ledger-size 50000000 \
--dynamic-port-range 8000-8020 \
--log /root/solana/solana.log \
--private-rpc \
--rpc-port 8899
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
[Install]
WantedBy=multi-user.target

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

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

--snapshot-interval-slots 500 \
--maximum-local-snapshot-age 1000 \
--maximum-snapshots-to-retain 1 \

Вы можете поставить эти:

--incremental-snapshots \
--full-snapshot-interval-slots 25000 \
--incremental-snapshot-interval-slots 500 \
--maximum-full-snapshots-to-retain 1 \
--maximum-incremental-snapshots-to-retain 2 \
--maximum-local-snapshot-age 1500 \

Опишу каждый параметр я ниже.

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

--known-validator - известный нам валидатор, которому мы доверяем и с которого мы будем качать снепшоты в случае, если мы их не пишем на свой жесткий диск или они оказались повреждены. В случае, когда мы берем этих валидаторов с доков соланы (для каждого кластера свои кноун-валидаторы), то мы указываем ноды, которые принадлежат команде Соланы, также мы можем указать там своего друга и качать снепшоты с него (но чтобы это заработало, нужны настройки его ноды, ниже об этом будет сказано)

--only-known-rpc - запрещает вашей ноде качать снепшоты с НЕ известных вам валидаторов, если у вас стоит этот параметр, то вы будете качать снепшот только с тех валидаторов, которые указали в параметре --known-validator, если же этого параметра не будет, то сначала нода попробует скачать снепшот с кноун-валидаторов, и если не получится, начнет качать у других. Почему этот параметр может оказаться важным? Все потому, что он защищает кластер от злоумышленников. Если вдруг владелец ноды, с которой можно качать снепшоты, изменит снепшот и внедрит в него вредоностный код, то ноды, которые будут с него качать этот снепшот будут делать то, что нужно ему. Если в тестнете это не критично, так как перезапустить сеть не стоит денег, а вот в майннете это может дорогого стоить, поэтому в майннете лучше качать снепшоты с доверенных нод.

--expected-genesis-hash - Ожидание определенного хэша у генезиса

--wal-recovery-mode - Режим восстановления леджера

--identity - путь до нашего основного ключа

--vote-account - путь до нашего воут-аккаунта

--ledger - путь до леджера

--accounts - путь до папки с аккаунтами

--snapshot-interval-slots - интервал, через сколько слотов делать снепшоты

--snapshot-compression - сжимать или не сжимать снепшоты, которые мы записываем на диск, если указываем значение none - то не сжимаем, если вообще не указываем параметр "--snapshot-compression" в сервисном файле - то сжимаем

--snapshot-archive-format - в каком формате будем сжимать снепшоты, если их сжимаем. По дефолту - zstd, могут быть варианты: bz2, gzip, zstd, tar.

--maximum-local-snapshot-age - этот параметр необходим для того, чтобы нода стартовала с локального снепшота в том случае, если он моложе этого показателя. Если поставите значение 2000, то с локального будете стартовать тогда, когда ваш локальный снепшот младше 2000 слотов (менее 2000 слотов отстает от кластера на данный момент), если старше - нода скачает свежий снепшот с кластера.

--incremental-snapshots - наличие этого параметра в вашем сервисном файле говорит о том, что вы включили функцию инкрементальных снепшотов.

--full-snapshot-interval-slots - через сколько слотов делать полный снепшот кластера.

--incremental-snapshot-interval-slots - через сколько слотов делать инкрементальные снепшоты.

--maximum-full-snapshots-to-retain - максимальное количество полных снепшотов кластера, которые будут храниться в вашем леджере (или в том месте, где укажите, чтобы хранились ваши снепшоты)

--maximum-incremental-snapshots-to-retain - максимальное количество инкрементальных снепшотов, которые будут храниться в вашем леджере (или в том месте. где укажете, чтобы хранились ваши снепшоты

--maximum-snapshots-to-retain - сколько снепшотов хранить на диске (этот параметр используется в случае, если инкрементальные снепшоты мы не включали)

--minimal-snapshot-download-speed - минимальная скорость скачивания снепшотов, этот параметр будет работать только в том случае, если есть выбор откуда качать снепшоты. Если у нас стоит запрет на скачивание снепшотов с НЕ известных для нас валидаторов, то скачивание снепшота будет идти с тех, кого мы указали в списке известных валидаторов, вне зависимости от скорость, с которой это скачивание будет происходить.

--limit-ledger-size - ограничение размера леджера, которое исчесляется в шредах, что такое шреды читаем тут.

--dynamic-port-range - порты, на которые Солана будет принимать и отправлять трафик.

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

--private-rpc - запрещает другим валидаторам качать с вас снепшоты и выполнять другие действия с помощью RPC-команд, которые могут нагружать ваш сервер. Для обычных валидаторов (таких как мы) команда не советует открывать RPC наружу.

--rpc-bind-address - этот параметр раньше выполнял роль параметра --private-rpc, по идее его уже можно не использовать, на на всякий случай он есть в моем сервисном файле.

--rpc-port - на каком порте будет работать RPC, если вдруг вы решите ее открыть наружу и сделать доступной для других. В этом случае этот порт должен быть у вас открыт (если вы используете фаирвол)

--no-port-check - не выполнять проверку доступных портов для работы Соланы. Вы можете поставить этот параметр себе в сервисный файл после того, как проверите, что у вас Солана работает нормально и логах нет никаких ошибок, связанных с портами. Этот параметр может сократить время запуска Соланы после перезагрузки на несколько секунд.

Параметры, которые могут нам пригодиться в момент подъема кластера, после падения сети:

--expected-shred-version

--wait-for-supermajority - запускает работу ноды полностью только тогда, когда 80% стейка окажется на слоте, который на 1 меньше значение, которое указано в параметре

--no-snapshot-fetch - запрет на скачивание снепшотов с других валидатор. Старт с локального снепшота, если он есть

--no-genesis-fetch - не запрашивать из кластера данные о генезисе

Информацию по остальным параметрам вы можете найти в своем терминале введя команду:

Установка logrotate

Для чего нам нужно?

Логротейт позволяет нам создать ротацию для файла лога, если сказать простым языком, то файл с логированием всех событий в Солане мы режем на куски, которые по времени равны одному дню. Файлы, которые содержат логи старше чем за 7 дней система удаляет. Итого у нас в системе находится актуальный файл с логами за текущий день плюс 7 файлов логов за последние 7 дней. Файл с логами за каждый день в Солане весит около 10Гб, итого получается мы храним 70Гб логов за 7 дней плюс логи за текущий день.

Создаем файл в папке Solana:

nano solana.logrotate

И записываем в него следующее:

/root/solana/solana.log {
rotate 7
daily
missingok
postrotate
systemctl kill -s USR1 solana.service
endscript
}

Что значат эти параметры?

rotate 7 - храним 7 файлов;

daily - интервал файлов 1 день;

missingok - не записывать сообщение об ошибке, если файл с логом отсутсвует;

postrotate - после этой команды и между endscript записывается команда, которая будет выполнена после создания каждого файла с логами.

systemctl kill -s USR1 solana.service - отправляет сигнал USR1 процессу solana-validator (так называется процесс нашей ноды Соланы) на пересоздание лог файла.

Создание символических ссылок

Для чего нам нужны?

Символические ссылки это своеобразные ярлыки на файлы или папки в Windows, используем мы их для удобства, чтобы производить редактирование сервисного файла из папки solana, а не из папки /etc/systemd/system

Создаем символические ссылки следующими командами

для Соланы:

ln -s /root/solana/solana.service /etc/systemd/system

для логротейта:

ln -s /root/solana/solana.logrotate /etc/logrotate.d/

Включение сервиса Соланы и запуска ноды

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

systemctl daemon-reload
systemctl enable solana.service
systemctl start solana.service

systemctl daemon-reload - эта команда выполняет роль "мягкой" перезагрузки системы, обновляет конфигурации из файловой системы и восстанавливает деревья зависимостей.

systemctl enable solana.service - эта команда автоматически запускает Солану после перезагрузки вашего сервера.

systemctl start solana.service - запускает Солану.

Установка ноды под пользователем (не Root)

Администрирование ноды

Скачивание снепшота с быстрых RPC Node до рестарта соланы

Как заменить пароль на ключ и изменить порт для SSH

Как читать логи?

Мониторинг температуры

Установка аватарки и смена имени ноды на сайте валидатор.апс

Нода - узел, или программный комплекс, который осуществляет передачу информации в сети. В нашем случае эта сеть Соланы.

Эпоха - промежуток времени, который измеряется в слотах (не в секундах, минутах или часах). Эпоха составляет 432000 слотов, каждый слот занимает примерно 0,4-0,8 секунд. Время каждого слота зависит от загруженности сети, чем она выше, тем больше будет создаваться блок за во времени одного слота, если сеть не загружена вообще, то время на создание 1 блока за слот будет составляеть 0,4 секунды и эпоха продлится 432000 * 0,4 / 3600 = 48 часов.

Чтобы посмотреть текущее время эпохи используем команду:

Валидатор - человек, который занимается обслуживанием ноды. Чтобы посмотреть список всех валидаторов в сети используем команду:

Слот - период времени, в течение которого каждый лидер принимает транзакции в сети и создает блок. Чтобы посмотреть, какой сейчас слот в блокчейне, используем команду:

Блок - непрерывный набор записей в леджере, которые были подтверждены голосованием валидаторов. Лидер производит не более 1 блока за один слот.

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

Лидер-слот - слот во время которого лидер должен совершить блок, количество лидерслотов в текущей эпохе у валидатора можно посмотреть следующей командой:

Расписание лидер-слотов у валидатора можно посмотреть этой командой:

Внимание! Вместо GtgtQLfqKjn3gaHuH7Fw64n49vr2DrYHiJAsSTNNscAE поставьте публичный ключ своего валидатора, или того, чью информацию хотите посмотреть.

Скип рейт / Скип - показатель работы ноды, который рассчитывается как отношение количества пропущенных блоков к тем блокам, которые были в расписании на данный момент.

Скип рейт можно посмотреть следующей командой:

Внимание! Вместо GtgtQLfqKjn3gaHuH7Fw64n49vr2DrYHiJAsSTNNscAE поставьте публичный ключ своего валидатора, или того, чью информацию хотите посмотреть.

Кластер - набор валидаторов, которые поддерживают один леджер (единую сеть)

Кредит или войт-кредит - очки или баллы, которые получает нода за голосование внутри сети (подтверждение возможности и правильности транзакции)

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

Кошелек - набор пар ключей (публичный и приватный ключ), который позволяет пользователям управлять своими средствами.

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

Пара ключей (keypair) - представляет собой открытый (публичный) ключ и закрытый (приватный) ключ. Публичный ключ представляет собой запись типа - GtgtQLfqKjn3gaHuH7Fw64n49vr2DrYHiJAsSTNNscAE из 44 символов, а приватный ключ представляет собой или мнемоническую фразу из 12 слов (плюс еще можно добавить одну фразу, которая будет являться паролем - passphrase) или json файлом.

Лампорт - является минимальной единицей монеты Sol и составляет 0.000000001 Sol, аналогом у Биткоина является Сатоши.

Леджер - Список записей, который содержит в себе все транзакции, совершенные в сети. Реестр (леджер) каждого валидатора содержит около 50 000 000 шредов, которые охватывают транзакции одной эпохи. Получается, что в каждый момент времени каждый валидатор хранит у себя на ноде историю всех транзакций блокчейна только за одну эпоху. Остальная информация хранится в Google Big Table Storage и на других частных серверах.

Шред - часть блока, которая содержит определенное количество транзакций, это количество зависит от текущей пропускной способности сети (TPS).

TPS - Transactions per second, количество транзакций в секунду.

Транзакция - одна или несколько инструкций, которая была подписана одной или несколькими парами ключей, выполняемая автоматически. У транзакции может быть только 2 результата: успех или неудача.

Смарт-контракт - это программа в блокчейне, которая может считывать или изменять учетные записи, которыми она управляет.

Стейк - Монеты SOL, которые заделегированы на ноду валидатора и которые приносят прибыль. В зависимости от комиссии валидатора владелец стейка получает от 90% до 100% прибыли, которая на текущий месяц равняется около 7% годовых. Валидатор может установить любую комиссию от 0% до 100%, которую будет получать от владельца стейка. Но так как мы находимся в свободном рынке, и текущие предложения по комиссии со стейка составляют от 0% до 10%, то валидаторы с большей комиссией вряд ли получат стейк от владельцев стейка.

ID транзакции - Первая подпись в транзакции, которая может однозначно использоваться для идентификации транзакции в леджере.

Период прогрева (warmup period) - это период, который занимает одну эпоху после того, как стейк был делегирован валидатору. В этот период стейк имеет статус активации, активным он станет на следующую эпоху. Это относится и к лидер-слотам, которые получает валидатор. Если стейк стал активным в текущей эпохе, то лидер-слоты он получит только в следующей эпохе. Это работает и в другую сторону: если вы потеряли стейк в прошлой эпохе, то в текущей эпохе вы еще получите лидер-слоты (так как они будут выданы на основе стейка в прошлой эпохи), а вот в следующей (которая идет за эпохой без стейка), вы уже не получите лидер-слотов.

• Если мы это делаем в сети Testnet - то у нас нет токенов для того, чтобы появились слоты и можно было создавать лидер-блоки (о том, как работает блокчейн Solana читаем тут). А без токенов мы можем только голосовать. Тестовые токены мы не можем купить на бирже, но можем попробовать подоить кран, который в последнее время токенов не дает вообще, или попросить у тех, кто уже валидирует в тестовой сети и заработал на этом тестовых токенов.
• Если мы это делаем в сети Mainnet - мы можем купить токены на бирже, но Solana потребляет за 1 эпоху (в среднем 2 дня 18 часов) около 2 SOL на голосование внутри сети (о расчете прибыльности в Mainnet читаем тут), соответственно заниматься этим никто не будет, так как это получается сжиганием собственных денег.

Для того, чтобы держать ноду в тестовой и основной (Mainnet) сети было выгодно и интересно команда придумала программу делегации от фонда Solana и назвала эту программу Solana Foundation Delegation Program.

Для того, чтобы приступить к регистрации, нам нужны:

1. Электронная почта
2. Учетная запись в Discord
3. Паспорт
4. Собственное лицо
5. Ключ (или его еще можно назвать кошельком) для сети Testnet;
6. Ключ для сети Mainnet
7. Пополнить ключ в сети Mainnet на 0,002 Sol
8. Связать ключи между собой

Установка Solana CLI

Для данной процедуры нам нужно установить Solana CLI (Command Line Interface - интерфейс командной строки для Solana). CLI можно установить на Linux, Mac и Windows. В данной инструкции я буду использовать операционную систему Ubuntu. Вы можете арендовать любой VPS или выделенный сервер для этих процедур. Итак, приступим.

1. Подключаемся к серверу по SSH с помощью любого клиента (как арендовать сервер и азы командной строки можно узнать в этой статье).
2. На всякий случай обновляем все приложения в системе, вводим команду:

sudo apt update && sudo apt upgrade -y

и видим следующий скрин:

1. Переходим по ссылке на официальную документацию Solana и видим следующее:

3. Копируем команду полностью (можно нажать на правый краешек, там будет кнопка Copy и вставляем ее в командную строку (ctrl+v). Нажимаем Enter и видим процесс установки Solana CLI:

4. После завершения процесса установки система предложит нам ввести команду:

export PATH="/root/.local/share/solana/install/active_release/bin:$PATH"

Копируем команду из терминала (выделяем ее мышкой и нажимаем ctrl+c) и вставляем в терминал (ctrl+v) или можно скопировать прям из этого мануала, со временем эта команда не изменится.

5. Далее проверяем, все ли нормально установилось, проверить это можно командой:

solana --version

В итоге вы увидите текущую версию Solana CLI, которую вы только что установили, идем дальше.

Создание ключей

Создаем ключ для тестнета

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

solana-keygen new -o ~/validator-keypair.json

В результате мы увидим такую информацию:

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

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

/root/validator-keypair.json

Его публичный ключ (по этому адресу вам можно отправить токены Sol):

BZwURm4QzNVHC4KPrJKboeh4hzdANdA26EgmBvLiufFq

И ваша мнемоническая фраза:

patch security safe middle panda wonder remind way valley second cable plunge

Создаем ключ для майннета

Процедура абсолютно одинаковая, отличаться будет только имя вашего ключа, поэтому вводим следующую команду в терминале:

solana-keygen new -o ~/mainnet-validator-keypair.json

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

Связывание ключей

Эта процедура нам необходима для того, чтобы система понимала, какой валидатор из тестнета будет работать или работает в майннете. Хочется уточнить один важный момент. В этой связке основным ключом является ключ от тестнета, именно по этому ключу вы будете отслеживать себя в очереди. Если вы потеряете ключ майннета (до вхождения в майннет), то ничего страшного, вы сможете привязать новый ключ майннета к тестнету и не потеряете свою очередь. Но если вы потеряете все данные от ключа тестнета, то вам придется начинать все заново.

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

1. Переходим на сайт https://rustup.rs/ и копируем следующую команду (можно нажать на иконку справа от строчки):

Вводим ее в терминал, нажимаем Enter и видим:

Нажимаем 1 и Enter. Ожидаем когда программа скачает необходимые пакеты, после этого программа предлагает нам или перезапустить нашу сессию (отключиться от сервера и подключиться снова) или ввести команду. Я ввожу команду:

source $HOME/.cargo/env

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

sudo apt install build-essential clang libudev-dev pkg-config libhidapi-dev librust-openssl-sys-dev librocksdb-dev
sudo apt install libssl-dev libudev-dev pkg-config zlib1g-dev llvm clang

Вводим команду и видим:

Нажимаем Y и потом Enter. Теперь мы можем увидеть процесс установки. Ожидаем окончания и идем дальше.

3. Запускаем следующую команду

cargo install solana-foundation-delegation-program-cli

Запасайтесь терпением, процедура может длиться минут 5-10, это нормально.

Перевод Sol на кошелек.

Как я писал в самом начале, теперь нам нужно пополнить наш кошелек реальными Sol с биржи или с другого кошелька.

А теперь заходим на вашу биржу или кошелек и переводим 0,002 Sol на публичный ключ для тестнета. Проверяем, поступили ли они командой

solana balance validator-keypair.json -um

Если токены поступили, то вводим следующую команду:

Я хотел бы чтобы вы понимали все команды, которые вводите в командную строку, особенно это касается команд самой Соланы. В некоторых мануалах написано, что токены нужно переводить на кошелек майннета, в других написано, что на кошелек тестнета. Вы должны понимать, что нет никакой разницы, на какой кошелек вы будете переводить токены, которые будут служить комиссией за транзакцию (связку ключей, которая записывается в блокчейне). Обратите внимание на эту часть команды:

Именно эта часть команды и указывает, откуда мы будем списывать комиссию за совершение транзакции.

Все, кошельки мы связали, статус их можно проверить следующей командой:

Если вы увидите статус Pending - значит все хорошо. Когда статус сменится на Approved, это будет значить, что вас ждут в качестве валидатора в майннете.

Регистрация в программе SFDS

1. Переходим на сайт по ссылке и нажимаем на Apply now:

Вводим свои данные:

1. Ваше гражданство
2. Публичный ключ майннета
3. Публичный ключ тестнета

Жмем Next.

Далее вводим:

1. Ваше имя (на латинице)
2. Вашу фамилию (на латинице)
3. Адрес электронной почты
4. Имя учетной записи в дискорде
5. Проходим проверку, что мы человек, а не робот

Жмем Next.

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

Где указываем:

1. Фамилию и имя на английском языке, например, Ivanov Ivan
2. В эту графу записываем Individual (если вы физическое лицо)
3. Здесь пишем страну вашего гражданства, например, Russia

Далее спускаемся вниз и видим следующую информацию:

1. Это поле у вас уже будет заполнено автоматически, там будет Фамилия и Имя.
2. В это поле вам нужно будет кликнуть и с помощью мышки или тачпада поставить свою подпись, вот тут:

3. В этом поле у вас также будет ваше Имя и Фамилия, они должны там отобразиться автоматически.

4. В это поле вводим Mr. - если вы мужчина, Mrs или Miss - если женщина.

Жмем Далее (справа сверху синяя кнопка)

Теперь осталось дело за малым. Вам нужно выбрать документ, с помощью которого вы будете проходить процедуру KYC. Можно выбрать:

1. Паспорт
2. Водительские права
3. Национальное удостоверение личности

После выбора одного из документов вас перенаправит на страницу, на которой нужно выбрать с помощью камеры ноутбука вы будете фотографировать документы и снимать свое лицо или с помощью камеры своего телефона (с телефона вы можете отсканировать QR-код, который перекинет вас на сайт для прохождения KYC или отправить ссылку себе на почту, по которой вы сможете также пройти со своего телефона или с любого другого устройства)

Выбирайте то, что вам нравится.

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

Бывают ситуации, когда у вас или плохой свет, или просто фото документа сделали размытым, тогда система предложит вам или загрузить фото заново или сделать новые фото.

Через несколько минут (или часов) вам придет письмо, в котором будет написано следующее:

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

Содержание

Краткий путь валидатора в майннет по программе SFDP

Кратко путь попадания в майннет (по программе SFDP) через тестнет (иначе никак, в майннет (по программе SFDP) могут попасть только валидаторы, которые прошли весь путь в тестнете) можно представить так:

1. Связывание ключей регистрация в SFDP и прохождение KYC (об этом читаем тут)
2. Примерно 2 месяца ожидания.
3. Мониторинг своей примерной очереди в сервисе SolanaTools
4. Обнаруживаем в сервисе SolanaTools прочерк в своей очереди
5. Ищем свой ключ в пулреквесте на гитхабе проекта, сначала в открытом пулреквесте - тут, потом в закрытом пулреквесте - тут.
6. Ожидаем примерно одну эпоху и ждем, когда ключ появится тут.
7. Запускаем ноду и начинаем отслеживать свою очередь тут или тут.
8. Усердно работаем в течение 12-24 месяцев и попадаем в майннет! Ура!

Для отслеживания очереди мы будем пользоваться следующими ресурсами:

• Официальный сайт Solana
• Solana tools от Хуенга (если есть вопросы или предложения по сервису, пишем тут)
• Официальный гитхаб Solana

Очередь в тестнет

С этой очередью все не так просто. А все потому, что на данный момент отсутствует официальный сервис от команды, который мог бы поставлять актуальные данные о очереди в тестнет. На сайте SolanaTools есть возможность проверить момент, в который была совершена связка ключей (тестнет и майнет, как это делать читаем в этой статье), эта информация дает нам примерное понимание, когда ключ попадет в тестнет. Почему примерное? А потому что очередь идет не по времени связывания ключей, а по времени прохождения KYC, и получается ситуация, что человек ключ связал сегодня, а KYC прошел через месяц, соответственно его очередь идет с момента прохождения KYC. Если так получилось, то вот что мы увидим на сайте:

Первые ключи были связаны давным-давно, а в тестнет они до сих пор не попали. Почему? Потому что они до сих пор не прошли KYC.

Как определить через сколько времени вы попадете в тестнет? Нужно свою очередь делить на 100.

Когда ваш ключ будет добавлен в теснет вы увидите вот такие прочерки в очереди:

Как видите, 1 ключ зашел в тестнет в 255 эпохе, второй в 258. Хотя, этот прочерк еще не означает, что ключ уже зашел в тестнет и его видит бот, который начисляет стейк. Этот прочерк значит, что ваш ключ был добавлен в список, который в ближайшие 1-2 эпоху попадет в тестнет, его заметит бот и даст стейк.

Как видите на этом скриншоте, второй ключ до 245 эпохи не был в очереди в тестнет, связка ключе произошла в 247 эпоху и с этого момента начинается отсчет его очереди (в том случае, если в эту же эпоху человек также прошел KYC). Теперь нужно ждать, когда прочерк будет ПОСЛЕ цифр очереди.

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

Пулреквесты, а точнее открытые пулреквесты на добавление 100 ключей в бота. Пока этот пулреквест не закрыт, ключ в бота не попадет. Как вы можете заметить, в этот раз команда сделала сразу несколько пулреквестов, но это исключение, обычно каждую неделю можно увидеть только один пулреквест. Видимо, это связано с Рождественскими и Новогодними каникулами. Поэтому кликаем на 192 Closed (192 пулреквеста команда уже закрыла и добавила какую-то информацию в бота, это не обязательно могут быть ваши ключ, могут быть и другие исправления в коде бота) и видим следующее:

Мы видим что 3 дня назад был закрыт пулреквест номер 216, кликаем на этот пулреквест и видим в вот такую ссылку:

Переходим по ней и видим список ключей, который в этот раз команда добавила в тестнет:

Так отмечены ключи, которые в этом пулреквесте были добавлены в бота. Нажимаете ctrl+F и ищете свой ключ в этом списке, если вы есть - все отлично, ждем около 1 эпохи и вы в тестнете!

Если нашли свой ключ тут - https://raw.githubusercontent.com/solana-labs/stake-o-matic/master/bot/src/validator_list.rs значит, смело можете запускать свою ноду!

После того, как запустите ноду и синхронизируетесь с сетью, примерно в течение 1 эпохи вас заметит бот и заделегирует на вас 1 SOL. Информацию об этом сможете найти тут:

• https://raw.githubusercontent.com/wiki/solana-labs/stake-o-matic/md/Validator-PUBLIC-KEY.md вставив за место PUBLIC-KEY свой публичный ключ. Если там есть информация о вашем ключе - значит бот вас уже заметил, если видите - 404: Not Found, значит пока еще не успел заметить и обновить свою базу.
• Перейти по ссылке в самого бота - и в поле Find a Page... вбить свой публичный ключ, вот тут:

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

Очередь в майннет

Если вы уже находитесь в тестнете и можете найти свой публичный ключ по ссылке - https://raw.githubusercontent.com/wiki/solana-labs/stake-o-matic/md/Validator-PUBLIC-KEY.md (PUBLIC-KEY необходимо заменить на ваш публичный ключ в сети тестнет).

То идем на эту страницу и вводим сюда свой публичный ключ:

В итоге мы видим следующее:

1. Какой процент бонусных эпох ваша нода едет в тестнете начиная с 207 эпохи.
2. Какой процент бонусных эпох ваша ноде едет в тестнете за последние 13 эпох.
3. Какое количество кредитов заработала ваша нода за последние 64 эпохи. (формулу изменили, данный параметр больше не актуален и не используется в расчете очереди)
4. Здесь находится описание на английском, что значат цифры в первой колонке (нужно навести на эту область мышкой)
5. Здесь находится описание на английском, что значат цифры во второй колонке (нужно навести на эту область мышкой)
6. Здесь находится описание на английском, что значат цифры в третьей колонке (нужно навести на эту область мышкой)

Как мы видим на скриншоте выше, столбец Onbording priority у этого ключа ровняется 1594, что это значит? А значит это то, что этот ключ попадет в майнет примерно через 64 недели (1594 / 25 = 64).

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

Что нам несет эта динамическая очередь? А несет она нам очень часто потерю нервных клеток). Пока вы не наберете полные 64 эпохи (а это максимум, который вы можете заработать по кредитам) вы будете двигаться вперед быстрее, чем на 25 позиций в неделю. А вот когда наберете все 64 эпохи по кредитам, вот тогда ваша очередь станет двигаться медленнее, иногда будут случаться эпохи, когда вас будет отбрасывать назад в очереди. В этом нет ничего плохого.

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

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

На сайте есть:

1. Строка поиска ключа
2. Возможность отменить ключ как избранный (он будет всегда находиться вверху списка ключей)
3. Ссылка на ключ в гитхабе

На момент написания статьи ключ находился в очереди на 1594 месте, с 207 по 264 эпоху он ехал с бонусом 12,77% эпох, за последние 13 эпох он ехал 46,15% эпох с бонусом и за все время работы в тестнете он набрал 3 210 043 кредитов, показатель в 19,82% говорит нам о том, что ключ еще очень долго будет набирать свои максимальные 64 эпохи (сколько он проехал посмотрим дальше), итоговый балл на данный момент ключ имеет 24,64. Как писал выше, расчет такой:

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

1. Смотрим на предыдущий скриншот, находим там прямоугольник подписанный цифрой 3 и щелкаем на ключ, и попадаем на гитхаб проекта с информацией о ключе:

Опускаемся вниз и ищем эпоху с которой начинается * Stake level: **Bonus**

Почему этот ключ получил бонус? Потому что в 256 эпоху он набрал достаточное количество кредитов и закончил ее со скипом, ниже максимального (вот тут смотрим требования под каждую эпоху - для тестнета и для майннета), а также выполнил еще одно требование.

Давайте попробуем этот момент закрепить еще с помощью этого скриншота:

Мы тут видим следующее:

1. Номер эпохи, которая идет в данный момент (по ней нет еще информации в боте, так как она еще не закончилась)
2. Минимальное количество кредитов, которое нужно было набрать для получения базового стейка в 263 эпохе (она уже закончилась).
3. Максимально допустимый скип в 263 эпохе.
4. Номер эпохи, данные которой представлены выше (НЕ ниже!).

Продолжаем наш анализ...

В итоге в тестнете в 256 эпохе были следующие требования:

• Минимальное количество кредитов - 186 197 (кредиты за эпоху по этому ключу мы посмотрим чуть позже)
• Максимальный скип рейт - 42%
• Также валидатор не превысил максимальную концентрацию в 25% (что это такое, читаем в статье, как выбрать сервер)

Начинаем считать бонусные эпохи и видим, что в 259 эпохи его лишают бонусного стейка вот за это - Stake reason: Poor block production during epoch 259: 11 blocks in 20 slots, 45% skip rate. А какой был максимально разрешенный скип для этой эпохи (идем опять на гитхаб и ищем 259 эпоху)? Он был 42%. За это ключ и лишили бонусного стейка, а значит его откинет в очереди назад (на сколько, зависит от того, как едут его соседи). Лишением бонусного стейка нода потеряет как в первом показателе, так и во втором. На трений показатель (кредиты) проблема со скипом влияния не окажет).

Идем дальше.

Итого у этого ключа по состоянию на 262 эпоху:

• 6 бонусных эпох (начиная с 207 эпохи)
• 3 бонусные эпохи подряд

С расчетом первого показателя вручную могут быть сложности, потому что некоторые эпохи из-за проблем с ботом были не учтены в статистике (речь идет о бонусных эпохах, при этом в подсчете кредитов пропущенных эпох нет). Чтобы узнать, какие эпохи мы пропустили, придется выбрать любой ключ, который уже находится в майннете или скоро туда попадет и проанализировать пропуски:

Считаем количество эпох начиная с 207 (ее не берем) по 262 (ее считаем), у нас получается 47, из 47 эпох у этого ключа бонусных 6, получается:

6 / 47 * 100 = 12,77%

Рассчитываем второй показатель - 6 / 13 * 100 = 46,15%

Теперь самое интересное, расчет кредитов, у нас есть 2 варианта:

1. Взять данные из блокчейна
2. Взять данные с сайта Solana Foundation
3. Взять данные с сайта SolanaTools

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

1. В терминале ввести команду:

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

2. Переходим на сайт, вбиваем свой ключ и кликаем на данные:

Далее спускаемся вниз и кликаем по кнопке Show details

Вот тут и видим всю информацию по кредитам за ваши 64 эпохи (полные или нет):

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

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

Ну, всё. Теперь вы умеете анализировать очередь как в тестнете, так и в майннете, часто у людей возникают вопросы:

1. А почему моя нода уже несколько эпох стоит на месте и не продвигается вперед?

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

Во-первых вы уже набрали максимум по 2 (13 эпох закрыли с бонусами) или 3 показателю (проехали 64 эпохи), а остальные ноды, которые ехали за вами, начали их набирать в эти эпохи, поэтому показатели выравниваются или даже немного опережают вашу ноду, так как в тестнет пускают по 100 человек, а в майннет только по 25 поэтому за меньшее место в очереди очень высокая конкуренция. Анализируйте ноды, которые едут перед вами и за вами, эта информация даст понимание, почему так происходит конкретно с вашей нодой.

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

2. На сколько нужно ехать хорошо, чтобы опередить тех, кто зашел раньше, т.е. старичков?

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

Возьмем гипотетический ключ (ключ А), который едет со следующими показателями:

1 показатель - 60%, 2 показатель - 100%, 3 показатель 100% (такое хоть и не реально, но мы же просто фантазируем).

И есть другой ключ (ключ Б), который едет со следующими показателями:

1 показатель 79%, 2 показатель 100%, 3 показатель 88% (вот это вполне реальные цифры), считаем итоговый баллы по каждому ключу:

Ключ А - 60 * 0,25 + 100 * 0,25 + 100 * 0,50 = 15 + 25 + 50 = 90

Ключ Б - 79 * 0,25 + 100 * 0,25 + 88 * 0,50 = 19,75 + 25 + 44 = 88,75

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

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

Вот что мы увидим:

Сначала идут флаги (Flags), они представляют собой параметры к команде, которые сами по себе самодостаточны, т.е. нам не нужно к этому флагу дописывать еще что-то.

Далее идут опции (Options), они представляю собой также параметры к команде, но вот они уже требует какой то аргумент к ним и без него они не сработают, как видно на скрине выше у опции --config должен быть аргумент с путем к ключу.

Ну, и самое главное для нас - это Субкоманды:

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

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

В итоге увидим вот такой хелп по команде (в данном случае по субкоманде):

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

И видим следующее:

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

• Адрес получателя (Recipient_Address)
• Количество (Amount)

И ниже еще мы видим подсказку, в каком виде можно использовать эту команду:

Не бойтесь практиковаться в командах, когда находитесь в тестнете, времени у вас достаточно чтобы научиться всему. Валидатор в майннете должен уметь все и не задавать вопросы: "А как мне посмотреть кэчап?" или "А почему у меня нода не может догнать кластер?". Все эти знания вы должны получить во время тестнета.

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

Содержание

Работа с ключами

Создать ключ

Операции в разных кластерах

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

Например, хотим мы посмотреть баланс нашего идентифи ключа в кластере Майннет, для этого пишем команду:

Если хотим отправить токены в кластере Майннет, делаем так:

Посмотреть публичный адрес по json файлу

Бывает ситуация, когда есть json файл ключа, а вот его публичный адрес найти не получается, для этого есть команда:

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

Стейк, реварды, войт-аккаунт

Создать войт-аккаунт

Для начала нам нужно создать простой ключ, как это делать идем сюда

Потом создаем из этого ключа войт-аккаунт вот так:

В этой команде мы создаем войт-аккаунт, прикрепляем его к своему основному ключу (валидатор кейпейр) и назначаем ауторизет виздравером ключ authorized-withdrawer-keypair.json. На данный момент именно так и рекомендуется создавать воут-аккаунт. А раньше можно было так:

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

Сменить виздравера для войт аккаунта

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

/root/solana/vote-account-keypair.json - ваш ключ войт аккаунта;

/root/solana/authorized-withdrawer-keypair.json - текущий ауторизет виздравер

/root/solana/authorized-withdrawer-keypair-new.json - новый ауторизет виздравер

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

Сменить виздравера для стейк аккаунта

Для смены виздравера у стейк аккаунта нам нужны следующие ключи:

EiZkmYw4t5gQT6srAGN5jM28UYsB8GH5L8nbqTm31WFL - публичный ключ вашего стейк аккаунта (можно использовать и файл, если он у вас есть)

/root/solana/authorized-withdrawer-keypair-new.json - новый виздравер

/root/solana/authorized-withdrawer-keypair.json - старый виздравер, которым мы подпишем транзакцию

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

Информация о стейке

Заделегировать токены

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

1. Создать новый ключ (абсолютной не важно как вы его назовете, но я назову его validator-stake-keypair.json) следующей командой:

2. Делаем из этого ключа стейк-аккаунт с указанием суммы, которую мы хотим в будущем делегировать на войт-аккаунт и сразу же в этой команде назначаем этому стейк-аккаунту ключ с правами stake-authority и withdraw-authority, т.е. мы задаем для стейк-аккаунта виздравера. Нам это нужно для того, чтобы в майннете бот определил наш стейк как селф-стейк. В тестнете это делать не обязательно, но лучше потренироваться сразу там.

3. Делегируем стейк на войт-аккаунт, если мы делегируем на свой войт-аккаунт, то легче всего нам указать его файл, а не публичный ключ, вот так:

А если мы хотим заделегировать на войт-аккаунт другого валидатора, то его ключа в формате json у нас конечно же нет, поэтому будем использовать публичный ключ этого войт-аккаунта, и команда будет выглядеть вот так:

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

или

И видим следующее:

1. Публичный ключ стейк-аккаунта
2. Баланс, который находится на этом стейк-аккаунте (так как он заделегирован валидатору, то этот баланс считается замороженным)
3. Жду ответ по вопросу
4. Делегированный стейк, тот, который фактически сейчас находится на воут-аккаунте.
5. Активный стейк, который уже активно участвует в голосовании в сети.
6. Публичный ключ воут-аккаунта, куда этот стейк заделегирован.
7. Stake Authority -
8. Withdraw Authority - публичный ключ, который имеет право забрать этот стейк назад (подробнее об этом ключе читаем тут)
9. Номер эпохи, когда стейк будет деактивирован, активация и деактивация стейка занимает ровно 1 эпоху. (в вашем случае после делегирования стейка будет написано Stake activates starting from epoch: № эпохи.)

Узнать сколько ревардов было заработано

За последнюю эпоху:

За последние 10 эпох (больше посмотреть не получается)

Забрать реварды

Теперь каждую эпоху мы можем забирать с этого стейка свои реварды (как они рассчитываются читаем тут) следующей командой:

В этой команде мы забираем реварды в количестве 50 токенов и переводим их на ключ 5cNEV9dx5Puuwp2GSZsUwUchCGfxchcxS6rNuD6yNGEh, при этом для подписания этой транзакции мы используем authorized-withdrawer (кто это такой - читаем тут)

В том случае, если вы не задавали authorized-withdrawer для воут-аккаунта в процессе его создания (как создавать его читаем тут), то команда будет иметь такой вид:

В этом случае подписывает транзакцию ваш основной ключ (validator-keypair.json), так как он тоже является authorized-withdrawer, т.е. имеет право на управление воут-ключем (разбираемся в этом вопросе подробнее тут).

Также вы можете забрать все реварды с воут-аккаунта следующей командой:

Деактивировать стейк

На деакцтивацию стейка, как и на активацию необходима 1 эпоха.

Забрать стейк со стейк аккаунта

Объединить стейки

Если вы сделали несколько стейк аккаунтов (и они в данный момент имеют статус active) и хотите объединить их в один, можете это сделать следующей командой:

В случае успеха этот ключ перестанет быть стейк-аккаунтом - /root/solana/validator-stake2-keypair.json, а весь стейк с него перейдет в этот стейк-аккаунт - /root/solana/validator-stake1-keypair.json

Изменить комиссию войт-аккаунта

Если вы не создавали для войт-аккаунта authorized-withdrawer

Если вы создавали authorized-withdrawer и связывали его с войт-аккаунтом

Что в первом, что во втором случае меняем мой публичный ключ войт-акканута, вот этот - 81iuTYDaeJ71XFGkPXNUuQ8gNvHQfBxpU7Vj2hzJ9Q4e на свой публичный ключ войт-аккаунта

Отправка токенов

На кошелек, на котором уже были токены:

На кошелек, на котором еще не было токенов (только что создали, например):

Убрать желтый треугольник

Кэчап

Проверка кэчапа в на текущий момент:

Проверка кэчапа в течение времени (пока не остановите его с помощью сочетания клавиш ctrl+C)

Как посмотреть свои кредиты и место по кредитам

Заменяем мой публичный ключ на свой.

Как посмотреть свой скип в текущей эпохе и сколько слотов уже сделано/пропущено

Заменяем мой публичный ключ на свой.

Сколько слотов запланировано в данную эпоху

Заменяем мой публичный ключ на свой.

Как посмотреть, какие слоты я уже сделал или пропустил в текущей эпохе

Заменяем мой публичный ключ на свой.

Средний скипрейт по кластеру

Информация по кластеру (сколько валидаторов на какой версии соланы и др.)

Посмотреть сколько нод сейчас не в сети (делинкет)

Информация о текущей эпохе

Узнать текущий слот

Логи соланы и журнал solana.service

Посмотреть логи соланы

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

Посмотреть системный журнал Solana.service

Если вы введете эту команду, то окажитесь на 1 странице системного журнала Соланы, которая вмещает в себя информацию в размере 46 строк (в моем случае 46 строк, у вас может быть больше или меньше, зависет о разрешения экрана), и тут есть сложность посмотреть последние страницы системного журнала Соланы, так как перелистывать его нужно пробелом. Если у вас нода работает давно, то таких страниц у вас может быть много, поэтому чтобы переместиться сразу на последнюю страницу системного журана Соланы, на которой вы увидите актуальную информацию по событиям, используем ключ -e и команда будет выглядеть так:

Посмотреть записей системного журнала Solana.service в режиме потока

Команды установки и обслуживания ноды

Установить Solana CLI

Подставляем необходимую версию за место "1.9.1". Актуальную версию смотрим в официальном дискорде команды - https://discord.gg/solana в канале testnet-announcements (для тестнета) и в канале mb-announcements (для майннета)

Обновить Solana

Подставляем необходимую версию за место "1.9.1". Актуальную версию смотрим в официальном дискорде команды - https://discord.gg/solana в канале testnet-announcements (для тестнета) и в канале mb-announcements (для майннета)

Запустить Solana (ноду)

или

Перезапустить Solana (рестарт ноды)

или

Остановить Solana (ноду)

или

Посмотреть статус Solana (ноды)

или

Перезагрузить демона

Команду необходимо запускать после внесения любых изменений в сервисный файл solana.service

Установить в конфиг кластер по умолчанию

Актуальные данные для каждого кластера лучше смотреть тут

Тестнет

Майннет

Девнет

Установить в конфиг ключ по умолчанию

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

1. О солане
1. Регистрация в качестве валидатора для получения стейка от фонда
2. Документация
3. Как работает блокчейн
4. Технические требования к железу
5. Тестнет, майннет, девнет. В чем разница?
6. Консольные команды
1. Стейк, реварды
2. Authorized withdrawer
3. Отправка токенов
4. Убрать желтый треугольник
5. Селфстейк для майнета
6. Кэчап
7. Информация о стейке
8. Как посмотреть свои кредиты
9. Как посмотреть свой скип в текущей эпохе
10. Сколько слотов запланировано в текущей эпохе
11. Как посмотреть сколько слотов сделано или пропущено в данной эпохе
7. Как учиться работать с Solana самостоятельно?
8. Github Solana, что там интересного?
1. Stake-o-maitc
2. Pull request (PL) ключей в тестнет
3. Версии новых релизов и чейнджлог
9. Полезная информация от команды Solana
2. Деньги
1. Сколько нужно денег для старта?
2. Сколько сейчас зарабатывают валидаторы?
3. А сколько я буду зарабатывать, когда попаду в Майннет?
4. Как долго нода в Майннете будет оставаться рентабельной?
5. Как получить стейк от пула Marinade.
3. Дата-центры
1. Hetzner (Хецнер)
2. OVH (ОВХ)
3. Mevspace (бывший skynode.eu)
4. Reliable (Релайбл)
5. Webtopia (Вебтопия)
6. Ikula (Икула)
7. Ionos (Айнос)
4. Домашнее нодоводство
5. Как диагностировать проблемы с нодой? Что делать, если большой скип?
6. Очередь в тестнет и майннет. Как работает? Как считать?
7. Настройка сервера, установка ноды, администрирование
1. Raid0
2. Firewall
3. Скачивание снепшота с быстрых нод до рестарта Solana
4. Как сменить пароль на ssh-ключ и изменить порт для SSH
5. Как читать логи?
6. Проверка дисков
7. Проверка интернета
8. Проверка оперативной памяти
9. Мониторинг температуры
10. Установка аватарки и смена имени ноды для сайта validators.app
8. Мониторинг
1. Телеграф
2. Телеграм бот
9. Установка GPU для Solana