Существует инструмент автоматического развёртывания нод
Оригинал: Automatic Node Provisioning Tool exists
Gonka NOP: интерфейс командной строки для развертывания валидатора одной командой
Категория: Предложения Ярлыки: улучшение, инструменты, инфраструктура, devops
Демо
Репозиторий: github.com/inc4/gonka-nop (https://github.com/inc4/gonka-nop)
Постановка задачи
Сегодня для развертывания валидатора Gonka требуется выполнить более 50 ручных шагов, связанных с драйверами графического процессора, настройкой Docker, управлением ключами, редактированием файлов компоновки, безопасностью портов и регистрацией в цепочке. Анализ примерно 9700 сообщений из чата DevOps валидатора Gonka показывает, что операторы сталкиваются с усугубляющимися сложностями на каждом этапе:
День-1 (Настройка):
- Установите и проверьте драйверы NVIDIA, Container Toolkit и Fabric Manager в разных дистрибутивах Linux.
- Определите архитектуру графического процессора (sm_80–sm_120) и выберите правильный образ MLNode (стандартный или Blackwell)
- Рассчитайте оптимальный размер тензорно-параллельных вычислений на основе количества графических процессоров, видеопамяти и требований модели.
- Правильно установите использование памяти gpu (0,99 вызывает OOM под нагрузкой — более 30 упоминаний в чате о частоте промахов из-за этого)
- Заполните более 15 переменных среды в config.env, отредактируйте node-config.json, настройте docker-compose.yml.
Привяжите внутренние порты к 127.0.0.1 (Docker обходит UFW — порт 5050 открыт = узел захвачен)
Настройка защиты от DDoS, обрезки, постоянных одноранговых узлов, синхронизации состояния
Управляйте тремя отдельными ключами (учетная запись, консенсус, операционное машинное обучение)
Загрузите вес модели более 200 ГБ
Зарегистрируйтесь в сети и предоставьте разрешения ML
День-2 (Операции — 90% времени оператора):
Мониторинг частоты промахов, задержки синхронизации, участия в эпохе, веса PoC
- Выполнение безопасных обновлений MLNode (6-этапный процесс: проверка временных интервалов → отключить → извлечь → воссоздать → дождаться загрузки модели → включить)
- Исправьте зависшие узлы после пропущенных обновлений цепочки (загрузите правильные двоичные файлы, поместите их в каталоги Космовизора)
- Управляйте узлами ML через Admin API (команды Curl с полезными данными JSON).
Восстановление дискового пространства из резервных копий Космовизора
На каждом этапе есть документированные виды отказов. Валидаторы регулярно ломают свои узлы, устанавливая слишком высокое значение использования памяти графического процессора, открывая внутренние порты, используя неправильные образы MLNode для своей архитектуры графического процессора или проваливая 6-этапный процесс обновления.
Решение: Гонка НОП
Gonka NOP — это Go CLI с открытым исходным кодом, который автоматизирует весь жизненный цикл валидатора — от «голого железа» до создания доказательств PoC — с помощью одной команды.
Curl -fsSL https://github.com/inc4/gonka-nop/releases/latest/download/gonka-nop -o /usr/local/bin/gonka-nop chmod +x /usr/local/bin/gonka-nop настройка gonka-nop
Что он автоматизирует
Архитектура
Gonka NOP — это один статический двоичный файл (Go, никаких зависимостей во время выполнения) с мастером поэтапной установки:
настройка gonka-nop │ ├── Этап 1: Предварительные условия │ ├── Обнаружение/установка Docker │ ├── Обнаружение/установка драйвера NVIDIA (с подтверждением пользователя) │ ├── Установка Container Toolkit + настройка среды выполнения Docker │ ├── Установка Fabric Manager (если обнаружен NVLink) │ ├── Проверка CUDA внутри контейнера Docker │ └── Проверка дискового пространства (минимум 250 ГБ) │ ├── Этап 2: Обнаружение графического процессора │ ├── Анализ nvidia-smi (количество, VRAM, архитектура, шина PCI) │ ├── Определение топологии NVLink │ ├── Расчет оптимального TP/PP для целевой модели │ ├── Рекомендовать использование памяти gpu (0,88–0,94) │ └── Выбор образа MLNode (стандартный или Blackwell) │ ├── Этап 3: Выбор сети │ ├── Выбор основной или тестовой сети │ └── Получить последние версии образа с GitHub (динамические, не жестко закодированные) │ ├── Этап 4: Управление ключами │ ├── Быстрый рабочий процесс: все ключи на сервере (автоматически) │ └── Безопасный рабочий процесс: холодный ключ на отдельном компьютере (по инструкции) │ ├── Этап 5: Конфигурация │ ├── Создать config.env (все переменные проверены) │ ├── Создать node-config.json (модель, TP, настройки VRAM) │ ├── Создание docker-compose.yml (безопасность порта, настройки по умолчанию для DDoS) │ └── Создание docker-compose.mlnode.yml (с учетом архитектуры графического процессора) │ ├── Этап 6: Развертывание │ ├── Извлечение образов контейнеров │ ├── Запуск сетевого узла, мониторинг синхронизации блокчейна │ ├── Загрузка весов модели (более 200 ГБ, с возможностью возобновления) │ ├── Запуск узла ML, дождитесь загрузки модели │ └── Запуск проверок работоспособности (11 проверок через Admin API) │ └── Этап 7: Регистрация ├── Регистрация узла в цепочке (отправка нового участника) └── Предоставление разрешений ML (предоставить-ml-ops-разрешения)
Операции дня-2
# Единая информационная панель состояния gonka-nop status # Показывает: высоту блока, статус синхронизации, эпоху, вес PoC, частоту промахов, # статус MLNode, использование графического процессора, проверки безопасности (всего 11) # Безопасное обновление обновления gonka-nop # Проверяет распределение временных интервалов → отключает узел ML → извлекает новый образ → # обновляет композицию → воссоздает → ждет загрузки модели → повторно включает # Исправляет зависшие узлы после пропущенных обновлений gonka-nop Repair # Обнаруживает отсутствующий обработчик обновлений → анализирует в цепочке update-info.json → # загружает правильные двоичные файлы (проверено SHA256) → помещает в каталоги Cosmovisor # Управление узлами ML gonka-nop ml-node list # Статус, вес PoC, временные интервалы, модель gonka-nop ml-node Enable # Включить для следующей эпохи gonka-nop ml-node отключить # Безопасное отключение # Предварительная загрузка весов модели (до или после установки) gonka-nop скачать-модель Qwen/Qwen3-235B-A22B-Instruct-2507-FP8
Неинтерактивный режим
Для операторов центров обработки данных, управляющих автопарком через Ansible/Terraform:
gonka-nop setup --yes \ --network mainnet \ --key-workflow fast \ --key-name my-key \ --keyring-password " $PASS " \ --public-ip 1.2.3.4 \ --hf-home /data/hf
Все интерактивные подсказки имеют переопределение флагов CLI. Совместимость с автоматизацией SSH, конвейерами CI/CD и сценариями пакетной подготовки.
Параметры безопасности по умолчанию
Gonka NOP по умолчанию применяет усиление безопасности, основываясь на реальных шаблонах атак, описанных в чате валидатора:
Текущий статус
Gonka NOP готов к использованию и активно используется в основной сети.
Тестовое покрытие: более 190 тестовых функций в 11 тестовых файлах.
Связь с существующей работой
Дорожная карта
Завершено (v0.1.8)
Полная автоматизация настройки (предварительные условия через регистрацию)
Операции дня-2 (статус, обновление, ремонт, ml-узел)
Неинтерактивный режим для развертываний по сценарию
Динамическое управление версиями
Централизованный мониторинг (Ansible)
Далее (v0.2.0)
Поддержка нескольких MLNode (2 × TP = 4 для ~ 2 × веса PoC на серверах с 8 графическими процессорами)
Разделенная архитектура ( --type network / --type mlnode для отдельных серверов)
DOCKER-USER автоматизация цепочки iptables
Проверка доступности PUBLIC_URL в команде статуса
команда выхода из тюрьмы gonka-nop
Команды внесения/снятия залога
Будущее
Механизм самообновления двоичного файла gonka-nop
Совместимость с облачными провайдерами (переназначение портов Vast.ai, голое железо GCore)
Предварительная загрузка обновления Cosmovisor на основе предложений по управлению
Интеграция сравнительного анализа производительности (compressa-perf)
Кто мы
Команда inc4 — работающие валидаторы в основной и тестовой сети Gonka. Мы проанализировали около 9700 сообщений из чата валидатора DevOps, чтобы понять болевые точки в работе, и создали Gonka NOP для систематического их устранения. Инструмент имеет открытый исходный код (MIT) и предназначен для снижения барьера для новых валидаторов и одновременного снижения операционной нагрузки для существующих.
Ссылки:
Репозиторий: github.com/inc4/gonka-nop (https://github.com/inc4/gonka-nop)
Демонстрационное видео: youtu.be/0w6biEROxUQ (https://youtu.be/0w6biEROxUQ?si=FJywggqlVax90Ohn)
- Предложение по мониторингу: обсуждение № 820 (https://github.com/gonka-ai/gonka/discussions/820).
Gonka NOP разрабатывается и поддерживается независимо. Он использует официальные конфигурации развертывания Gonka и не требует каких-либо изменений протокола. Обратная связь и вклад приветствуются.
Gonka NOP: One-Command Validator Deployment CLI
Category: Proposals Labels: enhancement, tooling, infrastructure, devops
Demo
Repository: github.com/inc4/gonka-nop (https://github.com/inc4/gonka-nop)
Problem Statement
Deploying a Gonka validator today requires executing 50+ manual steps across GPU drivers, Docker configuration, key management, compose file editing, port security, and on-chain registration. Analysis of ~9,700 messages from the Gonka validator DevOps chat reveals that operators face compounding complexity at every stage:
Day-1 (Setup):
Install and validate NVIDIA drivers, Container Toolkit, and Fabric Manager across different Linux distros
Detect GPU architecture (sm_80–sm_120) and choose the correct MLNode image (standard vs Blackwell)
Calculate optimal tensor-parallel size based on GPU count, VRAM, and model requirements
Set gpu-memory-utilization correctly (0.99 causes OOM under load — 30+ chat mentions of miss rate from this)
Fill 15+ environment variables in config.env , edit node-config.json , configure docker-compose.yml
Bind internal ports to 127.0.0.1 (Docker bypasses UFW — port 5050 exposed = node hijacked)
Configure DDoS protection, pruning, persistent peers, state sync
Manage three separate keys (account, consensus, ML operational)
Download 200+ GB model weights
Register on-chain and grant ML permissions
Day-2 (Operations — 90% of operator time):
Monitor miss rate, sync lag, epoch participation, PoC weight
Perform safe MLNode updates (6-step process: check timeslots → disable → pull → recreate → wait model load → enable)
Fix stuck nodes after missed chain upgrades (download correct binaries, place in Cosmovisor dirs)
Manage ML nodes via Admin API (curl commands with JSON payloads)
Recover disk space from Cosmovisor backups
Each step has documented failure modes. Validators regularly break their nodes by setting gpu-memory-utilization too high, exposing internal ports, using wrong MLNode images for their GPU architecture, or botching the 6-step update process.
Solution: Gonka NOP
Gonka NOP is an open-source Go CLI that automates the entire validator lifecycle — from bare metal to producing PoC proofs — in a single command.
curl -fsSL https://github.com/inc4/gonka-nop/releases/latest/download/gonka-nop -o /usr/local/bin/gonka-nop chmod +x /usr/local/bin/gonka-nop gonka-nop setup
What It Automates
Architecture
Gonka NOP is a single static binary (Go, zero runtime dependencies) with a phased setup wizard:
gonka-nop setup │ ├── Phase 1: Prerequisites │ ├── Detect/install Docker │ ├── Detect/install NVIDIA driver (with user confirmation) │ ├── Install Container Toolkit + configure Docker runtime │ ├── Install Fabric Manager (if NVLink detected) │ ├── Verify CUDA inside Docker container │ └── Check disk space (250GB minimum) │ ├── Phase 2: GPU Detection │ ├── Parse nvidia-smi (count, VRAM, architecture, PCI bus) │ ├── Detect NVLink topology │ ├── Calculate optimal TP/PP for target model │ ├── Recommend gpu-memory-utilization (0.88–0.94) │ └── Select MLNode image (standard vs Blackwell) │ ├── Phase 3: Network Select │ ├── Choose mainnet or testnet │ └── Fetch latest image versions from GitHub (dynamic, not hardcoded) │ ├── Phase 4: Key Management │ ├── Quick workflow: all keys on server (automated) │ └── Secure workflow: cold key on separate machine (guided) │ ├── Phase 5: Configuration │ ├── Generate config.env (all variables validated) │ ├── Generate node-config.json (model, TP, VRAM settings) │ ├── Generate docker-compose.yml (port security, DDoS defaults) │ └── Generate docker-compose.mlnode.yml (GPU architecture-aware) │ ├── Phase 6: Deploy │ ├── Pull container images │ ├── Start network node, monitor blockchain sync │ ├── Download model weights (200+ GB, resume-capable) │ ├── Start ML node, wait for model load │ └── Run health checks (11 checks via Admin API) │ └── Phase 7: Registration ├── Register node on-chain (submit-new-participant) └── Grant ML permissions (grant-ml-ops-permissions)
Day-2 Operations
# Unified health dashboard gonka-nop status # Shows: block height, sync status, epoch, PoC weight, miss rate, # MLNode status, GPU utilization, security checks (11 total) # Safe rolling update gonka-nop update # Checks timeslot allocation → disables ML node → pulls new image → # updates compose → recreates → waits for model load → re-enables # Fix stuck nodes after missed upgrades gonka-nop repair # Detects missing upgrade handler → parses on-chain upgrade-info.json → # downloads correct binaries (SHA256 verified) → places in Cosmovisor dirs # ML node management gonka-nop ml-node list # Status, PoC weight, timeslots, model gonka-nop ml-node enable # Enable for next epoch gonka-nop ml-node disable # Safe disable # Pre-download model weights (before or after setup) gonka-nop download-model Qwen/Qwen3-235B-A22B-Instruct-2507-FP8
Non-Interactive Mode
For datacenter operators managing fleets via Ansible/Terraform:
gonka-nop setup --yes \ --network mainnet \ --key-workflow quick \ --key-name my-key \ --keyring-password " $PASS " \ --public-ip 1.2.3.4 \ --hf-home /data/hf
All interactive prompts have CLI flag overrides. Compatible with SSH automation, CI/CD pipelines, and batch provisioning scripts.
Security Defaults
Gonka NOP applies security hardening by default, based on real-world attack patterns documented in the validator chat:
Current Status
Gonka NOP is production-ready and actively used on mainnet.
Test coverage: 190+ test functions across 11 test files.
Relationship to Existing Work
Roadmap
Completed (v0.1.8)
Full setup automation (prerequisites through registration)
Day-2 operations (status, update, repair, ml-node)
Non-interactive mode for scripted deployments
Dynamic version management
Centralized monitoring (Ansible)
Next (v0.2.0)
Multi-MLNode support (2× TP=4 for ~2× PoC weight on 8-GPU servers)
Split architecture ( --type network / --type mlnode for separate servers)
DOCKER-USER iptables chain automation
PUBLIC_URL reachability check in status command
gonka-nop unjail command
Collateral deposit/withdraw commands
Future
Self-update mechanism for the gonka-nop binary
Cloud provider compatibility (Vast.ai port remapping, GCore bare metal)
Cosmovisor upgrade pre-seeding from governance proposals
Performance benchmarking integration (compressa-perf)
Who We Are
inc4 team — operating validators on Gonka mainnet and testnet. We analyzed ~9,700 messages from the validator DevOps chat to understand operational pain points and built Gonka NOP to address them systematically. The tool is open-source (MIT) and designed to lower the barrier for new validators while reducing operational burden for existing ones.
Links:
Repository: github.com/inc4/gonka-nop (https://github.com/inc4/gonka-nop)
Demo video: youtu.be/0w6bIEROxUQ (https://youtu.be/0w6bIEROxUQ?si=FJywggqlVax90Ohn)
Monitoring proposal: Discussion #820 (https://github.com/gonka-ai/gonka/discussions/820)
Gonka NOP is independently developed and maintained. It consumes the official Gonka deployment configs and does not require any protocol changes. Feedback and contributions welcome.
Gonka NOP: интерфейс командной строки для развертывания валидатора одной командой
Категория: Предложения Ярлыки: улучшение, инструменты, инфраструктура, devops
Демо
Репозиторий: github.com/inc4/gonka-nop (https://github.com/inc4/gonka-nop)
Постановка задачи
Сегодня для развертывания валидатора Gonka требуется выполнить более 50 ручных шагов, связанных с драйверами графического процессора, настройкой Docker, управлением ключами, редактированием файлов компоновки, безопасностью портов и регистрацией в цепочке. Анализ примерно 9700 сообщений из чата DevOps валидатора Gonka показывает, что операторы сталкиваются с усугубляющимися сложностями на каждом этапе:
День-1 (Настройка):
Привяжите внутренние порты к 127.0.0.1 (Docker обходит UFW — порт 5050 открыт = узел захвачен)
Настройка защиты от DDoS, обрезки, постоянных одноранговых узлов, синхронизации состояния
Управляйте тремя отдельными ключами (учетная запись, консенсус, операционное машинное обучение)
Загрузите вес модели более 200 ГБ
Зарегистрируйтесь в сети и предоставьте разрешения ML
День-2 (Операции — 90% времени оператора):
Мониторинг частоты промахов, задержки синхронизации, участия в эпохе, веса PoC
Восстановление дискового пространства из резервных копий Космовизора
На каждом этапе есть документированные виды отказов. Валидаторы регулярно ломают свои узлы, устанавливая слишком высокое значение использования памяти графического процессора, открывая внутренние порты, используя неправильные образы MLNode для своей архитектуры графического процессора или проваливая 6-этапный процесс обновления.
Решение: Гонка НОП
Gonka NOP — это Go CLI с открытым исходным кодом, который автоматизирует весь жизненный цикл валидатора — от «голого железа» до создания доказательств PoC — с помощью одной команды.
Curl -fsSL https://github.com/inc4/gonka-nop/releases/latest/download/gonka-nop -o /usr/local/bin/gonka-nop chmod +x /usr/local/bin/gonka-nop настройка gonka-nopЧто он автоматизирует
Архитектура
Gonka NOP — это один статический двоичный файл (Go, никаких зависимостей во время выполнения) с мастером поэтапной установки:
настройка gonka-nop │ ├── Этап 1: Предварительные условия │ ├── Обнаружение/установка Docker │ ├── Обнаружение/установка драйвера NVIDIA (с подтверждением пользователя) │ ├── Установка Container Toolkit + настройка среды выполнения Docker │ ├── Установка Fabric Manager (если обнаружен NVLink) │ ├── Проверка CUDA внутри контейнера Docker │ └── Проверка дискового пространства (минимум 250 ГБ) │ ├── Этап 2: Обнаружение графического процессора │ ├── Анализ nvidia-smi (количество, VRAM, архитектура, шина PCI) │ ├── Определение топологии NVLink │ ├── Расчет оптимального TP/PP для целевой модели │ ├── Рекомендовать использование памяти gpu (0,88–0,94) │ └── Выбор образа MLNode (стандартный или Blackwell) │ ├── Этап 3: Выбор сети │ ├── Выбор основной или тестовой сети │ └── Получить последние версии образа с GitHub (динамические, не жестко закодированные) │ ├── Этап 4: Управление ключами │ ├── Быстрый рабочий процесс: все ключи на сервере (автоматически) │ └── Безопасный рабочий процесс: холодный ключ на отдельном компьютере (по инструкции) │ ├── Этап 5: Конфигурация │ ├── Создать config.env (все переменные проверены) │ ├── Создать node-config.json (модель, TP, настройки VRAM) │ ├── Создание docker-compose.yml (безопасность порта, настройки по умолчанию для DDoS) │ └── Создание docker-compose.mlnode.yml (с учетом архитектуры графического процессора) │ ├── Этап 6: Развертывание │ ├── Извлечение образов контейнеров │ ├── Запуск сетевого узла, мониторинг синхронизации блокчейна │ ├── Загрузка весов модели (более 200 ГБ, с возможностью возобновления) │ ├── Запуск узла ML, дождитесь загрузки модели │ └── Запуск проверок работоспособности (11 проверок через Admin API) │ └── Этап 7: Регистрация ├── Регистрация узла в цепочке (отправка нового участника) └── Предоставление разрешений ML (предоставить-ml-ops-разрешения)Операции дня-2
# Единая информационная панель состояния gonka-nop status # Показывает: высоту блока, статус синхронизации, эпоху, вес PoC, частоту промахов, # статус MLNode, использование графического процессора, проверки безопасности (всего 11) # Безопасное обновление обновления gonka-nop # Проверяет распределение временных интервалов → отключает узел ML → извлекает новый образ → # обновляет композицию → воссоздает → ждет загрузки модели → повторно включает # Исправляет зависшие узлы после пропущенных обновлений gonka-nop Repair # Обнаруживает отсутствующий обработчик обновлений → анализирует в цепочке update-info.json → # загружает правильные двоичные файлы (проверено SHA256) → помещает в каталоги Cosmovisor # Управление узлами ML gonka-nop ml-node list # Статус, вес PoC, временные интервалы, модель gonka-nop ml-node Enable # Включить для следующей эпохи gonka-nop ml-node отключить # Безопасное отключение # Предварительная загрузка весов модели (до или после установки) gonka-nop скачать-модель Qwen/Qwen3-235B-A22B-Instruct-2507-FP8Неинтерактивный режим
Для операторов центров обработки данных, управляющих автопарком через Ansible/Terraform:
gonka-nop setup --yes \ --network mainnet \ --key-workflow fast \ --key-name my-key \ --keyring-password " $PASS " \ --public-ip 1.2.3.4 \ --hf-home /data/hfВсе интерактивные подсказки имеют переопределение флагов CLI. Совместимость с автоматизацией SSH, конвейерами CI/CD и сценариями пакетной подготовки.
Параметры безопасности по умолчанию
Gonka NOP по умолчанию применяет усиление безопасности, основываясь на реальных шаблонах атак, описанных в чате валидатора:
Текущий статус
Gonka NOP готов к использованию и активно используется в основной сети.
Тестовое покрытие: более 190 тестовых функций в 11 тестовых файлах.
Связь с существующей работой
Дорожная карта
Завершено (v0.1.8)
Полная автоматизация настройки (предварительные условия через регистрацию)
Операции дня-2 (статус, обновление, ремонт, ml-узел)
Неинтерактивный режим для развертываний по сценарию
Динамическое управление версиями
Централизованный мониторинг (Ansible)
Далее (v0.2.0)
Поддержка нескольких MLNode (2 × TP = 4 для ~ 2 × веса PoC на серверах с 8 графическими процессорами)
Разделенная архитектура ( --type network / --type mlnode для отдельных серверов)
DOCKER-USER автоматизация цепочки iptables
Проверка доступности PUBLIC_URL в команде статуса
команда выхода из тюрьмы gonka-nop
Команды внесения/снятия залога
Будущее
Механизм самообновления двоичного файла gonka-nop
Совместимость с облачными провайдерами (переназначение портов Vast.ai, голое железо GCore)
Предварительная загрузка обновления Cosmovisor на основе предложений по управлению
Интеграция сравнительного анализа производительности (compressa-perf)
Кто мы
Команда inc4 — работающие валидаторы в основной и тестовой сети Gonka. Мы проанализировали около 9700 сообщений из чата валидатора DevOps, чтобы понять болевые точки в работе, и создали Gonka NOP для систематического их устранения. Инструмент имеет открытый исходный код (MIT) и предназначен для снижения барьера для новых валидаторов и одновременного снижения операционной нагрузки для существующих.
Ссылки:
Репозиторий: github.com/inc4/gonka-nop (https://github.com/inc4/gonka-nop)
Демонстрационное видео: youtu.be/0w6biEROxUQ (https://youtu.be/0w6biEROxUQ?si=FJywggqlVax90Ohn)
Gonka NOP разрабатывается и поддерживается независимо. Он использует официальные конфигурации развертывания Gonka и не требует каких-либо изменений протокола. Обратная связь и вклад приветствуются.