الحوكمة المزدوجة لـ LDo+Steth (تابع)

متوسط12/27/2023, 9:21:07 AM
تقدم هذه المقالة تحديث نموذج حوكمة مشروع Lido، وتشرح PAP والقضايا ذات الصلة، وتحلل كيفية تجاوز مجرد التصويت على رمز الحوكمة.

هذا هو استمرار الخيط الأولي حول الحوكمة المزدوجة 18. يحتوي الموضوع المرتبط على سياق مهم، لذا يرجى قراءته إذا كان لديك الوقت.

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

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

المشكلة

حاليًا، يتم التحكم في رمز بروتوكول Lido ومعلماته بواسطة Lido DAO عبر التصويت على رمز LDO. يأخذ البروتوكول رسومًا بنسبة 5٪ من مكافآت التخزين ويوجهها إلى خزانة DAO (يتم توزيع 5٪ أخرى على مشغلي العقدة المشاركين في البروتوكول).

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

يمكن تعميم ذلك كمشكلة وكيل رئيسي (PAP) بين DAO (الوكيل) ومستخدمي البروتوكول (الرئيسي). المشكلة موجودة لأن حاملي LDO ليس لديهم نفس الحوافز التي يتمتع بها المستخدمون.

علاوة على ذلك، كما يوضح فيتاليك في مقالته بعنوان « الانتقال إلى ما بعد التصويت على العملات 9 »، تتفاقم PAP بسبب حقيقة أن الاهتمام الاقتصادي بإيرادات البروتوكول يمكن فصله عن سلطة الحوكمة: يمكن للمرء أن يحرف حوافز حاملي رمز DAO عن طريق رشوتهم أو اقتراض رمز تصويت DAO في السوق المفتوحة لمحاولة الحصول على قوة تصويت كافية لدفع التغيير الذي يتعارض مع مصالح كل من DAO ومستخدمي البروتوكول.

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

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

العامل الأول هو تفاصيل كيفية عمل Ethereum PoS. لإلغاء اختبار ETH من المدقق، يتعين على المرء الانتظار حتى يتم الخروج من المدقق بالكامل، وتتم معالجة جميع مخارج مدقق Ethereum من خلال قائمة انتظار واحدة ذات إنتاجية محدودة. هذا يعني أن الوقت المطلوب لمغادرة البروتوكول يعتمد على عوامل خارجية خارج البروتوكول ويمكن أن يختلف حسب الحجم. وهذا بدوره يعني أن فرض قفل زمني ثابت على قرارات DAO لا يمكن أن يضمن أن أي مستخدم لديه الوقت الكافي لمغادرة البروتوكول قبل أن يطبق DAO تغييرًا ليس في اهتمامات المستخدم.

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

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

أنشأت Lido DAO عددًا من بروتوكولات الحوكمة للحد من عدم تناسق المعلومات (على سبيل المثال إطار GOOSE، ومجموعة الحوكمة الفرعية لمشغلي العقدة، وإطار LIP، والالتزام بالحد الأدنى لعدد عمليات التدقيق لأي تغيير في كود الشبكة الرئيسية) ولكنها كلها اتفاقيات الطبقة الاجتماعية بين حاملي LDO الحاليين وبالتالي لا يمكن حمايتها من هجوم خارجي على DAO.

نحو الحل

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

