गोंका में शासन: एक विकेन्द्रीकृत नेटवर्क का प्रबंधन कैसे किया जाता है

Gonka में प्रबंधन दो स्तरों पर चलता है, हर स्तर की गति और फ़ैसलों का दायरा अलग है।

Operational Voting (मिनट) — नेटवर्क के भीतर के परिचालन संबंधी फ़ैसले। जब किसी inference अनुरोध या PoC परिणाम की वैधता को लेकर विवाद उठता है, तो होस्ट Cosmos SDK के x/group मॉड्यूल के ज़रिए वोट डालते हैं। वोट का वज़न PoC weight से तय होता है — नोड जितनी ज़्यादा गणना करता है, उसका प्रभाव उतना ज़्यादा। ऐसे वोटिंग मिनटों में पूरी होती हैं और ठोस विवाद सुलझाती हैं: inference सही था या नहीं, नोड ने अपना काम किया या नहीं।

Governance Voting (दिन) — प्रोटोकॉल के विकास से जुड़े रणनीतिक फ़ैसले। सॉफ़्टवेयर अपडेट, नेटवर्क पैरामीटर में बदलाव, नए मॉडल की सक्रियता, Community Pool के फ़ंड का बँटवारा — यह सब सभी होस्ट के वोट पर रखा जाता है। वोटिंग की अवधि कुछ दिनों से लेकर एक हफ़्ते तक होती है, ताकि सभी प्रतिभागी प्रस्ताव को ठीक से पढ़-समझ सकें।

ज़्यादातर क्रिप्टो प्रोजेक्ट्स से बुनियादी फ़र्क़ यह है: वोट का वज़न Proof of Compute से तय होता है, स्टेकिंग से नहीं। Gonka में सिर्फ़ वॉलेट में टोकन जमा करके "वोट नहीं ख़रीदा जा सकता"। प्रभाव असली कंप्यूट योगदान के अनुपात में होता है — उन GPU का, जो AI अनुरोध प्रोसेस करते हैं और काम के सबूत पैदा करते हैं। v0.2.16 अपडेट से पिछली epoch में सत्यापित शक्ति ही गिनी जाती है: नया होस्ट अपनी पहली epoch में शून्य वज़न के साथ वोट करता है, और शक्ति बढ़ने पर अगली epoch से वोट जुड़ते हैं। इससे प्रबंधन उन लोगों से जुड़ जाता है जो वाक़ई नेटवर्क आर्किटेक्चर को सहारा देते हैं, न कि सट्टेबाज़ी वाली पूँजी से।

व्यवहार में इसका मतलब है: 8× H100 वाले दो सर्वर रखने वाले ऑपरेटर के पास एक ऐसे ही सर्वर वाले ऑपरेटर से लगभग दोगुने वोट होते हैं — क्योंकि वह लगभग दोगुने inference अनुरोध प्रोसेस करता है। यह सिस्टम ख़ुद को संतुलित करता है: जो नेटवर्क के काम में ज़्यादा लगाते हैं, उनका विकास पर ज़्यादा प्रभाव होता है।

Gonka प्रोटोकॉल अपग्रेड एक औपचारिक प्रक्रिया है — कोड से लेकर नेटवर्क पर एक्टिवेशन तक। हर कदम पारदर्शी और सत्यापन योग्य है।

अपग्रेड प्रक्रिया:

1. GitHub पर Pull Request — डेवलपर्स (Gonka टीम या कॉन्ट्रिब्यूटर्स) gonka-ai/gonka रिपॉज़िटरी में PR बनाते हैं।
2. कम्युनिटी रिव्यू — कोड की जाँच, चर्चा और टेस्टिंग होती है। महत्वपूर्ण बदलावों के लिए CertiK ऑडिट।
3. Release — inferenced बाइनरी का नया वर्शन बनाया जाता है।
4. On-chain proposal — नेटवर्क पर बदलावों के विवरण के साथ अपग्रेड प्रस्ताव बनाया जाता है।
5. Deposit + Vote — होस्ट डिपॉज़िट जमा करते हैं (एक्टिवेशन थ्रेशोल्ड) और voting period के दौरान वोट करते हैं।
6. Cosmovisor — मंज़ूरी मिलने पर Cosmovisor तय ब्लॉक हाइट पर नोड्स को अपने आप अपडेट कर देता है।

जनवरी से मई 2026 तक नेटवर्क ने 13+ सफल वोटिंग पूरी कीं — v0.2.2 से v0.2.13 तक। सभी प्रस्ताव पास हुए। प्रमुख अपग्रेड्स का क्रम:

