Governance sa Gonka: Paano pinamamahalaan ang isang desentralisadong network

Ang pamamahala sa Gonka ay gumagana sa dalawang antas, bawat isa ay may sariling bilis at saklaw ng mga desisyon.

Operational Voting (minuto) — mga operasyonal na desisyon sa loob ng network. Kapag may di-pagkakasundo tungkol sa validity ng inference-request o resulta ng PoC, bumoboto ang mga host sa pamamagitan ng x/group module ng Cosmos SDK. Ang bigat ng boto ay tinutukoy ng PoC weight — kung mas maraming computation ang ginagawa ng isang node, mas malaki ang impluwensya nito. Ang mga ganitong pagboto ay tumatagal ng ilang minuto at nilulutas ang mga konkretong salungatan: kung tama ba ang inference, o kung nagawa ba ng node ang trabaho nito.

Governance Voting (araw) — mga estratehikong desisyon tungkol sa pag-unlad ng protocol. Ang mga software update, pagbabago ng parameter ng network, pag-activate ng mga bagong modelo, pamamahagi ng pondo ng Community Pool — lahat ito ay isinasailalim sa pagboto ng lahat ng host. Ang panahon ng pagboto ay mula ilang araw hanggang isang linggo, upang magkaroon ng oras ang lahat ng kalahok na suriin ang panukala.

Ang pangunahing pagkakaiba mula sa karamihan ng mga proyekto ng crypto: ang bigat ng boto ay tinutukoy ng Proof of Compute, hindi ng staking. Sa Gonka, hindi ka maaaring 'bumili ng boto' sa pamamagitan lamang ng pag-iipon ng mga token sa isang wallet. Ang impluwensya ay proporsyonal sa aktwal na computational contribution — ang mga GPU na nagpoproseso ng AI requests at bumubuo ng proof of work. Ito ang nag-uugnay sa pamamahala sa mga talagang sumusuporta sa arkitektura ng network, at hindi sa speculative capital.

Sa praktika, nangangahulugan ito: ang isang operator ng farm na may 10 H100 ay may 10 beses na mas maraming boto kaysa sa isang operator na may isang card — dahil pinoproseso niya ang 10 beses na mas maraming inference-requests. Ang sistema ay self-balancing: ang mga mas malaking nag-aambag sa operasyon ng network ay mas malaki ang impluwensya sa pag-unlad nito.

Ang pag-update ng Gonka protocol ay isang pormalisadong proseso mula sa code hanggang sa activation sa network. Bawat hakbang ay transparent at nabe-verify.

Proseso ng Pag-update:

1. Pull Request sa GitHub — ang mga developer (Gonka team o contributors) ay gumagawa ng PR sa gonka-ai/gonka repository.
2. Review ng Komunidad — sinusuri, pinag-uusapan, at sinusubukan ang code. Audit ng CertiK para sa mga kritikal na pagbabago.
3. Release — binubuo ang bagong bersyon ng gonkad binary.
4. On-chain proposal — gumagawa ng panukalang pag-update sa network na may paglalarawan ng mga pagbabago.
5. Deposit + Vote — nagdedeposito ang mga host (activation threshold) at bumoboto sa loob ng voting period.
6. Cosmovisor — kapag naaprubahan, awtomatikong nag-a-update ang Cosmovisor ng mga node sa tinukoy na block height.

Mula Enero hanggang Marso 2026, ang network ay dumaan sa 11+ matagumpay na pagboto — mula v0.2.2 hanggang v0.2.11. Lahat ng panukala ay naaprubahan. Ang huling malaking pagboto — proposal #31 (v0.2.11) — ay nakakuha ng 673,699 na boto na “pabor” at 0 na boto na “kontra”. Ang update na ito ay nagpakilala ng subnet inference — isang mekanismo ng off-chain computations sa pamamagitan ng subnets, na nangangako ng 100-fold na pagtaas sa throughput.

Mga Opsyon sa Boto:

• Yes — sinusuportahan ang pag-update.
• No — laban sa pag-update.
• No with Veto — lubos na laban; kung higit sa 33% ng mga boto — tinatanggihan ang panukala, at nasusunog ang deposito.
• Abstain — umiiwas, ngunit lumalahok sa quorum.

Ang buong kasaysayan ng pagboto ay available sa gonka.gg/network/proposals — maaaring tingnan ang bawat panukala, mga resulta, at listahan ng mga bumoto.

