Отправляем транзакцию в cosmos-based сетях с нулём комиссии на примере Quicksilver.

Есть токены с генезиса, но они все залоченные, то есть нетрансферабельные.

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

Гениальный мув от команды Quicksilver, похлопаем.

Решение простое: добавить сеть в кеплер с кастомным рпц, нода которого принимает транзакции с 0 fees.

Первым делом импортируем кошель в Keplr по мнемонике из тестнета.

Теперь нам нужно добавить сеть quicksilver-1 в Keplr, для этого воспользуемся тулзой от акселара. Вставляем в поле конфиг нашего квиксильвера:

{
    "chainId": "quicksilver-1",
    "chainName": "quicksilver-m",
    "rpc": "http://quick.cyberomanov.tech:11241",
    "rest": "https://quick.api.m.stavr.tech",
    "bip44": {
        "coinType": 118
    },
    "coinType": 118,
    "bech32Config": {
        "bech32PrefixAccAddr": "quick",
        "bech32PrefixAccPub": "quickpub",
        "bech32PrefixValAddr": "quickvaloper",
        "bech32PrefixValPub": "quickvaloperpub",
        "bech32PrefixConsAddr": "quickvalcons",
        "bech32PrefixConsPub": "quickvalconspub"
    },
    "currencies": [
        {
            "coinDenom": "uqck",
            "coinMinimalDenom": "uqck",
            "coinDecimals": 6,
            "coinGeckoId": "unknown"
        }
    ],
    "feeCurrencies": [
        {
            "coinDenom": "uqck",
            "coinMinimalDenom": "uqck",
            "coinDecimals": 6,
            "coinGeckoId": "unknown"
        }
    ],
    "stakeCurrency": {
        "coinDenom": "uqck",
        "coinMinimalDenom": "uqck",
        "coinDecimals": 6,
        "coinGeckoId": "unknown"
    },
    "gasPriceStep": {
        "low": 0,
        "average": 0.025,
        "high": 0.03
    },
    "features": []
}

И добавляем сеть в кеплер:

Не апрувим, а нажимаем Add chain as suggested:

А теперь апрувим. Если добавилась сеть Quicksilver, то удаляем её и начинаем заново процедуру. Нам нужна сеть quicksilver-m.

Супер, сеть добавлена. Теперь попробуем заделегировать наши нетрансферабельные токены с 0 fees.

Переходим по ссылке и выбираем любого валидатора. Я показывать буду на своём, делегации приветствуются. Нажимаем Delegate:

Затем коннектим кошелёк:

Отлично, аккаунт добавлен. Теперь нужно вернуться на страницу с кнопкой Delegate и попытаться заделегировать с 0 fees.

Обязательно открываем Advanced настройки и выставляем Fee - 0, Gas - 250k.

Обязательно выбираем Low:

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

мамичу за то, что родила такого гения.

@how_to_node - канал, где я выкладываю свои гайды.

Полезные ресурсы.

Крипто-кошельки автора гайда.

Изучаем Bundlr Network, Arweave и участвуем в первом невознаграждаемом тестнете.

• Описание проекта:
• Введение в Bundlr Network;
• Отличия в методике хранения данных между Arweave, IPFS и AWS;
• Зачем нужен Bundlr и как он работает;
• Партнёры, бэкеры и активности.
• Нода:
• Установка;
• Ванлайнер от AMB;
• Ручная установка.
• Полезные команды при работе с нодой;
• Обновление;
• Перенос и бэкап: пригодится при переезде;
• Удаление ноды: на будущее.
• Благодарности.
• Полезные ресурсы на каждый день.

Bundlr - это layer 2 сеть над Arweave, которая позволяет записывать любые данные в децентрализованное хранилище в тысячи раз быстрее, дешевле и удобнее.

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

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

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

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

Ключевые особенности в подходе Bundlr к хранению данных:

• Данные не хранятся в одном месте, где они подвержены взломам и вредоносным атакам;
• Данные не принадлежат одному объекту, поэтому нет единого органа, который мог бы изменить данные или заблокировать вам доступ к ним;
• Данные хранятся вечно, поэтому не могут быть потеряны;
• Данные, загруженные в Bundlr, доступны мгновенно и в любой момент времени;
• Инфраструктура проста и интуитивно понятна в своём использовании;
• Bundlr позволяет оплачивать комиссии за транзакции в разных криптовалютах.

Решение Bundlr бесконечно масштабируемо и уже поддерживает такие сети, как: Solana, Ethereum, Polygon и Avalanche.

Bundlr создаёт самый безопасный, быстрый, удобный и долговечный способ хранения данных.

Amazon Web Services (AWS) - облачная платформа, насчитывающая миллионы клиентов, включая самые быстрорастущие стартапы, крупнейшие предприятия и ведущие государственные учреждения.

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

Главная проблема AWS в том, что данные могут быть навсегда потеряны: специально (если не оплачивать подписку) или случайно (в случае выхода оборудования из строя).

InterPlanetary File System (IPFS) - одноранговая децентрализованная файловая система с открытым исходным кодом.

Вроде бы всё хорошо: децентрализация и безопасность. Но и такая система не безупречна. IPFS не хранит информацию вечно.

Ноды, хранящие данные, не заинтересованы в вечном хранении данных и в конечном итоге сталкиваются с ограничением в пропускной способности: заканчивается место на жёстком диске. Запускается процесс, так называемый Garbage Collection (Сборкой Мусора), в процессе которого удаляются данные, которые система считает не такими уж и важными.

Один из популярных среди нодраннеров сервисов, использующих и предоставляющих доступ к ETH и IPFS, является Infura.

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

Arweave - единственное децентрализованное решение для вечного хранения данных.

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

Когда данные загружаются в Arweave, узлы получают награду за хранение данных, поэтому не возникает риска их утери.

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

Этот способ так же не бесплатен. Если вы хотите загрузить данные в Arweave и сохранить их навсегда, вам потребуется заплатить комиссию за транзакцию.

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

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

One-time-payment и ваши данные никогда не будут удалены или утеряны, но всегда будут доступны в любой момент времени.

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

Это позволяет пользователям оплачивать загрузку данных различными токенами, такими как ETH, SOL, MATIC, DOT и многими другими.

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

Уже сейчас Bundlr обрабатывает более 90% всех загрузок данных в Arweave.

Сеть состоит из:

- Bundlers: ноды-работяги, которые собирают несколько транзакций на layer 2 в одну большую транзакцию (bundle) и записывают метод оплаты комиссии (SOL, MATIC, BNB и другие);

- Bundles: пакеты транзакций на layer 2, которые были собраны бандлером и должны быть отправлены в основную сеть;

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

- Gateways: ноды-библиотекари, которые присваивают индексы бандлам, чтобы при необходимости быстро получать данные из Arweave блокчейна.

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

Менее чем за год Bundlr заключила партнерские отношения с ведущими сетями, такими как Polygon, Boba Network, Arbitrum, ZKSynk, Avalanche, Ethereum, Binance SC, Polkadot, Solana, чтобы предложить разработчикам легкий доступ к Arweave.

Проект также сотрудничает с ведущими рынками NFT, такими как Metaplex и Salsa, чтобы они могли хранить важные данные, такие как метаданные NFT, в Arweave, а также с Ethsign, Mintbase, Olta, FormFunction и KYVE.

“Цель Bundler - реализовать масс-адопшн Arweave. Технология Arweave потрясающая, но ей нужно стать более удобной в использовании. С помощью нашей технологии, мы позволяем этому сбыться. Существует так много возможностей для вечного хранения данных в Web3 и мы воодушевлены помочь росту популярности и доступности Arweave."

Josh Benaron, фаундер и CEO Bundlr Network.

Количество данных, загруженных на Arweave, выросло более чем на 450% после запуска Bundlr Network.

В ходе сида 4 мая собрали $5,200,000 от Hypersphere Ventures, arweave.org, Permanent Ventures, Framework, OpenSea Ventures и Race Capital.

Сейчас проходит девнет, после чего запланирован тестнет и, собственно, инсентив.

Можно подписаться на все соц. сети и поиграться с девнет-веб-интерфейсом.

Как таковой "ноды" на данный момент нет, но в ближайшем будущем обещают активности.

Blog | Docs | GitHub | WebSite | Twitter | Discord | Telegram | Chat_RU

Требования по железу:

Официальные требования: 4 CPU x 8 GB RAM x 250 GB SSD - Ubuntu 20.04.
Субъективные наблюдения: 2 CPU x 4 GB RAM x 250 GB SSD - Ubuntu 20.04.

Для лентяев/опытных пользователей AMB.place подготовили однострочник. Это bash-скрипт, который выполняет почти всю установку за вас.

# фрилайнер на самом деле
curl -s https://raw.githubusercontent.com/Kallen-c/Bundlr/main/Bundlr.sh > bundlr.sh && \
chmod +x bundlr.sh && \
bash bundlr.sh

# обновляем 'базу данных', обновляем дистрибутив
sudo apt-get update && sudo apt-get upgrade -y

# скачиваем необходимые зависимости одной командой
sudo apt-get install curl wget git jq libpq-dev libssl-dev \
build-essential pkg-config openssl ocl-icd-opencl-dev \
libopencl-clang-dev libgomp1 -y

