Polkadot الحوكمة V2: evolution of اللامركزية اتخاذ القرار

الحوكمة V2

تستخدم بولكادوت آلية حوكمة دقيقة، قادرة على التطور بشكل أنيق وفقًا لاحتياجات أصحاب المصلحة. هدفها هو ضمان أن يتمكن غالبية المساهمين دائمًا من السيطرة على الشبكة.

قد تتغير محتويات هذه المقالة. لقد مرت اتفاقية الحكم بعدة iterations (v1 وv2)، وستكون هناك المزيد من التغييرات في المستقبل (v2.5).

يتكون أول نظام حوكمة لامركزي لـ Polkadot (v1) من ثلاثة مكونات رئيسية:

  • اللجنة الفنية: إدارة جدول ترقية الوقت
  • المجلس: حكومة تنفيذية منتخبة، مسؤولة عن إدارة المعايير، وإدارة مقترحات الإنفاق
  • الاستفتاء: تصويت عام على جميع الأمور الأخرى، حيث يمتلك المساهمون على المدى الطويل تأثيرًا أكبر.

كان هذا النظام يعمل بشكل جيد في بداية تشغيله، مما يساعد على الاستخدام الرشيد لأموال الخزانة والترقيات والإصلاحات في الوقت المناسب. ولكن مع نضوج النظام، يحتاج إلى تحسين مستمر للعيوب ومتابعة التقدم. على سبيل المثال، في "الحوكمة v1"، كانت جميع أوزان الاستفتاءات متساوية، ويمكن التصويت على استفتاء واحد فقط في كل مرة، ويمكن أن تستمر فترة التصويت لعدة أسابيع. أدى ذلك إلى ميل النظام إلى التفكير بعناية في عدد قليل جداً من المقترحات، بدلاً من التفكير بشكل واسع في العديد من المقترحات. لذلك، نشأت "الحوكمة v2".

"الحوكمة v2" أو ما يعرف ب"Gov2" قد غيرت طريقة اتخاذ القرارات اليومية، مما جعل الاستفتاءات تؤثر بشكل أوسع وأكثر مرونة، وزادت بشكل كبير من عدد القرارات الجماعية التي يمكن للنظام اتخاذها.

بعد المراجعة النهائية الاحترافية للشيفرة، ستقوم Gov2 بإطلاقها على Kusama. بعد الاختبار على Kusama، سيتم تقديم اقتراح لنشرها على Polkadot.

سوف يتم تقديم المبادئ الأساسية للحوكمة في شبكة Polkadot أولاً. فهم جذور الحوكمة v1 سيساعد على فهم اتجاه التكرار الثاني بشكل أفضل. ستتم تسليط الضوء على هذه الاختلافات والتمييزات في مواضيع فرعية مختلفة.

من المهم ملاحظة أنه في المرحلة الحالية، لا يزال الحكم بروتوكولًا يتطور باستمرار. مع دخول تحديث الحكم v2 إلى الشبكة، يتم أيضًا وضع خطط للحكم v2.5.

مقدمة

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

يجب أن يتم التوصل إلى توافق بشأن جميع التغييرات على الاتفاقية من خلال تصويت مدعوم بالحقوق.

آلية

في الإدارة v1، يدير حاملو التوكن النشطون والمجلس قرارات ترقية الشبكة بشكل مشترك. سواء كانت الاقتراحات مقدمة من حاملي التوكن ( العامة أو المجلس، يجب أن تمر جميعها عبر استفتاء جميع الحائزين، مع اتخاذ القرار بناءً على وزن مقدار الرهن وقيمة الإيمان.

هناك عدة تغييرات في إدارة v2. الطريقة التي تعكس نموذج الإدارة الجديد خصائص اللامركزية هي:

  • نقل جميع مسؤوليات المجلس إلى حاملي الرموز من خلال التصويت الديمقراطي
  • حل المجلس الحالي جماعياً
  • يسمح للمستخدمين بتفويض حقوق التصويت لأعضاء المجتمع بطرق أكثر

تقوم الهيئة في Gov1 بدور ممثل لحاملي الرموز السلبية، وحارس الخزانة، ومبادر التشريع، لكنها تُعتبر عادةً كيانًا مركزيًا. من أجل مزيد من اللامركزية في الشبكة، يقترح Gov2 إعادة مسؤوليات الهيئة إلى المجتمع.

) استفتاء