• v0.2.11 (मार्च 2026, proposal #31) — 673,699 वोट "पक्ष" में, 0 "विपक्ष"। subnet inference पेश हुआ — सबनेट के ज़रिए off-chain कंप्यूटेशन का मैकेनिज़्म, जो 100 गुना थ्रूपुट बढ़ोतरी का वादा करता है।
• v0.2.13 (मई 2026, proposal #54) — 21 मई 2026 को पास (62.8% "पक्ष", 39.9% मतदान, 33.4% क्वोरम के साथ), ब्लॉक 4267300 पर एक्टिवेट हुआ। नेटवर्क में तीसरे मॉडल के रूप में MiniMax-M2.7 जोड़ा, Ethereum bridge wiring एक्टिवेट की और क्वोरम घटाकर 0.25 किया।

वोट के विकल्प:

• Yes — अपग्रेड का समर्थन करता/करती हूँ।
• No — अपग्रेड के ख़िलाफ़।
• No with Veto — पूरी तरह ख़िलाफ़; अगर 33% से ज़्यादा वोट — प्रस्ताव ख़ारिज, और डिपॉज़िट जल जाता है।
• Abstain — तटस्थ, पर क्वोरम में शामिल।

पूरा वोटिंग इतिहास gonka.gg/network/proposals पर उपलब्ध है — हर प्रस्ताव, नतीजे और वोट करने वालों की सूची देख सकते हैं।

GiP — Gonka प्रोटोकॉल के विकास के लिए विचारों को औपचारिक रूप देने की एक प्रणाली है, जिसे 24 फरवरी 2026 को GitHub Discussions (issue #795) के माध्यम से शुरू किया गया था।

प्रत्येक GiP का प्रारूप:

• Motivation — प्रस्ताव किस समस्या का समाधान करता है।
• Solution — समाधान का तकनीकी विवरण।
• Roadmap — चरणों के अनुसार कार्यान्वयन योजना।
• Open Questions — समुदाय द्वारा चर्चा के लिए अनसुलझे प्रश्न।

GiP बाइंडिंग नहीं होते हैं — वे टीम को कार्यान्वयन के लिए बाध्य नहीं करते हैं। लेकिन वे समुदाय की सहमति बनाते हैं और भविष्य के on-chain proposals के लिए दिशा निर्धारित करते हैं। वास्तव में, GiP एक «pre-governance» है: मतदान से पहले की चर्चा।

प्रमुख GiP:

• #800 Multi-Model PoC — एक साथ कई AI-मॉडल का समर्थन। वर्तमान में, नेटवर्क MiniMax M2.7 (v0.2.13 में जोड़ा गया), DeepSeek V4 Flash (proposal #94) और GLM-5.3 Flash (proposal #101) के साथ काम करता है। GiP अलग Proof of Useful Work के साथ विभिन्न मॉडलों के समानांतर संचालन के लिए आर्किटेक्चर का वर्णन करता है।
• #801 Inference Scaling — स्केलिंग के लिए subnet architecture। इस GiP का एक हिस्सा v0.2.11 (subnet inference) में पहले ही लागू किया जा चुका है।
• #860 Quality Protocol — प्रतिक्रिया गुणवत्ता को ध्यान में रखते हुए अनुरोध रूटिंग। बेहतर परिणाम देने वाले नोड्स को अधिक ट्रैफ़िक और रिवॉर्ड मिलते हैं।

कोई भी प्रतिभागी GitHub Discussions के माध्यम से GiP बना सकता है। प्रवेश की सीमा न्यूनतम है — केवल एक GitHub-अकाउंट और समस्या की समझ आवश्यक है। Gonka टीम और होस्ट्स की भागीदारी वाली सक्रिय चर्चाएं दिखाती हैं कि सिस्टम काम कर रहा है: प्रस्तावों पर फीडबैक मिलता है, उन्हें सुधारा जाता है और वे कार्यान्वयन की ओर बढ़ते हैं।

सामुदायिक पूल — गोंका पारिस्थितिकी तंत्र के विकास के लिए एक निधि। उत्पत्ति उत्सर्जन का लगभग 20% (~200 मिलियन GNK) अनुदान, बाउंटियों और सामुदायिक पहलों के वित्तपोषण के लिए आवंटित किया गया है।

कोड में योगदान के लिए बाउंटियां — सामुदायिक पूल से धन वितरित करने का मुख्य तंत्र। डेवलपर्स को gonka-ai/gonka रिपॉजिटरी में PRs के लिए इनाम मिलते हैं: बग फिक्स से लेकर नई सुविधाओं के कार्यान्वयन तक। बाउंटियों का आकार योगदान की जटिलता और महत्व पर निर्भर करता है:

अनुमोदन तंत्र: बाउंटियां अपग्रेड प्रस्तावों के README में शामिल हैं। जब होस्ट प्रोटोकॉल अपडेट के लिए वोट करते हैं, तो वे एक साथ उस रिलीज में शामिल पीआर के लिए भुगतानों की सूची को मंजूरी देते हैं। पारदर्शिता पूर्ण है — कोई भी यह जांच सकता है कि किसके लिए और कितना भुगतान किया गया था।

बाउंटियों के अलावा, सामुदायिक पूल वित्तपोषित कर सकता है: पारिस्थितिकी तंत्र उपकरणों का विकास, विपणन, शैक्षिक पहल और अनुसंधान अनुदान। GitHub के माध्यम से कमाई के बारे में अधिक जानकारी एक अलग लेख में है।

एक युवा नेटवर्क असुरक्षित होता है: कुछ नोड्स, कम स्टेक, 51% हमला सैद्धांतिक रूप से संभव है। गोंका इसे कई तंत्रों से हल करता है।

गार्डियन सिस्टम — गोंका टीम द्वारा नियंत्रित तीन विश्वसनीय नोड्स, कुल 34% आम सहमति शक्ति के साथ। गार्डियन निर्णय थोप नहीं सकते (स्वीकृति के लिए 34% < 67%), लेकिन एक दुर्भावनापूर्ण प्रस्ताव को ब्लॉक कर सकते हैं (34% > 33% वीटो थ्रेशोल्ड)। मुख्य बात: जब कुल नेटवर्क शक्ति (total_network_power) 10 मिलियन इकाइयों तक पहुंचती है, तो गार्डियन स्वचालित रूप से निष्क्रिय हो जाते हैं। यह एक मैनुअल स्विच नहीं है - निष्क्रियकरण प्रोटोकॉल में प्रोग्राम किया गया है।

संपार्श्विक प्रणाली — होस्टों को पूर्ण भार प्राप्त करने के लिए GNK में एक संपार्श्विक जमा करना होगा:

• आधार भार (20%) — बिना शर्त भार, नोड के संचालन के तथ्य के लिए लगाया जाता है।
• संपार्श्विक-योग्य (80%) — अतिरिक्त भार, केवल GNK में संपार्श्विक होने पर उपलब्ध। संपार्श्विक का आकार कंप्यूटेशनल शक्ति के अनुपात में है।

स्लैशिंग — उल्लंघनों के लिए दंड:

• 20% संपार्श्विक — INVALID अनुमान के लिए (नोड ने गलत परिणाम दिया)।
• 10% संपार्श्विक — डाउनटाइम के लिए (नोड अनुमेय सीमा से अधिक अनुपलब्ध है)।

ग्रेस पीरियड — 180 युग (~6 महीने), जिसके दौरान नए होस्ट बिना संपार्श्विक के काम कर सकते हैं। यह प्रवेश बाधा को कम करता है: आप माइनिंग शुरू कर सकते हैं, पुरस्कारों के माध्यम से GNK कमा सकते हैं और उसके बाद ही संपार्श्विक जमा कर सकते हैं। ग्रेस पीरियड समाप्त होने के बाद, बिना संपार्श्विक वाला नोड संभावित भार का केवल 20% प्राप्त करता है।

ये सभी तंत्र GNK टोकनोमिक्स में वर्णित हैं और एक ही लक्ष्य पर केंद्रित हैं: दीर्घकालिक में विकेंद्रीकरण का त्याग किए बिना प्रारंभिक चरण में नेटवर्क की रक्षा करना।

Gonka में Governance एक स्थिर प्रणाली नहीं, बल्कि एक विकसित होने वाली प्रक्रिया है। 2026–2027 के लिए विकास की मुख्य दिशाएं यहाँ दी गई हैं।

Multi-Model PoC (GiP #800) — कार्यान्वित: मई 2026 में DevShards के माध्यम से पहली बार Kimi K2.6 आई (बाद में नेटवर्क से हटा दी गई), MiniMax-M2.7 को v0.2.13 (proposal #54) में जोड़ा गया, DeepSeek V4 Flash अगस्त 2026 (proposal #94) में कनेक्ट हुआ, GLM-5.3 Flash — सितंबर 2026 (proposal #101) में। अगले उम्मीदवार RAG के लिए एम्बेडिंग-मॉडल हैं: यह Gonka को एप्लिकेशन के एक नए वर्ग (सर्च इंजन, कॉर्पोरेट ज्ञान आधार, मेमोरी वाले चैट-बॉट्स) के लिए खोल देगा।

Inference Quality Protocol (GiP #860) — गुणवत्ता के आधार पर रूटिंग। अब अनुरोध नोड्स की उपलब्धता के अनुसार वितरित किए जाते हैं; भविष्य में — प्रतिक्रिया की गुणवत्ता के आधार पर। बेहतर हार्डवेयर और अधिक स्थिर संचालन वाले नोड्स को प्राथमिकता मिलेगी।

On-chain governance migration (2026–2027) — Cosmos SDK से पूर्ण मॉड्यूल x/gov पर माइग्रेशन। इससे मिलेगा: औपचारिक proposal types, स्वीकृत परिवर्तनों का स्वचालित निष्पादन, IBC (Inter-Blockchain Communication) के साथ एकीकरण और किसी भी Cosmos-संगत वॉलेट के माध्यम से governance proposals बनाने की क्षमता।

मतदान को ट्रैक करने और भाग लेने के लिए gonka.gg/network/proposals पर जाएं।