الحوكمة في Gonka: كيف تدار شبكة لامركزية

تعمل الحوكمة في Gonka على مستويين، لكل منهما وتيرته ونطاق قراراته الخاصة.

Operational Voting (دقائق) — قرارات تشغيلية داخل الشبكة. عندما ينشأ خلاف حول صلاحية طلب inference أو نتيجة PoC، يصوّت المضيفون عبر وحدة x/group في Cosmos SDK. يُحدَّد وزن الصوت بواسطة PoC weight — فكلما زادت الحوسبة التي تنفذها العقدة، زاد تأثيرها. تستمر هذه التصويتات دقائق معدودة وتحسم نزاعات محددة: هل كان الـ inference صحيحًا، وهل أدّت العقدة عملها.

Governance Voting (أيام) — قرارات استراتيجية بشأن تطوير البروتوكول. تحديثات البرمجيات، وتغيير معاملات الشبكة، وتفعيل نماذج جديدة، وتوزيع أموال Community Pool — كل ذلك يُطرح للتصويت من قِبل جميع المضيفين. تمتد فترة التصويت من بضعة أيام إلى أسبوع حتى يتمكن كل المشاركين من الاطلاع على المقترح.

الفرق الجوهري عن معظم مشاريع الكريبتو: وزن الصوت يُحدَّد بواسطة Proof of Compute، لا بواسطة الـ staking. في Gonka لا يمكنك \"شراء صوت\" بمجرد تكديس العملات في المحفظة. التأثير يتناسب مع المساهمة الحاسوبية الفعلية — وحدات GPU التي تعالج طلبات الذكاء الاصطناعي وتولّد إثباتات العمل. ومنذ التحديث v0.2.16، تُحتسب فقط القدرة الموثّقة في الحقبة السابقة: المضيف الجديد يصوّت بوزن صفري خلال الحقبة الأولى، وتُضاف أصوات القدرة الإضافية بدءًا من الحقبة التالية. وهذا يربط الحوكمة بمن يدعمون فعليًا بنية الشبكة، لا برأس المال المضارب.

عمليًا، يعني هذا أن مشغّلًا يمتلك خادمين بقدرة 8× H100 لكل منهما يمتلك نحو ضعف أصوات مشغّل يمتلك خادمًا واحدًا من هذا النوع — لأنه يعالج نحو ضعف طلبات الـ inference. النظام يوازن نفسه بنفسه: من يستثمر أكثر في عمل الشبكة يكون تأثيره أكبر في تطورها.

ترقية بروتوكول Gonka هي عملية مُقنّنة تمتد من الكود حتى التنشيط على الشبكة. كل خطوة شفافة وقابلة للتحقق.

عملية الترقية:

1. Pull Request على GitHub — يُنشئ المطوّرون (فريق Gonka أو المساهمون) طلب PR في مستودع gonka-ai/gonka.
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 للتوسع. تم تنفيذ جزء من هذا GiP بالفعل في v0.2.11 (subnet inference).
• #860 Quality Protocol — توجيه الطلبات بناءً على جودة الردود. العقد (nodes) التي تقدم نتائج أفضل تحصل على مزيد من حركة المرور والمكافآت.

يمكن لأي مشارك إنشاء GiP عبر GitHub Discussions. عتبة الدخول منخفضة — تحتاج فقط إلى حساب GitHub وفهم للمشكلة. تظهر المناقشات النشطة بمشاركة فريق Gonka والمضيفين أن النظام يعمل: تتلقى المقترحات تعليقات، ويتم تحسينها والمضي قدماً نحو التنفيذ.

مجمع المجتمع - صندوق تطوير نظام Gonka البيئي. ما يقرب من 20% من الإصدار الأولي (~200 مليون GNK) مخصصة للمنح والمكافآت وتمويل مبادرات المجتمع.

المكافآت للمساهمات في الكود - الآلية الرئيسية لتوزيع أموال مجمع المجتمع. يحصل المطورون على مكافآت مقابل طلبات السحب في مستودع gonka-ai/gonka: من إصلاح الأخطاء إلى تنفيذ الميزات الجديدة. يعتمد حجم المكافأة على تعقيد وأهمية المساهمة:

