تعتمد بولكادوت على آلية حوكمة معقدة، مما يسمح لها بالتطور باستمرار وفقًا لاحتياجات أصحاب المصلحة. هدفها هو ضمان أن تتمكن الغالبية العظمى من المساهمين دائمًا من التحكم في الشبكة.
قد تتغير محتويات هذه الوثيقة. لقد مرت بروتوكولات الحوكمة بعدة مراحل من التحديث (v1 و v2)، وسيكون هناك المزيد من التغييرات في المستقبل (v2.5).
يتكون أول نظام للحكم اللامركزي في بولكادوت (v1) من ثلاثة مكونات رئيسية:
لجنة التكنولوجيا: إدارة جدول ترقية
المجلس: حكومة تنفيذية منتخبة، مسؤولة عن إدارة المعلمات وإدارة مقترحات الإنفاق
استفتاء: نظام التصويت العام، يمنح أصحاب المصلحة طويل الأمد تأثيرًا أكبر
عمل النظام بشكل جيد في السنوات الأولى، لكن مع نضجه، يحتاج إلى التطور المستمر لتحسين العيوب ومواكبة التقدم. على سبيل المثال، في "الحوكمة v1"، كانت جميع أوزان الاستفتاء متساوية، ويمكن التصويت على استفتاء واحد فقط في المرة الواحدة، وكانت فترة التصويت تستمر لأسابيع. أدى ذلك إلى ميل النظام للتفكير بعناية في عدد قليل جداً من المقترحات، بدلاً من النظر بشكل واسع في مقترحات متعددة. وبالتالي، نشأت "الحوكمة v2".
"الحوكمة v2" أو ما يعرف بـ "Gov2" غيرت طرق اتخاذ القرار اليومية، مما جعل تأثير الاستفتاءات أكثر اتساعًا ومرونة، وبالتالي زادت بشكل ملحوظ عدد القرارات الجماعية التي يمكن للنظام اتخاذها.
ستبدأ Gov2 على Kusama وتختبرها قبل أن تقترح نشرها على Polkadot. حاليًا، تم إطلاق Gov2 على شبكة Kusama.
سوف تتناول المحتويات التالية المبادئ الأساسية للحكومة في شبكة Polkadot. يساعد فهم جذور الحكومة v1 على فهم اتجاه النسخة الثانية بشكل أفضل. ستبرز هذه الاختلافات في المواضيع الفرعية المختلفة.
من المهم ملاحظة أنه في المرحلة الحالية، لا يزال الحوكمة بروتوكولًا يتطور باستمرار. مع تحديث الحوكمة v2، تم أيضًا وضع خطة الحوكمة v2.5.
مقدمة
بإيجاز، يجمع هذا الشبكة بين آليات جديدة متعددة، بما في ذلك دالة تحويل الحالة غير المحددة المخزنة على السلسلة ( المحددة بواسطة WebAssembly )، بالإضافة إلى آليات تصويت متعددة على السلسلة، مثل الاستفتاءات ذات العتبة المطلقة المتكيفة والتصويت بالموافقة الجماعية.
يجب أن تتم جميع التغييرات على الاتفاقية من خلال تصويت يعتمد على وزن الحقوق.
آلية
في الحوكمة v1، يدير حاملو الرموز النشطون والمجلس معًا قرارات ترقية الشبكة. سواء تم تقديم الاقتراح من قبل الجمهور أو المجلس، يجب أن يمر في النهاية عبر استفتاء شعبي، مع اتخاذ القرار بناءً على وزن المبلغ المضمون وقيمة الإيمان.
هناك عدة تغييرات في إدارة v2. تتمثل الطريقة التي تعكس الخصائص اللامركزية في النموذج الجديد للإدارة في:
نقل مسؤوليات المجلس إلى حاملي التوكن من خلال التصويت الديمقراطي
حل المجلس الحالي
يسمح للمستخدمين بتفويض حقوق التصويت لأعضاء المجتمع بطرق أكثر.
استفتاء
الاستفتاء هو خطة تصويت بسيطة وشاملة تعتمد على الرهانات. يحتوي كل استفتاء على اقتراح ذي صلة، يتم استخدامه في شكل استدعاءات وظائف الامتياز في وقت التشغيل ( بما في ذلك استدعاء set_code الأقوى، الذي يمكنه تبديل كود وقت التشغيل بالكامل ).
الاستفتاء هو حدث منفصل له فترة تصويت ثابتة. بعد انتهاء فترة التصويت وإحصاء بطاقات الاقتراع، إذا تم الموافقة عليها، سيتم استدعاء الدوال ذات الصلة. الاستفتاء دائماً ثنائي؛ خيارات التصويت يمكن أن تكون "موافقة" أو "معارضة" أو الامتناع عن التصويت بالكامل.
يمكن بدء الاستفتاءات في الحوكمة v1 بعدة طرق:
الاقتراحات المقدمة علنًا
الاقتراحات التي تم الموافقة عليها بأغلبية أو بالإجماع من المجلس
الاقتراح المقدم كجزء من تنفيذ الاستفتاء السابق
اقتراح عاجل مقدم من اللجنة الفنية وموافق عليه من قبل مجلس الإدارة
توجد فترة تأخير تنفيذ مناسبة لجميع الاستفتاءات. هذه هي الفترة الزمنية بين انتهاء الاستفتاء وتنفيذ الاقتراح فعليًا.
في Gov2، يمكن لأي شخص بدء استفتاء في أي وقت، دون حد لعدد المرات. يقدم Gov2 مفاهيم Origins( و Tracks) لمساعدة عملية معالجة بروتوكول الاستفتاء.
يمكن اعتبار Origin بمثابة موصوف لمستوى الامتياز المعطى. يحتاج المقترحون إلى اختيار Origin المناسب للطلب وفقًا لمتطلبات الاقتراح.
كل Origin مرتبط بفئة استفتاء، وكل فئة لديها Track. يوضح Track دورة حياة الاقتراح، وهو مستقل عن الفئات الأخرى. تتيح المسارات المستقلة المختلفة للشبكة تعديل ديناميكيات الاستفتاء وفقًا لمستويات الامتياز الضمنية.
على سبيل المثال، تأثير ترقية Runtime على النظام البيئي، يختلف عن الموافقة على المكافآت الحكومية، لذلك هناك حاجة إلى أصول مختلفة، حيث سيتم تحديد معدلات التصويت المختلفة، ومعدلات الموافقة، والودائع، وأقصر فترة تنفيذ مسبقًا.
( اقتراح استفتاء
استفتاء عام
يمكن لأي شخص اقتراح استفتاء من خلال إيداع الحد الأدنى من الرموز في فترة معينة. إذا وافق شخص ما، يمكنه إيداع نفس كمية الرموز للدلالة على الدعم.
هذا يسمى "التأييد". سيتم اختيار الاقتراح الذي يحصل على أعلى دعم من الرموز المرتبطة ليكون الاقتراح التالي في دورة التصويت. لاحظ أن هذا قد يختلف عن العدد المطلق للتأييد؛ على سبيل المثال، ثلاثة حسابات كل منها مرتبطة بـ 20 DOT ست "تتجاوز" عشرة حسابات كل منها مرتبطة بـ 1 DOT.
بمجرد تقديم الاقتراح ) للتصويت ###، سيتم تحرير الرموز المرتبطة.
بالنسبة للحوكمة v1، يمكن أن تحتوي قائمة الاقتراحات على ما يصل إلى 100 اقتراح عام.
في Gov2، بمجرد إنشاء الاستفتاء، يمكن للمجتمع التصويت على الفور. لكن هذا الاستفتاء ليس في حالة قابلة للإغلاق، أو حساب الأصوات، أو الحصول على الموافقة، أو التنفيذ النهائي. بدلاً من ذلك، يجب أن يستوفي الاستفتاء بعض المعايير للدخول في حالة "تقرير (Deciding)". قبل ذلك، لا يزال في حالة معلقة.
معايير الدخول في حالة Decided هي كما يلي:
مرت بفترة الاستيراد، وهي الوقت الذي يجب أن يمر قبل أن يُتخذ القرار بالبدء. يساعد ذلك في تقليل احتمالية "القرار المفاجئ"، حيث يمكن للجهات المهاجمة التي تتحكم في كمية كبيرة من حقوق التصويت أن تمرر الاقتراح مباشرة بعد تقديمه، دون إعطاء جميع الناخبين وقتًا كافيًا للتفكير والمشاركة.
يجب أن يكون هناك مساحة متبقية للقرار. جميع المسارات لديها قيود على عدد الاستفتاءات التي يمكن أن تقرر في نفس الوقت. قيود المسارات الأقوى أقل. على سبيل المثال، الحد على مستوى Root Origin هو 1، مما يعني أنه يمكن اتخاذ قرار واحد فقط بشأن اقتراح شديد الخطورة في كل مرة.
يجب دفع الوديعة المحددة. تكلفة إنشاء الاستفتاء منخفضة جدًا، حيث أن الوديعة تتضمن فقط قيمة التخزين على السلسلة المطلوبة للتتبع. لكن هناك خطر استنفاد المواقع المحدودة في قائمة الاستفتاءات عند مراجعة الاستفتاء واتخاذ القرار. إن المطالبة بإيداع أكبر ولكن قابل للاسترداد يساعد على تقليل الرسائل غير المرغوب فيها.
استفتاء المجلس (v1)
تمت الموافقة بالإجماع من قبل المجلس - عندما يوافق جميع أعضاء المجلس على اقتراح ما، يمكن نقله إلى استفتاء. سيؤدي هذا الاستفتاء إلى انحراف عن معدل التصويت السلبي ( أي كلما قل عدد الأصوات المؤيدة، كلما قل العدد المطلوب للموافقة ).
تم التصويت بالموافقة من قبل أغلبية المجلس - عندما توافق أغلبية بسيطة من أعضاء المجلس، يمكن أيضًا التصويت على الاستفتاء، ولكن سيكون نظام التصويت هو نظام الأغلبية، حيث يفوز الطرف الذي يحصل على 51% من الأصوات (.
لا يمكن أن يكون هناك سوى استفتاء واحد صالح في أي وقت، ما لم يكن هناك استفتاء طارئ جارٍ.
جدول التصويت
في حوكمة v1، يُفترض أنه يوجد اقتراح واحد على الأقل في الصف، وسيتم إجراء استفتاء جديد كل 28 يومًا. هناك صف للاقتراحات التي وافق عليها المجلس، وهناك أيضًا صف للاقتراحات المقدمة من الجمهور. سيتم إجراء الاستفتاء بالتناوب بين الاقتراحات التي تحتل المراتب العليا في الصفين.
تحدد الاقتراحات ذات الترتيب الأعلى بناءً على كمية الرهان المرتبطة بها. إذا حاولت قائمة الانتظار الحالية إنشاء استفتاء بدون اقتراح ) وكانت قائمة الانتظار فارغة (، وإذا كانت هناك قائمة أخرى تحتوي على اقتراحات في الانتظار، فسيتم إدخال الاقتراح الأعلى ترتيبًا في تلك القائمة في الاستفتاء.
لا يمكن التصويت على عدة استفتاءات في نفس الفترة، باستثناء الاستفتاءات الطارئة. الاستفتاء الطارئ الذي يحدث في نفس الوقت مع الاستفتاءات العادية هو الحالة الوحيدة التي يمكن فيها التصويت على عدة استفتاءات في نفس الوقت.
عندما يتم الموافقة على الاقتراح، تشارك إدارة v2 نفس فترة التأهيل البالغة 28 يومًا. إذا لم يتم الموافقة عليه بحلول نهاية هذه المرحلة، فسيتم رفض الاقتراح تلقائيًا.
استفتاء التصويت) الحوكمةv2(
في الحوكمة v2، إذا استوفى الاقتراح متطلبات معدل الموافقة ومعدل الدعم، فسيتم الموافقة على الاقتراح، مما يعني إزالة نظام التحيز الجماعي التكيفي.
معدل الموافقة ) يتم تعريفه على أنه وزن تصويت الموافقة ( بعد تعديل الإيمان ) من إجمالي وزن التصويت ( الذي يتضمن حصة الموافقة والرفض ).
معدل الدعم ( Support ) هو العدد الإجمالي للأصوات المعتمدة ( تجاهل تعديل القناعة ) بالمقارنة مع العدد الإجمالي للأصوات التي قد تتم في النظام.
يجب أن تستوفي هذه المعايير في أقصر وقت ممكن خلال فترة التأكيد. تختلف المسارات المختلفة في فترة التأكيد ومتطلبات الموافقة والدعم. يمكن الآن تكوين ذلك من خلال كمية الدعم المطلوبة والإجمالي المعتمد. بالنسبة للاقتراحات التي تستخدم مصادر منخفضة الامتياز، فإن خفض نسبة التصويت المطلوبة إلى أرقام أكثر واقعية في وقت مبكر يكون أكثر عقلانية مقارنة بالاقتراحات التي تستخدم فئات عالية الامتياز ( مثل Root). يمكن أن تتطلب الدورات ذات الأهمية السياسية الكبيرة موافقة أعلى في وقت مبكر لتجنب النزاعات.
في Gov2، سيتم اعتبار المقترحات التي لم يتم الموافقة عليها بعد 28 يومًا بمثابة رفض ضمني، وسيتم إعادة إيداع القرار. إذا بقي الاقتراح مقبولًا قبل انتهاء فترة التأكيد، فسيتم اعتباره معتمدًا، وسيتم التخطيط لتنفيذه من مصدر الاقتراح بعد فترة الصياغة. يتم تحديد فترة الصياغة عند اقتراح التصويت الشعبي، ولكنها تخضع أيضًا للحد الأدنى القائم على المسار. ستفرض المسارات الأكثر قوة فترة تنفيذ أطول لضمان أن يكون لدى الشبكة الوقت الكافي للاستعداد للتغييرات المحتملة التي قد يجلبها الاقتراح.
الإغلاق الطوعي
تستخدم Polkadot مفهوم "الإغلاق الطوعي"، مما يسمح لحاملي الرموز بزيادة حقوق التصويت من خلال إعلان مدة رغبتهم في إغلاق الرموز، لذلك، سيتم حساب عدد أصوات كل حامل رمز باستخدام الصيغة التالية:
عدد الأصوات = الرمز * معامل الاقتناع
عدد فترات القفل يتضاعف في كل جولة، وسيزيد مضاعف الاقتناع مضاعف التصويت بمقدار واحد.
عدد مضاعفات تصويت فترة القفل 00.111224384165326
تم ضبط الحد الأقصى لعدد مرات "التأمين" على 6( فترة تأمين إجمالية 32، حيث تعادل فترة التأمين 28 يومًا. يُسمح بالتأمين فقط، على سبيل المثال، لا يُسمح بتأمين 24 دورة وزيادة الإدانة بمقدار 5.5.
عندما يتم قفل الرمز، لا يزال يمكن استخدامه للتصويت والتخزين؛ فقط يتم حظر نقل هذه الرموز إلى حساب آخر.
تُحتسب الأصوات دائمًا في نفس الوقت، أي عند انتهاء فترة التصويت. وهذا لا يتأثر بفترة قفل الرمز.
تحيز المجموعة التكيفي
تم استخدام انحراف المجموعة التكيفي لفترة أطول في الحوكمة v2 ، وتم استبداله بنظام الموافقة / الدعم.
) المجلس
في الحوكمة v1، يتم تمثيل أصحاب المصلحة السلبيين على بولكادوت من قبل هيئة إدارية تُعرف باسم "المجلس". المجلس هو كيان على السلسلة يتكون من عدة مشاركين، يمثل كل مشارك حساباً على السلسلة. في بولكادوت، يتكون المجلس حالياً من أعضاء.
بجانب السيطرة على الخزانة، تتولى الهيئة أيضاً ثلاثة مهام رئيسية في الحوكمة:
استفتاء حكيم للعرض
إلغاء الاستفتاءات الخطرة أو الضارة
لجنة تقنية الانتخابات
في الحوكمة v2، هناك حاجة إلى استراتيجيات بديلة لتحل محل مهام مجلس الإدارة السابقة كوكالة تفويض للناخبين، لتعويض حقيقة أن العديد من الأشخاص اختاروا عدم المشاركة في الحوكمة اليومية. يعتمد Gov2 على وظيفة تفويض التصويت في v1، حيث يمكن للناخبين اختيار تفويض حقوق التصويت لناخب آخر في النظام. يتم تحقيق ذلك من خلال تحسين وظيفة تُعرف بتفويض الأدوار المتعددة، حيث يمكن للناخبين تعيين ممثلين مختلفين لكل نوع من أنواع الاستفتاءات في النظام. لذا، يمكن للناخبين تفويض كيان معين لإدارة نوع استفتاء له تأثيرات غير كبيرة، واختيار ممثل مختلف لإدارة نوع آخر له عواقب أكثر أهمية، ولا يزال يحتفظون بحق التصويت الكامل على أي فئات متبقية.
( إلغاء الاستفتاء
في إدارة v1، إذا وافق المجلس الفني بالإجماع على إلغاء الاقتراح، أو إذا تم تفعيل هذه الوظيفة من قبل مصدر Root ) مثل sudo (، يمكن إلغاء الاقتراح. سيتم تدمير الوديعة الخاصة بالاقتراح الملغي.
علاوة على ذلك، يمكن لمجلس الإدارة إلغاء الاستفتاء بأغلبية ثلثي الأصوات. إذا تم اكتشاف مشكلة في اقتراح الاستفتاء في وقت متأخر )، مثل وجود خطأ في الكود البرمجي الذي سيتم تنفيذه في الاقتراح ###، فقد يكون ذلك بمثابة الملاذ الأخير.
إذا كانت النزاعات الملغاة كبيرة بما يكفي بحيث لا يمكن للمجلس الحصول على أغلبية الثلثين، فسيتم تحديد مصير الاقتراح من قبل أصحاب المصلحة بشكل مشترك.
في الحوكمة v2، هناك عملية خاصة تسمى Cancelation### لإلغاء ( تُستخدم للتدخل في الاقتراحات التي تم التصويت عليها بالفعل. ستقوم هذه العملية برفض الاستفتاء الجاري على الفور، بغض النظر عن حالته. هناك أيضًا قاعدة تنص على أنه إذا كان الاقتراح ضارًا أو يحتوي على معلومات مزعجة، فيجب ضمان مصادرة وديعة المقترح.
الإلغاء هو في حد ذاته عملية حوكمة، يجب أن يتم تنفيذها من خلال تصويت الشبكة. يرتبط الإلغاء بأصله ومساره الخاص، ولديه فترة إدخال قصيرة جدًا ومنحنى معدل الموافقة/الدعم، حيث ينخفض العتبة قليلاً بشكل أسرع، لأنه يتم استدعاؤه فقط في حالات الطوارئ.
) لجنة التكنولوجيا
في الحوكمة v1، يعد مجلس التكنولوجيا (TC) واحدًا من ثلاث غرف لحوكمة Kusama(، والغرفتان الأخريان هما المجلس والاستفتاء). يتكون TC من فرق نجحت في تنفيذ أو تعريف Polkadot runtime أو Polkadot Host. يمكن إضافة أو حذف الفرق في TC من خلال تصويت أغلبية بسيطة من المجلس.
الغرض من TC هو منع الاستفتاءات الخبيثة، وتنفيذ إصلاحات الأخطاء، وعكس التحديثات الخاطئة runtime أو إضافة ميزات جديدة تم اختبارها في المعارك. يحق لـ TC استخدام منصة الديمقراطية لتسريع الاقتراحات، وهو الوحيد القادر على
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
بولكادوت الحوكمة V2: فصل جديد من القرارات اللامركزية
الحوكمة V2
تعتمد بولكادوت على آلية حوكمة معقدة، مما يسمح لها بالتطور باستمرار وفقًا لاحتياجات أصحاب المصلحة. هدفها هو ضمان أن تتمكن الغالبية العظمى من المساهمين دائمًا من التحكم في الشبكة.
قد تتغير محتويات هذه الوثيقة. لقد مرت بروتوكولات الحوكمة بعدة مراحل من التحديث (v1 و v2)، وسيكون هناك المزيد من التغييرات في المستقبل (v2.5).
يتكون أول نظام للحكم اللامركزي في بولكادوت (v1) من ثلاثة مكونات رئيسية:
عمل النظام بشكل جيد في السنوات الأولى، لكن مع نضجه، يحتاج إلى التطور المستمر لتحسين العيوب ومواكبة التقدم. على سبيل المثال، في "الحوكمة v1"، كانت جميع أوزان الاستفتاء متساوية، ويمكن التصويت على استفتاء واحد فقط في المرة الواحدة، وكانت فترة التصويت تستمر لأسابيع. أدى ذلك إلى ميل النظام للتفكير بعناية في عدد قليل جداً من المقترحات، بدلاً من النظر بشكل واسع في مقترحات متعددة. وبالتالي، نشأت "الحوكمة v2".
"الحوكمة v2" أو ما يعرف بـ "Gov2" غيرت طرق اتخاذ القرار اليومية، مما جعل تأثير الاستفتاءات أكثر اتساعًا ومرونة، وبالتالي زادت بشكل ملحوظ عدد القرارات الجماعية التي يمكن للنظام اتخاذها.
ستبدأ Gov2 على Kusama وتختبرها قبل أن تقترح نشرها على Polkadot. حاليًا، تم إطلاق Gov2 على شبكة Kusama.
سوف تتناول المحتويات التالية المبادئ الأساسية للحكومة في شبكة Polkadot. يساعد فهم جذور الحكومة v1 على فهم اتجاه النسخة الثانية بشكل أفضل. ستبرز هذه الاختلافات في المواضيع الفرعية المختلفة.
من المهم ملاحظة أنه في المرحلة الحالية، لا يزال الحوكمة بروتوكولًا يتطور باستمرار. مع تحديث الحوكمة v2، تم أيضًا وضع خطة الحوكمة v2.5.
مقدمة
بإيجاز، يجمع هذا الشبكة بين آليات جديدة متعددة، بما في ذلك دالة تحويل الحالة غير المحددة المخزنة على السلسلة ( المحددة بواسطة WebAssembly )، بالإضافة إلى آليات تصويت متعددة على السلسلة، مثل الاستفتاءات ذات العتبة المطلقة المتكيفة والتصويت بالموافقة الجماعية.
يجب أن تتم جميع التغييرات على الاتفاقية من خلال تصويت يعتمد على وزن الحقوق.
آلية
في الحوكمة v1، يدير حاملو الرموز النشطون والمجلس معًا قرارات ترقية الشبكة. سواء تم تقديم الاقتراح من قبل الجمهور أو المجلس، يجب أن يمر في النهاية عبر استفتاء شعبي، مع اتخاذ القرار بناءً على وزن المبلغ المضمون وقيمة الإيمان.
هناك عدة تغييرات في إدارة v2. تتمثل الطريقة التي تعكس الخصائص اللامركزية في النموذج الجديد للإدارة في:
استفتاء
الاستفتاء هو خطة تصويت بسيطة وشاملة تعتمد على الرهانات. يحتوي كل استفتاء على اقتراح ذي صلة، يتم استخدامه في شكل استدعاءات وظائف الامتياز في وقت التشغيل ( بما في ذلك استدعاء set_code الأقوى، الذي يمكنه تبديل كود وقت التشغيل بالكامل ).
الاستفتاء هو حدث منفصل له فترة تصويت ثابتة. بعد انتهاء فترة التصويت وإحصاء بطاقات الاقتراع، إذا تم الموافقة عليها، سيتم استدعاء الدوال ذات الصلة. الاستفتاء دائماً ثنائي؛ خيارات التصويت يمكن أن تكون "موافقة" أو "معارضة" أو الامتناع عن التصويت بالكامل.
يمكن بدء الاستفتاءات في الحوكمة v1 بعدة طرق:
توجد فترة تأخير تنفيذ مناسبة لجميع الاستفتاءات. هذه هي الفترة الزمنية بين انتهاء الاستفتاء وتنفيذ الاقتراح فعليًا.
في Gov2، يمكن لأي شخص بدء استفتاء في أي وقت، دون حد لعدد المرات. يقدم Gov2 مفاهيم Origins( و Tracks) لمساعدة عملية معالجة بروتوكول الاستفتاء.
يمكن اعتبار Origin بمثابة موصوف لمستوى الامتياز المعطى. يحتاج المقترحون إلى اختيار Origin المناسب للطلب وفقًا لمتطلبات الاقتراح.
كل Origin مرتبط بفئة استفتاء، وكل فئة لديها Track. يوضح Track دورة حياة الاقتراح، وهو مستقل عن الفئات الأخرى. تتيح المسارات المستقلة المختلفة للشبكة تعديل ديناميكيات الاستفتاء وفقًا لمستويات الامتياز الضمنية.
على سبيل المثال، تأثير ترقية Runtime على النظام البيئي، يختلف عن الموافقة على المكافآت الحكومية، لذلك هناك حاجة إلى أصول مختلفة، حيث سيتم تحديد معدلات التصويت المختلفة، ومعدلات الموافقة، والودائع، وأقصر فترة تنفيذ مسبقًا.
( اقتراح استفتاء
استفتاء عام
يمكن لأي شخص اقتراح استفتاء من خلال إيداع الحد الأدنى من الرموز في فترة معينة. إذا وافق شخص ما، يمكنه إيداع نفس كمية الرموز للدلالة على الدعم.
هذا يسمى "التأييد". سيتم اختيار الاقتراح الذي يحصل على أعلى دعم من الرموز المرتبطة ليكون الاقتراح التالي في دورة التصويت. لاحظ أن هذا قد يختلف عن العدد المطلق للتأييد؛ على سبيل المثال، ثلاثة حسابات كل منها مرتبطة بـ 20 DOT ست "تتجاوز" عشرة حسابات كل منها مرتبطة بـ 1 DOT.
بمجرد تقديم الاقتراح ) للتصويت ###، سيتم تحرير الرموز المرتبطة.
بالنسبة للحوكمة v1، يمكن أن تحتوي قائمة الاقتراحات على ما يصل إلى 100 اقتراح عام.
في Gov2، بمجرد إنشاء الاستفتاء، يمكن للمجتمع التصويت على الفور. لكن هذا الاستفتاء ليس في حالة قابلة للإغلاق، أو حساب الأصوات، أو الحصول على الموافقة، أو التنفيذ النهائي. بدلاً من ذلك، يجب أن يستوفي الاستفتاء بعض المعايير للدخول في حالة "تقرير (Deciding)". قبل ذلك، لا يزال في حالة معلقة.
معايير الدخول في حالة Decided هي كما يلي:
مرت بفترة الاستيراد، وهي الوقت الذي يجب أن يمر قبل أن يُتخذ القرار بالبدء. يساعد ذلك في تقليل احتمالية "القرار المفاجئ"، حيث يمكن للجهات المهاجمة التي تتحكم في كمية كبيرة من حقوق التصويت أن تمرر الاقتراح مباشرة بعد تقديمه، دون إعطاء جميع الناخبين وقتًا كافيًا للتفكير والمشاركة.
يجب أن يكون هناك مساحة متبقية للقرار. جميع المسارات لديها قيود على عدد الاستفتاءات التي يمكن أن تقرر في نفس الوقت. قيود المسارات الأقوى أقل. على سبيل المثال، الحد على مستوى Root Origin هو 1، مما يعني أنه يمكن اتخاذ قرار واحد فقط بشأن اقتراح شديد الخطورة في كل مرة.
يجب دفع الوديعة المحددة. تكلفة إنشاء الاستفتاء منخفضة جدًا، حيث أن الوديعة تتضمن فقط قيمة التخزين على السلسلة المطلوبة للتتبع. لكن هناك خطر استنفاد المواقع المحدودة في قائمة الاستفتاءات عند مراجعة الاستفتاء واتخاذ القرار. إن المطالبة بإيداع أكبر ولكن قابل للاسترداد يساعد على تقليل الرسائل غير المرغوب فيها.
استفتاء المجلس (v1)
تمت الموافقة بالإجماع من قبل المجلس - عندما يوافق جميع أعضاء المجلس على اقتراح ما، يمكن نقله إلى استفتاء. سيؤدي هذا الاستفتاء إلى انحراف عن معدل التصويت السلبي ( أي كلما قل عدد الأصوات المؤيدة، كلما قل العدد المطلوب للموافقة ).
تم التصويت بالموافقة من قبل أغلبية المجلس - عندما توافق أغلبية بسيطة من أعضاء المجلس، يمكن أيضًا التصويت على الاستفتاء، ولكن سيكون نظام التصويت هو نظام الأغلبية، حيث يفوز الطرف الذي يحصل على 51% من الأصوات (.
لا يمكن أن يكون هناك سوى استفتاء واحد صالح في أي وقت، ما لم يكن هناك استفتاء طارئ جارٍ.
جدول التصويت
في حوكمة v1، يُفترض أنه يوجد اقتراح واحد على الأقل في الصف، وسيتم إجراء استفتاء جديد كل 28 يومًا. هناك صف للاقتراحات التي وافق عليها المجلس، وهناك أيضًا صف للاقتراحات المقدمة من الجمهور. سيتم إجراء الاستفتاء بالتناوب بين الاقتراحات التي تحتل المراتب العليا في الصفين.
تحدد الاقتراحات ذات الترتيب الأعلى بناءً على كمية الرهان المرتبطة بها. إذا حاولت قائمة الانتظار الحالية إنشاء استفتاء بدون اقتراح ) وكانت قائمة الانتظار فارغة (، وإذا كانت هناك قائمة أخرى تحتوي على اقتراحات في الانتظار، فسيتم إدخال الاقتراح الأعلى ترتيبًا في تلك القائمة في الاستفتاء.
لا يمكن التصويت على عدة استفتاءات في نفس الفترة، باستثناء الاستفتاءات الطارئة. الاستفتاء الطارئ الذي يحدث في نفس الوقت مع الاستفتاءات العادية هو الحالة الوحيدة التي يمكن فيها التصويت على عدة استفتاءات في نفس الوقت.
عندما يتم الموافقة على الاقتراح، تشارك إدارة v2 نفس فترة التأهيل البالغة 28 يومًا. إذا لم يتم الموافقة عليه بحلول نهاية هذه المرحلة، فسيتم رفض الاقتراح تلقائيًا.
استفتاء التصويت) الحوكمةv2(
في الحوكمة v2، إذا استوفى الاقتراح متطلبات معدل الموافقة ومعدل الدعم، فسيتم الموافقة على الاقتراح، مما يعني إزالة نظام التحيز الجماعي التكيفي.
معدل الموافقة ) يتم تعريفه على أنه وزن تصويت الموافقة ( بعد تعديل الإيمان ) من إجمالي وزن التصويت ( الذي يتضمن حصة الموافقة والرفض ).
معدل الدعم ( Support ) هو العدد الإجمالي للأصوات المعتمدة ( تجاهل تعديل القناعة ) بالمقارنة مع العدد الإجمالي للأصوات التي قد تتم في النظام.
يجب أن تستوفي هذه المعايير في أقصر وقت ممكن خلال فترة التأكيد. تختلف المسارات المختلفة في فترة التأكيد ومتطلبات الموافقة والدعم. يمكن الآن تكوين ذلك من خلال كمية الدعم المطلوبة والإجمالي المعتمد. بالنسبة للاقتراحات التي تستخدم مصادر منخفضة الامتياز، فإن خفض نسبة التصويت المطلوبة إلى أرقام أكثر واقعية في وقت مبكر يكون أكثر عقلانية مقارنة بالاقتراحات التي تستخدم فئات عالية الامتياز ( مثل Root). يمكن أن تتطلب الدورات ذات الأهمية السياسية الكبيرة موافقة أعلى في وقت مبكر لتجنب النزاعات.
في Gov2، سيتم اعتبار المقترحات التي لم يتم الموافقة عليها بعد 28 يومًا بمثابة رفض ضمني، وسيتم إعادة إيداع القرار. إذا بقي الاقتراح مقبولًا قبل انتهاء فترة التأكيد، فسيتم اعتباره معتمدًا، وسيتم التخطيط لتنفيذه من مصدر الاقتراح بعد فترة الصياغة. يتم تحديد فترة الصياغة عند اقتراح التصويت الشعبي، ولكنها تخضع أيضًا للحد الأدنى القائم على المسار. ستفرض المسارات الأكثر قوة فترة تنفيذ أطول لضمان أن يكون لدى الشبكة الوقت الكافي للاستعداد للتغييرات المحتملة التي قد يجلبها الاقتراح.
الإغلاق الطوعي
تستخدم Polkadot مفهوم "الإغلاق الطوعي"، مما يسمح لحاملي الرموز بزيادة حقوق التصويت من خلال إعلان مدة رغبتهم في إغلاق الرموز، لذلك، سيتم حساب عدد أصوات كل حامل رمز باستخدام الصيغة التالية:
عدد الأصوات = الرمز * معامل الاقتناع
عدد فترات القفل يتضاعف في كل جولة، وسيزيد مضاعف الاقتناع مضاعف التصويت بمقدار واحد.
عدد مضاعفات تصويت فترة القفل 00.111224384165326
تم ضبط الحد الأقصى لعدد مرات "التأمين" على 6( فترة تأمين إجمالية 32، حيث تعادل فترة التأمين 28 يومًا. يُسمح بالتأمين فقط، على سبيل المثال، لا يُسمح بتأمين 24 دورة وزيادة الإدانة بمقدار 5.5.
عندما يتم قفل الرمز، لا يزال يمكن استخدامه للتصويت والتخزين؛ فقط يتم حظر نقل هذه الرموز إلى حساب آخر.
تُحتسب الأصوات دائمًا في نفس الوقت، أي عند انتهاء فترة التصويت. وهذا لا يتأثر بفترة قفل الرمز.
تحيز المجموعة التكيفي
تم استخدام انحراف المجموعة التكيفي لفترة أطول في الحوكمة v2 ، وتم استبداله بنظام الموافقة / الدعم.
) المجلس
في الحوكمة v1، يتم تمثيل أصحاب المصلحة السلبيين على بولكادوت من قبل هيئة إدارية تُعرف باسم "المجلس". المجلس هو كيان على السلسلة يتكون من عدة مشاركين، يمثل كل مشارك حساباً على السلسلة. في بولكادوت، يتكون المجلس حالياً من أعضاء.
بجانب السيطرة على الخزانة، تتولى الهيئة أيضاً ثلاثة مهام رئيسية في الحوكمة:
في الحوكمة v2، هناك حاجة إلى استراتيجيات بديلة لتحل محل مهام مجلس الإدارة السابقة كوكالة تفويض للناخبين، لتعويض حقيقة أن العديد من الأشخاص اختاروا عدم المشاركة في الحوكمة اليومية. يعتمد Gov2 على وظيفة تفويض التصويت في v1، حيث يمكن للناخبين اختيار تفويض حقوق التصويت لناخب آخر في النظام. يتم تحقيق ذلك من خلال تحسين وظيفة تُعرف بتفويض الأدوار المتعددة، حيث يمكن للناخبين تعيين ممثلين مختلفين لكل نوع من أنواع الاستفتاءات في النظام. لذا، يمكن للناخبين تفويض كيان معين لإدارة نوع استفتاء له تأثيرات غير كبيرة، واختيار ممثل مختلف لإدارة نوع آخر له عواقب أكثر أهمية، ولا يزال يحتفظون بحق التصويت الكامل على أي فئات متبقية.
( إلغاء الاستفتاء
في إدارة v1، إذا وافق المجلس الفني بالإجماع على إلغاء الاقتراح، أو إذا تم تفعيل هذه الوظيفة من قبل مصدر Root ) مثل sudo (، يمكن إلغاء الاقتراح. سيتم تدمير الوديعة الخاصة بالاقتراح الملغي.
علاوة على ذلك، يمكن لمجلس الإدارة إلغاء الاستفتاء بأغلبية ثلثي الأصوات. إذا تم اكتشاف مشكلة في اقتراح الاستفتاء في وقت متأخر )، مثل وجود خطأ في الكود البرمجي الذي سيتم تنفيذه في الاقتراح ###، فقد يكون ذلك بمثابة الملاذ الأخير.
إذا كانت النزاعات الملغاة كبيرة بما يكفي بحيث لا يمكن للمجلس الحصول على أغلبية الثلثين، فسيتم تحديد مصير الاقتراح من قبل أصحاب المصلحة بشكل مشترك.
في الحوكمة v2، هناك عملية خاصة تسمى Cancelation### لإلغاء ( تُستخدم للتدخل في الاقتراحات التي تم التصويت عليها بالفعل. ستقوم هذه العملية برفض الاستفتاء الجاري على الفور، بغض النظر عن حالته. هناك أيضًا قاعدة تنص على أنه إذا كان الاقتراح ضارًا أو يحتوي على معلومات مزعجة، فيجب ضمان مصادرة وديعة المقترح.
الإلغاء هو في حد ذاته عملية حوكمة، يجب أن يتم تنفيذها من خلال تصويت الشبكة. يرتبط الإلغاء بأصله ومساره الخاص، ولديه فترة إدخال قصيرة جدًا ومنحنى معدل الموافقة/الدعم، حيث ينخفض العتبة قليلاً بشكل أسرع، لأنه يتم استدعاؤه فقط في حالات الطوارئ.
) لجنة التكنولوجيا
في الحوكمة v1، يعد مجلس التكنولوجيا (TC) واحدًا من ثلاث غرف لحوكمة Kusama(، والغرفتان الأخريان هما المجلس والاستفتاء). يتكون TC من فرق نجحت في تنفيذ أو تعريف Polkadot runtime أو Polkadot Host. يمكن إضافة أو حذف الفرق في TC من خلال تصويت أغلبية بسيطة من المجلس.
الغرض من TC هو منع الاستفتاءات الخبيثة، وتنفيذ إصلاحات الأخطاء، وعكس التحديثات الخاطئة runtime أو إضافة ميزات جديدة تم اختبارها في المعارك. يحق لـ TC استخدام منصة الديمقراطية لتسريع الاقتراحات، وهو الوحيد القادر على