# устанавливаем 'docker' и 'docker-compose' одной командой
. <(wget -qO- https://raw.githubusercontent.com/SecorD0/utils/main/installers/docker.sh)

# устанавливаем 'rust' одной командой
curl https://sh.rustup.rs -sSf | sh -s -- -y

# проверяем версию 'cargo' одной командой
source "$HOME/.cargo/env" && \
echo -e "\n$(cargo --version).\n"

# устанавливаем 'nodejs' и 'npm' одной командой
curl -sL https://deb.nodesource.com/setup_16.x | sudo -E bash - && \
sudo apt-get install nodejs -y && \
echo -e "\nnodejs > $(node --version).\nnpm  >>> v$(npm --version).\n"

# создаём каталог 'bundlr' и переходим в него одной командой
mkdir $HOME/bundlr; cd $HOME/bundlr

# клонируем репозиторий 'validator-rust' одной командой
git clone \
--recurse-submodules https://github.com/Bundlr-Network/validator-rust.git

# генерируем 'wallet.json' одной командой
cd $HOME/bundlr/validator-rust && \
cargo run --bin wallet-tool create > wallet.json

Многочисленные warning - нормально, игнорируем.

# выводим адрес одной командой
cd $HOME/bundlr/validator-rust && \
cargo run --bin wallet-tool show-address \
--wallet wallet.json | jq ".address" | tr -d '"'

Предпоследняя строка - ваш адрес. В моём случае: erjX8M5...FwM.

Переходим на страницу с краном и запрашиваем токены на только что сгенерированный кошелёк.

Создаём некоторые переменные.

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

# создаём переменную с портом
PORT=2109

Создаём вторую переменную с адресом нашего кошелька (мы генерировали его в прошлом пункте).

# создаём переменную с адресом, используйте адрес своего кошелька
# например, ADDRESS=erjX8M5_PUGEOQN0sFY6_cQqLOUl4x7iHEnfXFIyFwM
ADDRESS=erj...FwM

# сохраняем наши переменные
echo "export BUNDLR_PORT="${PORT}"" >> $HOME/.bash_profile
echo "export BUNDLR_ADDRESS="${ADDRESS}"" >> $HOME/.bash_profile

# чтобы переменные загрузились, необходимо перезагрузить '.bash_profile'
source $HOME/.bash_profile

# проверим значения переменных
echo -e "\nport >>>> ${BUNDLR_PORT}.\naddress > ${BUNDLR_ADDRESS}.\n"

# создаём '.env' одной командой, ничего не трогая
sudo tee <<EOF >/dev/null $HOME/bundlr/validator-rust/.env
PORT=${BUNDLR_PORT}
VALIDATOR_KEY=./wallet.json
BUNDLER_URL=https://testnet1.bundlr.network
GW_WALLET=./wallet.json
GW_CONTRACT=RkinCLBlY4L5GZFv8gCFcrygTyd5Xm91CzKlR6qxhKA
GW_ARWEAVE=https://arweave.testnet1.bundlr.network
EOF

# проверяем актуальность
cat $HOME/bundlr/validator-rust/.env

# поднимаем 'docker-compose' в фоне
cd $HOME/bundlr/validator-rust && \
docker-compose up -d

Начинается билд. Он может продлиться 5-30 минут в зависимости от мощностей сервера.

# наблюдаем логи 'docker-compose' одной командой
cd $HOME/bundlr/validator-rust && \
docker-compose logs -f --tail 10

Насколько я понимаю, так выглядят адекватные логи:

Закрываем логи с помощью Ctrl + C и едем дальше.

# билдим 'testnet-cli' одной командой
cd $HOME/bundlr/validator-rust && \
npm i -g @bundlr-network/testnet-cli

# проверяем баланс кошелька одной командой
cd $HOME/bundlr/validator-rust && \
testnet-cli balance ${BUNDLR_ADDRESS}

Баланс в очень много нулей обозначает то, что сейчас вы можете зарегистрировать валидатора.

# присоединяемся к сети одной командой, ничего не трогая
cd $HOME/bundlr/validator-rust && \
testnet-cli join RkinCLBlY4L5GZFv8gCFcrygTyd5Xm91CzKlR6qxhKA \
-w ./wallet.json \
-u "http://$(wget -qO- eth0.me):${BUNDLR_PORT}" \
-s 25000000000000

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

Теперь мы можем перейти в эксплорер и найти своего валидатора:

Есть вероятность, что валидатор появляется в эксплорере в начале следующей эпохи. Каждая эпоха длится примерно 30 минут.

Возможно, придётся подождать несколько десятков минут перед тем, как валидатор отобразится в эксплорере.

Вот и всё. В ближайших тестнетах подвезут стейкинг и другие тулсы!

# рестарт докера одной командой
cd $HOME/bundlr/validator-rust && \
docker-compose restart

# остановка докера одной командой
cd $HOME/bundlr/validator-rust && \
docker-compose stop

# запуск докера одной командой
cd $HOME/bundlr/validator-rust && \
docker-compose up -d

# удаление докера одной командой
cd $HOME/bundlr/validator-rust && \
docker-compose down -v

# просмотр логов докера
cd $HOME/bundlr/validator-rust && \
docker-compose logs -f --tail 10

# посмотреть адрес кошелька #1
cd $HOME/bundlr/validator-rust && \
cargo run --bin wallet-tool show-address \
--wallet wallet.json | jq ".address" | tr -d '"'

# посмотреть адрес кошелька #2
echo ${BUNDLR_ADDRESS}

# посмотреть баланс кошелька
cd $HOME/bundlr/validator-rust && \
testnet-cli balance ${BUNDLR_ADDRESS}

# обновляемся одной командой
cd $HOME/bundlr/validator-rust && \
git pull origin master && \
docker-compose up --build -d

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

# останавливаем и удаляем контейнер
cd $HOME/bundlr/validator-rust && \
docker-compose down -v

# удаляем каталог 'bundlr'
rm -Rvf $HOME/bundlr

мамичу за то, что родила такого гения.

@how_to_node - канал, где я выкладываю свои гайды.

Полезные ресурсы.

Крипто-кошельки автора гайда.

Устанавливаем фармер Subspace для участия в открытом тесте без наград Gemini-3c.

Описание проекта: несколько слов о проекте, условия участия в ивенте.

Нода:

• Установка ноды;
• Polkadot wallet;
• Инициализация;
• Сервисный файл;
• Телеметрия и TSSC.

Полезные вещи:

• Полезные команды при работе с нодой;
• Обновление;
• Перенос и бэкап: пригодится при переезде;
• Удаление ноды: на будущее.

Благодарности.

Полезные ресурсы на каждый день.

Subspace Network - сеть, позволяющая разработчикам очень просто и быстро развёртывать децентрализованные Web3-приложения, которые, в свою очередь, могут автоматически масштабироваться при необходимости.

Полная интеграция с Polkadot & Kusama, в ближайшем будущем и с EVM.

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

Эти проблемы позволяет решить свежая реализация proof-of-capacity (PoC). Знакомые нам аналоги на PoC: Chia, Spacemesh, Filecoin.

Вводим новое понятие - дилемма фермера. Более подробно почитать о проблеме можно тут, но грубый смысл в том, что, невозможно бесконечно хранить бесконечное количество данных. когда-нибудь придётся чем-то пожертвовать: децентрализацией или “качеством” данных.

Subspace считает, что его аналоги вообще не решают дилемму фермера: кто-то слишком централизован, кто-то не умеет в масштабирование, а кто-то вообще файлкойн.

Так как же Subspace решает задачу?

Subspace работает на основе консенсуса proof-of-archive-storage (PoAS) или “доказательство хранения архивной истории блокчейна”.

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

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

Чем больше фермер выделяет пространства, тем больший шанс он имеет быть выбранным для создания блока.

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

Вводим ещё одно умное словосочетание: блокчейн-трилемма.

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

Subspace предлагает следующее решение: разделить консенсус и вычисления.

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

Исполнитель выбирается на основе его доли: больше стейк > чаще избирается для завершения блока > больше награда.

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

Инвесторы: более $37kk от Coinbase, IOSG, Republic, Crypto.com, Alameda, Pantera, Hypersphere, Bixin, Vendetta, NGC, Gate и других.

Medium | GitHub | WebSite | Twitter | Discord | Telegram | Ru_Telegram

Требования по железу:

Официальные требования: 4 CPU x 4 GB RAM x 50 GB SSD - Ubuntu 20.04.

# обновляем 'базу данных', обновляем дистрибутив
sudo apt-get update && sudo apt-get upgrade -y

# скачиваем необходимые зависимости одной командой
sudo apt-get install wget jq ocl-icd-opencl-dev \
libopencl-clang-dev libgomp1 ocl-icd-libopencl1 -y

# скачиваем исполняемые файлы и выводим их версии одной командой
mkdir $HOME/subspace >/dev/null 2>&1 && \
cd $HOME/subspace && \
VER=$(wget -qO- https://api.github.com/repos/subspace/subspace-cli/releases | jq '.[] | select(.prerelease==false) | select(.draft==false) | .html_url' | grep -Eo "v[0-9]*.[0-9]*.[0-9]*" | head -n 1) && \
wget https://github.com/subspace/subspace-cli/releases/download/${VER}/subspace-cli-ubuntu-x86_64-v3-${VER} -qO subspace; \
sudo chmod 777 * && \
if [[ $(./subspace -h) == "" ]]; then
  echo -e "\n\ndat sh*t is broken, ping @cyberomanov.\n\n"
else
  sudo mv * /usr/local/bin/ && \
  echo -e "\n\nrelease >> ${VER}.\n\n"
fi && \
cd $HOME && \
rm -Rvf $HOME/subspace >/dev/null 2>&1

Или

Теперь нам нужен кошелёк. Переходим на дашборд Subspace Gemini 3c и копируем адрес нашего кошелька.

Если по каким-то причинам у вас ещё нет кошелька полькусамы, нужно скачать polkadot.js расширение и сгенерировать кошелёк там.

На этот адрес мы будем фармить TSSC токены, как доказательство участия в тестнете.

# инициализируемся
subspace init

1. Вводим кошелёк из прошлого пункта;
2. Вводим желаемый никнейм;
3. Путь к плотам я оставил по дефолту (просто нажать Enter);
4. Размер плота выставил 100 GB, но это индивидуально;
5. Сеть оставил по дефолту (просто нажать Enter).

После данного шага по пути /root/.config/subspace-cli/settings.toml появится конфигурационный файл, который можно отредактировать ручками, если очень хочется:

# фиксим журнал
sudo tee <<EOF >/dev/null /etc/systemd/journald.conf
Storage=persistent
EOF

# рестартим журнал
sudo systemctl restart systemd-journald

# создаём файл сервиса для запуска ноды
sudo tee <<EOF >/dev/null /etc/systemd/system/subspaced.service
[Unit]
Description=Subspace Node
After=network.target
[Service]
Type=simple
User=$USER
ExecStart=$(which subspace) farm -v
Restart=always
RestartSec=3
LimitNOFILE=1024000
[Install]
WantedBy=multi-user.target
EOF

# запускаем ноду
sudo systemctl daemon-reload && \
sudo systemctl enable subspaced && \
sudo systemctl restart subspaced

# проверяем логи
sudo journalctl -fu subspaced --no-hostname -o cat

За синхронизацией можно следить в прямом эфире с помощью команды:

sudo journalctl -fu subspaced -o cat | grep -E "best"

Ещё можно наблюдать синхронизацию в телеметрии, но она часто отваливается.

"Идеальную" высоту можно найти в экслорере.

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

Вот и всё. Фармим TSSC и ждём окончания инсентивайза стресс-теста.

# пезапуск фармера и ноды
sudo systemctl restart subspaced

# остановка фармера и ноды
sudo systemctl stop subspaced

# проверяем логи
sudo journalctl -fu subspaced --no-hostname -o cat

# останавливаем сервисы ноды и фармера
sudo systemctl stop subspaced

# чистим данные старой сети одной командой
# только, если ушли в форк или хотите начать синхронизацию с нуля
subspace wipe && rm -Rvf $HOME/.local/share/subspace-cli/node/chains/*

Пробегаемся по установке с самого начала.

Бэкапа, как такового, нет. Просто устанавливаем ноду на новом сервере, указывая старый адрес для фарма. Вот и всё.

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

Это сработает, если на сервере нет других важных нод. В случае, если вы хотите оставить сервер, но удалить конкретную ноду - приступаем к её удалению:

# останавливаем и отключаем сервис ноды одной командой
sudo systemctl stop subspaced && \
sudo systemctl disable subspaced

# удаляем остаточные файлы
rm -Rvf $HOME/.local/share/subspace* \
$HOME/.config/subspace* \
/usr/local/bin/subspace

# удаляем файл сервиса и перезагружаем демона одной командой
sudo rm -v /etc/systemd/system/subspaced.service && \
sudo systemctl daemon-reload

мамичу за то, что родила такого гения.

@how_to_node - канал, где я выкладываю свои гайды.

Полезные ресурсы.

Крипто-кошельки автора гайда.

Устанавливаем ноду Pontem для участия в открытом тесте сети.

• Описание проекта: несколько слов о проекте, условия участия в ивенте.
• Требования к железу: рекомендуемые технические параметры сервера.
• Установка
• Кран: запрашиваем токены для теста;
• Установка: скачиваем и настраиваем ПО;
• Кошелёк: регистрируем аккаунт Nimbus;
• Нода: запускаем ноду в докере;
• Коллатор: создаём валидатора;
• Номинатор: делегируем токены коллатору.
• Полезные вещи
• Полезные команды при работе с нодой;
• Перенос и бэкап: пригодится при переезде;
• Удаление ноды: на будущее.
• Благодарности
• Полезные ресурсы на каждый день

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

Что делает Pontem, так это соединяет Diem (проект, поддерживаемый компанией Meta (в прошлом: Facebook)с 3,1 миллиардом пользователей) и децентрализованный мир, включая традиционные крипторынки.

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

Pontem стремится соединить виртуальную машину Move, язык и сообщество, созданные блокчейн-проектом Diem с "разрешениями" (permissioned) Facebook, с экосистемой блокчейна "без разрешений" (permissionless) через Polkadot.

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

В отличие от других проектов блокчейна первого уровня, которые сосредоточены на разработке с использованием такого языка, как Solidity, Pontem - первый проект, который привнес технологию Facebook Move в "разрешенную" криптометавселенную, позволяя новым и крипто-нативным проектам создавать, тестировать и развертывать приложения на блокчейне Diem Facebook.

Pontem обладает уникальным потенциалом создания инфраструктуры для поддержки миллиардов пользователей, которые впервые в жизни откроют для себя удивительные возможности криптовалюты с помощью финансовых услуг, предоставляемых экосистемой Diem Facebook, но также захотят подключиться к криптовселенной "без разрешений".

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

Backers: Animoca, Delphi, Mechanism, Morningstar, CMS, Alameda, GBIC, Kenetic, Spartan, NGC, Skynet, Momentum6, Genesis Block, AU21, Altonomy, Avalanche, Taureon и ещё около 10 фондов.

Pontem будет награждать активных валидаторов (коллаторов), а также делегаторов, которые вложили свои монеты в ноды активных коллаторов.

Если вам интересно стать валитором в основной сети - Kusama, можно заполнить форму интереса.

Стать участником тестнета можно двумя способами:

• делегировать токены активным коллаторам и получать тестовые награды (фантики) за делегирование;
• запустить собственного коллатора (валидатора) и получать награды (фантики) за валидирование.

Medium | Docs | GitHub | WebSite | Twitter | Discord | Telegram | RU_Chat

Официальные требования: 4 CPU x 8 GB RAM x 100 GB SSD - Ubuntu 20.04.

Субъективные наблюдения: 2 CPU x 4 GB RAM x 100 GB SSD - Ubuntu 20.04.

Прежде всего, нам нужно запросить токены.

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

После того, как адрес получен - переходим в телеграм бота и запрашиваем токены:

Сначала я покажу, как создать собственного коллатора, после чего мы будем делегировать ПОНТы на чужих валидаторов.

# обновляем 'базу данных', обновляем дистрибутив
$ sudo apt-get update && sudo apt-get upgrade -y

# скачиваем докер одной командой
$ sudo apt-get install curl gnupg apt-transport-https ca-certificates \
lsb-release -y && curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
| sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg && \
echo "deb [arch=$(dpkg --print-architecture) \
signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] \
https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" \
| sudo tee /etc/apt/sources.list.d/docker.list > /dev/null && \
sudo apt-get update && \
sudo apt-get install docker-ce docker-ce-cli containerd.io -y
# если не работает команда, гуглите 'how to install docker on ubuntu'

# скачиваем 'docker-compose' одной командой
$ sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose && \
sudo chmod +x /usr/local/bin/docker-compose && docker-compose --version

# клонируем репозиторий одной командой
$ git clone https://github.com/pontem-network/bootstrap.git pontem-bootstrap && \
cd ~/pontem-bootstrap && cp .env.testnet .env

# вставляем в 'конфиг' свой никнейм
$ nano ~/pontem-bootstrap/.env

# билдим
$ cd ~/pontem-bootstrap && docker-compose build

Генерируем новый кошелёк Nimbus и сохраняем весь вывод команды.

$ cd ~/pontem-bootstrap && \
docker-compose run pontem-node pontem key generate --scheme sr25519

Теперь привязываем ключи к ноде.

$ cd ~/pontem-bootstrap && \
docker-compose run pontem-node pontem key insert \
--suri "<your_mnemonic>" --keystore-path /opt/pontem/keys --key-type nmbs

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

$ cd ~/pontem-bootstrap && \
docker-compose run pontem-node pontem key inspect \
--keystore-path /opt/pontem/keys "<you_mnemonic>"

# запуск 'pontem-node'
$ cd ~/pontem-bootstrap && docker-compose up -d

Если увидели такую ошибку:

Открываем файл конфига и редактируем порты.

$ nano $HOME/pontem-bootstrap/docker-compose.yml

Теперь контейнер успешно создался.

Посмотрим его логи:

$ cd ~/pontem-bootstrap && docker-compose logs -f --tail 10

Узнать последний блок можно в эксплорере:

Пример рабочих логов после синхронизации:

Perfect!

Переходим на сайт и теперь будем работаем с дашбордом польки.

Во вкладке Developer будем использовать следующиеинструменты:

• Extrinsics: здесь будем создавать коллатора, делегировать токены.
• Chain State: а здесь будем запрашивать данные о блокчейне.

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

Открываем Extrinsics и выбираем authorMapping, addAssociation(author_id) и вставляем свой публичный ключ, который мы сохраняли раннее, в соответствующее поле.

Подробнее на скриншоте:

Подтверждаем транзакцию. С баланса спишется 1 PONT и небольшая комиссия за транзакцию.

Теперь запрашиваем данные об уже созданных коллаторах.

Переходим в JavaScript и "выполняем" следующий код (предварительно удалив дефолтный, разумеется):

const candidatePool = await api.query.parachainStaking.candidatePool();
console.log(`Candidate pool size is: ${candidatePool.length}`);

Вот так должно выглядеть:

Возвращаемся к Extrinsics и выбираем parachainStaking, joinCandidates(bond, candidate_count).

Вставляем своё значение PONT, которое хотите заделегировать в своего коллатора. Минимум 1000 токенов.

В поле canditate_count вставляем своё значение из прошлого пункта. Для меня это 20.

Пример на скриншоте. Подписываем транзакцию:

Если встретили эту ошибку, просто увеличьте на 1 своё значение кандидатов.

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

Поэтому выбивает ошибку, что слишком маленькое число кандидатов. Просто за это время кандидатов стало больше.

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

Реварды будут начисляться прямо на кошелёк.

Как проверить, всё ли прошло удачно?

Переходим в Chain State, выбираем parachainStaking, затем candidatePool (чтобы посмотреть весь список, включая активных и неактивных) или selectedCandidates (чтобы увидеть список только активных коллаторов).

Пример на скриншоте:

Теперь просто ищем свой адрес, с которого отправляли транзакции по созданию коллатора.

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

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

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

Переходим в Chain State, выбираем parachainStaking, затем selectedCandidates (чтобы увидеть список только активных коллаторов).

Выбираем любого понравившегося и копируем его адрес.

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

const collatorAccount = 'COLLATOR_ADDRESS';
const collatorInfo = await api.query.parachainStaking.collatorState2(collatorAccount);
console.log('Nominators count: ' + collatorInfo.toHuman()["nominators"].length);

В моём случае, результат: 0.

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

const yourNominatorAccount = 'YOUR_ADDRESS_HERE';
const nominatorInfo = await api.query.parachainStaking.nominatorState2(yourNominatorAccount);
console.log('Nominations: ' + nominatorInfo.toHuman()["nominations"].length);

Так как я номинирую в первый раз, у меня выбивает ошибку. Это нормально, значит, моё значение: снова 0.

Теперь приступаем к стейкингу. Переходим к Extrinsics, выбираем parachainStaking > nominate(collator, amount, collatorNominatorCount, nominationCount).

В поле collator вставляем адрес выбранного коллатора, в amount - количество PONT, в collatorNominatorCount - результат из первого запроса, в nominationCount - результат из второго запроса.

Пример на скриншоте:

Подписываем транзакцию. Вот и всё.

Чтобы застейкать больше или меньше, используем соответствующие запросы:

• nominatorBontMore
• nominatorBondLess

Чтобы забрать свой стейк у коллатора, выполняем запрос:

• revokeNomination

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

# посмотреть логи контейнера
$ cd ~/pontem-bootstrap && docker-compose logs -f --tail 10

# рестартануть контейнер
$ cd ~/pontem-bootstrap && docker-compose restart

# стопнуть контейнер
$ cd ~/pontem-bootstrap && docker-compose stop

Про перенос я написал полноценную статью. Читаем внимательно и вдумчиво.

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

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

Это сработает, если на сервере нет других важных нод. В случае, если вы хотите оставить сервер, но удалить конкретную ноду - приступаем к её удалению:

# получаем ID контейнера и отключаем его
$ docker ps
$ docker stop <ID> && docker rm <ID>

# получаем ID образа и удаляем образ
$ docker images
$ docker rmi <ID> --force

# удаляем каталог
$ sudo rm -Rvf $HOME/pontem-bootstrap

мамичу за то, что родила такого гения.

@saltedsanya за помощь с гайдом.

@how_to_node - канал, где я выкладываю свои гайды.

Полезные ресурсы.

Крипто-кошельки автора гайда.

Отправляем gentx на примере Olympus.

• Установка: устанавливаем необходимую ноду.
• Gentx: создаём gentx.
• Github: отправляем pull request.
• Благодарности
• Полезные ресурсы на каждый день

Немного подготавливаем сервер. Подразумевается установка на чистый сервер.

# обновляем 'базу данных', обновляем дистрибутив 
$ sudo apt-get update && sudo apt-get upgrade -y

# устанавливаем необходимые пакеты, если необходимо
$ sudo apt install curl tar wget clang pkg-config libssl-dev \
jq build-essential git make ncdu -y

# устанавливаем 'go', если это необходимо
$ wget https://golang.org/dl/go1.17.2.linux-amd64.tar.gz; \
rm -rv /usr/local/go 2>/dev/null; \
tar -C /usr/local -xzf go1.17.2.linux-amd64.tar.gz && \
rm -v go1.17.2.linux-amd64.tar.gz && \
echo "export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin" \
>> ~/.bash_profile && \
source ~/.bash_profile && \
go version

Уставляем необходимую нам ноду.

# устанавливаем нужную ноду
$ cd && \
rm -Rvf $HOME/evmos 2>/dev/null; \
git clone https://github.com/tharsis/evmos.git && \
cd $HOME/evmos && \
make install && \
cd

# удаляем старый генезис. если нода не 'evmos' - редактируйте команду
$ rm $HOME/.evmosd/config/genesis.json 2>/dev/null

# восстанавливаем ключи из прошлого тестнета, либо генерим новые
# БЕЗ < >, ЛАДНО?
$ evmosd keys add <nickname> --recover
$ evmosd keys add <nickname>

Создаём gentx.

# инициализируем ноду. если нода не 'evmos' - редактируйте команду
# БЕЗ < >, ЛАДНО?
$ evmosd init <nickname> --chain-id=evmos_9000-2

# добавляем генезис аккаунт. если нода не 'evmos' - редактируйте команду
# БЕЗ < >, ЛАДНО?
$ evmosd add-genesis-account \
$(evmosd keys show <nickname> -a) 1000000000000aphoton

# удаляем возможный старый 'gentx'
$ rm -Rvf $HOME/.evmosd/config/gentx

# генерация gentx. если нода не 'evmos' - редактируйте команду
# БЕЗ < >, ЛАДНО?
$ evmosd gentx <nickname> 1000000000000aphoton \
--commission-rate=0.1 \
--commission-max-rate=1 \
--commission-max-change-rate=0.1 \
--pubkey $(evmosd tendermint show-validator) \
--chain-id=evmos_9000-2

Выводим на экран gentx. Если нода не evmos - редактируем пути под себя.

$ cat $HOME/.evmosd/config/gentx/`ls $HOME/.evmosd/config/gentx/`

Копируем и сохраняем в текстовый файл на ПК.

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

Открываем репозиторий нужного нам тестнета и форкаем репозиторий.

В моём случае, это эвмос: https://github.com/tharsis/testnets.

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

В моём случае, это testnets-1/olympus_mons/gentxs/:

Добавляем новый файл:

В названии файла пишем, собственно, название файла.

Для каждого тестнета требования к названию уникальны. Конкретно в моём случае, я должен назвать файл по следующему примеру: <moniker>.json

Так я и делаю. При создании gentx в терминале я обозвал моникер, как test, название файла указываю соответствующее. Это важно.

В содержимое файла вставляем последний вывод терминала и название коммита указываем: ADD <moniker> gentx. Выглядеть должно так:

Теперь нажимаем на "Commit new file". Выглядит это у меня следующим образом.

Теперь отправим сам пул реквест: Contribute > Open pull request:

Ваш пул должен появиться в главном репозитории, во вкладке Pull requests:

Вот и всё. Основные моменты описал.

Если у вас возникают трудности при таких простых манипуляциях - задумайтесь, а оно вам надо?

Если надо, тогда долбите. Рано или поздно получится. Главное не сдаваться, если сильно хочется.

Взаимодействие с гитхабом очень востребовано. Важно уметь работать с ним.

мамичу за то, что родила такого гения.

@how_to_node - канал, где я выкладываю свои гайды.

Полезные ресурсы.

Крипто-кошельки автора гайда.

Устанавливаем ноду IDEP для участия в SanfordV2.

• Описание проекта: несколько слов о проекте, условия участия в ивенте.
• Требования к железу: рекомендуемые технические параметры сервера.
• Установка
• Нода: скачиваем и настраиваем ноду;
• Кошелёк: регистрируем аккаунт;
• Кран: запрашиваем тестовые токены;
• Валидатор: создаём валидатора;
• Полезные вещи
• Полезные команды при работе с нодой;
• Ределегация: выводим реварды за стейкинг и ределегируем их.
• Идентификация: делаем валидатора уникальным;
• Обновление;
• Перенос и бэкап: пригодится при переезде;
• Удаление ноды: на будущее.
• Благодарности
• Полезные ресурсы на каждый день

IDEP - это блокчейн NFT2.0, который фокусируется на децентрализованных цифровых медиа. Он построен с использованием механизма консенсуса Tendermint и Cosmos SDK.

Основное видение IDEP состоит в том, чтобы стать первой платформой AR (дополненной реальности) для цифровых медиа глобального масштаба, использующей PoS Tendermint.

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

AR IDEP - новый стандарт в области дополненной реальности.

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

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

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

IDEP запустится с 3 основными базовыми моделями экосистемы:

• Uptake: платформа следующего поколения NFT2.0;
• IDENTITY: гиперрасширяемый сетевой профиль;
• IDEP-Swap: рынок цифровых активов.

Сейчас множество блокчейнов являются "общими" сетями, с отсутствием целенаправленности, узкой специализизации.

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

Сеть IDEP является частью Cosmos, что подразумевает нативную поддержку IBC.

IDEP полностью интегрировал виртуальную машину Ethereum (EVM) в свою архитектуру. Используя EVM в качестве основы, вся база знаний Ethereum напрямую применима к IDEP - разработчики могут использовать все инструменты, которые уже созданы для экосистемы Ethereum.

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

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

$IDEP - это собственный, нативный токен сети IDEP. Подробная информация о токеномике представлена здесь.

Roadmap:

Текущая фаза тестнета является стимулируемой (оплачиваемой).

За награды могут бороться только участники дискорда с ролью Testnet-Sanford.

Если у вас нет такой роли - нет смысла ставить ноду.

Medium | Docs | GitHub | WebSite | Twitter | Discord | Telegram | RU_Chat

Официальные требования: 4 CPU x 8 GB RAM x 1 TB SSD - Ubuntu 20.04.

Субъективные наблюдения: 2 CPU x 4 GB RAM x 200 GB SSD - Ubuntu 20.04.

# обновляем 'базу данных', обновляем дистрибутив
$ sudo apt-get update && sudo apt-get upgrade -y

# скачиваем необходимые зависимости
$ sudo apt-get install git curl build-essential gcc jq -y

# устанавливаем 'go' одной командой
$ wget https://golang.org/dl/go1.17.5.linux-amd64.tar.gz; \
rm -rv /usr/local/go; \
tar -C /usr/local -xzf go1.17.5.linux-amd64.tar.gz && \
rm -v go1.17.5.linux-amd64.tar.gz && \
echo "export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin" >> ~/.bash_profile && \
source ~/.bash_profile && \
go version

# клонируем репозиторий
$ git clone https://github.com/IDEP-network/SanfordV2.git && \
sudo cp SanfordV2/iond /usr/local/bin/

# выдаём права на исполнение
$ sudo chmod a+x /usr/local/bin/iond

# устанавливаем 'wasmvm' одной командой
$ cd && \
go get -u github.com/CosmWasm/wasmvm@v1.0.0-beta4 && \
cd $HOME/go/pkg/mod/github.com/\!cosm\!wasm/wasmvm@v1.0.0-beta4/api && \
chmod +x libwasmvm.so && \
mv libwasmvm.so /usr/lib/ && \
cd

# проверяем работоспособность
$ iond -h

Если всё прошло успешно, тогда переходим к инициализации ноды.

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

# например, "export NICKNAME="cyberomanov"" 
$ echo "export NICKNAME="<nickname>"" >> ~/.bash_profile

# чтобы переменная загрузилась, необходимо перезагрузить '.bash_profile' 
$ source ~/.bash_profile

# проверим значение переменной, выведя её на экран
$ echo $NICKNAME

Инициализируем ноду.

$ rm ~/.ion/config/genesis.json; \
iond init $NICKNAME --chain-id SanfordNetworkV2

# удаляем старый файл генезиса и скачиваем новый одной командой
$ rm $HOME/.ion/config/genesis*; \
wget -O $HOME/.ion/config/genesis.json "https://raw.githubusercontent.com/IDEP-network/SanfordV2/master/genesis.json"

# определяем моникер в файле конфига одной командой
$ sed -i.bak -e "s/^moniker *=.*/moniker = \"$NICKNAME\"/" \
$HOME/.ion/config/config.toml

# добавляем сиды в файл конфига одной командой
$ sed -i.bak -e "s/^seeds *=.*/seeds = \
\"4f32b91384999069bdfdbc82b7725866f1c37cbb@142.93.121.105:26656\"/" \
$HOME/.ion/config/config.toml

# включаем прунинг одной командой
$ pruning="custom" && \
pruning_keep_recent="100" && \
pruning_keep_every="5000" && \
pruning_interval="10" && \
sed -i -e "s/^pruning *=.*/pruning = \"$pruning\"/" $HOME/.ion/config/app.toml && \
sed -i -e "s/^pruning-keep-recent *=.*/pruning-keep-recent = \"$pruning_keep_recent\"/" $HOME/.ion/config/app.toml && \
sed -i -e "s/^pruning-keep-every *=.*/pruning-keep-every = \"$pruning_keep_every\"/" $HOME/.ion/config/app.toml && \
sed -i -e "s/^pruning-interval *=.*/pruning-interval = \"$pruning_interval\"/" $HOME/.ion/config/app.toml

# создаём файл сервиса для запуска ноды
$ sudo tee <<EOF >/dev/null /etc/systemd/system/iond.service
[Unit]
Description=IDEP
After=network-online.target
[Service]
User=$USER
ExecStart=$(which iond) start
Restart=always
RestartSec=10
LimitNOFILE=65535
[Install]
WantedBy=multi-user.target
EOF

# включаем сервис 'idepd' одной командой
$ sudo systemctl daemon-reload && \
sudo systemctl enable iond && sudo systemctl restart iond

# проверяем логи
$ sudo journalctl -u iond -f -o cat

Ждём, пока нода найдёт рабочие пиры и начнёт синхронизацию.

# настраиваем сеть и ноду 'по умолчанию'
$ iond config chain-id SanfordNetworkV2
$ iond config node `cat "$HOME/.ion/config/config.toml" \
| grep -oPm1 "(?<=^laddr = \")([^%]+)(?=\")"`

# проверяем конфиг
$ iond config

# получаем высоту блоков нашей ноды
$ iond status 2>&1 | jq ."SyncInfo"."latest_block_height"

# получаем статус синхронизации ноды
$ iond status 2>&1 | jq ."SyncInfo"."catching_up"

# 'true' - нода синхронизируется, 'false' - нода синхронизирована

Создаём новый кошелёк, как просит команда.

# выполняем команду создания кошелька
$ iond keys add $NICKNAME

# либо восстанавливаем старый по мнемонике (не рекомендуется)
$ iond keys add $NICKNAME --recover

Чтобы запросить токены на адрес, необходимо, прежде всего, этот адрес узнать.

Если вы сделали бэкап ключей, как я просил - можете скопировать адрес оттуда.

Для остальных выполняем команду:

$ iond keys list

Копируем адрес, вставляем его в дискорд #confirm-wallet и ждём, пока команда начислит токены.

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

# проверяем баланс из командной строки
$ iond query bank balances <address>

Отправляем транзакцию создания валидатора после полной синхронизации:

$ iond tx staking create-validator \
--amount 10000000000idep \
--commission-max-change-rate 0.01 \
--commission-max-rate 0.2 \
--commission-rate 0.1 \
--from "$NICKNAME" \
--min-self-delegation 1 \
--moniker "$NICKNAME" \
--pubkey $(iond tendermint show-validator)

Посмотрим информацию о валидаторе:

$ iond query staking \
validator $(iond keys show $NICKNAME --bech=val -a)

Несколько команд для удобной работы с нодой.

# получаем высоту блоков нашей ноды
$ iond status 2>&1 | jq ."SyncInfo"."latest_block_height"

# получаем статус синхронизации ноды
$ iond status 2>&1 | jq ."SyncInfo"."catching_up"

# 'true' - нода синхронизируется, 'false' - нода синхронизирована

# посмотреть информацию о валидаторе
$ iond query staking \
validator $(iond keys show $NICKNAME --bech=val -a)

# локальный эксплорер
$ iond q staking validators \
-o json --limit=1000 \
| jq '.validators[] | select(.status=="BOND_STATUS_BONDED")' \
| jq -r '.tokens + " - " + .description.moniker' | sort -gr | nl

# выйти из 'тюрьмы'
$ iond tx slashing unjail \
--gas="auto" \
--gas-prices="0.5idep" \
--gas-adjustment=1.5 \
--from=$NICKNAME

# перезапустить сервис с нодой
$ sudo systemctl restart iond

# остановить сервис с нодой
$ sudo systemctl stop iond

# проверить логи ноды
$ sudo journalctl -u iond -f -o cat

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

# вывести реварды за стейкинг для последующей ределегации
$ iond tx distribution withdraw-all-rewards -y \
--gas="auto" \
--gas-adjustment=1.5 \
--gas-prices="0.5idep" \
--from=$NICKNAME

# проверяем новый баланс на аккаунтах
$ iond query bank balances <address>

Где <address> - адрес, с которого производилось создание валидатора.

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

# добавляем свой 'operator-address' в переменные
$ echo "export OPERATOR="$(iond query staking \
validator $(iond keys show $NICKNAME --bech=val -a) \
| grep "valoper" | awk '{print $2}')"" >> ~/.bash_profile

# чтобы переменная загрузилась, необходимо перезагрузить '.bash_profile' 
$ source ~/.bash_profile

# проверим значение переменной, выведя её на экран
$ echo $OPERATOR

# делегируем токены на своего валидатора
$ iond tx staking delegate $OPERATOR "100000000idep" -y \
--gas="auto" \
--gas-adjustment=1.5 \
--gas-prices="0.5idep" \
--from=$NICKNAME

"100000000idep" - 1 токен.
Меняем только значение "100000000idep" на своё.

Посмотрим информацию о валидаторе:

$ iond query staking \
validator $(iond keys show $NICKNAME --bech=val -a)

Добавим аватар и немного описания нашему валидатору.

$ iond tx staking edit-validator -y \
--moniker="new node nickname" \
--website="https://t.me/nickname" \
--identity="1A1A2B2B3C3C4D4D" \
--details="any details" \
--gas="auto" \
--gas-adjustment="1.5" \
--gas-prices="0.5idep" \
--from=$NICKNAME

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

Посмотрим информацию о валидаторе:

$ iond query staking \
validator $(iond keys show $NICKNAME --bech=val -a)

Первым делом бэкапим файл по пути ~/.ion/config/priv_validator_key.json и файлы ключей: 9ef0xxxxxx.address, wallet.info, keyhash. На всякий случай.

# удаляем мусор
$ sudo systemctl stop iond && \
iond unsafe-reset-all && \
rm -Rvf ~/testnet-binaries/ ~/incentivized-testnet/

И начинаем установку с нуля.

Про перенос я написал полноценную статью. Читаем внимательно и вдумчиво.

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

Это сработает, если на сервере нет других важных нод. В случае, если вы хотите оставить сервер, но удалить конкретную ноду - приступаем к её удалению:

# останавливаем и отключаем сервис ноды
$ sudo systemctl stop iond && sudo systemctl disable iond

# удаляем каталоги и исполняемые файлы
$ sudo rm -Rvf $HOME/.ion/ /usr/bin/iond $HOME/SanfordV2/

# удаляем файлы сервиса и перезагружаем демона одной командой
$ sudo rm -v /etc/systemd/system/iond.service \
&& sudo systemctl daemon-reload

мамичу за то, что родила такого гения.

@mzonder.

@how_to_node - канал, где я выкладываю свои гайды.

Полезные ресурсы.

Крипто-кошельки автора гайда.

Участвуем в публичном тестнете KYVE Network.

• Описание проекта.
• Участие:
• Кран: Arweave + Korellia;
• Нода: kysor;
• Полезные команды;
• Удаление ноды;
• Благодарности.
• Полезные ресурсы на каждый день.

KYVE - децентрализованный протокол архивирования данных. Это протокол нового поколения, который стандартизирует, валидирует и хранит потоки данных.

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

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

Благодаря своей масштабируемости, постоянности и доступности, Arweave является идеальным решением для хранения данных.

Тем не менее, доступность данных не равнозначна достоверности данных.
Поэтому мы рассматриваем KYVE и Arweave как связку: в то время как KYVE обеспечивает надежную достоверность данных, Arweave, напротив, фокусируется на доступности данных (воспроизводимости).

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

Архитектура KYVE полностью децентрализована и состоит из двух основных компонентов: пулы и загрузчики с валидаторами.

Пулы. Пул - этоавтономная система управления, которая занимается проверкой "качества работы загрузчиков и валидаторов" или "нарушениями контракта”.

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

Перед пулом стоит 2 задачи: получить информацию из источника (в нашем случае, из блокчейна) и проверить информацию на достоверность.

Функциональность управления обеспечивается путем размещения токена $KYVE, гарантируя, что участники ведут себя в соответствии с целями сети.

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

Загрузчик (Uploader): Для каждого пула выбирается только один загрузчик.
Загрузчики извлекают данные из источника, выполняют инструкции, которые могут включать вычислительный этап, и записывают эти данные в Arweave.

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

Валидатор (Validator): проверяет информацию, загруженную загрузчиком на достоверность.

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

Каждый пул принимает форму децентрализованной автономной организации (DAO), которая работает на SmartWeave, языке смарт-контрактов Arweave.

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

Если соблюдены определенные критерии, пулы также распределяют токены $KYVE среди назначенных загрузчиков и валидаторов.

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

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

Backers: Coinbase, CMS, Mechanism, Distributed Global, Solana, Hypersphere, Permanent, 4SV, Volt, Compute, Ternary, Avalanche, Zee Prime, Mina, Moonbeam, Near, Interchain, Ava и ещё 7 "скрытых" инвесторов.

Roadmap:

Blog | Docs | GitHub | WebSite | Twitter | Discord | Telegram | Chat_RU

Первым делом, мы, конечно, должны привязать кошелёк к app.kyve.network. Открываем DApp, чтобы подключить свой Keplr:

Разрешаем сайту получить доступ к кошельку и добавить в него сеть Kaon/Korellia, кликнув на Approve:

Отлично, кошелёк подключился.

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

Нажимаем на Share on twitter, твиттер сразу предложит отправить твит:

После отправки твита, копируем ссылку на свой пост и вставляем её в соответствующее поле на сайте. Нажимаем Claim your tokens и решаем капчу:

Теперь открываем Keplr и выбираем сеть Korellia, которая была добавлена автоматически:

И наблюдаем наш баланс:

Ещё можно воспользоваться колесом фортуны, где заработаем от 1 до 10 токенов:

One more thing: нам нужно несколько десятых токена AR и arweave.json. Это файл, содержащий приватные ключи от кошелька Arweave.

Если до сих пор у вас нет arweave-кошелька, то переходим на сайт, где мы сгенерируем аккаунт и сразу запросим на него пару копеек.

Нажимаем Continue:

И скачиваем ключи. Сохраните arweave.json в надёжное место, этот файл нам ещё понадобится:

Нажимаем Open tweet pop-up, чтобы запросить токены и отправляем твит:

Итого у вас должно быть:

• Токены KYVE на кошельке Keplr и мнемоника от этого кошелька;
• Токены AR на кошельке Arweave и файл с ключами от этого кошелька.

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

Требования по железу:

Официальные требования: 1 CPU x 4 GB RAM x 20 GB SSD - Ubuntu 20.04.
Субъективные наблюдения: 1 CPU x 2 GB RAM x 40 GB SSD - Ubuntu 20.04.

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

# обновляем 'базу данных'
sudo apt-get update && sudo apt-get upgrade -y

# скачиваем необходимые пакеты
sudo apt-get install curl build-essential git jq unzip -y

# скачиваем 'kysor'
wget https://github.com/KYVENetwork/kyvejs/releases/download/%40kyve%2Fkysor%401.0.0-beta.7/kysor-linux-x64.zip && \
unzip kysor-linux-x64.zip && \
mv kysor-linux-x64 kysor && \
chmod +x kysor && \
mv kysor /usr/bin/kysor && \
rm kysor-linux-x64.zip*

# инициализируем 'kysor'
kysor init -d \
--chain-id korellia \
--rpc "https://rpc.korellia.kyve.network" \
--rest "https://api.korellia.kyve.network"

Теперь нам нужно загрузить arweave.json (мы генерировали его здесь) на сервер, в каталог $HOME/.kysor/.

Можно отправить файл на сервер с помощью инструментов программы Mobaxterm/Termius, но я воспользуюсь SCP:

# выполняем команду на локальном пк
scp path/myfile user@8.8.8.8:/full/path/to/new/location/

# в моём случае команда выглядит так
scp /Users/cyber/Downloads/arweave.json root@8.8.8.8:/root/.kysor/

mv $HOME/arweave.json $HOME/.kysor/

Сейчас нужно создать valaccount - это кошелёк, на котором нужно хранить несколько десятков $KYVE для оплаты комиссий за транзакции валидатора.

Этот valaccount будет храниться на сервере и подписывать транзакции.

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

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

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

• Стэш - основной адрес, который не участвует в валидировании -> не хранится на сервере;
• Контроллер - дополнительный кошелёк, который чисто подписывает транзакции -> хранится на сервере.

# создаём 'valaccount'
kysor valaccounts create \
--name <pool_name> \
--pool <N> \
--storage-priv "$(cat ~/.kysor/arweave.json)" \
--metrics

# восстанавливаем 'valaccount'
kysor valaccounts create \
--name <pool_name> \
--pool <N> \
--storage-priv "$(cat ~/.kysor/arweave.json)" \
--recover

Где:

<pool_name> - название будущего valaccount. рекомендуется называть так же, как и называется пул, для простоты понимания;

<N> - номер пула, который можно найти на странице конкретного пула в адресной строке браузера или в описанных параметрах.

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

# создаём 'valaccount'
kysor valaccounts create \
--name bitcoin \
--pool 3 \
--storage-priv "$(cat ~/.kysor/arweave.json)" \
--metrics

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

# идём в каталог с конфигами
cd ~/.kysor/valaccounts/

# выводим на экран все конфиги
ls

В моём случае конфиг называется bitcoin.toml. Открываем файл и редактируем порт:

nano bitcoin.toml

Я выбрал значение 10001. Можете выбрать любой порт из возможных и открытых. В случае, если я захочу поставить на этот же сервер вторую протокольную ноду, скажем, Avalanche, я установлю её на 10002 порт и так далее.

# создаём файл сервиса для запуска 'kysor'
tee <<EOF > /dev/null /etc/systemd/system/bitcoind.service
[Unit]
Description=KYVE Protocol
After=network-online.target
[Service]
User=$USER
ExecStart=$(which kysor) start \\
--valaccount bitcoin
Restart=always
RestartSec=3
LimitNOFILE=infinity
[Install]
WantedBy=multi-user.target
EOF

# запускаем ноду со своим названием сервисного файла
sudo systemctl daemon-reload && \
sudo systemctl enable bitcoind && \
sudo systemctl restart bitcoind

# проверяем логи
sudo journalctl -u bitcoind -f -o cat

Если вчитаться, то логи сервиса просят нас присоединиться к пулу, поскольку мы этого ещё не сделали. Приступим.

Открываем app.kyve.network, убеждаемся, что включен мод эксперта:

Переходим на страницу валидаторов и нажимаем на Become a validator:

Прокликиваем и читаем предложенный нам текст:

Вписываем желаемое количество токенов, которое хотите внести в качестве селф-стейка:

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

В разделе Manage Validator можно отредактировать комиссию и описание валидатора:

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

valaddress и valname можно найти в логах:

Как только мы подписали транзакцию после нажатия Join pool, начали бежать логи:

Вот и всё. Мы создали и запустили валидатора.

Следите за балансом valaccount и вовремя пополняйте его, чтобы не угодить в jail:

Если вы хотите запустить несколько протокольных нод с одного сервера и с одного "мастер-адреса", просто повторяем все действия с создания valaccount:

1. Создаём valaccount;
2. Меняем порт, на котором висят метрики в новом конфиге;
3. Создаём новый сервис с новым названием;
4. Присоединяемся к новому пулу через сайт.

# пезапуск сервиса
sudo systemctl restart bitcoind

# остановка сервиса
sudo systemctl stop bitcoind

# проверка лога
sudo journalctl -u bitcoind -f -o cat

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

Это сработает, если на сервере нет других важных нод. В случае, если вы хотите оставить сервер, но удалить конкретную ноду - приступаем к её удалению:

# останавливаем сервис
sudo systemctl stop bitcoind && \
sudo systemctl disable bitcoind

# удаляем остаточные файлы
rm -Rvf /usr/bin/kysor* $HOME/.kysor

# удаляем файл сервиса и перезагружаем демона одной командой
sudo rm -v /etc/systemd/system/bitcoind.service; \
sudo systemctl daemon-reload

мамичу за то, что родила такого гения.

@kyvecheckerbot - бот для слежения за нодой.

@KyveProposals - канал с уведомлениями о пропозалах.

@how_to_node - канал, где я выкладываю свои гайды.

Полезные ресурсы.

Крипто-кошельки автора гайда.

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

• А зачем?
• Установка
• Установка node-exporter на сервер с нодой
• Установка prometheus на сервер-обработчик
• Установка grafana на сервер-обработчик
• Импортируем лучший в мире дашборд
• Благодарности
• Полезные ресурсы на каждый день

Grafana - это платформа с открытым исходным кодом для визуализации, мониторинга и анализа данных.

Grafana позволяет пользователям создавать дашборды с панелями, каждая из которых отображает определенные показатели.

С помощью графаны можно творить действительно волшебные вещи.

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

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

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

По истине волшебная вещь, но за таким дашбордом - добро пожаловать в 2Top.

В данной статье я просто не могу объяснить, как добавить мониторинг на таком уровне - я не знаю язык запросов.

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

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

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

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

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

# обновляем 'базу данных'
sudo apt-get update && sudo apt-get upgrade -y

# скачиваем 'node_exporter' и наводим порядок одной командой
cd $HOME && \
wget https://github.com/prometheus/node_exporter/releases/download/v1.2.0/node_exporter-1.2.0.linux-amd64.tar.gz && \
tar xvf node_exporter-1.2.0.linux-amd64.tar.gz && \
rm node_exporter-1.2.0.linux-amd64.tar.gz && \
sudo mv node_exporter-1.2.0.linux-amd64 node_exporter && \
chmod +x $HOME/node_exporter/node_exporter && \
mv $HOME/node_exporter/node_exporter /usr/bin && \
rm -Rvf $HOME/node_exporter/

# создаём файл сервиса 'exporterd'
sudo tee /etc/systemd/system/exporterd.service > /dev/null <<EOF
[Unit]
Description=node_exporter
After=network-online.target
[Service]
User=$USER
ExecStart=/usr/bin/node_exporter
Restart=always
RestartSec=3
LimitNOFILE=65535
[Install]
WantedBy=multi-user.target
EOF

# запускаем сервис 'exporterd' одной командой
sudo systemctl daemon-reload && \
sudo systemctl enable exporterd && \
sudo systemctl restart exporterd

# проверяем логи
sudo journalctl -u exporterd -f

В выводе терминала вы увидите нечто подобное:

Теперь переходим в браузере на своём домашнем устройстве по адресу: http://<server_IP>:9100/, где <server_IP> - IP сервера, на котором установлен node_exporter.

Отобразится Node Exporter. Нажимаем Metrics:

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

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

Открываем сессию с нашим новым сервером (нода-обработчик) и устанавливаем необходимое ПО:

# обновляем 'базу данных' 
sudo apt-get update && sudo apt-get upgrade -y

# устанавливаем 'prometheus' одной командой
wget https://github.com/prometheus/prometheus/releases/download/v2.28.1/prometheus-2.28.1.linux-amd64.tar.gz && \
tar xvf prometheus-2.28.1.linux-amd64.tar.gz && \
rm prometheus-2.28.1.linux-amd64.tar.gz && \
mv prometheus-2.28.1.linux-amd64 prometheus

# открываем конфиг прометеуса для настройки
nano $HOME/prometheus/prometheus.yml

В графу tagrets нам нужно после запятой добавить IP-адрес нашего сервера с нодой, откуда экспортируется статистика.

Сохраняем изменения и создаём сервис.

# выдаём права на исполнение
chmod +x $HOME/prometheus/prometheus

# создаём файл сервиса 'prometheusd'
sudo tee /etc/systemd/system/prometheusd.service > /dev/null <<EOF
[Unit]
Description=prometheus
After=network-online.target
[Service]
User=$USER
ExecStart=$HOME/prometheus/prometheus \
--config.file="$HOME/prometheus/prometheus.yml"
Restart=always
RestartSec=3
LimitNOFILE=65535
[Install]
WantedBy=multi-user.target
EOF

# запускаем сервис 'prometheusd' одной командой
sudo systemctl daemon-reload && \
sudo systemctl enable prometheusd && \
sudo systemctl restart prometheusd

# проверяем логи
sudo journalctl -u prometheusd -f

Переходим в браузере на своём домашнем устройстве по адресу: http://<server_IP>:9090/, где <server_IP> - IP сервера, на котором установлен prometheus.

Переходим в Status > Targets:

Прометеус показывает 2 цели: первая - сервер, где мы устанавливали node_exporter, 2 - сам прометеус (localhost). Отлично.

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

# устанавливаем графану одной командой
sudo apt-get install -y adduser libfontconfig1 && \
wget https://dl.grafana.com/oss/release/grafana_8.0.6_amd64.deb && \
sudo dpkg -i grafana_8.0.6_amd64.deb

# запускаем сервис 'grafana-server'
sudo systemctl daemon-reload && \
sudo systemctl enable grafana-server && \
sudo systemctl restart grafana-server

# смотрим логи
sudo journalctl -u grafana-server -f

Переходим в браузере на своём домашнем устройстве по адресу: http://<server_IP>:3000/, где <server_IP> - IP сервера, на котором установлен prometheus и grafana.

Если всё прошло удачно, нас встречает приветственное окно графаны:

Теперь задаём собственный пароль:

Следующим шагом станет добавление Data Sources. Выбираем Prometheus:

Указываем в графе URL адрес к своему серверу с прометеусом и графаной:

После чего нажимаем Save & test.

Если всё настроили правильно - отобразится зелёная галочка:

Теперь нам нужно импортировать дашборд, чтобы наконец-то увидеть графики:

Чтобы импортировать дашборд по ID, нам, прежде всего, этот ID нужно узнать.

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

Выбираем имя для дашборда и источник прометеуса:

И вот уже начинают заполняться некоторые графики и панели:

Уже выглядит неплохо, правда?

Но как добавить в один дашборд несколько нод? Ведь не интересно создавать для каждой ноды отдельный дашборд в отдельной вкладке - это не удобно.

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

Но зато я создал 2 темплейта для коммьюнити, возможно вам понравится.

Выглядят они вот так:

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

Прям по кайфу, реально.

Плюс к этому, в левом углу есть поле Node, в выпадающем списке можно выбрать интересующую ноду и посмотреть её метрики более детально:

Пушка, правда?

Теперь расскажу, как импортировать один из этих дашбордов себе и как добавить несколько нод в таблицу.

Первым делом, заходим на мой гитхаб и скачиваем архив с двумя json-файлами:

Затем открываем сессии с нужными нам серверами и устанавливаем на каждый сервер (откуда хотите собирать статистику) node-exporter из соответствующего раздела статьи.

Проверяем, чтобы экспортёр установился корректно на каждом сервере.

После того, как экспортёры настроены, открываем файл конфига прометеуса на ноде-обработчике:

nano $HOME/prometheus/prometheus.yml

Так выглядит мой конфиг:

Нас интересует только раздел static_configs.

targets - это цель, определённая машина, на которую мы устанавливали ноду-экспортёр и откуда желаем собирать метрики.

label - название этого сервера для отображения в графане.

# так будет выглядеть конфиг для одной ноды
global:
  scrape_interval:     15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "node_exporter"
    static_configs:
    - targets: [<IP>:9100]
      labels:
        label: "<label_1>"
        
# так будет выглядеть конфиг для четырёх нод
global:
  scrape_interval:     15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "node_exporter"
    static_configs:
    - targets: [<IP-1>:9100]
      labels:
        label: "<label_1>"
    - targets: [<IP-2>:9100]
      labels:
        label: "<label_2>"
    - targets: [<IP-3>:9100]
      labels:
        label: "<label_3>"
    - targets: [<IP-4>:9100]
      labels:
        label: "<label_4>"

После того, как настроили конфиг - сохраняем изменения и перезапускаем графану и прометеус:

sudo systemctl daemon-reload && \
sudo systemctl enable grafana-server && \
sudo systemctl restart grafana-server && \
sudo systemctl restart prometheusd

Возвращаемся в графану и импортируем один из скачанных с гитхаба дашбордов:

Вуаля! Выглядит бомбически, мне очень нравится.

Если вам не нравится форма или размер виджета/панели, можно легко их редактировать: просто потянув за правый нижний угол виджета.

Например, если у вас много нод в списке и не удобно просматривать список с помощью скрола - просто увеличиваем высоту виджета:

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

мамичу за то, что родила такого гения.

@how_to_node - канал, где я выкладываю свои гайды.

Полезные ресурсы.

Крипто-кошельки автора гайда.

В этой статье я буду «переносить» ноды, построенные на базе Polkadot и Tendermint, на другие сервера, не теряя валидатора и (практически) не пропуская блоков.

Проекты на вышеупомянутых сетях «переносятся» по одному и тому же сценарию.

Если проект использует свой собственный блокчейн — подход будет уникальным от проекта к проекту и лучше уточнять особенности «переезда» в тематическом чате.

• Polkadot или Cosmos?
• Перенос
• Перенос Polkadot
• Перенос Cosmos
• Благодарности
• Полезные ресурсы на каждый день

Я не буду углубляться в технические особенности и различия блокчейнов на уровне кода — я в этом не силён, да нам и не нужно.

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

Например, отличительной особенностью нод на польке является их телеметрия и дашборд.

Так выглядит дашборд или эксплорер:

А так телеметрия:

Если вам знаком данный дизайн, можете приступать к пункту: перенос polkadot.

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

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

Для космоса характерны такие команды, как:

# отправляем транзакцию создания валидатора
$ rizond tx staking create-validator \
--amount="7000000uatolo" \
--pubkey=$($HOME/go/bin/rizond tendermint show-validator) \
--moniker=$NICKNAME \
--commission-rate="0.10" \
--commission-max-rate="0.20" \
--commission-max-change-rate="0.01" \
--min-self-delegation="1" \
--from $NICKNAME'_keys' \
--chain-id=groot-011 \
--fees="1000uatolo"

или:

# получаем высоту блоков нашей ноды
$ stchaincli status 2>&1 | jq ."sync_info"."latest_block_height"

# получаем статус синхронизации ноды
$ stchaincli status 2>&1 | jq ."sync_info"."catching_up"

# 'true' - нода синхронизируется, 'false' - нода синхронизирована

Если вы узнали эти команды, можно приступать к пункту: перенос tendermint.

Например, у меня есть функционирующая нода porta, которую я хочу «перенести» на другой сервер.

Первое, что нужно сделать — зайти в Staking > Account actions и убедиться, что валидатор вообще работает:

Второе, мы арендуем второй сервер (куда будем «переносить» ноду) и устанавливаем ПО на новый сервер, запускаем узел и начинаем синхронизацию. Можно даже использовать старый никнейм ноды.

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

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

Теперь мы заходим в Staking > Account actions, выбираем своего валидатора и нажимаем на настройки, затем — Change session keys:

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

$ curl -H "Content-Type: application/json" \
-d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' \
http://127.0.0.1:9937 | jq .result | sed 's/"//g'

И вставляем новые ключи в соответствующее поле на сайте:

На скриншоте видно, что транзакция прошла успешно и нода теперь «привязана» к новому серверу. Теперь можно выключить ноду на старом сервере.

Для меня это:

$ sudo systemctl stop portad

В начале новой эпохи валидатор перестанет валидировать, нужно будет вновь нажать Validate в Staking > Account actions и заново настроить комиссию:

Теперь валидатор валидирует с нового сервера с новыми ключами:

Например, у меня есть функционирующая нода stratos, которую я хочу «перенести» на другой сервер.

Первое, мы скачиваем со старого сервера файл, которые находится в следующем каталоге: $HOME/.<cosmos>/config/ на свой компьютер.

Нужный нам файл называется: priv_validator_key.json.

Скачать файлы можно с помощью инструментов программы MobaXterm или SCP:

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

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

Теперь восстанавливаем ключи на новом сервере по старой мнемонической фразе. Для стратоса команда имеет вид:

$ stchaincli keys add --hd-path "m/44'/606'/0'/0/0" \
--keyring-backend=test $NICKNAME --recover

Стандартный вид команды:

$ cosmosd keys add $NICKNAME --recover

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

И положить их в соответствующую директорию: рядом с конфигом или в конкретный каталог keyring-test, например, — одним словом туда, откуда вы их сохранили со старого сервера.

Настал момент, когда нам нужно остановить сервисы нод на каждом из серверов, чтобы не было такой ситуации, что одновременно работают 2 валидатора на одних и тех же ключах.

Важно убедиться, что старая нода выключена и не обрабатывает блоки. Очень важно.

Для меня это:

$ sudo systemctl stop stratosd

На новом сервере, в каталоге config мы удаляем файл priv_validator_key.json. Можно руками, можно командами:

$ cd $HOME/.<cosmos>/config/
$ rm -vf priv_validator_key.json

И загружаем скачанный ранее priv_validator_key.json на новый сервер, в соответствующую директорию config.

Теперь можно со спокойной душой запускать сервис на новом сервере:

# включаем сервис 'stratosd' одной командой 
$ sudo systemctl daemon-reload && \
sudo systemctl enable stratosd && sudo systemctl restart stratosd

Сейчас нужно наблюдать в эксплорере, прошло ли всё удачно.

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

Также можно проверить состояние валидатора на новом сервере с помощью команды:

$ stchaincli query staking validator $(stchaincli keys show $NICKNAME \
--bech val --address --keyring-backend test) --trust-node

Стандартный вид команды:

$ cosmosd query staking \
validator $(cosmosd keys show $NICKNAME --bech val --address)

Получилось всё провести быстро и нода даже не успела попасть в тюрьму.

Но если валидатор всё же угодил в неё — нужно соответствующей командой его оттуда вытащить:

# выйти из 'тюрьмы'
$ stchaincli tx slashing unjail --from=$NICKNAME \
--chain-id=stratos-testnet-2 \
--keyring-backend=test \
--gas="auto" \
--gas-prices="0.5ustos" \
--gas-adjustment=1.5

Стандартный вид команды:

$ cosmosd tx slashing unjail --from=$NICKNAME --chain-id=<chain-id>

мамичу за то, что родила такого гения.

@napal_ded за статью про переезд омнифликса. эта статья и натолкнула меня на написание текущего, на мой взгляд, более универсального гайда.

@MikhailRadusha за отчёт по «переносу» порты.

@how_to_node - канал, где я выкладываю свои гайды.

Полезные ресурсы.

Крипто-кошельки автора гайда.

Устанавливаем ноду Omniflix для участия в тестнете FlixNet-3.

• Краткое описание ивента: несколько слов про ивент, условия участия.
• Требования к железу: рекомендуемые технические параметры сервера.
• Установка
• Нода: скачиваем и настраиваем ноду;
• Валидатора: создаём файл сервиса и запускаем валидатора.
• Полезные вещи
• Полезные команды при работе с нодой;
• Перенос и бэкап: пригодится при переезде;
• Удаление ноды: на будущее;

• Ределегация: выводим реварды за стейкинг и ределегируем их.

• Благодарности
• Полезные ресурсы на каждый день

Omniflix Network - это мультимедийная сеть для авторов, позволяющая создавать, распространять и монетизировать мультимедийные активы.

Blog | Docs | GitHub | WebSite | Twitter | Discord | Telegram

Официальные требования: 2 CPU x 4 GB RAM x 200 GB SSD - Ubuntu 20.04.

Субъективные наблюдения: 1 CPU x 2 GB RAM x 200 GB SSD - Ubuntu 20.04.

В этом блоке мы скачаем необходимые модули на сервер, установим и инициализируем ноду, а также восстановим ключи.

# обновляем 'базу данных' и скачиваем необходимые зависимости 
$ sudo apt-get update && sudo apt-get upgrade -y
$ sudo apt install curl build-essential git wget jq -y

# устанавливаем 'go' одной командой
$ wget https://golang.org/dl/go1.17.5.linux-amd64.tar.gz; \
rm -rv /usr/local/go; \
tar -C /usr/local -xzf go1.17.5.linux-amd64.tar.gz && \
rm -v go1.17.5.linux-amd64.tar.gz && \
echo "export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin" >> ~/.bash_profile && \
source ~/.bash_profile && \
go version

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

# клонируем и устанавливаем ноду
$ git clone https://github.com/Omniflix/omniflixhub.git && \
cd omniflixhub && \
git fetch --all && \
git checkout v0.3.0 && \
go mod tidy && \
make install && \
cd

# проверяем
$ omniflixhubd version

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

# например, "export NICKNAME="cyberomanov"" 
$ echo "export NICKNAME="<nickname>"" >> ~/.bash_profile 

# чтобы переменная загрузилась, необходимо перезагрузить '.bash_profile' 
$ source ~/.bash_profile

# проверим значение переменной, выведя её на экран
$ echo $NICKNAME

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

# инициализируем ноду  
$ omniflixhubd init $NICKNAME --chain-id flixnet-3

# восстанавливаем ключи по мнемонике
$ omniflixhubd keys add $NICKNAME --recover
# либо генерируем новые
$ omniflixhubd keys add $NICKNAME

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

# скачиваем новый генезис файл
$ curl https://raw.githubusercontent.com/OmniFlix/testnets/main/flixnet-3/genesis.json > ~/.omniflixhub/config/genesis.json

# создаём файл сервиса
$ sudo tee /etc/systemd/system/omniflixhubd.service > /dev/null <<EOF
[Unit]
Description=OmniFlixHub Daemon
After=network-online.target

[Service]
User=$USER
ExecStart=$(which omniflixhubd) start
Restart=always
RestartSec=3
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target
EOF

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

# создаём временные переменные, где указываем рабочие пиры и сиды
$ seeds="75a6d3a3b387947e272dab5b4647556e8a3f9fc1@45.72.100.122:26656"

$ peers="f05968e78c84fd3997583fabeb3733a4861f53bf@45.72.100.120:26656,\
b29fad915c9bcaf866b0a8ad88493224118e8b78@104.154.172.193:26656,\
28ea934fbe330df2ca8f0ddd7a57a8a68c39a1a2@45.72.100.110:26656,\
94326ddc5661a1b571ea10c0626f6411f4926230@45.72.100.111:26656"

# и выполняем команду по установке новых пиров
$ sed -i.bak -e "s/^seeds *=.*/seeds = \"$seeds\"/; s/^persistent_peers *=.*/persistent_peers = \"$peers\"/" $HOME/.omniflixhub/config/config.toml

# устанавливаем минимальную цену газа
$ sed -i.bak -e "s/^minimum-gas-prices *=.*/minimum-gas-prices = \"0.001uflix\"/" $HOME/.omniflixhub/config/app.toml

# 'очищаем кеш'
$ omniflixhubd unsafe-reset-all

# обновляем данные о сервисах и запускаем ноду одной командой
$ sudo systemctl daemon-reload && \
sudo systemctl enable omniflixhubd && \
sudo systemctl restart omniflixhubd

# проверяем логи
$ sudo journalctl -u omniflixhubd -f -o cat

После полной синхронизации создаём валидатора:

$ omniflixhubd tx staking create-validator \
--amount=1000000uflix \
--pubkey=$(omniflixhubd tendermint show-validator) \
--moniker="$NICKNAME" \
--chain-id="flixnet-3" \
--commission-rate="0.10" \
--commission-max-rate="0.20" \
--commission-max-change-rate="0.01" \
--min-self-delegation="1" \
--gas="auto" \
--gas-adjustment="1.2" \
--gas-prices="0.025uflix" \
--node `cat "$HOME/.omniflixhub/config/config.toml" \
| grep -oPm1 "(?<=^laddr = \")([^%]+)(?=\")"` \
--from=$NICKNAME

Несколько команд для удобной работы с нодой.

# получаем высоту блоков нашей ноды
$ omniflixhubd status 2>&1 \
--node `cat "$HOME/.omniflixhub/config/config.toml" \
| grep -oPm1 "(?<=^laddr = \")([^%]+)(?=\")"` \
| jq ."SyncInfo"."latest_block_height"

# получаем статус синхронизации ноды
$ omniflixhubd status 2>&1 \
--node `cat "$HOME/.omniflixhub/config/config.toml" \
| grep -oPm1 "(?<=^laddr = \")([^%]+)(?=\")"` \
| jq ."SyncInfo"."catching_up"
# 'true' - нода синхронизируется, 'false' - нода синхронизирована

# посмотреть информацию о валидаторе
$ omniflixhubd query staking \
validator $(omniflixhubd keys show $NICKNAME --bech=val -a) \
--node `cat "$HOME/.omniflixhub/config/config.toml" \
| grep -oPm1 "(?<=^laddr = \")([^%]+)(?=\")"`

# локальный эксплорер
$ omniflixhubd q staking validators --node `cat "$HOME/.omniflixhub/config/config.toml" \
| grep -oPm1 "(?<=^laddr = \")([^%]+)(?=\")"` \
-o json --limit=1000 \
| jq '.validators[] | select(.status=="BOND_STATUS_BONDED")' \
| jq -r '.tokens + " - " + .description.moniker' | sort -gr | nl

# выйти из 'тюрьмы'
$ omniflixhubd tx slashing unjail \
--chain-id="flixnet-3" \
--gas="auto" \
--gas-prices="0.025uflix" \
--gas-adjustment="1.2" \
--node `cat "$HOME/.omniflixhub/config/config.toml" \
| grep -oPm1 "(?<=^laddr = \")([^%]+)(?=\")"` \
--from=$NICKNAME

# перезапустить сервис с нодой
$ sudo systemctl restart omniflixhubd

# остановить сервис с нодой
$ sudo systemctl stop omniflixhubd

# проверить логи ноды
$ sudo journalctl -u omniflixhubd -f

Про перенос я написал полноценную статью. Читаем внимательно и вдумчиво.

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

Это сработает, если на сервере нет других важных нод. В случае, если вы хотите оставить сервер, но удалить конкретную ноду - приступаем к её удалению:

# останавливаем и отключаем сервис ноды
$ sudo systemctl stop omniflixhubd && sudo systemctl disable omniflixhubd

# удаляем каталоги с файлами ноды
$ rm -Rvf $HOME/omniflixhub
$ rm -Rvf $HOME/.omniflixhub

# удаляем файл сервиса и перезагружаем демона
$ sudo rm -v /etc/systemd/system/omniflixhubd.service 
$ sudo systemctl daemon-reload

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

# вывести реварды за стейкинг для последующей ределегации
$ omniflixhubd tx distribution withdraw-all-rewards \
 --gas="auto" \
 --gas-adjustment="1.5" \
 --gas-prices="0.025uflix" \
 --chain-id=flixnet-3 \
 --node `cat "$HOME/.omniflixhub/config/config.toml" \
| grep -oPm1 "(?<=^laddr = \")([^%]+)(?=\")"` \
 --from=$NICKNAME

# проверяем баланс
$ omniflixhubd query bank balances <address> --denom="uflix" \
--node `cat "$HOME/.omniflixhub/config/config.toml" \
| grep -oPm1 "(?<=^laddr = \")([^%]+)(?=\")"`

Где <address> - адрес, с которого производилось создание валидатора.

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

# делегировать токены на своего валидатора
$ omniflixhubd tx staking delegate <operator_address> "1000000uflix" \
 --gas="auto" \
 --gas-adjustment=1.5 \
 --gas-prices="0.025uflix" \
 --chain-id=flixnet-3 \
 --node `cat "$HOME/.omniflixhub/config/config.toml" \
| grep -oPm1 "(?<=^laddr = \")([^%]+)(?=\")"`
 --from=$NICKNAME

Где <operator_address> - адрес для делегации:

"1000000uflix" - 1 токен.

Проверяем информацию о валидаторе:

$ omniflixhubd query staking \
validator $(omniflixhubd keys show $NICKNAME --bech=val -a) \
--node `cat "$HOME/.omniflixhub/config/config.toml" \
| grep -oPm1 "(?<=^laddr = \")([^%]+)(?=\")"`

мамичу за то, что родила такого гения.

@how_to_node - канал, где я выкладываю свои гайды.

Полезные ресурсы.

Крипто-кошельки автора гайда.