GiP — ito ay isang sistema para sa pagfo-formalize ng mga ideya para sa pagpapaunlad ng Gonka protocol, inilunsad noong Pebrero 24, 2026 sa pamamagitan ng GitHub Discussions (issue #795).

Format ng bawat GiP:

• Motivation — anong problema ang nilulutas ng panukala.
• Solution — teknikal na paglalarawan ng solusyon.
• Roadmap — plano ng pagpapatupad sa bawat yugto.
• Open Questions — mga hindi pa nalulutas na katanungan para sa talakayan ng komunidad.

Ang GiP ay hindi binding — hindi nila inoobliga ang koponan na ipatupad. Ngunit bumubuo sila ng consensus ng komunidad at nagtatakda ng direksyon para sa mga future on-chain proposals. Sa katunayan, ang GiP ay 'pre-governance': talakayan bago ang pagboto.

Mga Pangunahing GiP:

• #800 Multi-Model PoC — suporta para sa maraming AI-models nang sabay-sabay. Sa kasalukuyan, gumagana ang network sa Qwen3-235B; nilalarawan ng GiP na ito ang arkitektura para sa parallel na trabaho ng iba't ibang modelo na may magkahiwalay na Proof of Useful Work.
• #801 Inference Scaling — subnet architecture para sa scaling. Bahagi ng GiP na ito ay naipatupad na sa v0.2.11 (subnet inference).
• #860 Quality Protocol — routing ng mga request na isinasaalang-alang ang kalidad ng mga tugon. Ang mga node na nagbibigay ng mas mahusay na resulta ay nakakakuha ng mas maraming traffic at rewards.

Kahit sinong kalahok ay maaaring lumikha ng GiP sa pamamagitan ng GitHub Discussions. Ang entry barrier ay minimal — kailangan lamang ng GitHub account at pag-unawa sa problema. Ang aktibong talakayan sa paglahok ng Gonka team at mga host ay nagpapakita na gumagana ang sistema: ang mga panukala ay nakakatanggap ng feedback, pinipino, at nagpapatuloy sa pagpapatupad.

Community Pool — pondo para sa pagpapaunlad ng Gonka ecosystem. Humigit-kumulang 20% ng genesis-emission (~200 milyong GNK) ay inilaan para sa mga grants, bounties at pagpopondo sa mga inisyatiba ng komunidad.

Bounties para sa kontribusyon sa code — ang pangunahing mekanismo ng pamamahagi ng pondo ng Community Pool. Ang mga developer ay tumatanggap ng reward para sa PR sa repositoryong gonka-ai/gonka: mula sa pag-aayos ng mga bug hanggang sa pagpapatupad ng mga bagong feature. Ang laki ng bounty ay depende sa kumplikado at kahalagahan ng kontribusyon:

Mekanismo ng Pag-apruba: Ang mga bounty ay isinasama sa README ng upgrade proposals. Kapag bumoto ang mga host para sa pag-update ng protocol, sabay nilang inaaprubahan ang listahan ng mga bayad para sa mga PR na isinama sa release na iyon. Ang transparency ay kumpleto — kahit sino ay maaaring suriin kung para saan at magkano ang ibinayad.

Bukod sa mga bounty, maaaring pondohan ng Community Pool ang: pag-develop ng mga tool ng ecosystem, marketing, mga inisyatibong pang-edukasyon at mga grants para sa pananaliksik. Higit pa tungkol sa pagkakakitaan sa pamamagitan ng GitHub — sa isang hiwalay na artikulo.

Ang bata pang network ay vulnerable: kakaunti ang mga node, kakaunti ang stake, ang 51% attack ay teoretikal na posible. Nilulutas ito ng Gonka sa pamamagitan ng ilang mekanismo.

Guardian System — tatlong pinagkakatiwalaang node, kontrolado ng Gonka team, na may kabuuang 34% consensus power. Hindi maaaring magpataw ng desisyon ang Guardians (34% < 67% para sa pagtanggap), ngunit maaari nilang harangan ang isang mapanirang panukala (34% > 33% veto threshold). Ang susi: Awtomatikong nade-deactivate ang Guardians kapag ang kabuuang kapangyarihan ng network (total_network_power) ay umabot sa 10 milyong yunit. Ito ay hindi isang manual na switch — ang deactivation ay naka-program sa protocol.

Collateral System — kailangan ng mga host na magdeposito ng GNK bilang collateral upang makakuha ng buong weight:

• Base Weight (20%) — walang kondisyong weight, iginagawad sa mismong paggana ng node.
• Collateral-Eligible (80%) — karagdagang weight, magagamit lamang kung may collateral sa GNK. Ang halaga ng collateral ay proporsyonal sa computational power.

Slashing — parusa para sa mga paglabag:

• 20% ng collateral — para sa INVALID inference (nagbigay ang node ng maling resulta).
• 10% ng collateral — para sa downtime (hindi available ang node nang higit sa pinahihintulutang threshold).

Grace Period — 180 epochs (~6 na buwan), kung saan ang mga bagong host ay maaaring gumana nang walang collateral. Binabawasan nito ang hadlang sa pagpasok: maaaring magsimulang mag-mine, kumita ng GNK sa pamamagitan ng mga reward at pagkatapos ay magdeposito ng collateral. Matapos ang Grace Period, ang node na walang collateral ay nakakakuha lamang ng 20% ng potensyal na weight.

Ang lahat ng mekanismong ito ay inilarawan sa tokenomics ng GNK at nakatuon sa isang layunin: upang protektahan ang network sa maagang yugto, nang hindi sinasakripisyo ang desentralisasyon sa pangmatagalang panahon.

Ang Governance sa Gonka — hindi ito isang static na sistema, kundi isang prosesong nagbabago. Narito ang mga pangunahing direksyon ng pag-unlad para sa 2026–2027.

Multi-Model PoC (GiP #800) — suporta para sa maraming modelo nang sabay-sabay. Ang unang kandidato — embedding-models para sa RAG. Magbubukas ito ng Gonka sa isang ganap na bagong klase ng mga aplikasyon: search engines, corporate knowledge bases, chat-bots na may memory.

Inference Quality Protocol (GiP #860) — routing ayon sa kalidad. Sa kasalukuyan, ang mga request ay ipinapamahagi batay sa availability ng mga node; sa hinaharap — batay sa kalidad ng mga tugon. Ang mga node na may mas mahusay na hardware at mas matatag na operasyon ay makakakuha ng priyoridad.

On-chain governance migration (2026–2027) — paglipat sa isang full-fledged x/gov module mula sa Cosmos SDK. Magbibigay ito ng: pormalisadong proposal types, awtomatikong pagpapatupad ng mga naaprubahang pagbabago, integrasyon sa IBC (Inter-Blockchain Communication) at kakayahan na lumikha ng governance proposals sa pamamagitan ng anumang Cosmos-compatible wallet.

Maaaring subaybayan at lumahok sa mga pagboto sa gonka.gg/network/proposals.