الاستفتاء هو خطة تصويت بسيطة وشاملة تستند إلى الحصة. يحتوي كل استفتاء على اقتراح محدد، يتم استخدامه من خلال استدعاء وظيفة امتياز وقت التشغيل ###، بما في ذلك أقوى استدعاء set_code، والذي يمكنه تبديل كود وقت التشغيل بالكامل (.

الاستفتاء هو حدث منفصل له فترة تصويت محددة. بعد انتهاء فترة التصويت وإحصاء بطاقات الاقتراع، إذا تم الموافقة عليها، سيتم استدعاء الدالة المعنية. الاستفتاء دائمًا ثنائي؛ يمكن أن تكون الخيارات "موافقة" أو "معارضة" أو التخلي تمامًا.

في الحوكمة v1، يمكن بدء الاقتراع من خلال إحدى الطرق التالية:

  • الاقتراحات المقدمة علنًا
  • الاقتراحات التي تم الموافقة عليها بأغلبية الأصوات أو بالإجماع
  • الاقتراح المقدم كجزء من تنفيذ الاستفتاء السابق
  • اقتراح طارئ مقدم من اللجنة الفنية وموافق عليه من قبل مجلس الإدارة

كل الاستفتاءات لها فترة تأخير تنفيذ مناسبة. هذه هي الفترة الزمنية من انتهاء الاستفتاء حتى التنفيذ الفعلي للاقتراح ) إذا تم الموافقة عليه (.

إذا تم إغلاق الاستفتاء وإكمال الإحصاءات، يعتبر ذلك قد اكتمل. إذا تم الموافقة على الاقتراح، فسيتم جدولته للتنفيذ. إذا كان الاستفتاء في انتظار النتائج أي أنه في مرحلة التصويت، يعتبر ذلك غير مكتمل.

إذا تم تقديم الاقتراح من قبل الجمهور أو المجلس، فسيكون هناك فترة تأخير تنفيذ ثابتة مدتها 28 يومًا. يمكن تعيين فترة تأخير التنفيذ للاقتراحات المقدمة كجزء من تنفيذ استفتاء سابق حسب الحاجة. تتطلب معالجة الاقتراحات العاجلة "متابعة سريعة" لقضايا مهمة، مما يؤدي إلى تقصير وقت التنفيذ.

في Gov2، يمكن لأي شخص بدء استفتاء في أي وقت، ويمكنه إطلاق استفتاءات متعددة. يقدم Gov2 ميزات جديدة Origins) ومصادر( وTracks) لمساعدة عملية ومعالجة بروتوكول الاستفتاء.

يمكن اعتبار Origin وصفًا غنيًا لمستوى الامتياز المعطى. يحتاج المقترح الآن إلى اختيار Origin المناسب للطلب بناءً على متطلبات الاقتراح.

ترتبط كل Origin بفئة استفتاء، وترتبط كل فئة بمسار. يلخص المسار دورة حياة الاقتراح، وهو مستقل عن مسارات الفئات الأخرى. وجود مسارات مستقلة مختلفة يسمح للشبكة بضبط ديناميات الاستفتاء وفقًا لمستويات الامتياز الضمنية.

على سبيل المثال، تأثير ترقية Runtime ( واستدعاء set_code ) على النظام البيئي، يختلف عن الموافقة على إكرامية الخزانة ( واستدعاء reportAwesome )، لذا تحتاج إلى Origins مختلفة، حيث ستحدد معدلات التصويت المختلفة، ومعدلات الموافقة، والودائع، وأقصر فترة تنفيذ مسبقًا على pallet.

( اقتراح استفتاء

استفتاء عام

يمكن لأي شخص اقتراح استفتاء من خلال إيداع الحد الأدنى من كمية الرموز خلال فترة معينة من عدد الكتل ) ###. إذا وافق شخص ما على الاقتراح، يمكنه إيداع نفس كمية الرموز للتعبير عن الدعم.

