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 protocol ng Gonka ay isang pormalisadong proseso mula sa code hanggang sa activation sa network. Ang bawat hakbang ay transparent at nabe-verify.

Proseso ng Pag-update:

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

Mula Enero hanggang Mayo 2026, ang network ay dumaan sa 13+ matagumpay na botohan — mula bersyon v0.2.2 hanggang v0.2.13. Lahat ng mga proposal ay naaprubahan. Kronolohiya ng mga pangunahing pag-upgrade:

• v0.2.11 (Marso 2026, proposal #31) — 673,699 na boto “para” at 0 “laban.” Ipinakilala ang subnet inference — isang mekanismo ng off-chain computation sa pamamagitan ng mga subnetwork, na nangangako ng 100-fold na paglago sa throughput.
• v0.2.13 (Mayo 2026, proposal #54) — tinanggap noong Mayo 21, 2026 (62.8% “para,” 39.9% turnout sa quorum na 33.4%), na-activate sa block 4267300. Nagdagdag ng MiniMax-M2.7 bilang ikatlong modelo sa network, na-activate ang Ethereum bridge wiring at binawasan ang quorum sa 0.25.

Mga Opsyon sa Boto:

• Yes — sinusuportahan ko ang pag-update.
• No — laban sa pag-update.
• No with Veto — lubos na laban; kung mahigit 33% ng boto — ang proposal ay tinatanggihan, at ang deposit ay nawala.
• Abstain — umiiwas, ngunit kasama sa quorum.

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

GiP — isa itong sistema ng pormalisasyon ng mga ideya para sa pagpapaunlad ng protocol ng Gonka, na 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 para sa implementasyon sa iba't ibang yugto.
• Open Questions — mga hindi pa nalulutas na tanong para sa talakayan ng komunidad.

Ang GiP ay hindi binding — hindi nito pinipilit ang team na ipatupad ang mga ito. Ngunit bumubuo ito ng consensus sa komunidad at nagtatakda ng direksyon para sa mga darating na on-chain proposals. Sa katunayan, ang GiP ay isang «pre-governance»: diskusyon bago ang pagboto.

Mga pangunahing GiP:

• #800 Multi-Model PoC — suporta para sa maraming AI models nang sabay-sabay. Sa kasalukuyan, ang network ay gumagana sa Kimi K2.6 at MiniMax M2.7. Ang MiniMax-M2.7 ay idinaragdag sa v0.2.13. Nilalarawan ng GiP ang arkitektura para sa parallel operation ng iba't ibang models na may magkakahiwalay 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 batay sa kalidad ng mga response. Ang mga node na nagbibigay ng pinakamahusay na resulta ay nakakatanggap ng mas maraming trapiko at gantimpala.

Sinumang participant ay maaaring gumawa ng GiP sa pamamagitan ng GitHub Discussions. Ang threshold para makilahok ay minimum — kailangan lang ng GitHub account at pag-unawa sa problema. Ang mga aktibong diskusyon kasama ang Gonka team at mga host ay nagpapakita na ang sistema ay gumagana: ang mga panukala ay tumatanggap ng feedback, pinapabuti, at isinasagawa.

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 — ay hindi isang static na sistema, kundi isang proseso ng pagbabago. Narito ang mga pangunahing direksyon ng pag-unlad para sa 2026–2027.

Multi-Model PoC (GiP #800) — naiimplementa na: Ang Kimi K2.6 ay gumagana na sa DevShards simula Mayo 2026, ang MiniMax-M2.7 ay idinadagdag sa v0.2.13 (proposal #54). Ang susunod na mga kandidato ay ang embedding-models para sa RAG: ito ay magbubukas ng Gonka sa bagong klase ng mga aplikasyon (mga search engine, corporate knowledge bases, chatbots na may memorya).

Inference Quality Protocol (GiP #860) — pagruruta sa pamamagitan ng kalidad. Sa ngayon, ang mga kahilingan ay ipinamamahagi ayon sa availability ng mga node; sa hinaharap — ayon sa kalidad ng mga sagot. Ang mga node na may mas mahusay na hardware at mas matatag na operasyon ay makakakuha ng prioridad.

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

Maaari mong subaybayan ang mga botohan at lumahok sa gonka.gg/network/proposals.