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ółautorzy) 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 — tworzona jest nowa wersja binarki gonkad.
4. Propozycja On-chain — tworzona jest propozycja aktualizacji w sieci z opisem zmian.
5. Wpłata + 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 marca 2026 roku sieć przeszła przez 11+ udanych głosowań – od wersji v0.2.2 do v0.2.11. Wszystkie propozycje zostały zatwierdzone. Ostatnie duże głosowanie – proposal #31 (v0.2.11) – zebrało 673 699 głosów „za” przy 0 głosach „przeciw”. Ta aktualizacja wprowadziła wnioskowanie podsieci – mechanizm obliczeń poza łańcuchem poprzez podsieci, obiecujący 100-krotny wzrost przepustowości.

Opcje głosowania:

• Tak — popieram aktualizację.
• Nie — jestem przeciw aktualizacji.
• Nie z wetem — zdecydowanie przeciw; jeśli ponad 33% głosów – propozycja zostanie odrzucona, a depozyt przepadnie.
• Wstrzymaj się — wstrzymuję się, ale uczestniczę w kworum.

Cała historia głosowań jest dostępna na gonka.gg/network/proposals – można 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 roku poprzez GitHub Discussions (issue #795).

Format każdego GiP:

• Motywacja — jaki problem rozwiązuje propozycja.
• Rozwiązanie — techniczny opis rozwiązania.
• Mapa drogowa — plan realizacji etapami.
• Otwarte pytania — nierozwiązane kwestie do dyskusji społeczności.

GiP nie są wiążące – nie zobowiązują zespołu do ich wdrożenia. Jednak kształtują konsensus społeczności i wyznaczają kierunek dla przyszłych on-chain proposals. 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; ten GiP opisuje architekturę do równoległej pracy różnych modeli z oddzielnym Proof of Useful Work.
• #801 Inference Scaling — architektura podsieci do skalowania. Część tego GiP została już zaimplementowana w v0.2.11 (subnet inference).
• #860 Quality Protocol — routing zapytań z uwzględnieniem jakości odpowiedzi. Węzły dają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 – potrzebne jest tylko 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 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 to nie statyczny system, lecz ewoluujący proces. Oto kluczowe kierunki rozwoju na lata 2026–2027.

Multi-Model PoC (GiP #800) — obsługa wielu modeli jednocześnie. Pierwszym kandydatem są modele embeddingowe dla RAG. Otworzy to Gonka na zupełnie nową klasę zastosowań: systemy wyszukiwania, korporacyjne bazy wiedzy, chatboty z pamięcią.

Inference Quality Protocol (GiP #860) — routerowanie zapytań według 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 stabilniejszą 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 typy propozycji, automatyczne wykonywanie zatwierdzonych zmian, integrację z IBC (Inter-Blockchain Communication) oraz możliwość tworzenia propozycji zarządzania za pośrednictwem dowolnego portfela kompatybilnego z Cosmos.

Możesz śledzić i uczestniczyć w głosowaniach na gonka.gg/network/proposals.