Zarządzanie w Gonka: Jak zdecentralizowana sieć jest zarządzana

Zarządzanie w Gonka działa na dwóch poziomach, każdy z własnym tempem i skalą decyzji.

Operational Voting (minuty) — decyzje operacyjne wewnątrz sieci. Gdy pojawia się spór o ważność zapytania inference lub wyniku PoC, hosty głosują przez moduł x/group Cosmos SDK. Waga głosu jest określana przez PoC weight — im więcej obliczeń wykonuje node, tym większy ma wpływ. Takie głosowania trwają minuty i rozstrzygają konkretne konflikty: czy inference był prawidłowy, czy node wykonał swoją pracę.

Governance Voting (dni) — strategiczne decyzje o rozwoju protokołu. Aktualizacje oprogramowania, zmiany parametrów sieci, aktywacja nowych modeli, dystrybucja środków Community Pool — to wszystko trafia pod głosowanie wszystkich hostów. Okres głosowania wynosi od kilku dni do tygodnia, aby wszyscy uczestnicy zdążyli zapoznać się z propozycją.

Kluczowa różnica w stosunku do większości projektów krypto: o wadze głosu decyduje Proof of Compute, a nie staking. W Gonka nie można „kupić głosu”, po prostu gromadząc tokeny w portfelu. Wpływ jest proporcjonalny do rzeczywistego wkładu obliczeniowego — GPU, które przetwarzają zapytania AI i generują dowody pracy. Od aktualizacji v0.2.16 liczy się moc potwierdzona w poprzedniej epoce: nowy host w pierwszej epoce głosuje z zerową wagą, a wzrost mocy dodaje głosy od następnej epoki. To wiąże zarządzanie z tymi, którzy naprawdę wspierają architekturę sieci, a nie z kapitałem spekulacyjnym.

W praktyce oznacza to: operator z dwoma serwerami po 8× H100 ma około dwa razy więcej głosów niż operator z jednym takim serwerem — ponieważ przetwarza około dwa razy więcej zapytań inference. System sam się równoważy: ci, którzy więcej inwestują w pracę sieci, mają większy wpływ na jej rozwój.

Ulepszenie protokołu Gonka to sformalizowany proces — od kodu po aktywację w sieci. Każdy krok jest przejrzysty i weryfikowalny.

Proces aktualizacji:

1. Pull Request na GitHubie — deweloperzy (zespół Gonka lub kontrybutorzy) tworzą PR w repozytorium gonka-ai/gonka.
2. Review społeczności — kod jest sprawdzany, omawiany i testowany. Audyt CertiK dla krytycznych zmian.
3. Release — budowana jest nowa wersja binarki inferenced.
4. On-chain proposal — tworzona jest propozycja aktualizacji w sieci z opisem zmian.
5. Deposit + Vote — hosty wpłacają depozyt (próg aktywacji) i głosują w czasie voting period.
6. Cosmovisor — po zatwierdzeniu Cosmovisor automatycznie aktualizuje nody na wskazanej wysokości bloku.

Od stycznia do maja 2026 sieć przeszła przez 13+ udanych głosowań — od wersji v0.2.2 do v0.2.13. Wszystkie propozycje zostały zatwierdzone. Chronologia kluczowych upgrade'ów:

