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 na GitHubie — deweloperzy (zespół Gonki lub współtwórcy) tworzą PR w repozytorium gonka-ai/gonka.
2. Recenzja społeczności — kod jest sprawdzany, omawiany, testowany. Audyt CertiK dla krytycznych zmian.
3. Wydanie — tworzona 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 wskazanej wysokości bloku.

Od stycznia do maja 2026 roku sieć przeszła przez ponad 13 udanych 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”, 0 „przeciw”. Wprowadzono wnioskowanie podsieci — mechanizm obliczeń off-chain poprzez 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łosu:

• Tak — popieram aktualizację.
• Nie — jestem przeciw aktualizacji.
• Nie z wetem — jestem kategorycznie przeciwny; 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 formalizacji pomysłów na rozwój protokołu Gonka, uruchomiony 24 lutego 2026 r. poprzez 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 nie są binding — nie zobowiązują zespołu do ich realizacji. Jednak kształtują one konsensus społeczności i wyznaczają kierunek przyszłych on-chain proposals. W istocie GiP to „pre-governance”: dyskusja przed głosowaniem.

Kluczowe GiP:

• #800 Multi-Model PoC — obsługa wielu modeli AI jednocześnie. Obecnie sieć współpracuje z Kimi K2.6 oraz MiniMax M2.7. MiniMax-M2.7 zostanie dodany w v0.2.13. GiP opisuje architekturę paralelnego działania różnych modeli z osobnym Proof of Useful Work.
• #801 Inference Scaling — subnet architecture do skalowania. Część tego GiP jest już zaimplementowana 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 wynagrodzeń.

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 oraz 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.

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.