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.