يعد تقليل نطاق الحوكمة تدريجيًا أمرًا يراه المساهمون في البروتوكول ضرورة في السنوات القادمة. ومع ذلك، حتى يتم تعديل مواصفات Ethereum، لا يمكن تقليل إمكانية ترقية الكود إلا إلى حد معين (على سبيل المثال. انظر EIP-7002 5، EIP-7251(6). بالإضافة إلى ذلك، يجب التحقق رسميًا من أي كود غير قابل للتغيير على مستوى البايت كود لاستبعاد احتمال حدوث خطأ في المحول البرمجي ينتج ثغرة أمنية غير قابلة للإصلاح.

هناك أيضًا طبقة قابلية الاستبدال للبروتوكول التي تعمل كمحرك لتقييم المخاطر/المكافآت وتوزع ETH بين مجموعات فرعية مختلفة من المدققين بطريقة توازن العائد ومخاطر مجموعة المدققين الناتجة. تشمل المخاطر هنا المخاطر الخلفية التي تخلقها مجموعة المدققين لشبكة Ethereum، على سبيل المثال الرقابة ومخاطر القطع المرتبطة بها. هناك بحث مستمر (انظر هذا التقرير 6 للحصول على أحدث نسخة) حول ما إذا كان يمكن تقدير هذه المخاطر بواسطة البروتوكول بمساعدة أداة أوراكل غير الموثوقة التي توفر المعلومات المطلوبة على السلسلة ولكنها محاولة طويلة الأجل وليس من الواضح بعد كيف يمكن تحقيق النتيجة المرجوة عمليًا. حتى يتم تنفيذ مثل هذه الآلية غير الموثوقة للبروتوكول، يجب أن يكون هناك بعض الحوكمة في طبقة قابلية الاستبدال.

يتمثل أحد مجالات البحث المحتملة الأخرى في البحث عن طرق لإدخال اشتراك صريح في إصدارات التعليمات البرمجية الجديدة ومجموعة المعلمات لحاملي StETH وعمليات الدمج. ليس من الواضح بعد ما إذا كان يمكن القيام بذلك دون كسر قابلية استبدال LST وتجزئة السيولة الناتجة والتي، نظرًا لأن السيولة هي أحد العوامل الرئيسية التي تدفع المستخدمين إلى LSTs، من شأنها أن تدمر القدرة التنافسية للبروتوكول ضد مزودي تخزين السيولة اللامركزية والمركزية الآخرين. ومع ذلك، فهو اتجاه بحثي مثير للاهتمام.

الآن بعد أن أثبتنا أن البروتوكول يجب أن يتعايش مع نوع من الحوكمة على الأقل على المدى المتوسط، دعونا نرى كيف يمكننا تقليل < a href= " https://notes.ethereum.org/@mikeneuder/magnitude-and-direction " > المخاطر التي تخلقها هذه الحوكمة 1.

حوكمة مزدوجة

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

هذا هو المكان الذي نصل فيه إلى تصميم الحوكمة المزدوجة المقترح. تهدف إلى التحسينات التالية:

  1. امنح أصحاب المصلحة طريقة للإشارة بمصداقية إلى عدم موافقتهم مع DAO والالتزام بمغادرة البروتوكول إذا لم تتعاون DAO في حل تعارض الحوافز.
  2. توفير جهاز تفاوض بين المساهمين و DAO.
  3. قدم قفلًا زمنيًا ديناميكيًا ممتدًا لقرارات DAO التي يمكن تشغيلها من قبل أقلية نشطة من المساهمين وإطالة أمدها مع مشاركة المزيد من أصحاب المصلحة.
  4. قم بتحسين كفاءة التصويت بالقدم من خلال السماح للمخزنين بالخروج من البروتوكول دون الخضوع لقرارات DAO الجديدة والمعلقة.

يمكن العثور على نظرة عامة على تصميم الآلية المقترحة وبعض الأفكار للبحث المستقبلي حول تقليل مخاطر الحوكمة في هذه المذكرة: < a href= " https://hackmd.io/@skozin/r17mlW2la " " > https://hackmd.io/@skozin/r17mlW2la 37.

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

هناك اتجاه آخر للبحث المستقبلي وهو استكشاف الحوكمة غير الرمزية والهجينة 2.

الخطوات التالية

من هنا، يجب أن تحدث العديد من الأشياء قبل الانتهاء من التصميم، مما يؤدي إلى اقتراح تحسين Lido (LIP) الأكثر رسمية والذي سيتم تقديمه للتصويت على DAO ووثيقة سجل القرار المعماري (ADR) المرتبطة به:

  1. تقييم متانة الآلية المقترحة من خلال نمذجة السيناريو والهجوم.
  2. تقييم التطبيق العملي للآلية من خلال وضع نماذج أولية للشفرة.
  3. جمع ملاحظات المجتمع.

يهدف هذا الموضوع إلى تحقيق 3 بينما يعمل المساهمون في البروتوكول على 1 و 2 (كلاهما قيد التقدم حاليًا) لذا فإن أي ملاحظات تحظى بتقدير كبير!

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

إخلاء المسؤولية:

  1. تمت إعادة طباعة هذه المقالة من [lido]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [skozin]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسيتعاملون معها على الفور.
  2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
  3. يقوم فريق Gate Learn بترجمة المقالة إلى لغات أخرى. ما لم يُذكر، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.

الحوكمة المزدوجة لـ LDo+Steth (تابع)

متوسط12/27/2023, 9:21:07 AM
تقدم هذه المقالة تحديث نموذج حوكمة مشروع Lido، وتشرح PAP والقضايا ذات الصلة، وتحلل كيفية تجاوز مجرد التصويت على رمز الحوكمة.

هذا هو استمرار الخيط الأولي حول الحوكمة المزدوجة 18. يحتوي الموضوع المرتبط على سياق مهم، لذا يرجى قراءته إذا كان لديك الوقت.

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

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

المشكلة

حاليًا، يتم التحكم في رمز بروتوكول Lido ومعلماته بواسطة Lido DAO عبر التصويت على رمز LDO. يأخذ البروتوكول رسومًا بنسبة 5٪ من مكافآت التخزين ويوجهها إلى خزانة DAO (يتم توزيع 5٪ أخرى على مشغلي العقدة المشاركين في البروتوكول).

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

يمكن تعميم ذلك كمشكلة وكيل رئيسي (PAP) بين DAO (الوكيل) ومستخدمي البروتوكول (الرئيسي). المشكلة موجودة لأن حاملي LDO ليس لديهم نفس الحوافز التي يتمتع بها المستخدمون.

علاوة على ذلك، كما يوضح فيتاليك في مقالته بعنوان « الانتقال إلى ما بعد التصويت على العملات 9 »، تتفاقم PAP بسبب حقيقة أن الاهتمام الاقتصادي بإيرادات البروتوكول يمكن فصله عن سلطة الحوكمة: يمكن للمرء أن يحرف حوافز حاملي رمز DAO عن طريق رشوتهم أو اقتراض رمز تصويت DAO في السوق المفتوحة لمحاولة الحصول على قوة تصويت كافية لدفع التغيير الذي يتعارض مع مصالح كل من DAO ومستخدمي البروتوكول.

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

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

العامل الأول هو تفاصيل كيفية عمل Ethereum PoS. لإلغاء اختبار ETH من المدقق، يتعين على المرء الانتظار حتى يتم الخروج من المدقق بالكامل، وتتم معالجة جميع مخارج مدقق Ethereum من خلال قائمة انتظار واحدة ذات إنتاجية محدودة. هذا يعني أن الوقت المطلوب لمغادرة البروتوكول يعتمد على عوامل خارجية خارج البروتوكول ويمكن أن يختلف حسب الحجم. وهذا بدوره يعني أن فرض قفل زمني ثابت على قرارات DAO لا يمكن أن يضمن أن أي مستخدم لديه الوقت الكافي لمغادرة البروتوكول قبل أن يطبق DAO تغييرًا ليس في اهتمامات المستخدم.

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

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

أنشأت Lido DAO عددًا من بروتوكولات الحوكمة للحد من عدم تناسق المعلومات (على سبيل المثال إطار GOOSE، ومجموعة الحوكمة الفرعية لمشغلي العقدة، وإطار LIP، والالتزام بالحد الأدنى لعدد عمليات التدقيق لأي تغيير في كود الشبكة الرئيسية) ولكنها كلها اتفاقيات الطبقة الاجتماعية بين حاملي LDO الحاليين وبالتالي لا يمكن حمايتها من هجوم خارجي على DAO.

نحو الحل

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

يعد تقليل نطاق الحوكمة تدريجيًا أمرًا يراه المساهمون في البروتوكول ضرورة في السنوات القادمة. ومع ذلك، حتى يتم تعديل مواصفات Ethereum، لا يمكن تقليل إمكانية ترقية الكود إلا إلى حد معين (على سبيل المثال. انظر EIP-7002 5، EIP-7251(6). بالإضافة إلى ذلك، يجب التحقق رسميًا من أي كود غير قابل للتغيير على مستوى البايت كود لاستبعاد احتمال حدوث خطأ في المحول البرمجي ينتج ثغرة أمنية غير قابلة للإصلاح.

هناك أيضًا طبقة قابلية الاستبدال للبروتوكول التي تعمل كمحرك لتقييم المخاطر/المكافآت وتوزع ETH بين مجموعات فرعية مختلفة من المدققين بطريقة توازن العائد ومخاطر مجموعة المدققين الناتجة. تشمل المخاطر هنا المخاطر الخلفية التي تخلقها مجموعة المدققين لشبكة Ethereum، على سبيل المثال الرقابة ومخاطر القطع المرتبطة بها. هناك بحث مستمر (انظر هذا التقرير 6 للحصول على أحدث نسخة) حول ما إذا كان يمكن تقدير هذه المخاطر بواسطة البروتوكول بمساعدة أداة أوراكل غير الموثوقة التي توفر المعلومات المطلوبة على السلسلة ولكنها محاولة طويلة الأجل وليس من الواضح بعد كيف يمكن تحقيق النتيجة المرجوة عمليًا. حتى يتم تنفيذ مثل هذه الآلية غير الموثوقة للبروتوكول، يجب أن يكون هناك بعض الحوكمة في طبقة قابلية الاستبدال.

يتمثل أحد مجالات البحث المحتملة الأخرى في البحث عن طرق لإدخال اشتراك صريح في إصدارات التعليمات البرمجية الجديدة ومجموعة المعلمات لحاملي StETH وعمليات الدمج. ليس من الواضح بعد ما إذا كان يمكن القيام بذلك دون كسر قابلية استبدال LST وتجزئة السيولة الناتجة والتي، نظرًا لأن السيولة هي أحد العوامل الرئيسية التي تدفع المستخدمين إلى LSTs، من شأنها أن تدمر القدرة التنافسية للبروتوكول ضد مزودي تخزين السيولة اللامركزية والمركزية الآخرين. ومع ذلك، فهو اتجاه بحثي مثير للاهتمام.

الآن بعد أن أثبتنا أن البروتوكول يجب أن يتعايش مع نوع من الحوكمة على الأقل على المدى المتوسط، دعونا نرى كيف يمكننا تقليل < a href= " https://notes.ethereum.org/@mikeneuder/magnitude-and-direction " > المخاطر التي تخلقها هذه الحوكمة 1.

حوكمة مزدوجة

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

هذا هو المكان الذي نصل فيه إلى تصميم الحوكمة المزدوجة المقترح. تهدف إلى التحسينات التالية:

  1. امنح أصحاب المصلحة طريقة للإشارة بمصداقية إلى عدم موافقتهم مع DAO والالتزام بمغادرة البروتوكول إذا لم تتعاون DAO في حل تعارض الحوافز.
  2. توفير جهاز تفاوض بين المساهمين و DAO.
  3. قدم قفلًا زمنيًا ديناميكيًا ممتدًا لقرارات DAO التي يمكن تشغيلها من قبل أقلية نشطة من المساهمين وإطالة أمدها مع مشاركة المزيد من أصحاب المصلحة.
  4. قم بتحسين كفاءة التصويت بالقدم من خلال السماح للمخزنين بالخروج من البروتوكول دون الخضوع لقرارات DAO الجديدة والمعلقة.

يمكن العثور على نظرة عامة على تصميم الآلية المقترحة وبعض الأفكار للبحث المستقبلي حول تقليل مخاطر الحوكمة في هذه المذكرة: < a href= " https://hackmd.io/@skozin/r17mlW2la " " > https://hackmd.io/@skozin/r17mlW2la 37.

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

هناك اتجاه آخر للبحث المستقبلي وهو استكشاف الحوكمة غير الرمزية والهجينة 2.

الخطوات التالية

من هنا، يجب أن تحدث العديد من الأشياء قبل الانتهاء من التصميم، مما يؤدي إلى اقتراح تحسين Lido (LIP) الأكثر رسمية والذي سيتم تقديمه للتصويت على DAO ووثيقة سجل القرار المعماري (ADR) المرتبطة به:

  1. تقييم متانة الآلية المقترحة من خلال نمذجة السيناريو والهجوم.
  2. تقييم التطبيق العملي للآلية من خلال وضع نماذج أولية للشفرة.
  3. جمع ملاحظات المجتمع.

يهدف هذا الموضوع إلى تحقيق 3 بينما يعمل المساهمون في البروتوكول على 1 و 2 (كلاهما قيد التقدم حاليًا) لذا فإن أي ملاحظات تحظى بتقدير كبير!

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

إخلاء المسؤولية:

  1. تمت إعادة طباعة هذه المقالة من [lido]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [skozin]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسيتعاملون معها على الفور.
  2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
  3. يقوم فريق Gate Learn بترجمة المقالة إلى لغات أخرى. ما لم يُذكر، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.
Comece agora
Inscreva-se e ganhe um cupom de
$100
!