آلية الموافقة: تُدرج المكافآت في ملف README مع مقترحات الترقية. عندما يصوت المضيفون على تحديث البروتوكول، فإنهم يوافقون في نفس الوقت على قائمة المدفوعات لطلبات السحب التي تم تضمينها في هذا الإصدار. الشفافية كاملة - يمكن لأي شخص التحقق من المبلغ الذي تم دفعه ولماذا.

بالإضافة إلى المكافآت، يمكن لمجمع المجتمع تمويل: تطوير أدوات النظام البيئي، والتسويق، والمبادرات التعليمية، ومنح البحث. مزيد من التفاصيل حول الربح عبر GitHub - في مقالة منفصلة.

الشبكة الجديدة ضعيفة: عدد قليل من العقد، ورهن قليل، وهجوم 51% ممكن نظريًا. تحل Gonka هذا الأمر بعدة آليات.

نظام الحارس - ثلاث عقد موثوقة، يسيطر عليها فريق Gonka، بإجمالي 34% من قوة الإجماع. لا يمكن للحراس فرض قرارات (34% < 67% للموافقة)، ولكن يمكنهم حظر اقتراح ضار (34% > 33% عتبة النقض). الأهم: يتم إلغاء تفعيل الحراس تلقائيًا عندما تصل إجمالي قوة الشبكة (total_network_power) إلى 10 ملايين وحدة. هذا ليس مفتاحًا يدويًا - إلغاء التفعيل مبرمج في البروتوكول.

نظام الضمان - يجب على المضيفين إيداع ضمان في GNK للحصول على الوزن الكامل:

• الوزن الأساسي (20%) - وزن غير مشروط، يتم احتسابه بمجرد عمل العقدة.
• الوزن المؤهل للضمان (80%) - وزن إضافي، متاح فقط بوجود ضمان في GNK. يتناسب حجم الضمان مع قوة الحوسبة.

العقوبات - عقوبات على الانتهاكات:

• 20% من الضمان - للاستدلال غير الصالح (أصدرت العقدة نتيجة غير صحيحة).
• 10% من الضمان - لوقت التوقف (العقدة غير متاحة فوق العتبة المسموح بها).

فترة السماح - 180 حقبة (~6 أشهر)، يمكن خلالها للمضيفين الجدد العمل بدون ضمان. هذا يقلل من حاجز الدخول: يمكن البدء في التعدين، وكسب GNK من خلال المكافآت، ثم إيداع الضمان فقط. بعد انتهاء فترة السماح، تحصل العقدة بدون ضمان على 20% فقط من الوزن المحتمل.

تُصف كل هذه الآليات في اقتصاديات GNK وتهدف إلى هدف واحد: حماية الشبكة في المرحلة المبكرة، دون التضحية باللامركزية على المدى الطويل.

الحوكمة (Governance) في Gonka ليست نظاماً ثابتاً، بل عملية متطورة. فيما يلي الاتجاهات الرئيسية للتطوير لعامي 2026–2027.

Multi-Model PoC (GiP #800) — تم تنفيذه: كانت Kimi K2.6 أول نموذج ينضم عبر DevShards في مايو 2026 (تم سحبه لاحقاً من الشبكة)، تمت إضافة MiniMax-M2.7 في v0.2.13 (proposal #54)، وتم توصيل DeepSeek V4 Flash في أغسطس 2026 (proposal #94)، وGLM-5.3 Flash في سبتمبر 2026 (proposal #101). المرشحون التاليون هم نماذج التضمين (embedding models) لـ RAG: سيفتح هذا Gonka أمام فئة جديدة من التطبيقات (محركات البحث، قواعد المعرفة المؤسسية، روبوتات المحادثة ذات الذاكرة).

Inference Quality Protocol (GiP #860) — التوجيه بناءً على الجودة. يتم توزيع الطلبات حالياً بناءً على توفر العقد؛ في المستقبل — سيتم توزيعها بناءً على جودة الردود. ستعطى الأولوية للعقد ذات الأجهزة الأفضل والأداء الأكثر استقراراً.

On-chain governance migration (2026–2027) — الانتقال إلى وحدة x/gov الكاملة من Cosmos SDK. سيؤدي هذا إلى: أنواع مقترحات رسمية، تنفيذ تلقائي للتغييرات المعتمدة، التكامل مع IBC (Inter-Blockchain Communication) والقدرة على إنشاء مقترحات حوكمة عبر أي محفظة متوافقة مع Cosmos.

يمكنك متابعة التصويت والمشاركة عبر الرابط gonka.gg/network/proposals.