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

Zarządzanie w Gonka działa na dwóch poziomach, każdy z własną szybkością i skalą decyzji.

Operational Voting (minuty) — decyzje operacyjne w sieci. Gdy pojawia się spór dotyczący ważności żądania wnioskowania lub wyniku PoC, hosty głosują za pośrednictwem modułu x/group Cosmos SDK. Waga głosu jest określana przez PoC weight – im więcej obliczeń wykonuje węzeł, tym większy ma wpływ. Takie głosowania trwają minuty i rozwiązują konkretne konflikty: czy wnioskowanie było poprawne, czy węzeł wykonał swoją pracę.

Governance Voting (dni) — strategiczne decyzje dotyczące rozwoju protokołu. Aktualizacje oprogramowania, zmiany parametrów sieci, aktywacja nowych modeli, dystrybucja środków Community Pool – wszystko to jest poddawane głosowaniu wszystkich hostów. Okres głosowania wynosi od kilku dni do tygodnia, aby wszyscy uczestnicy mieli czas na zapoznanie się z propozycją.

Kluczowa różnica w stosunku do większości projektów kryptograficznych: waga głosu jest określana przez Proof of Compute, a nie stakowanie. 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ą żądania AI i generują dowody pracy. To wiąże zarządzanie z tymi, którzy rzeczywiście wspierają architekturę sieci, a nie ze spekulacyjnym kapitałem.

W praktyce oznacza to: operator farmy z 10 H100 ma 10 razy więcej głosów niż operator z jedną kartą – ponieważ przetwarza 10 razy więcej żądań wnioskowania. System jest samobalansujący: ci, którzy bardziej angażują się w pracę sieci, bardziej wpływają na jej rozwój.

Aktualizacja protokołu Gonka to sformalizowany proces od kodu do aktywacji w sieci. Każdy krok jest przejrzysty i weryfikowalny.

Proces aktualizacji:

1. Pull Request w GitHub — deweloperzy (zespół Gonka lub współtwórcy) tworzą PR w repozytorium gonka-ai/gonka.
2. Przegląd społeczności — kod jest sprawdzany, omawiany, testowany. Audyt CertiK dla krytycznych zmian.
3. Wydanie — budowana jest nowa wersja pliku binarnego gonkad.
4. Propozycja on-chain — tworzona jest propozycja aktualizacji w sieci z opisem zmian.
5. Depozyt + głosowanie — hosty wpłacają depozyt (próg aktywacji) i głosują w okresie głosowania.
6. Cosmovisor — po zatwierdzeniu Cosmovisor automatycznie aktualizuje węzły na określonej wysokości bloku.

Od stycznia do maja 2026 sieć przeszła przez ponad 13 pomyślnych głosowań — od wersji v0.2.2 do v0.2.13. Wszystkie propozycje zostały zatwierdzone. Chronologia kluczowych aktualizacji:

• v0.2.11 (marzec 2026, propozycja #31) — 673 699 głosów „za” przy 0 „przeciw”. Wprowadzono subnet inference — mechanizm obliczeń off-chain za pośrednictwem podsieci, obiecujący 100-krotny wzrost przepustowości.
• v0.2.13 (maj 2026, propozycja #54) — przyjęta 21 maja 2026 (62,8% „za”, frekwencja 39,9% przy kworum 33,4%), aktywowana na bloku 4267300. Dodała MiniMax-M2.7 jako trzeci model w sieci, aktywowała okablowanie mostu Ethereum i zmniejszyła kworum do 0.25.

Opcje głosowania:

• Tak — popieram aktualizację.
• Nie — jestem przeciwko aktualizacji.
• Nie z wetem — kategorycznie przeciw; jeśli ponad 33% głosów — propozycja zostaje odrzucona, a depozyt przepada.
• Wstrzymuję się — wstrzymuję się, ale uczestniczę w kworum.

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

GiP to system formalizowania pomysłów na rozwój protokołu Gonka, uruchomiony 24 lutego 2026 roku 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 etapami.
• Open Questions — nierozwiązane pytania do dyskusji przez społeczność.

GiP-y nie są wiążące – nie zobowiązują zespołu do ich wdrożenia. Kształtują jednak konsensus społeczności i wyznaczają kierunek dla przyszłych propozycji on-chain. W rzeczywistości GiP to „pre-governance”: dyskusja przed głosowaniem.

Kluczowe GiP:

• #800 Multi-Model PoC — obsługa wielu modeli AI jednocześnie. Obecnie sieć działa z Qwen3-235B i Kimi K2.6 (przez DevShards od maja 2026). MiniMax-M2.7 jest dodawana w v0.2.13. GiP opisuje architekturę dla równoległej pracy różnych modeli z oddzielnym Proof of Useful Work.
• #801 Inference Scaling — architektura podsieci do skalowania. Część tego GiP jest już zaimplementowana w v0.2.11 (subnet inferenced).
• #860 Quality Protocol — routingu zapytań z uwzględnieniem jakości odpowiedzi. Nody, które dostarczają lepsze wyniki, otrzymują więcej ruchu i nagród.

Każdy uczestnik może stworzyć GiP za pośrednictwem GitHub Discussions. Próg wejścia jest minimalny – wystarczy konto GitHub i zrozumienie problemu. Aktywne dyskusje z udziałem zespołu Gonka i hostów pokazują, że system działa: propozycje otrzymują informacje zwrotne, są dopracowywane i zmierzają do wdrożenia.

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.

Zarządzanie w Gonka nie jest systemem statycznym, lecz ewoluującym procesem. Oto kluczowe kierunki rozwoju na lata 2026–2027.

Multi-Model PoC (GiP #800) — zaimplementowany: Kimi K2.6 działa już w DevShards od maja 2026, MiniMax-M2.7 zostanie dodany w v0.2.13 (proposal #54). Kolejnymi kandydatami są modele embeddingowe dla RAG: otworzy to Gonka na nową klasę aplikacji (wyszukiwarki, firmowe bazy wiedzy, chatboty z pamięcią).

Inference Quality Protocol (GiP #860) — routingu pod względem jakości. Obecnie zapytania są dystrybuowane na podstawie dostępności nodów; w przyszłości — na podstawie jakości odpowiedzi. Nody z lepszym sprzętem i stabilniejszą pracą będą miały priorytet.

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

Możesz śledzić głosowania i brać w nich udział na gonka.gg/network/proposals.