تسمى هذه العملية "التأييد". سيتم اختيار الاقتراح الذي يحصل على أعلى دعم من الرموز المرتبطة ليكون استفتاء دورة التصويت التالية. لاحظ أن هذا قد يختلف عن العدد المطلق للتأييد؛ على سبيل المثال، ستتجاوز ثلاث حسابات مرتبطة بـ 20 DOT كل منها فعالية عشرة حسابات مرتبطة بـ 1 DOT لكل منها.

بمجرد تقديم الاقتراح ( سيتم التصويت )، سيتم تحرير الرموز المرتبطة.

بالنسبة للحوكمة v1، يمكن أن تحتوي قائمة الاقتراحات على ما يصل إلى 100 اقتراح عام.

في Gov2، عندما يتم إنشاء استفتاء، يمكن للمجتمع التصويت عليه على الفور. ولكن هذا الاستفتاء لم يكن في حالة يمكن إنهاؤه أو حساب الأصوات، والموافقة عليه وتنفيذه في النهاية. بدلاً من ذلك، يجب أن يلبي الاستفتاء بعض المعايير للدخول في حالة "تحديد (Deciding)". قبل الدخول في هذه الحالة، لا يزال في حالة معلقة.

معايير الدخول في حالة Decided هي كما يلي:

  • عاشت فترة الاستيراد(lead-in period)، وهي الوقت الذي يجب أن يمر به القرار قبل أن يبدأ. يساعد ذلك في تقليل احتمالية "التصويب على القرار"، حيث يمكن للمهاجمين الذين يتحكمون في حقوق التصويت الكبيرة تمرير الاقتراح مباشرة بعد تقديمه، بدلاً من منح جميع الناخبين الوقت الكافي للتفكير والمشاركة.
  • يجب أن يكون هناك مساحة متبقية للقرار. جميع المسارات لها قيود على عدد الاستفتاءات التي يمكن اتخاذ قرارات بشأنها في نفس الوقت. المسارات ذات القدرات الأقوى لها قيود أقل. على سبيل المثال، الحد في مستوى الجذر Origin هو 1، مما يعني أنه يمكن اتخاذ قرار واحد فقط بشأن اقتراح شديد الخطورة في وقت واحد.
  • يجب دفع إيداع القرار. تكلفة إنشاء التصويت منخفضة للغاية، حيث أن قيمة الإيداع تشمل فقط القيمة المطلوبة لتخزين البيانات على السلسلة. ولكن هناك خطر استنفاد المواقع المحدودة في قائمة التصويت عند مراجعة القرار. الطلب على إيداع أكبر ولكن قابل للاسترداد يساعد في تقليل الرسائل غير المرغوب فيها.

استفتاء المجلس (v1)

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

تمت الموافقة بأغلبية المجلس - عندما يوافق عدد بسيط من أعضاء المجلس فقط، يمكن أيضًا التصويت على الاستفتاء، لكنه سيكون بنظام الأغلبية، حيث يفوز الجانب الذي يحصل على 51% من الأصوات (.

لا يمكن أن يكون هناك استفتاء صالح واحد فقط في أي وقت معين، ما لم يكن هناك استفتاء طارئ جارٍ.

جدول التصويت

في Governance v1، إذا كان هناك اقتراح واحد على الأقل في أحد القوائم، سيتم إجراء استفتاء جديد كل 28 يومًا. يوجد قائمة للاقتراحات التي تمت الموافقة عليها من قبل المجلس، وهناك قائمة للاقتراحات المقدمة من الجمهور. سيتم إجراء الاستفتاء بالتناوب بين الاقتراحات التي تحتل المراتب العليا في القائمتين.

يتم تحديد الاقتراحات الأعلى تصنيفًا بناءً على كمية الرهانات المرتبطة بها. إذا تم اختيار قائمة الانتظار الحالية لمحاولة إنشاء تصويت بدون اقتراح ) وكانت القائمة فارغة (، وكانت هناك اقتراحات في قائمة انتظار أخرى، فإن الاقتراح الأعلى ترتيبًا في القائمة الأخرى سيدخل التصويت.

لا يمكن التصويت على أكثر من استفتاء في نفس الوقت ، باستثناء الاستفتاءات العاجلة. الاستفتاءات العاجلة التي تحدث في نفس الوقت مع الاستفتاء العادي ) أو اقتراح المجلس ( هي الحالة الوحيدة التي يمكن فيها التصويت على أكثر من استفتاء في نفس الوقت.

عند الموافقة على الاقتراح، تشارك حوكمة v2 نفس فترة التأهيل التي تبلغ 28 يومًا. إذا لم تتم الموافقة عليه بحلول نهاية هذه المرحلة، سيتم رفض الاقتراح تلقائيًا.

استفتاء التصويت) الإدارةv2(

في Governance v2، إذا كانت الاقتراحات تلبي متطلبات معدل الموافقة ومعدل الدعم، فسيتم الموافقة على الاقتراح، مما يعني أنه تم حذف نظام التحيز الجماعي التكيفي.

معدل الموافقة ) يُعرَّف بأنه وزن التصويت الموافق ( بعد تعديل الاقتناع ) الذي يمثل جزءًا من الوزن الإجمالي للتصويت ( ويتضمن حصص الموافقة والرفض ).