• v0.2.11 (marzec 2026, proposal #31) — 673 699 głosów „za" przy 0 „przeciw". Wprowadzono subnet inference — mechanizm obliczeń off-chain przez podsieci, obiecujący 100-krotny wzrost przepustowości.
• v0.2.13 (maj 2026, proposal #54) — przyjęto 21 maja 2026 (62,8% „za", frekwencja 39,9% przy kworum 33,4%), aktywowano na bloku 4267300. Dodało MiniMax-M2.7 jako trzeci model w sieci, aktywowało Ethereum bridge wiring i obniżyło kworum do 0.25.

Opcje głosu:

• Yes — popieram aktualizację.
• No — jestem przeciw aktualizacji.
• No with Veto — kategorycznie przeciw; jeśli ponad 33% głosów — propozycja zostaje odrzucona, a depozyt przepada.
• Abstain — wstrzymuję się, ale uczestniczę w kworum.

Cała historia głosowań dostępna jest na gonka.gg/network/proposals — można przejrzeć każdą propozycję, wyniki i listę głosujących.

GiP — to system formalizacji pomysłów dotyczących rozwoju protokołu Gonka, uruchomiony 24 lutego 2026 r. za pośrednictwem GitHub Discussions (issue #795).

Format każdego GiP:

• Motivation — jaki problem rozwiązuje propozycja.
• Solution — techniczny opis rozwiązania.
• Roadmap — plan realizacji w etapach.
• Open Questions — otwarte pytania do dyskusji przez społeczność.

GiP nie są binding — nie zobowiązują zespołu do ich realizacji. Formują jednak konsensus społeczności i wyznaczają kierunek dla przyszłych on-chain proposals. W praktyce GiP to «pre-governance»: dyskusja przed głosowaniem.

Kluczowe GiP:

• #800 Multi-Model PoC — wsparcie dla wielu modeli AI jednocześnie. Obecnie sieć współpracuje z MiniMax M2.7 (dodano w v0.2.13), DeepSeek V4 Flash (proposal #94) oraz GLM-5.3 Flash (proposal #101). GiP opisuje architekturę równoległej pracy różnych modeli z oddzielnym Proof of Useful Work.
• #801 Inference Scaling — subnet architecture do skalowania. Część tego GiP została już wdrożona w v0.2.11 (subnet inference).
• #860 Quality Protocol — routing zapytań z uwzględnieniem jakości odpowiedzi. Węzły dostarczające najlepsze wyniki otrzymują więcej ruchu i nagród.

Każdy uczestnik może stworzyć GiP poprzez GitHub Discussions. Próg wejścia jest minimalny — wystarczy konto na GitHubie i zrozumienie problemu. Aktywne dyskusje z udziałem zespołu Gonka i hostów pokazują, że system działa: propozycje otrzymują feedback, są dopracowywane i zmierzają ku realizacji.

Community Pool — fundusz na rozwój ekosystemu Gonka. Około 20% początkowej emisji (~200 milionów GNK) przeznaczono na granty, bounty i finansowanie inicjatyw społeczności.

Bounty za wkład w kod — główny mechanizm dystrybucji środków Community Pool. Deweloperzy otrzymują wynagrodzenie za PR w repozytorium gonka-ai/gonka: od naprawy błędów po implementację nowych funkcji. Wysokość bounty zależy od złożoności i znaczenia wkładu:

Mechanizm zatwierdzania: bounty są uwzględniane w README do propozycji aktualizacji. Kiedy hosty głosują za aktualizacją protokołu, jednocześnie zatwierdzają listę wypłat za PR, które zostały włączone do tego wydania. Pełna przejrzystość — każdy może sprawdzić, za co i ile zostało wypłacone.

Oprócz bounty, Community Pool może finansować: rozwój narzędzi ekosystemu, marketing, inicjatywy edukacyjne i granty badawcze. Więcej o zarabianiu przez GitHub — w osobnym artykule.

Młoda sieć jest podatna na ataki: mało węzłów, mało stakowanych tokenów, atak 51% jest teoretycznie możliwy. Gonka rozwiązuje to za pomocą kilku mechanizmów.

Guardian System — trzy zaufane węzły, kontrolowane przez zespół Gonka, z łączną mocą konsensusu równą 34%. Guardiany nie mogą narzucać decyzji (34% < 67% do zaakceptowania), ale mogą zablokować szkodliwą propozycję (34% > 33% próg weta). Kluczowe: Guardiany automatycznie dezaktywują się, gdy ogólna moc sieci (total_network_power) osiągnie 10 milionów jednostek. To nie jest ręczny przełącznik — dezaktywacja jest zaprogramowana w protokole.

System zabezpieczeń — hosty muszą zdeponować depozyt w GNK, aby uzyskać pełną wagę:

• Waga bazowa (20%) — bezwarunkowa waga, naliczana za sam fakt działania węzła.
• Zabezpieczone (80%) — dodatkowa waga, dostępna tylko w przypadku posiadania depozytu w GNK. Wysokość depozytu jest proporcjonalna do mocy obliczeniowej.

Slashing — kara za naruszenia:

• 20% depozytu — za NIEPRAWIDŁOWE wnioskowanie (węzeł zwrócił niepoprawny wynik).
• 10% depozytu — za przestój (węzeł niedostępny powyżej dopuszczalnego progu).

Grace Period — 180 epok (~6 miesięcy), podczas których nowe hosty mogą działać bez depozytu. To obniża barierę wejścia: można zacząć wydobywać, zarabiać GNK poprzez nagrody, a dopiero potem wpłacić zabezpieczenie. Po zakończeniu Grace Period węzeł bez zabezpieczenia otrzymuje tylko 20% potencjalnej wagi.

Wszystkie te mechanizmy są opisane w tokenomice GNK i mają jeden cel: chronić sieć we wczesnej fazie, nie poświęcając decentralizacji w dłuższej perspektywie.

Governance w Gonka to nie statyczny system, lecz ewoluujący proces. Oto kluczowe kierunki rozwoju na lata 2026–2027.

Multi-Model PoC (GiP #800) — zrealizowano: pierwszą w maju 2026 przez DevShards była Kimi K2.6 (później wycofana z sieci), MiniMax-M2.7 dodano w v0.2.13 (proposal #54), DeepSeek V4 Flash podłączono w sierpniu 2026 (proposal #94), GLM-5.3 Flash — we wrześniu 2026 (proposal #101). Kolejni kandydaci to modele embeddingowe dla RAG: otworzy to Gonka na nową klasę aplikacji (wyszukiwarki, firmowe bazy wiedzy, chatboty z pamięcią).

Inference Quality Protocol (GiP #860) — routing oparty na jakości. Obecnie zapytania są rozdzielane według dostępności węzłów; w przyszłości — według jakości odpowiedzi. Węzły z lepszym sprzętem i bardziej stabilną pracą będą miały priorytet.

On-chain governance migration (2026–2027) — przejście na pełnoprawny moduł x/gov z Cosmos SDK. Da to: sformalizowane proposal types, automatyczną realizację zatwierdzonych zmian, integrację z IBC (Inter-Blockchain Communication) oraz możliwość tworzenia governance proposals za pomocą dowolnego portfela kompatybilnego z Cosmos.

Głosowania można śledzić i brać w nich udział na stronie gonka.gg/network/proposals.