INC4 | Gonka NOP — грант на инструмент развертывания нод
Оригинал: INC4 | Gonka NOP - grant for the node deployment tool
Gonka NOP — грант на инструмент развертывания узлов
Запрос на финансирование CommunityPool, охватывающий выполненную работу над gonka-nop, текущую поддержку операторов и постоянное развитие инструмента.
ТЛ;ДР
INC4 предлагает выделить 50 000 долларов США из CommunityPool для gonka-nop (Node Onboarding Package), инструмента CLI для развертывания и обслуживания узлов Gonka. Инструмент уже создан, выпущен под лицензией MIT и активно используется некоторыми операторами в основной сети — это не предложение создать что-то новое, а просьба профинансировать работу, которая уже создала работающий инструмент со своими собственными пользователями. Грант охватывает три области: уже проделанную работу, постоянную поддержку пользователей NOP и дальнейшее развитие инструмента. Грант выплачивается в долларах США, а не в собственных токенах GNK, и структурирован как единый перевод без перехода прав или поэтапных траншей. Не существует подробной разбивки бюджета и графика этапов: распределение усилий по трем областям остается на усмотрение INC4, при этом публичный репозиторий служит основой подотчетности.
Что такое гонка-ноп
Gonka NOP — это интерфейс командной строки, который сводит развертывание узла Gonka к одной операции. Инструмент проверяет состояние целевого сервера, устанавливает недостающие зависимости, подключает необходимые компоненты в правильном порядке и регистрирует узел в сети. Детали, специфичные для Gonka, закодированы внутри инструмента и обновляются вместе с сетевыми выпусками, поэтому оператору не нужно отслеживать их выпуск за выпуском. Сюда входят версии образа, конфигурация vLLM, настроенная на конкретную модель графического процессора, присутствующую на хосте, параметры регистрации, ожидаемые цепочкой, и условия готовности, которым узел должен соответствовать перед раундами PoC и cPoC. Это то, что отличает NOP от пакета docker-compose: он содержит операционную модель Gonka, а не только набор контейнеров. Поддерживаются основные топологии развертывания: автономный сетевой узел, комбинированная конфигурация с узлом ML на одном компьютере и распределенная настройка с несколькими узлами ML на отдельных хостах за одним сетевым узлом.
Инструмент предназначен для двух разных аудиторий. Для операторов без глубокого опыта DevOps это снижает входной барьер: достаточно арендовать сервер с подходящим графическим процессором и пройти через интерактивный мастер, без необходимости вручную работать с драйверами графического процессора, взаимодействием между уровнями или файлами конфигурации vLLM. Мастер отображает небольшой набор вариантов, которые фактически необходимо сделать оператору (топология, профиль оборудования, конечные точки сети), а остальное решает на основе значений по умолчанию, которые отслеживают текущие требования к сети. Для опытных администраторов один и тот же двоичный файл обеспечивает повторяемость: большинство запросов в мастере имеют эквивалентный флаг командной строки, двоичный файл запускается в неинтерактивном режиме, когда конфигурация предоставляется заранее, а полученные вызовы легко интегрируются в сборники сценариев Ansible и другие системы автоматизации. Одни и те же флаги управляют как первоначальным развертыванием, так и обновлением на месте, поэтому путь от новой установки до узла, на котором работает последняя версия, — это одна и та же команда для всего парка операторов. Развертывание десятков узлов примерно так же сложно, как и развертывание одного, что важно для любого оператора, управляющего парком, а не одним экземпляром.
- Репозиторий на GitHub: https://github.com/inc4/gonka-nop.
- Документация: https://github.com/inc4/gonka-nop/blob/main/README.md.
- Прохождение в прямом эфире на YouTube (автор — Gonka.Top@Mitch): https://www.youtube.com/watch?v=1t9GEMN92Vo.
Проблема с развертыванием
Развертывание узла Gonka — это многоэтапный процесс, включающий несколько разнородных компонентов: драйверы графического процессора, среду выполнения контейнера и сами различные компоненты Gonka. Каждый уровень имеет свои требования к версиям, портам, ресурсам и порядку конфигурации. Интерфейсы между ними неумолимы — несовпадение в каком-то одном месте редко проявляется при установке; он появляется позже, когда ожидается, что узел будет обслуживать раунды PoC и cPoC. Требования также периодически меняются в зависимости от сетевых выпусков: новые модели заменяют старые, теги изображений перемещаются, параметры vLLM перенастраиваются, в поддерживаемый набор входят дополнительные семейства графических процессоров, а конкретная комбинация версий, составляющая действительный узел в любой данный момент, не является той же комбинацией, которая была действительна двумя выпусками ранее. Каждая смена затрагивает разные подмножества слоев, и оператор несет расходы по определению того, какое это подмножество.
Сочетание цепочки Cosmos SDK с производственным стеком вывода ML под одним и тем же оператором встречается редко. Операционные знания, необходимые для управления обоими аспектами — проблемами на уровне цепочки, такими как участие в консенсусе и сокращение, а также проблемами инфраструктуры, такими как расположение памяти графического процессора и обслуживание моделей, — не широко доступны за пределами специализированных команд.
Стоимость ошибки ложится на оператора. Пропущенные раунды PoC и cPoC, отстающий сетевой узел или несоответствие версий между компонентами могут привести к потере вознаграждения и, возможно, тюремному заключению. Время, потраченное на диагностику инцидентов, не возвращается. Для опытного администратора это легко, но отнимает много времени. Для оператора, впервые работающего в сетях Cosmos SDK, стек требований практически невозможен без внешней помощи. NOP снимает эту часть нагрузки с оператора.
Предложение
Запрос на финансирование отражает структуру самой работы: что уже выполнено, что необходимо для ее продолжения и что будет дальше. Грант охватывает три соответствующие области.
Ретроактивная компенсация за разработку уже выплачена. Текущая версия NOP — это рабочий инструмент с активной базой пользователей среди операторов основной сети. INC4 взял на себя первоначальную разработку как вклад в сеть. Ретроактивная часть гранта оплачивает выполненную работу.
Поддержка пользователей NOP. INC4 сортирует инциденты, помогает с диагностикой во время развертывания и эксплуатации, отвечает в чатах DevOps и отправляет исправления и обновления, соответствующие новым выпускам Gonka. Эта рабочая нагрузка является повторяющейся, а не разовой — она возвращается каждый раз при изменении сети. Грант обязывает INC4 поддерживать инструмент в рамках той же модели.
Продолжение развития. Новые возможности, более широкий охват сценариев развертывания, дальнейшее снижение входного барьера. Конкретные задачи формируются в диалоге с операторами и основной командой Gonka и публично отслеживаются в репозитории. В предложении намеренно не предусмотрены предварительные обязательства по списку функций: приоритеты должны соответствовать тому, что на самом деле требуется сети по мере ее развития.
Условия гранта
Сумма составляет 50 000 долларов США и выплачивается одним переводом, без перехода прав и без поэтапных траншей. Работа ведется открыто: код, релизы, система отслеживания проблем и журнал изменений доступны на GitHub и доступны всем — операторам, основной команде и участникам DAO. Никакой дополнительной структуры отчетности для DAO не предлагается: публичный репозиторий является отчетом. Любой — член сообщества, валидатор или основной участник — может проверить состояние работы в любой момент после утверждения гранта, не спрашивая об этом.
Предложение было опубликовано для обсуждения сообществом до подачи заявки в сети. Обсуждения остаются открытыми по адресу:
https://vote.gonka.vip/tenders/2cbbe98e-ceff-4f09-a1cd-e8d370e97fde
https://gonkavote.com/proposals/6
Почему это важно для сети
Этот грант посвящен тому, насколько легко сеть может поглощать новых операторов. Сегодня большинство операторов Gonka — это люди, имеющие опыт самостоятельного развертывания и запуска узла. Это работает, пока сеть растет через свое ядро, но в какой-то момент рост сталкивается с входным барьером для всех, у кого нет такого опыта. NOP устраняет этот барьер: новому оператору не нужно разбираться во внутреннем устройстве, а опытный оператор получает возможность автоматизации управления парком узлов.
Сеть меняется с каждым релизом — новые модели, обновленные изображения, корректируемые параметры. Если инструмент не успевает за ним, он быстро становится снимком прошлого, и входной барьер возвращается. Грант финансирует именно эту задачу: сохранение текущей версии NOP за другой.
Грант покрывает не только продукт, но и работу по его поддержанию. Развертывание узлов должно оставаться простым по мере развития сети, а уровень инфраструктуры не должен становиться узким местом для роста.
В зрелых сетях инструменты развертывания рассматриваются как часть поверхности протокола, а не как побочный проект, поддерживаемый с той же частотой, что и цепочка. Альтернативой является набор операторов, который уменьшается с каждым обновлением, поскольку операторы, которые не могут идти в ногу с каждым выпуском, незаметно отстают и перестают участвовать. Долгосрочная устойчивость сети ограничена количеством операторов, которые могут поддерживать исправность своих узлов посредством изменений, а не тем, сколько из них смогли их настроить изначально.
INC4
- Сайт: https://inc4.net.
Гитхаб: https://github.com/inc4
Gonka NOP - grant for the node deployment tool
A CommunityPool funding request covering delivered work on gonka-nop, ongoing operator support, and continued development of the tool.
TL;DR
INC4 proposes a 50,000 USDT allocation from the CommunityPool for gonka-nop (Node Onboarding Package), a CLI tool for deploying and maintaining Gonka nodes. The tool is already built, released under the MIT license, and in active use by some operators on mainnet — it is not a proposal to build something new, but a request to fund work that has already produced a working tool with its own users. The grant covers three areas: the work already delivered, ongoing support for NOP users, and continued development of the tool. The grant is paid in USDT rather than the native GNK token, and is structured as a single transfer without vesting or milestone tranches. There is no detailed budget breakdown and no milestone schedule: allocation of effort across the three areas remains at INC4's discretion, with the public repository serving as the basis of accountability.
What is gonka-nop
Gonka NOP is a CLI that reduces deploying a Gonka node to a single operation. The tool inspects the state of the target server, installs missing dependencies, brings up the required components in the correct order, and registers the node with the network. Gonka-specific details are encoded inside the tool and updated alongside network releases, so the operator does not have to track them release by release. This includes image versions, vLLM configuration tuned to the specific GPU model present on the host, registration parameters expected by the chain, and readiness conditions a node must satisfy before PoC and cPoC rounds. This is what separates NOP from a docker-compose bundle: it carries Gonka's operational model, not just its container set. The main deployment topologies are supported: a standalone Network Node, a combined configuration with the ML Node on the same machine, and a distributed setup with multiple ML Nodes on separate hosts behind a single Network Node.
The tool addresses two distinct audiences. For operators without deep DevOps experience, it lowers the entry barrier: renting a server with a suitable GPU and stepping through an interactive wizard is enough, with no need to work through GPU drivers, the interaction between layers, or vLLM configuration files by hand. The wizard surfaces the small set of choices an operator actually needs to make — topology, hardware profile, network endpoints — and resolves the rest from defaults that track current network requirements. For experienced administrators, the same binary provides repeatability: most prompts in the wizard have an equivalent command-line flag, the binary runs non-interactively when configuration is supplied up front, and the resulting invocations integrate cleanly into Ansible playbooks and other automation systems. The same flags drive both initial deployment and in-place upgrades, so the path from a fresh installation to a node running the latest release is the same single command across an operator's fleet. Deploying dozens of nodes ends up roughly as complex as deploying one, which matters for any operator running a fleet rather than a single instance.
Repository on GitHub: https://github.com/inc4/gonka-nop
Documentation: https://github.com/inc4/gonka-nop/blob/main/README.md
Live walkthrough on YouTube (by Gonka.Top@Mitch): https://www.youtube.com/watch?v=1t9GEMN92Vo
The deployment problem
Deploying a Gonka node is a multi-step process involving several heterogeneous components: GPU drivers, the container runtime, and the various Gonka components themselves. Each layer has its own requirements for versions, ports, resources, and configuration order. The interfaces between them are unforgiving — a mismatch in any one place rarely shows up during installation; it surfaces later, once the node is expected to serve PoC and cPoC rounds. Requirements also shift periodically with network releases: new models replace older ones, image tags move, vLLM parameters get retuned, additional GPU families enter the supported set, and the specific combination of versions that constitutes a valid node at any given moment is not the same combination that was valid two releases earlier. Each shift touches a different subset of layers, and the operator carries the cost of working out which subset that is.
The combination of a Cosmos SDK chain with a production ML inference stack under the same operator is uncommon. The operational knowledge needed to manage both — chain-level concerns like consensus participation and slashing, alongside infrastructure concerns like GPU memory layout and model serving — is not widely available outside specialized teams.
The cost of getting it wrong falls on the operator. Missed PoC and cPoC rounds, a lagging Network Node, or version mismatches between components can all result in lost rewards and possibly jail. Time spent diagnosing incidents does not come back. For an experienced administrator this is tractable but time-consuming. For an operator new to Cosmos SDK networks, the requirement stack is in practice impassable without external help. NOP removes that part of the workload from the operator.
Proposal
The funding request reflects the structure of the work itself: what has already been delivered, what is needed to keep it running, and what comes next. The grant covers three corresponding areas.
Retroactive compensation for development already delivered. The current version of NOP is a working tool with an active user base among mainnet operators. INC4 took on the initial development as a contribution to the network. The retroactive portion of the grant settles that delivered work.
Support for NOP users. INC4 triages incidents, helps with diagnostics during deployment and operation, responds in DevOps chats, and ships patches and updates aligned with new Gonka releases. This workload is recurring rather than one-off — it returns each time the network changes. The grant commits INC4 to maintaining the tool under the same model.
Continued development. New capabilities, broader coverage of deployment scenarios, further reductions in the entry barrier. Concrete tasks are shaped in dialogue with operators and the Gonka core team, and tracked publicly in the repository. The proposal deliberately does not pre-commit to a feature list: priorities need to remain responsive to what the network actually requires as it evolves.
Grant terms
The amount is 50,000 USDT, paid as a single transfer, without vesting and without milestone tranches. Work is conducted in the open: code, releases, the issue tracker, and the changelog all live on GitHub and are accessible to anyone — operators, the core team, and DAO participants. No additional reporting structure to the DAO is proposed: the public repository is the report. Anyone — community member, validator, or core contributor — can inspect the state of the work at any point after the grant is approved, without having to ask.
The proposal was published for community discussion in advance of this on-chain submission. The discussions remain open at:
https://vote.gonka.vip/tenders/2cbbe98e-ceff-4f09-a1cd-e8d370e97fde
https://gonkavote.com/proposals/6
Why this matters for the network
This grant is about how easily the network can absorb new operators. Today most Gonka operators are people with the experience to deploy and run a node on their own. That works while the network grows through its core, but at some point growth runs into the entry barrier for everyone without that background. NOP removes that barrier: a new operator doesn't have to understand the internals, and an experienced operator gets the automation to manage a fleet of nodes.
The network changes with every release — new models, updated images, adjusted parameters. If the tool doesn't keep up, it quickly becomes a snapshot of the past, and the entry barrier comes back. The grant funds exactly that work: keeping NOP current release after release.
The grant covers not just the product, but the work of keeping it current. Node deployment should stay simple as the network evolves, and the infrastructure layer shouldn't become a bottleneck to growth.
In mature networks, deployment tooling is treated as part of the protocol surface rather than a side project, maintained at the same cadence as the chain — the alternative is an operator set that thins out with every upgrade, as operators who cannot keep pace with each release quietly fall behind and stop participating. A network's long-term resilience is bounded by the breadth of operators who can keep their nodes correct through change, not by how many were able to set one up in the first place.
Gonka NOP — грант на инструмент развертывания узлов
Запрос на финансирование CommunityPool, охватывающий выполненную работу над gonka-nop, текущую поддержку операторов и постоянное развитие инструмента.
ТЛ;ДР
INC4 предлагает выделить 50 000 долларов США из CommunityPool для gonka-nop (Node Onboarding Package), инструмента CLI для развертывания и обслуживания узлов Gonka. Инструмент уже создан, выпущен под лицензией MIT и активно используется некоторыми операторами в основной сети — это не предложение создать что-то новое, а просьба профинансировать работу, которая уже создала работающий инструмент со своими собственными пользователями. Грант охватывает три области: уже проделанную работу, постоянную поддержку пользователей NOP и дальнейшее развитие инструмента. Грант выплачивается в долларах США, а не в собственных токенах GNK, и структурирован как единый перевод без перехода прав или поэтапных траншей. Не существует подробной разбивки бюджета и графика этапов: распределение усилий по трем областям остается на усмотрение INC4, при этом публичный репозиторий служит основой подотчетности.
Что такое гонка-ноп
Gonka NOP — это интерфейс командной строки, который сводит развертывание узла Gonka к одной операции. Инструмент проверяет состояние целевого сервера, устанавливает недостающие зависимости, подключает необходимые компоненты в правильном порядке и регистрирует узел в сети. Детали, специфичные для Gonka, закодированы внутри инструмента и обновляются вместе с сетевыми выпусками, поэтому оператору не нужно отслеживать их выпуск за выпуском. Сюда входят версии образа, конфигурация vLLM, настроенная на конкретную модель графического процессора, присутствующую на хосте, параметры регистрации, ожидаемые цепочкой, и условия готовности, которым узел должен соответствовать перед раундами PoC и cPoC. Это то, что отличает NOP от пакета docker-compose: он содержит операционную модель Gonka, а не только набор контейнеров. Поддерживаются основные топологии развертывания: автономный сетевой узел, комбинированная конфигурация с узлом ML на одном компьютере и распределенная настройка с несколькими узлами ML на отдельных хостах за одним сетевым узлом.
Инструмент предназначен для двух разных аудиторий. Для операторов без глубокого опыта DevOps это снижает входной барьер: достаточно арендовать сервер с подходящим графическим процессором и пройти через интерактивный мастер, без необходимости вручную работать с драйверами графического процессора, взаимодействием между уровнями или файлами конфигурации vLLM. Мастер отображает небольшой набор вариантов, которые фактически необходимо сделать оператору (топология, профиль оборудования, конечные точки сети), а остальное решает на основе значений по умолчанию, которые отслеживают текущие требования к сети. Для опытных администраторов один и тот же двоичный файл обеспечивает повторяемость: большинство запросов в мастере имеют эквивалентный флаг командной строки, двоичный файл запускается в неинтерактивном режиме, когда конфигурация предоставляется заранее, а полученные вызовы легко интегрируются в сборники сценариев Ansible и другие системы автоматизации. Одни и те же флаги управляют как первоначальным развертыванием, так и обновлением на месте, поэтому путь от новой установки до узла, на котором работает последняя версия, — это одна и та же команда для всего парка операторов. Развертывание десятков узлов примерно так же сложно, как и развертывание одного, что важно для любого оператора, управляющего парком, а не одним экземпляром.
Проблема с развертыванием
Развертывание узла Gonka — это многоэтапный процесс, включающий несколько разнородных компонентов: драйверы графического процессора, среду выполнения контейнера и сами различные компоненты Gonka. Каждый уровень имеет свои требования к версиям, портам, ресурсам и порядку конфигурации. Интерфейсы между ними неумолимы — несовпадение в каком-то одном месте редко проявляется при установке; он появляется позже, когда ожидается, что узел будет обслуживать раунды PoC и cPoC. Требования также периодически меняются в зависимости от сетевых выпусков: новые модели заменяют старые, теги изображений перемещаются, параметры vLLM перенастраиваются, в поддерживаемый набор входят дополнительные семейства графических процессоров, а конкретная комбинация версий, составляющая действительный узел в любой данный момент, не является той же комбинацией, которая была действительна двумя выпусками ранее. Каждая смена затрагивает разные подмножества слоев, и оператор несет расходы по определению того, какое это подмножество.
Сочетание цепочки Cosmos SDK с производственным стеком вывода ML под одним и тем же оператором встречается редко. Операционные знания, необходимые для управления обоими аспектами — проблемами на уровне цепочки, такими как участие в консенсусе и сокращение, а также проблемами инфраструктуры, такими как расположение памяти графического процессора и обслуживание моделей, — не широко доступны за пределами специализированных команд.
Стоимость ошибки ложится на оператора. Пропущенные раунды PoC и cPoC, отстающий сетевой узел или несоответствие версий между компонентами могут привести к потере вознаграждения и, возможно, тюремному заключению. Время, потраченное на диагностику инцидентов, не возвращается. Для опытного администратора это легко, но отнимает много времени. Для оператора, впервые работающего в сетях Cosmos SDK, стек требований практически невозможен без внешней помощи. NOP снимает эту часть нагрузки с оператора.
Предложение
Запрос на финансирование отражает структуру самой работы: что уже выполнено, что необходимо для ее продолжения и что будет дальше. Грант охватывает три соответствующие области.
Ретроактивная компенсация за разработку уже выплачена. Текущая версия NOP — это рабочий инструмент с активной базой пользователей среди операторов основной сети. INC4 взял на себя первоначальную разработку как вклад в сеть. Ретроактивная часть гранта оплачивает выполненную работу.
Поддержка пользователей NOP. INC4 сортирует инциденты, помогает с диагностикой во время развертывания и эксплуатации, отвечает в чатах DevOps и отправляет исправления и обновления, соответствующие новым выпускам Gonka. Эта рабочая нагрузка является повторяющейся, а не разовой — она возвращается каждый раз при изменении сети. Грант обязывает INC4 поддерживать инструмент в рамках той же модели.
Продолжение развития. Новые возможности, более широкий охват сценариев развертывания, дальнейшее снижение входного барьера. Конкретные задачи формируются в диалоге с операторами и основной командой Gonka и публично отслеживаются в репозитории. В предложении намеренно не предусмотрены предварительные обязательства по списку функций: приоритеты должны соответствовать тому, что на самом деле требуется сети по мере ее развития.
Условия гранта
Сумма составляет 50 000 долларов США и выплачивается одним переводом, без перехода прав и без поэтапных траншей. Работа ведется открыто: код, релизы, система отслеживания проблем и журнал изменений доступны на GitHub и доступны всем — операторам, основной команде и участникам DAO. Никакой дополнительной структуры отчетности для DAO не предлагается: публичный репозиторий является отчетом. Любой — член сообщества, валидатор или основной участник — может проверить состояние работы в любой момент после утверждения гранта, не спрашивая об этом.
Предложение было опубликовано для обсуждения сообществом до подачи заявки в сети. Обсуждения остаются открытыми по адресу:
https://vote.gonka.vip/tenders/2cbbe98e-ceff-4f09-a1cd-e8d370e97fde
https://gonkavote.com/proposals/6
Почему это важно для сети
Этот грант посвящен тому, насколько легко сеть может поглощать новых операторов. Сегодня большинство операторов Gonka — это люди, имеющие опыт самостоятельного развертывания и запуска узла. Это работает, пока сеть растет через свое ядро, но в какой-то момент рост сталкивается с входным барьером для всех, у кого нет такого опыта. NOP устраняет этот барьер: новому оператору не нужно разбираться во внутреннем устройстве, а опытный оператор получает возможность автоматизации управления парком узлов.
Сеть меняется с каждым релизом — новые модели, обновленные изображения, корректируемые параметры. Если инструмент не успевает за ним, он быстро становится снимком прошлого, и входной барьер возвращается. Грант финансирует именно эту задачу: сохранение текущей версии NOP за другой.
Грант покрывает не только продукт, но и работу по его поддержанию. Развертывание узлов должно оставаться простым по мере развития сети, а уровень инфраструктуры не должен становиться узким местом для роста.
В зрелых сетях инструменты развертывания рассматриваются как часть поверхности протокола, а не как побочный проект, поддерживаемый с той же частотой, что и цепочка. Альтернативой является набор операторов, который уменьшается с каждым обновлением, поскольку операторы, которые не могут идти в ногу с каждым выпуском, незаметно отстают и перестают участвовать. Долгосрочная устойчивость сети ограничена количеством операторов, которые могут поддерживать исправность своих узлов посредством изменений, а не тем, сколько из них смогли их настроить изначально.
INC4
Гитхаб: https://github.com/inc4