Governance в Gonka: как управляется децентрализованная сеть

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

Operational Voting (минуты) — оперативные решения внутри сети. Когда возникает спор о валидности inference-запроса или результата PoC, хосты голосуют через модуль x/group Cosmos SDK. Вес голоса определяется PoC weight — чем больше вычислений выполняет нода, тем больше её влияние. Такие голосования длятся минуты и разрешают конкретные конфликты: был ли inference корректным, выполнила ли нода свою работу.

Governance Voting (дни) — стратегические решения о развитии протокола. Обновления софта, изменение параметров сети, активация новых моделей, распределение средств Community Pool — всё это выносится на голосование всех хостов. Период голосования — от нескольких дней до недели, чтобы все участники успели ознакомиться с предложением.

Ключевое отличие от большинства крипто-проектов: вес голоса определяется Proof of Compute, а не стейкингом. В Gonka нельзя «купить голос», просто накопив токены на кошельке. Влияние пропорционально реальному вычислительному вкладу — GPU, которые обрабатывают AI-запросы и генерируют доказательства работы. Это привязывает управление к тем, кто действительно поддерживает архитектуру сети, а не к спекулятивному капиталу.

На практике это означает: оператор фермы из 10 H100 имеет в 10 раз больше голосов, чем оператор с одной картой — потому что он обрабатывает в 10 раз больше inference-запросов. Система самобалансирующаяся: те, кто больше вкладывает в работу сети, больше влияют на её развитие.

Обновление протокола Gonka — это формализованный процесс от кода до активации в сети. Каждый шаг прозрачен и проверяем.

Процесс обновления:

1. Pull Request в GitHub — разработчики (команда Gonka или контрибьюторы) создают PR в репозитории gonka-ai/gonka.
2. Review сообществом — код проверяется, обсуждается, тестируется. Аудит CertiK для критических изменений.
3. Release — собирается новая версия бинарника gonkad.
4. On-chain proposal — создаётся предложение об обновлении в сети с описанием изменений.
5. Deposit + Vote — хосты вносят депозит (порог активации) и голосуют в течение voting period.
6. Cosmovisor — при одобрении Cosmovisor автоматически обновляет ноды на указанной высоте блока.

С января по март 2026 сеть прошла через 11+ успешных голосований — от версии v0.2.2 до v0.2.11. Все предложения были одобрены. Последнее крупное голосование — proposal #31 (v0.2.11) — набрало 673,699 голосов «за» при 0 голосов «против». Это обновление ввело subnet inference — механизм off-chain вычислений через подсети, обещающий 100-кратный рост пропускной способности.

Варианты голоса:

• Yes — поддерживаю обновление.
• No — против обновления.
• No with Veto — категорически против; если более 33% голосов — предложение отклоняется, а депозит сгорает.
• Abstain — воздерживаюсь, но участвую в кворуме.

Вся история голосований доступна на gonka.gg/network/proposals — можно посмотреть каждое предложение, результаты и список проголосовавших.

GiP — это система формализации идей по развитию протокола Gonka, запущенная 24 февраля 2026 через GitHub Discussions (issue #795).

Формат каждого GiP:

• Motivation — какую проблему решает предложение.
• Solution — техническое описание решения.
• Roadmap — план реализации по этапам.
• Open Questions — нерешённые вопросы для обсуждения сообществом.

GiP не являются binding — они не обязывают команду к реализации. Но они формируют консенсус сообщества и задают направление для будущих on-chain proposals. Фактически GiP — это «pre-governance»: обсуждение до голосования.

Ключевые GiP:

• #800 Multi-Model PoC — поддержка нескольких AI-моделей одновременно. Сейчас сеть работает с Qwen3-235B; этот GiP описывает архитектуру для параллельной работы разных моделей с раздельным Proof of Useful Work.
• #801 Inference Scaling — subnet architecture для масштабирования. Часть этого GiP уже реализована в v0.2.11 (subnet inference).
• #860 Quality Protocol — маршрутизация запросов с учётом качества ответов. Ноды, дающие лучшие результаты, получают больше трафика и вознаграждений.

Любой участник может создать GiP через GitHub Discussions. Порог входа минимальный — нужен только GitHub-аккаунт и понимание проблемы. Активные обсуждения с участием команды Gonka и хостов показывают, что система работает: предложения получают обратную связь, дорабатываются и двигаются к реализации.

Community Pool — фонд развития экосистемы Gonka. Около 20% генезис-эмиссии (~200 миллионов GNK) выделено на гранты, баунти и финансирование инициатив сообщества.

Баунти за вклад в код — основной механизм распределения средств Community Pool. Разработчики получают вознаграждение за PR в репозитории gonka-ai/gonka: от исправления багов до реализации новых фич. Размер баунти зависит от сложности и важности вклада:

Механизм одобрения: баунти включаются в README к upgrade proposals. Когда хосты голосуют за обновление протокола, они одновременно одобряют список выплат за PR, вошедшие в этот релиз. Прозрачность полная — любой может проверить, за что и сколько было выплачено.

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

Молодая сеть уязвима: мало нод, мало стейка, атака 51% теоретически возможна. Gonka решает это несколькими механизмами.

Guardian System — три доверенных узла, контролируемых командой Gonka, с суммарными 34% consensus power. Guardians не могут навязывать решения (34% < 67% для принятия), но могут заблокировать вредоносное предложение (34% > 33% порог вето). Ключевое: Guardians автоматически деактивируются, когда общая мощность сети (total_network_power) достигнет 10 миллионов единиц. Это не ручной переключатель — деактивация запрограммирована в протоколе.

Коллатеральная система — хосты должны внести залог в GNK для получения полного веса:

• Base Weight (20%) — безусловный вес, начисляется за сам факт работы ноды.
• Collateral-Eligible (80%) — дополнительный вес, доступный только при наличии залога в GNK. Размер залога пропорционален вычислительной мощности.

Слэшинг — наказание за нарушения:

• 20% залога — за INVALID inference (нода выдала некорректный результат).
• 10% залога — за downtime (нода недоступна сверх допустимого порога).

Grace Period — 180 эпох (~6 месяцев), в течение которых новые хосты могут работать без залога. Это снижает барьер входа: можно начать майнить, заработать GNK через вознаграждения и только потом внести коллатерал. После завершения Grace Period нода без залога получает только 20% от потенциального веса.

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

Governance в Gonka — не статичная система, а эволюционирующий процесс. Вот ключевые направления развития на 2026–2027 годы.

Multi-Model PoC (GiP #800) — поддержка нескольких моделей одновременно. Первый кандидат — embedding-модели для RAG. Это откроет Gonka для совершенно нового класса приложений: поисковые системы, корпоративные базы знаний, чат-боты с памятью.

Inference Quality Protocol (GiP #860) — маршрутизация по качеству. Сейчас запросы распределяются по доступности нод; в будущем — по качеству ответов. Ноды с лучшим железом и более стабильной работой будут получать приоритет.

On-chain governance migration (2026–2027) — переход на полноценный модуль x/gov из Cosmos SDK. Это даст: формализованные proposal types, автоматическое исполнение одобренных изменений, интеграцию с IBC (Inter-Blockchain Communication) и возможность создавать governance proposals через любой Cosmos-совместимый кошелёк.

Следить за голосованиями и участвовать можно на gonka.gg/network/proposals.