نسبة الدعم ( الدعم ) هو إجمالي عدد الأصوات المعتمدة ( تجاهل تعديل الإدانة ) مقارنةً بإجمالي عدد الأصوات التي قد تُجرى في النظام.

يجب أن يستوفي هذا المعيار في أقصر فترة زمنية خلال فترة التأكيد. تختلف فترات التأكيد ومتطلبات الموافقة والدعم بين المسارات المختلفة. يمكن الآن تكوينها من خلال كمية الدعم المطلوبة والموافقة العامة. من المعقول تقليل نسبة التصويت المطلوبة إلى عدد أكثر واقعية في الاقتراحات التي تستخدم مصادر ذات امتيازات منخفضة مقارنة بالاقتراحات التي تستخدم فئات ذات امتيازات عالية ( مثل Root). يمكن أن تطلب الاقتراحات ذات الأهمية السياسية الكبيرة موافقة أعلى في وقت مبكر لتجنب الجدل.

في Gov2، سيتم اعتبار المقترحات التي لم تتم الموافقة عليها بعد 28 يومًا كرفض افتراضي، وسيتم إعادة ودائع القرار. إذا تمكن الاقتراح من الحفاظ على الموافقة قبل انتهاء فترة التأكيد، فسيعتبر معتمدًا، وسيتم التخطيط لتنفيذه من المصدر المقترح بعد فترة الصياغة. يتم تحديد فترة الصياغة عند اقتراح تصويت شعبي، ولكنها تخضع أيضًا للحد الأدنى القائم على المسار. ستفرض المسارات الأقوى فترة تنفيذ أطول لضمان أن يكون لدى الشبكة الوقت الكافي للاستعداد لأي تغييرات قد يجلبها الاقتراح.

التأمين الطوعي

تستخدم Polkadot مفهوم "القفل الطوعي"، مما يسمح لحاملي الرموز بزيادة حقوق التصويت من خلال إعلان رغبتهم في قفل الرموز لفترة معينة، لذلك سيتم حساب عدد أصوات كل حامل رمز باستخدام المعادلة التالية:

عدد الأصوات = الرمز * مضاعف الاقتناع

مدة القفل تضاعف في كل جولة، وسيؤدي معامل الاقتناع إلى زيادة معامل التصويت بواحد.

عدد فترة القفل مضاعف التصويت 0 1 1 2 2 3 4 4 8 5 16 6 32 6

تم تعيين الحد الأقصى لعدد مرات "التضاعف" لفترة الإغلاق إلى 6(، وبالتالي يوجد إجمالي 32 فترة إغلاق )، حيث تعادل فترة الإغلاق 28 يومًا. يُسمح بالتضاعف فقط، على سبيل المثال، لا يمكنك إغلاق 24 دورة وزيادة إيمانك بمقدار 5.5.

عند قفل التوكن، لا يزال بإمكانك استخدامه للتصويت والرهان؛ أنت ممنوع فقط من نقل هذه التوكنات إلى حساب آخر.

