تستخدم بولكادوت مجموعة متقنة من آليات الحوكمة التي تتطور بشكل أنيق وفقًا لاحتياجات أصحاب المصلحة. الهدف منها هو ضمان أن الأغلبية دائمًا ما تستطيع التحكم في الشبكة.
قد تتغير محتويات هذه الوثيقة. لقد مرت بروتوكولات الحوكمة بعدة تكرارات (v1 و v2)، وهناك المزيد من التغييرات المخطط لها (v2.5).
يتكون أول نظام للحكم اللامركزي في Polkadot (v1) من ثلاثة مكونات رئيسية:
اللجنة الفنية: اللجنة المسؤولة عن إدارة جدول ترقية التكنولوجيا.
المجلس: حكومة تنفيذية يتم انتخابها عن طريق التصويت، مسؤولة عن إدارة المعلمات وإدارة مقترحات المصروفات.
الاستفتاء: نظام تصويت عام، يتم التصويت على كل شيء آخر، حيث يتمتع أصحاب المصلحة على المدى الطويل بتأثير أكبر.
كان هذا النظام يعمل بشكل جيد في السنوات الأولى، حيث ساعد على ضمان الاستخدام السليم لأموال الخزينة وتمكن من التحديث والإصلاح في الوقت المناسب. كما هو الحال مع معظم التقنيات المبكرة، كان يجب على النظام والبروتوكولات أن تتطور باستمرار لتحسين العيوب ومواكبة التقدم. على سبيل المثال، في "الحوكمة v1"، كان لكل استفتاء نفس الوزن، لأنه يمكن التصويت على استفتاء واحد فقط في المرة الواحدة، ومدة التصويت يمكن أن تستمر لعدة أسابيع. أدى ذلك إلى ميل النظام للتفكير بعناية في عدد قليل جداً من الاقتراحات بدلاً من التفكير على نطاق واسع في العديد من الاقتراحات. وهكذا وُلِدت "الحوكمة v2"!
"الحوكمةv2" أو "Gov2" غيرت طريقة اتخاذ القرارات اليومية، مما جعل نطاق تأثير الاستفتاءات أوسع وأكثر مرونة، وبالتالي زادت بشكل كبير عدد القرارات الجماعية التي يمكن للنظام اتخاذها.
سيتم إطلاق Gov2 على Kusama بعد إجراء مراجعة احترافية نهائية لشفرتها. بعد الاختبار على Kusama، سيتم تقديم مقترح لنشره على Polkadot.
سوف يقدم المحتوى أدناه العديد من المبادئ الأساسية للحوكمة على شبكة Polkadot. من المهم فهم جذور الحوكمة v1 لفهم أفضل اتجاهات المرحلة الثانية. ستتم إبراز هذه الاختلافات والتمييزات في مختلف الموضوعات الفرعية.
من المهم أن نلاحظ أنه في هذه المرحلة من دورة حياتها، فإن الحوكمة هي بروتوكول يتطور باستمرار. مع دخول تحديث الحوكمة v2 إلى الشبكة، تم أيضًا وضع خطط للحوكمة v2.5.
فرضية
باختصار، يجمع هذا الشبكة آليات جديدة متعددة، بما في ذلك دالة تحويل الحالة غير المحددة المخزنة على السلسلة والتي تُعرف بلغة وسيطة محايدة للمنصة (WebAssembly)، بالإضافة إلى آليات تصويت متعددة على السلسلة، مثل الاستفتاءات ذات العتبة المطلقة التكيفية وآليات التصويت بالموافقة الجماعية.
يجب أن يتم التوصل إلى توافق بشأن جميع التعديلات على الاتفاقية من خلال استفتاء يعتمد على وزن الحقوق.
آلية
في الحوكمة v1، يدير حاملو الرموز النشطون والمجلس قرارات ترقية الشبكة معًا. سواء تم تقديم الاقتراح من قبل حاملي الرموز العامة ( أو من قبل المجلس، يجب أن يمر في النهاية عبر استفتاء شامل لجميع الحاملي، حيث يتم اتخاذ القرار بناءً على وزن المبلغ المرهون ) والاعتقاد (.
توجد بعض التغييرات في إدارة v2. الطريقة التي تعكس بها نموذج الإدارة الجديد خصائصه اللامركزية هي:
نقل جميع مسؤوليات المجلس إلى حاملي الرموز من خلال التصويت الديمقراطي
حل المجلس الحالي بشكل جماعي
السماح للمستخدمين بتفويض حقوق التصويت لأعضاء المجتمع بطرق أكثر
تقوم الهيئة في Gov1 بدور ممثل حاملي الرموز السلبية، وصائدي الخزائن، ومقدمي التشريعات، لكنها تُعتبر عادةً كيانًا مركزيًا. من أجل مزيد من اللامركزية لشبكات Polkadot وKusama، يقترح Gov2 إعادة مسؤوليات الهيئة إلى المجتمع.
) استفتاء
الاستفتاء هو خطة تصويت بسيطة وشاملة قائمة على الرهان. يحتوي كل استفتاء على اقتراح محدد ذي صلة، يتم استخدامه في شكل استدعاءات وظائف امتياز وقت التشغيل (، بما في ذلك أقوى استدعاء: set_code، الذي يمكنه تبديل شفرات وقت التشغيل بالكامل، مما يحقق وظائف كانت تحتاج في الأصل إلى "انقسام صلب" لتحقيقها ).
الاستفتاء هو حدث منفصل له فترة تصويت محددة. عند انتهاء فترة التصويت وإحصاء الأصوات، إذا تم الموافقة على التصويت، سيتم استدعاء الدالة ###set_code(. الاستفتاء دائماً ثنائي؛ خيارك في التصويت يمكن أن يكون "موافق"، "معارض" أو الامتناع تماماً.
يمكن بدء الاستفتاء في إدارة v1 بعدة طرق:
اقتراحات مقدمة علنياً;
المقترحات التي تم الموافقة عليها بأغلبية الأصوات أو بالإجماع من قبل المجلس;
الاقتراح المقدم كجزء من تنفيذ الاستفتاء السابق;
اقتراح طارئ مقدم من اللجنة الفنية وموافق عليه من قبل مجلس الإدارة.
توجد فترة تأخير تنفيذ مناسبة لجميع الاستفتاءات. هذه الفترة هي من نهاية الاستفتاء حتى التنفيذ الفعلي للاقتراح ) على افتراض أن الاقتراح قد تم قبوله (.
إذا تم إغلاق استفتاء واكتمال الإحصاءات، يُعتبر هذا الاستفتاء قد اكتمل. وبالمثل، إذا تم الموافقة على الاقتراح، فسيتم ترتيب تنفيذه. إذا كان الاستفتاء في انتظار النتائج، أي أنه يتم التصويت عليه، يُعتبر هذا الاستفتاء غير مكتمل.
إذا كانت الاقتراحات مقدمة من الجمهور أو المجلس، فهناك فترة تأخير تنفيذ ثابتة مدتها 28 يومًا. يمكن ضبط فترة تأخير التنفيذ للاقتراحات المقدمة كجزء من تنفيذ استفتاء سابق حسب الحاجة. معالجة الاقتراحات العاجلة تتطلب "متابعة سريعة" لمشاكل الشبكة الكبيرة، مما يقلل من وقت التنفيذ.
في Gov2، يمكن لأي شخص بدء استفتاء في أي وقت، ويمكنه بدء عدد غير محدود من الاستفتاءات. يقدم Gov2 العديد من الميزات الجديدة، المسماة Origins) ومصادر( وTracks) ومسارات(، للمساعدة في سير عملية الاستفتاءات ومعالجتها.
يمكن اعتبار Origin وصفًا غنيًا لمستوى الامتياز المعطى. يحتاج مقترحو الاستفتاء الآن إلى اختيار Origin مناسب لطلباتهم وفقًا لمتطلبات الاقتراح.
كل Origin مرتبط بفئة استفتاء، وكل فئة مرتبطة بـ Track. يوضح Track دورة حياة الاقتراح، وهو مستقل عن Tracks الأخرى. إن وجود Tracks مستقلة مختلفة يسمح للشبكة بتعديل ديناميكيات الاستفتاء وفقًا لمستوى الامتياز الضمني.
على سبيل المثال، تأثير ترقية Runtime ) على استدعاء set_code ( على النظام البيئي، يختلف عن الموافقة على إكرامية الخزانة ) لاستدعاء reportAwesome (، لذا تحتاج إلى أصول مختلفة، حيث سيتم تحديد معدلات التصويت المختلفة ومعدلات الموافقة والودائع وأقصر فترة تنفيذ مسبقًا على الصندوق.
) اقتراع المقترحات
استفتاء عام
يمكن لأي شخص اقتراح استفتاء من خلال إيداع الحد الأدنى من عدد الرموز في فترة معينة ضمن ( عدد الكتل ). إذا وافق شخص ما على الاقتراح، يمكنه إيداع نفس العدد من الرموز لإظهار الدعم.
تُعرف هذه العملية باسم "التأييد". سيتم اختيار الاقتراح الذي يحصل على أعلى دعم من الرموز المربوطة ليكون اقتراح التصويت التالي في الدورة الانتخابية. يرجى ملاحظة أن هذا قد يختلف عن العدد المطلق للتأييدات; على سبيل المثال، سيؤدي ربط 20 DOT من قبل ثلاثة حسابات إلى "تجاوز" فعالية عشرة حسابات تربط 1 DOT لكل منها.
بمجرد تقديم الاقتراح ### سيتم التصويت (، سيتم تحرير الرموز المرتبطة.
في إدارة v1، يمكن أن تحتوي قائمة الاقتراحات على ما يصل إلى 100 اقتراح عام.
في Gov2، عندما يتم إنشاء استفتاء، يمكن للمجتمع التصويت عليه على الفور. ومع ذلك، فإن هذا الاستفتاء ليس في حالة يمكن إنهاؤها، أو بطريقة أخرى حساب أصواتها، والحصول على الموافقة وتنفيذها نهائيًا. بدلاً من ذلك، يجب أن يستوفي الاستفتاء بعض المعايير قبل أن يدخل في حالة تُسمى "قرار )Deciding(". قبل أن تكون في هذه الحالة، لا تزال في حالة الانتظار.
معايير الدخول في حالة Decided هي كما يلي:
مرت بفترة الاستيراد ) lead-in period (، وهي المدة الزمنية التي يجب أن تمر بها قبل اتخاذ القرار بالبدء. يساعد ذلك في تقليل احتمال "هجوم القرار"، حيث يمكن للمهاجم الذي يسيطر على كمية كبيرة من حقوق التصويت أن يمرر الاقتراح مباشرة بعد الاقتراح، بدلاً من منح جميع الناخبين الوقت الكافي للتفكير والمشاركة.
يجب أن تكون هناك مساحة متبقية حاسمة. جميع المسارات تحدد عدد الاستفتاءات التي يمكن أن تقرر في نفس الوقت. ستكون المسارات ذات القدرات الأقوى لديها قيود أقل. على سبيل المثال، الحد بالنسبة لمستوى الجذر Origin هو 1، مما يعني أنه يمكن قرار اقتراح واحد شديد الخطورة في وقت واحد.
يجب دفع وديعة القرار. تكلفة إنشاء التصويت منخفضة، لأن قيمة الوديعة تتضمن فقط القيمة المطلوبة للتخزين على السلسلة اللازمة لتتبعها. ومع ذلك، هناك خطر استنفاد المواقع المحدودة في قائمة التصويت عند مراجعة القرار. طلب مبلغ أكبر من الوديعة القابلة للاسترداد يساعد في تقليل الرسائل غير المرغوب فيها.
جدول التصويت
في Governance v1، إذا كان هناك اقتراح واحد على الأقل في إحدى القوائم، سيتم إجراء استفتاء جديد كل 28 يومًا. هناك قائمة للاقتراحات المعتمدة من المجلس، وأيضًا قائمة للاقتراحات المقدمة من الجمهور. سيتم إجراء الاستفتاءات بالتناوب بين الاقتراحات الأعلى تصنيفًا في القائمتين.
تحدد الاقتراحات الأكثر تصنيفًا من خلال كمية الرهان المرتبطة بها. إذا كانت قائمة الاختيار الحالية تحاول إنشاء استفتاء بدون اقتراح، فإن قائمة الاستفتاء ) تكون فارغة (، وإذا كانت هناك قائمة أخرى بها اقتراحات في الانتظار، فإن الاقتراح الأكثر تصنيفًا في القائمة الأخرى سيدخل الاستفتاء.
لا يمكن التصويت على عدة استفتاءات في نفس الوقت، باستثناء الاستفتاءات الطارئة. الاستفتاءات الطارئة التي تحدث في نفس الوقت مع الاستفتاءات العادية ) أو المقترحات المقدمة من المجلس ( هي الحالة الوحيدة التي يمكن فيها التصويت على عدة استفتاءات في نفس الوقت.
عندما يتم الموافقة على الاقتراح، تشارك إدارة V2 نفس فترة التأهيل البالغة 28 يومًا. إذا لم يتم الموافقة عليه بحلول نهاية هذه المرحلة، فسيتم رفض الاقتراح تلقائيًا.
استطلاع رأي ) إدارة v2(
في Governance v2، إذا استوفى الاقتراح متطلبات معدل الموافقة ومعدل الدعم، فسيتم الموافقة على الاقتراح، مما يعني إزالة نظام التحيز الجماعي التكيفي.
تم تعريف معدل الموافقة ) على أنه وزن تصويت الموافقة ( بعد تعديل الاقتناع ) كنسبة من الوزن الكلي للتصويت ( والتي تشمل حصة الموافقة والرفض ).
نسبة الدعم ( دعم ) هو العدد الإجمالي للأصوات المعتمدة ( تجاهل تعديل الاقتناع ) مقارنةً بالعدد الإجمالي للأصوات التي يمكن أن تُجرى في النظام.
يجب أن تستوفي هذا المعيار في أقصر فترة زمنية ممكنة من فترة التأكيد. تختلف المسارات المختلفة في فترة التأكيد ومتطلبات الموافقة والدعم. يمكن الآن تكوينها من خلال الكمية المطلوبة من الدعم والموافقة العامة. بالنسبة للاقتراحات التي تستخدم مصادر ذات امتيازات منخفضة، يكون من الأكثر معقولية تقليل نسبة التصويت المطلوبة في وقت مبكر إلى أرقام أكثر واقعية مقارنةً بالاقتراحات التي تستخدم فئات ذات امتيازات عالية ( مثل Root). يمكن أن تطلب الدورات ذات الأهمية السياسية الكبيرة موافقة أعلى في وقت مبكر لتجنب النزاع.
في Gov2، سيتم اعتبار الاقتراحات التي لم تتم الموافقة عليها بعد 28 يومًا بمثابة رفض افتراضي، وسيتم استرداد وديعة القرار. إذا تمكن الاقتراح من الحفاظ على الموافقة قبل انتهاء فترة التأكيد، فسيتم اعتباره معتمدًا، وسيتم التخطيط للتنفيذ من المصدر المقترح بعد فترة الصياغة. يتم تحديد فترة الصياغة عند اقتراح التصويت الشعبي، ولكنها تخضع أيضًا للحد الأدنى القائم على المسار. ستفرض المسارات الأقوى فترات تنفيذ أطول لضمان أن يكون لدى الشبكة وقت كافٍ للاستعداد لأي تغييرات قد يجلبها الاقتراح.
الاحتجاز الطوعي
تستخدم Polkadot مفهومًا يُسمى "القفل الطوعي"، والذي يسمح لحاملي التوكن بزيادة أصواتهم من خلال إعلان المدة الزمنية التي يرغبون في قفل التوكن خلالها، وبالتالي، سيتم حساب عدد أصوات كل حامل توكن باستخدام الصيغة التالية:
عدد الأصوات = توكن * مضاعف الاقتناع
عدد فترة القفل يتضاعف في كل مرة، وسيزيد مضاعف الاقتناع من مضاعف التصويت بمقدار واحد.
عدد الاقتراع لعقد القفل مضاعف 00.111224384165326
تم تعيين الحد الأقصى لعدد مرات "التأمين" المزدوجة إلى 6( ، لذا هناك إجمالي 32 فترة تأمين ) ، حيث تساوي فترة التأمين 28 يومًا. يُسمح فقط بالتأمين المزدوج، على سبيل المثال، لا يمكنك تأمين 24 دورة وزيادة قناعتك بمقدار 5.5.
بعد قفل الرمز، لا يزال بإمكانك استخدامه للتصويت والتخزين؛ أنت فقط محظور من نقل هذه الرموز إلى حساب آخر.
تُحسب الأصوات دائمًا في نفس الوقت، أي عند انتهاء فترة التصويت. هذا لا يتأثر بفترة قفل الرموز.
( إلغاء الاستفتاء
في إدارة v1، إذا وافق المجلس الفني بالإجماع على إلغاء الاقتراح، أو إذا تم تفعيل هذه الوظيفة بواسطة مصدر Root، يمكن إلغاء الاقتراح. سيتم تدمير الوديعة الخاصة بالاقتراح الملغى.
علاوة على ذلك، يمكن لمجلس الإدارة إلغاء الاستفتاء بأغلبية الثلثين. إذا تم اكتشاف مشكلة في اقتراح الاستفتاء في وقت متأخر مثل وجود خطأ في كود التشغيل الذي سيتم تنفيذه، فقد يكون ذلك بمثابة الملاذ الأخير.
إذا كانت النزاعات الملغاة كبيرة بما يكفي بحيث لا يمكن للمجلس الحصول على ثلثي الأصوات، فسيتم تحديد مصير الاقتراح من قبل أصحاب المصلحة بشكل مشترك.
في إدارة v2، هناك عملية خاصة تسمى Cancelation) لإلغاء (، تُستخدم للتدخل في الاقتراحات التي تم التصويت عليها بالفعل. ستقوم هذه العملية برفض الاستفتاء الجاري على الفور، بغض النظر عن حالته. هناك أيضًا شرط ينص على أنه إذا كان الاقتراح خبيثًا أو عبارة عن معلومات زائفة، فإنه يتم ضمان مصادرة وديعة مقدمي الاقتراح.
الإلغاء هو في حد ذاته عملية حوكمة، ويجب أن يتم تنفيذه من خلال تصويت الشبكة. يأتي الإلغاء مع أصله ومساره الخاص، وله فترة إدخال قصيرة جداً ومنحنى معدل الموافقة / الدعم، حيث ينخفض عتبة تمريرها بسرعة أكبر قليلاً، لأنها تُستدعى فقط في الحالات العاجلة.
) زمالة بولكادوت
هذه الزمالة هي هيئة خبراء ذات حكم ذاتي أساسي، هدفها الرئيسي هو تمثيل الأفراد الذين يمتلكون قاعدة معرفية تقنية حول شبكة بروتوكول بولكادوت. تعمل الزمالة من خلال "المساواة
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 18
أعجبني
18
8
مشاركة
تعليق
0/400
TokenGuru
· منذ 15 س
المشاريع القديمة يجب أن تتماشى مع اتجاهات الثور والدب، كما قلت سابقاً!
شاهد النسخة الأصليةرد0
WenAirdrop
· 07-22 23:59
dot قد تطورت وترقيت مرة أخرى
شاهد النسخة الأصليةرد0
Lonely_Validator
· 07-22 07:29
ما هو الحكم؟ إذا كنت لا تفهم فلا تستثمر.
شاهد النسخة الأصليةرد0
GateUser-4745f9ce
· 07-22 03:19
لا تهتم بـ V2، فقط قم بتسوية رسوم الغاز لـ V1.
شاهد النسخة الأصليةرد0
GraphGuru
· 07-22 03:18
لقد كنت أتابع v2 لفترة جيدة الآن. جيد جيد.
شاهد النسخة الأصليةرد0
BearMarketSurvivor
· 07-22 03:13
أليس مجرد تفويض التصويت؟ ما الجديد في ذلك؟
شاهد النسخة الأصليةرد0
SneakyFlashloan
· 07-22 03:05
لم لا تعطي لي حق الحكم مباشرة؟
شاهد النسخة الأصليةرد0
TokenSherpa
· 07-22 02:50
في الواقع، هذا النموذج v2 لا يزال يتجاهل آليات التصويت التربيعي... *sigh* دعني أوضح هذا.
بولكادوت الحوكمة V2: تجديد آلية الاستفتاء لزيادة كفاءة اتخاذ القرار
الحوكمة V2
تستخدم بولكادوت مجموعة متقنة من آليات الحوكمة التي تتطور بشكل أنيق وفقًا لاحتياجات أصحاب المصلحة. الهدف منها هو ضمان أن الأغلبية دائمًا ما تستطيع التحكم في الشبكة.
قد تتغير محتويات هذه الوثيقة. لقد مرت بروتوكولات الحوكمة بعدة تكرارات (v1 و v2)، وهناك المزيد من التغييرات المخطط لها (v2.5).
يتكون أول نظام للحكم اللامركزي في Polkadot (v1) من ثلاثة مكونات رئيسية:
كان هذا النظام يعمل بشكل جيد في السنوات الأولى، حيث ساعد على ضمان الاستخدام السليم لأموال الخزينة وتمكن من التحديث والإصلاح في الوقت المناسب. كما هو الحال مع معظم التقنيات المبكرة، كان يجب على النظام والبروتوكولات أن تتطور باستمرار لتحسين العيوب ومواكبة التقدم. على سبيل المثال، في "الحوكمة v1"، كان لكل استفتاء نفس الوزن، لأنه يمكن التصويت على استفتاء واحد فقط في المرة الواحدة، ومدة التصويت يمكن أن تستمر لعدة أسابيع. أدى ذلك إلى ميل النظام للتفكير بعناية في عدد قليل جداً من الاقتراحات بدلاً من التفكير على نطاق واسع في العديد من الاقتراحات. وهكذا وُلِدت "الحوكمة v2"!
"الحوكمةv2" أو "Gov2" غيرت طريقة اتخاذ القرارات اليومية، مما جعل نطاق تأثير الاستفتاءات أوسع وأكثر مرونة، وبالتالي زادت بشكل كبير عدد القرارات الجماعية التي يمكن للنظام اتخاذها.
سيتم إطلاق Gov2 على Kusama بعد إجراء مراجعة احترافية نهائية لشفرتها. بعد الاختبار على Kusama، سيتم تقديم مقترح لنشره على Polkadot.
سوف يقدم المحتوى أدناه العديد من المبادئ الأساسية للحوكمة على شبكة Polkadot. من المهم فهم جذور الحوكمة v1 لفهم أفضل اتجاهات المرحلة الثانية. ستتم إبراز هذه الاختلافات والتمييزات في مختلف الموضوعات الفرعية.
من المهم أن نلاحظ أنه في هذه المرحلة من دورة حياتها، فإن الحوكمة هي بروتوكول يتطور باستمرار. مع دخول تحديث الحوكمة v2 إلى الشبكة، تم أيضًا وضع خطط للحوكمة v2.5.
فرضية
باختصار، يجمع هذا الشبكة آليات جديدة متعددة، بما في ذلك دالة تحويل الحالة غير المحددة المخزنة على السلسلة والتي تُعرف بلغة وسيطة محايدة للمنصة (WebAssembly)، بالإضافة إلى آليات تصويت متعددة على السلسلة، مثل الاستفتاءات ذات العتبة المطلقة التكيفية وآليات التصويت بالموافقة الجماعية.
يجب أن يتم التوصل إلى توافق بشأن جميع التعديلات على الاتفاقية من خلال استفتاء يعتمد على وزن الحقوق.
آلية
في الحوكمة v1، يدير حاملو الرموز النشطون والمجلس قرارات ترقية الشبكة معًا. سواء تم تقديم الاقتراح من قبل حاملي الرموز العامة ( أو من قبل المجلس، يجب أن يمر في النهاية عبر استفتاء شامل لجميع الحاملي، حيث يتم اتخاذ القرار بناءً على وزن المبلغ المرهون ) والاعتقاد (.
توجد بعض التغييرات في إدارة v2. الطريقة التي تعكس بها نموذج الإدارة الجديد خصائصه اللامركزية هي:
تقوم الهيئة في Gov1 بدور ممثل حاملي الرموز السلبية، وصائدي الخزائن، ومقدمي التشريعات، لكنها تُعتبر عادةً كيانًا مركزيًا. من أجل مزيد من اللامركزية لشبكات Polkadot وKusama، يقترح Gov2 إعادة مسؤوليات الهيئة إلى المجتمع.
) استفتاء
الاستفتاء هو خطة تصويت بسيطة وشاملة قائمة على الرهان. يحتوي كل استفتاء على اقتراح محدد ذي صلة، يتم استخدامه في شكل استدعاءات وظائف امتياز وقت التشغيل (، بما في ذلك أقوى استدعاء: set_code، الذي يمكنه تبديل شفرات وقت التشغيل بالكامل، مما يحقق وظائف كانت تحتاج في الأصل إلى "انقسام صلب" لتحقيقها ).
الاستفتاء هو حدث منفصل له فترة تصويت محددة. عند انتهاء فترة التصويت وإحصاء الأصوات، إذا تم الموافقة على التصويت، سيتم استدعاء الدالة ###set_code(. الاستفتاء دائماً ثنائي؛ خيارك في التصويت يمكن أن يكون "موافق"، "معارض" أو الامتناع تماماً.
يمكن بدء الاستفتاء في إدارة v1 بعدة طرق:
توجد فترة تأخير تنفيذ مناسبة لجميع الاستفتاءات. هذه الفترة هي من نهاية الاستفتاء حتى التنفيذ الفعلي للاقتراح ) على افتراض أن الاقتراح قد تم قبوله (.
إذا تم إغلاق استفتاء واكتمال الإحصاءات، يُعتبر هذا الاستفتاء قد اكتمل. وبالمثل، إذا تم الموافقة على الاقتراح، فسيتم ترتيب تنفيذه. إذا كان الاستفتاء في انتظار النتائج، أي أنه يتم التصويت عليه، يُعتبر هذا الاستفتاء غير مكتمل.
إذا كانت الاقتراحات مقدمة من الجمهور أو المجلس، فهناك فترة تأخير تنفيذ ثابتة مدتها 28 يومًا. يمكن ضبط فترة تأخير التنفيذ للاقتراحات المقدمة كجزء من تنفيذ استفتاء سابق حسب الحاجة. معالجة الاقتراحات العاجلة تتطلب "متابعة سريعة" لمشاكل الشبكة الكبيرة، مما يقلل من وقت التنفيذ.
في Gov2، يمكن لأي شخص بدء استفتاء في أي وقت، ويمكنه بدء عدد غير محدود من الاستفتاءات. يقدم Gov2 العديد من الميزات الجديدة، المسماة Origins) ومصادر( وTracks) ومسارات(، للمساعدة في سير عملية الاستفتاءات ومعالجتها.
يمكن اعتبار Origin وصفًا غنيًا لمستوى الامتياز المعطى. يحتاج مقترحو الاستفتاء الآن إلى اختيار Origin مناسب لطلباتهم وفقًا لمتطلبات الاقتراح.
كل Origin مرتبط بفئة استفتاء، وكل فئة مرتبطة بـ Track. يوضح Track دورة حياة الاقتراح، وهو مستقل عن Tracks الأخرى. إن وجود Tracks مستقلة مختلفة يسمح للشبكة بتعديل ديناميكيات الاستفتاء وفقًا لمستوى الامتياز الضمني.
على سبيل المثال، تأثير ترقية Runtime ) على استدعاء set_code ( على النظام البيئي، يختلف عن الموافقة على إكرامية الخزانة ) لاستدعاء reportAwesome (، لذا تحتاج إلى أصول مختلفة، حيث سيتم تحديد معدلات التصويت المختلفة ومعدلات الموافقة والودائع وأقصر فترة تنفيذ مسبقًا على الصندوق.
) اقتراع المقترحات
استفتاء عام
يمكن لأي شخص اقتراح استفتاء من خلال إيداع الحد الأدنى من عدد الرموز في فترة معينة ضمن ( عدد الكتل ). إذا وافق شخص ما على الاقتراح، يمكنه إيداع نفس العدد من الرموز لإظهار الدعم.
تُعرف هذه العملية باسم "التأييد". سيتم اختيار الاقتراح الذي يحصل على أعلى دعم من الرموز المربوطة ليكون اقتراح التصويت التالي في الدورة الانتخابية. يرجى ملاحظة أن هذا قد يختلف عن العدد المطلق للتأييدات; على سبيل المثال، سيؤدي ربط 20 DOT من قبل ثلاثة حسابات إلى "تجاوز" فعالية عشرة حسابات تربط 1 DOT لكل منها.
بمجرد تقديم الاقتراح ### سيتم التصويت (، سيتم تحرير الرموز المرتبطة.
في إدارة v1، يمكن أن تحتوي قائمة الاقتراحات على ما يصل إلى 100 اقتراح عام.
في Gov2، عندما يتم إنشاء استفتاء، يمكن للمجتمع التصويت عليه على الفور. ومع ذلك، فإن هذا الاستفتاء ليس في حالة يمكن إنهاؤها، أو بطريقة أخرى حساب أصواتها، والحصول على الموافقة وتنفيذها نهائيًا. بدلاً من ذلك، يجب أن يستوفي الاستفتاء بعض المعايير قبل أن يدخل في حالة تُسمى "قرار )Deciding(". قبل أن تكون في هذه الحالة، لا تزال في حالة الانتظار.
معايير الدخول في حالة Decided هي كما يلي:
جدول التصويت
في Governance v1، إذا كان هناك اقتراح واحد على الأقل في إحدى القوائم، سيتم إجراء استفتاء جديد كل 28 يومًا. هناك قائمة للاقتراحات المعتمدة من المجلس، وأيضًا قائمة للاقتراحات المقدمة من الجمهور. سيتم إجراء الاستفتاءات بالتناوب بين الاقتراحات الأعلى تصنيفًا في القائمتين.
تحدد الاقتراحات الأكثر تصنيفًا من خلال كمية الرهان المرتبطة بها. إذا كانت قائمة الاختيار الحالية تحاول إنشاء استفتاء بدون اقتراح، فإن قائمة الاستفتاء ) تكون فارغة (، وإذا كانت هناك قائمة أخرى بها اقتراحات في الانتظار، فإن الاقتراح الأكثر تصنيفًا في القائمة الأخرى سيدخل الاستفتاء.
لا يمكن التصويت على عدة استفتاءات في نفس الوقت، باستثناء الاستفتاءات الطارئة. الاستفتاءات الطارئة التي تحدث في نفس الوقت مع الاستفتاءات العادية ) أو المقترحات المقدمة من المجلس ( هي الحالة الوحيدة التي يمكن فيها التصويت على عدة استفتاءات في نفس الوقت.
عندما يتم الموافقة على الاقتراح، تشارك إدارة V2 نفس فترة التأهيل البالغة 28 يومًا. إذا لم يتم الموافقة عليه بحلول نهاية هذه المرحلة، فسيتم رفض الاقتراح تلقائيًا.
استطلاع رأي ) إدارة v2(
في Governance v2، إذا استوفى الاقتراح متطلبات معدل الموافقة ومعدل الدعم، فسيتم الموافقة على الاقتراح، مما يعني إزالة نظام التحيز الجماعي التكيفي.
تم تعريف معدل الموافقة ) على أنه وزن تصويت الموافقة ( بعد تعديل الاقتناع ) كنسبة من الوزن الكلي للتصويت ( والتي تشمل حصة الموافقة والرفض ).
نسبة الدعم ( دعم ) هو العدد الإجمالي للأصوات المعتمدة ( تجاهل تعديل الاقتناع ) مقارنةً بالعدد الإجمالي للأصوات التي يمكن أن تُجرى في النظام.
يجب أن تستوفي هذا المعيار في أقصر فترة زمنية ممكنة من فترة التأكيد. تختلف المسارات المختلفة في فترة التأكيد ومتطلبات الموافقة والدعم. يمكن الآن تكوينها من خلال الكمية المطلوبة من الدعم والموافقة العامة. بالنسبة للاقتراحات التي تستخدم مصادر ذات امتيازات منخفضة، يكون من الأكثر معقولية تقليل نسبة التصويت المطلوبة في وقت مبكر إلى أرقام أكثر واقعية مقارنةً بالاقتراحات التي تستخدم فئات ذات امتيازات عالية ( مثل Root). يمكن أن تطلب الدورات ذات الأهمية السياسية الكبيرة موافقة أعلى في وقت مبكر لتجنب النزاع.
في Gov2، سيتم اعتبار الاقتراحات التي لم تتم الموافقة عليها بعد 28 يومًا بمثابة رفض افتراضي، وسيتم استرداد وديعة القرار. إذا تمكن الاقتراح من الحفاظ على الموافقة قبل انتهاء فترة التأكيد، فسيتم اعتباره معتمدًا، وسيتم التخطيط للتنفيذ من المصدر المقترح بعد فترة الصياغة. يتم تحديد فترة الصياغة عند اقتراح التصويت الشعبي، ولكنها تخضع أيضًا للحد الأدنى القائم على المسار. ستفرض المسارات الأقوى فترات تنفيذ أطول لضمان أن يكون لدى الشبكة وقت كافٍ للاستعداد لأي تغييرات قد يجلبها الاقتراح.
الاحتجاز الطوعي
تستخدم Polkadot مفهومًا يُسمى "القفل الطوعي"، والذي يسمح لحاملي التوكن بزيادة أصواتهم من خلال إعلان المدة الزمنية التي يرغبون في قفل التوكن خلالها، وبالتالي، سيتم حساب عدد أصوات كل حامل توكن باستخدام الصيغة التالية:
عدد الأصوات = توكن * مضاعف الاقتناع
عدد فترة القفل يتضاعف في كل مرة، وسيزيد مضاعف الاقتناع من مضاعف التصويت بمقدار واحد.
عدد الاقتراع لعقد القفل مضاعف 00.111224384165326
تم تعيين الحد الأقصى لعدد مرات "التأمين" المزدوجة إلى 6( ، لذا هناك إجمالي 32 فترة تأمين ) ، حيث تساوي فترة التأمين 28 يومًا. يُسمح فقط بالتأمين المزدوج، على سبيل المثال، لا يمكنك تأمين 24 دورة وزيادة قناعتك بمقدار 5.5.
بعد قفل الرمز، لا يزال بإمكانك استخدامه للتصويت والتخزين؛ أنت فقط محظور من نقل هذه الرموز إلى حساب آخر.
تُحسب الأصوات دائمًا في نفس الوقت، أي عند انتهاء فترة التصويت. هذا لا يتأثر بفترة قفل الرموز.
( إلغاء الاستفتاء
في إدارة v1، إذا وافق المجلس الفني بالإجماع على إلغاء الاقتراح، أو إذا تم تفعيل هذه الوظيفة بواسطة مصدر Root، يمكن إلغاء الاقتراح. سيتم تدمير الوديعة الخاصة بالاقتراح الملغى.
علاوة على ذلك، يمكن لمجلس الإدارة إلغاء الاستفتاء بأغلبية الثلثين. إذا تم اكتشاف مشكلة في اقتراح الاستفتاء في وقت متأخر مثل وجود خطأ في كود التشغيل الذي سيتم تنفيذه، فقد يكون ذلك بمثابة الملاذ الأخير.
إذا كانت النزاعات الملغاة كبيرة بما يكفي بحيث لا يمكن للمجلس الحصول على ثلثي الأصوات، فسيتم تحديد مصير الاقتراح من قبل أصحاب المصلحة بشكل مشترك.
في إدارة v2، هناك عملية خاصة تسمى Cancelation) لإلغاء (، تُستخدم للتدخل في الاقتراحات التي تم التصويت عليها بالفعل. ستقوم هذه العملية برفض الاستفتاء الجاري على الفور، بغض النظر عن حالته. هناك أيضًا شرط ينص على أنه إذا كان الاقتراح خبيثًا أو عبارة عن معلومات زائفة، فإنه يتم ضمان مصادرة وديعة مقدمي الاقتراح.
الإلغاء هو في حد ذاته عملية حوكمة، ويجب أن يتم تنفيذه من خلال تصويت الشبكة. يأتي الإلغاء مع أصله ومساره الخاص، وله فترة إدخال قصيرة جداً ومنحنى معدل الموافقة / الدعم، حيث ينخفض عتبة تمريرها بسرعة أكبر قليلاً، لأنها تُستدعى فقط في الحالات العاجلة.
) زمالة بولكادوت
هذه الزمالة هي هيئة خبراء ذات حكم ذاتي أساسي، هدفها الرئيسي هو تمثيل الأفراد الذين يمتلكون قاعدة معرفية تقنية حول شبكة بروتوكول بولكادوت. تعمل الزمالة من خلال "المساواة