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

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

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

التصويت على الحوكمة (أيام) - القرارات الاستراتيجية بشأن تطوير البروتوكول. تحديثات البرامج، وتغيير معلمات الشبكة، وتفعيل نماذج جديدة، وتوزيع أموال مجمع المجتمع - كل هذا يتم طرحه للتصويت على جميع المضيفين. تتراوح فترة التصويت من عدة أيام إلى أسبوع حتى يتمكن جميع المشاركين من الاطلاع على الاقتراح.

الاختلاف الرئيسي عن معظم مشاريع التشفير: يتم تحديد وزن الصوت بواسطة Proof of Compute، وليس بالرهن. في Gonka، لا يمكنك «شراء صوت» بمجرد تجميع الرموز المميزة في المحفظة. يتناسب التأثير مع المساهمة الحسابية الحقيقية - وحدات معالجة الرسومات التي تعالج طلبات الذكاء الاصطناعي وتولد إثبات العمل. هذا يربط الحوكمة بأولئك الذين يدعمون حقًا هندسة الشبكة، وليس برأس المال المضارب.

في الممارسة العملية، هذا يعني أن: مشغل مزرعة من 10 H100 لديه 10 أضعاف الأصوات مقارنة بالمشغل ببطاقة واحدة - لأنه يعالج 10 أضعاف طلبات الاستدلال. النظام متوازن ذاتيًا: أولئك الذين يستثمرون أكثر في عمل الشبكة، يؤثرون بشكل أكبر على تطويرها.

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

عملية التحديث:

1. طلب سحب في GitHub — يقوم المطورون (فريق Gonka أو المساهمون) بإنشاء طلب سحب في مستودع gonka-ai/gonka.
2. مراجعة المجتمع — يتم فحص الكود ومناقشته واختباره. تدقيق CertiK للتغييرات الحيوية.
3. إصدار — يتم تجميع إصدار ثنائي جديد من gonkad.
4. اقتراح On-chain — يتم إنشاء اقتراح تحديث في الشبكة مع وصف التغييرات.
5. إيداع + تصويت — يقوم المضيفون بإيداع (عتبة التفعيل) والتصويت خلال فترة التصويت.
6. Cosmovisor — عند الموافقة، يقوم Cosmovisor تلقائيًا بتحديث العقد عند ارتفاع الكتلة المحدد.

من يناير إلى مايو 2026، مرت الشبكة بأكثر من 13 تصويتًا ناجحًا — من الإصدار v0.2.2 إلى v0.2.13. تمت الموافقة على جميع الاقتراحات. تسلسل التحديثات الرئيسية:

• v0.2.11 (مارس 2026، اقتراح #31) — 673,699 صوتًا «مع» مقابل 0 «ضد». تم إدخال استدلال الشبكة الفرعية — آلية الحسابات خارج السلسلة عبر الشبكات الفرعية، والتي تعد بزيادة 100 ضعف في سعة المعالجة.
• v0.2.13 (مايو 2026، اقتراح #54) — تم قبوله في 21 مايو 2026 (62,8% «مع»، نسبة المشاركة 39,9% عند النصاب 33,4%)، وتم تفعيله في الكتلة 4267300. أضاف MiniMax-M2.7 كنموذج ثالث في الشبكة، وفعل ربط جسر Ethereum وخفض النصاب إلى 0.25.

خيارات التصويت:

• نعم — أدعم التحديث.
• لا — ضد التحديث.
• لا مع حق النقض — أعارض بشدة؛ إذا كانت نسبة الأصوات تزيد عن 33% — يتم رفض الاقتراح ويتم حرق الإيداع.
• امتناع — أمتنع، لكنني أشارك في النصاب.

يتوفر سجل التصويت بالكامل على gonka.gg/network/proposals — يمكنك عرض كل اقتراح ونتائجه وقائمة المصوتين.

GiP هو نظام لتوثيق الأفكار لتطوير بروتوكول Gonka، تم إطلاقه في 24 فبراير 2026 عبر GitHub Discussions (العدد #795).

تنسيق كل GiP:

• Motivation — المشكلة التي يحلها الاقتراح.
• Solution — وصف تقني للحل.
• Roadmap — خطة التنفيذ خطوة بخطوة.
• Open Questions — أسئلة مفتوحة لمناقشة المجتمع.

GiP ليست ملزمة — فهي لا تلزم الفريق بالتنفيذ. لكنها تشكل إجماع المجتمع وتضع اتجاهًا للمقترحات المستقبلية على السلسلة. في الواقع، GiP هي "حوكمة مسبقة": مناقشة قبل التصويت.

GiP الرئيسية:

• #800 Multi-Model PoC — دعم نماذج AI متعددة في وقت واحد. تعمل الشبكة حاليًا مع Qwen3-235B و Kimi K2.6 (عبر DevShards اعتبارًا من مايو 2026). يتم إضافة MiniMax-M2.7 في v0.2.13. يصف GiP بنية للعمل المتوازي للنماذج المختلفة مع Proof of Useful Work منفصل.
• #801 Inference Scaling — بنية الشبكة الفرعية للتوسع. تم بالفعل تنفيذ جزء من GiP هذا في v0.2.11 (الاستدلال بالشبكة الفرعية).
• #860 Quality Protocol — توجيه الطلبات مع مراعاة جودة الاستجابات. تحصل العقد التي تقدم أفضل النتائج على المزيد من حركة المرور والمكافآت.

يمكن لأي مشارك إنشاء 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 وتهدف إلى هدف واحد: حماية الشبكة في المرحلة المبكرة، دون التضحية باللامركزية على المدى الطويل.

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

Multi-Model PoC (GiP #800) — تم التنفيذ: يعمل Kimi K2.6 بالفعل في DevShards منذ مايو 2026، وسيتم إضافة MiniMax-M2.7 في v0.2.13 (الاقتراح #54). المرشحون التاليون هم نماذج التضمين لـ 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.