تتم "حساب" الأصوات دائمًا في نفس الوقت، أي عند انتهاء فترة التصويت. هذا لا يتأثر بفترة قفل الرموز.

تحيز الجماعات التكيفي

تم استخدام الانحراف الجماعي التكيفي لفترة أطول في Governance v2 وتم استبداله بنظام الموافقة/الدعم.

( المجلس

في الحوكمة v1، يتم تمثيل أصحاب المصلحة السلبيين على بولكادوت من قبل هيئة إدارية تُعرف باسم "المجلس". المجلس هو كيان على السلسلة يتكون من عدة مشاركين، يمثل كل مشارك حسابًا على السلسلة. في بولكادوت، يتكون المجلس حاليًا من أعضاء.

بجانب السيطرة على الخزينة، يتحمل المجلس أيضًا ثلاث مهام رئيسية في الحوكمة:

  • اقتراح استفتاء حكيم
  • إلغاء الاستفتاءات الخطرة أو الضارة
  • لجنة التقنية الانتخابية

في الحوكمة v2، هناك حاجة لاستراتيجية بديلة لتحل محل مسؤوليات المجلس السابق كوكيل للناخبين، لتعويض حقيقة أن الكثيرين يختارون عدم المشاركة في الحوكمة اليومية. تستند Gov2 إلى وظيفة تفويض التصويت في v1، حيث يمكن للناخبين اختيار تفويض حقوق التصويت لناخب آخر في النظام. يتم ذلك من خلال تحسين وظيفة تسمى التفويض متعدد الأدوار، حيث يمكن للناخبين تعيين ممثلين مختلفين لكل فئة من فئات الاستفتاءات في النظام. وبالتالي، على سبيل المثال، يمكن للناخب أن يفوض كيانًا معينًا لإدارة فئة استفتاء ذات تأثير غير كبير، بينما يختار ممثلًا مختلفًا لإدارة فئة أخرى لها عواقب أكثر أهمية، ولا يزال يحتفظ بكامل حقوق التصويت على أي فئات متبقية.

) إلغاء الاستفتاء

في حوكمة v1، إذا وافق المجلس الفني بالإجماع على إلغاء الاقتراح، أو إذا تم تفعيل هذه الميزة من قبل مصدر Root ( مثل sudo )، يمكن إلغاء الاقتراح. سيتم تدمير الوديعة الخاصة بالاقتراح الملغى.

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

إذا كانت النزاعات الملغاة كبيرة بما فيه الكفاية،

شاهد النسخة الأصلية
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • أعجبني
  • 9
  • مشاركة
تعليق
0/400
ShamedApeSellervip
· 07-04 15:22
تظاهر بالتحكم في هذا الأمر
شاهد النسخة الأصليةرد0
LiquidationKingvip
· 07-04 14:13
هل تقوم DOT مرة أخرى بتحركات كبيرة؟
شاهد النسخة الأصليةرد0
LayerHoppervip
· 07-04 08:49
كل يوم تحديثات كيف نحلها
شاهد النسخة الأصليةرد0
HodlNerdvip
· 07-01 15:56
نظرية الألعاب في الحوكمة مثيرة... لكن هل رأيت التوزيع الإحصائي لمعدل مشاركة الناخبين؟ إنه نوعاً ما مقلق بصراحة
شاهد النسخة الأصليةرد0
BearMarketSurvivorvip
· 07-01 15:56
لا يزال مجرد أسلوب جديد لخداع الحمقى.
شاهد النسخة الأصليةرد0
GhostChainLoyalistvip
· 07-01 15:42
متى يمكن أن تكون اللامركزية حقيقية؟
شاهد النسخة الأصليةرد0
CryptoMotivatorvip
· 07-01 15:40
هل تم لفها جميعًا في الإصدار 2.5؟
شاهد النسخة الأصليةرد0
BackrowObservervip
· 07-01 15:40
لا أستطيع التحمل، حتى لو زاد لا أستطيع تذكره...
شاهد النسخة الأصليةرد0
CoconutWaterBoyvip
· 07-01 15:39
إدارة v2؟ من الأفضل إضافة DAO مجتمعي
شاهد النسخة الأصليةرد0
عرض المزيد
  • تثبيت