أطلقت AAVE، بروتوكول الإقراض الرئيسي، رسميًا أحدث وحدة حوكمة لها - Aave Governance V3، اليوم (12/27). وهذا يجلب مزايا كبيرة، بما في ذلك التخفيض الكبير في تكاليف التصويت، وإضافة الروبوتات الآلية، وتحسين البنية التحتية عبر السلاسل، ووضع نموذج جديد للحوكمة على السلسلة.

جدول المحتويات:

القيمة المرجعية لوحدة حوكمة Aave

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

على عكس نماذج إدارة المشروع الأخرى التي تعتمد على التحكم المتعدد في وظائف الباب الخلفي للبروتوكول (قد لا يحتوي بعضها حتى على multisig)، فإن بروتوكول Aave يحتوي على آلية آمنة نسبيًا. إنه يوفر رؤى قيمة حول آلية الحوكمة المثالية للمستقبل.

من ناحية أخرى، تم تشغيل AAVE Governance V2 منذ عام 2020، وتم التحقق من جدواها بدقة. حتى أنها سهلت إصدار عملة GHO المستقرة وتكامل البروتوكول، والتعامل مع مثل هذا الإنجاز الهندسي المعقد فقط من خلال تشغيل وحدة الحوكمة، وهو أمر مثير للاهتمام حقًا.

مقدمة إلى وحدة حوكمة Wave V2

سيتم إيقاف وحدة AAVE Governance V2 الحالية، ولكن V3 سترث هيكلها العام وتخضع للتحسينات، مما يتطلب فهمًا أساسيًا.

الهندسة المعمارية الأساسية

الهدف التشغيلي لـ AAVE Governance V2 هو تحقيق اللامركزية الكاملة. تقوم DAO تلقائيًا بتحديث البروتوكول بناءً على نتائج الحوكمة على السلسلة، دون الاعتماد على الفريق المؤسس للموافقة على المقترحات على السلسلة.

حفظ V2() بنية حوكمة الموجة
V2 (المصدر)

من الناحية العملية، يمكن تقسيم Aave Governance V2 إلى المكونات التالية:

• aaveGovernanceV2：مسؤول عن التعامل مع إنشاء وتقديم المعلومات وإعداد المعلمات وما إلى ذلك لـ AIP.
• المنفذ القصير: يستخدم لإجراء تغييرات أصغر على البروتوكول، وهو مسؤول عن تنفيذ محتوى المقترحات التي تم تمريرها بعتبة أقل لإكمال التكرارات السريعة، مثل المقترحات لزيادة أو تقليل قائمة الأصول المقبولة في البروتوكول.
• المنفذ الطويل: يستخدم لإجراء تغييرات كبيرة على الكود الأساسي للبروتوكول، وهو مسؤول عن تنفيذ المقترحات التي تمر بعتبة أعلى، مثل مقترحات تعديل القواعد المنطقية للبروتوكول نفسه.
• GovernanceStrategy：معالجة المنطق التشغيلي لمقترحات المستخدم والتصويت، وتحديد الرموز التي يمكن استخدامها للتصويت. الرموز المميزة التي يمكن استخدامها للتصويت في V2 هي AAVE و Stkaave (Stake AAVE).

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

(انفجار ثغرة أمنية Aave ｜ لم تعد الأموال معرضة للخطر، في انتظار تصويت المجتمع لإعادة تشغيل السوق)

تدفق التشغيل

في الماضي، كان الهيكل الأساسي لعملية الحوكمة لوحدة AAVE Governance V2 كما يلي:

1. تقديم الاقتراح: تتم مناقشة الاقتراح في منتدى المجتمع، ويتم إجراء فحص درجة الحرارة، يليه التصويت خارج السلسلة.
2. ARFC: قم بتجميع المقترحات التي تمرر التصويت خارج السلسلة إلى اقتراح كامل (AIP)، وأرسل الكود الكامل في نفس الوقت، وقم بإجراء التصويت خارج السلسلة مرة أخرى.
3. تقديم AIP: عادةً ما يقدم الفريق AIP إلى عقد الحوكمة للمقترحات التي تجتاز التصويت الثاني خارج السلسلة، ولكن يمكن لأي شخص تقديم AIP.
4. فترة التأخير: بعد فترة تأخير تبلغ حوالي يوم واحد، يكمل عقد الحوكمة لقطة حالة الرمز المميز ويؤكد حقوق التصويت.
5. التصويت على السلسلة: هناك حدود نجاح مختلفة للمقترحات ذات مستويات مختلفة من التأثير.
6. تنفيذ الاقتراح: بعد تمرير الاقتراح، ستكون هناك فترة قفل. بعد النهاية، سيتم استخدام Short Executor أو Long Executor لتنفيذ كود التحديث وفقًا للمقترحات ذات مستويات التأثير المختلفة. يجب تشغيل هذا الجزء بواسطة عنوان خارجي.
7. التنفيذ عبر السلاسل: إذا كان الاقتراح موجودًا على شبكة أخرى غير Ethereum، فمن الضروري تنفيذ المعاملات عبر السلاسل وتنفيذ عقد تنفيذ الشبكة المقابلة، والتي تحتاج أيضًا إلى تشغيلها بواسطة عنوان خارجي.

المشاكل الحالية

المشكلات التي حددتها AAVE Governance V2 بعد ثلاث سنوات من التشغيل:

• تكاليف التصويت المرتفعة: يتكبد التصميم الحالي تكاليف غاز كبيرة، لا سيما التأثير على المستخدمين الصغار. تعتبر حقوق التصويت على الرمز المميز لـ Aave و Stkaave لامركزية، حيث يوجد أكثر من 150,000 من حاملي Aave و 20,000 من حاملي Stkaave. يمتلك العديد من المستخدمين كمية صغيرة من الرموز وقوة التصويت المقابلة. حتى في السيناريوهات التي تكون فيها رسوم غاز Ethereum منخفضة نسبيًا (على سبيل المثال، 20 gwei)، لا يزال إكمال التصويت يكلف حوالي 5 دولارات. أثناء ازدحام الشبكة، يمكن أن ترتفع تكاليف التصويت من خمس إلى عشر مرات.
• الحوكمة وتضارب المصالح الرمزية: لاستيعاب وحدة الحوكمة الحالية، يجب أن تكون الرموز قابلة للاستعلام عن طريق العقود للتحقق من حقوق التصويت لحاملي رموز AAVE و StkaAve. تتطلب الرموز نفسها تسجيل سجل رصيد إضافي، مما يؤدي إلى زيادة رسوم المعاملات لتحويلات AAVE و StkaAave. يؤدي هذا بشكل غير مباشر إلى زيادة التكاليف التشغيلية لحاملي الرموز. تسلط هذه التحديات الضوء على الحاجة إلى تحسينات في نموذج AAVE Governance V2 لمعالجة تكاليف التصويت، وتعزيز اللامركزية، وتخفيف التعارضات بين الحوكمة والمصالح الرمزية.

مقدمة إلى وحدة حوكمة Wave V3

نظرة سريعة على أوجه التشابه والاختلاف بين Aave Governance V3 و V2

• إنشاء الاقتراح: تتطلب قواعد حوكمة V3 من مقدمي العروض نشر رمز عقد قابل للتنفيذ وصالح في عقد Aave والتسجيل الكامل للحصول على الاعتراف بالاقتراح قبل إنشاء الاقتراح.
• تأخير التصويت: تقريبًا مثل V2، سيكون هناك تأخير لمدة يوم واحد بين إنشاء الاقتراح وبدء التصويت، مع لقطة من حقوق التصويت المأخوذة بعد النهاية. ومع ذلك، نظرًا لبعض الأسباب الفنية، سيختلف وقت الاستجابة على الإصدار 3 حسب الساعات.
• التصويت على الاقتراح: لن يدلي الناخبون في معظم الحالات بأصواتهم على Ethereum، ولكن على شبكات أخرى مثل Polygon أو Avalanche أو Arbitrum أو Optimism، مع فتح المزيد من الشبكات في المستقبل. ملحق: سيتم إجراء التصويت على الاقتراح على شبكة واحدة فقط، وليس على شبكات متعددة في وقت واحد. يمكن لمقدم العرض اختيار الشبكة التي سيتم التصويت عليها بناءً على التفضيلات أو العوامل الأخرى.
• تنفيذ الاقتراح: ستكون مرحلة القفل الزمني وتنفيذ الاقتراح هي نفسها تمامًا كما في V2، مع تمديد التنفيذ إلى شبكات أخرى.
• اقبل المزيد من حقوق التصويت الخاصة بالاعتراف بالأصول: ستحصل كل من AAVE و AAAve و StkaBPT على حقوق التصويت.

هيكل التنفيذ: عملية تشغيل الحوكمة

ستخضع جميع المقترحات المستقبلية في وحدة حوكمة AAVE للعملية التالية:

عملية تشغيل Wave Governance V3(المصدر)

1. تقديم الكود: يقوم مقدم العرض بإنشاء اقتراح وإرسال الرمز وتسجيله في عقد وحدة التحكم على الشبكة المستهدفة. على سبيل المثال، إذا كان الاقتراح يهدف إلى إضافة فئات أصول على Aave v3 Avalanche، فيجب تقديم الاقتراح ونشر الكود على Avalanche، دون الحاجة إلى إذن طوال العملية.
2. معرف اقتراح الإرجاع: بعد الانتهاء من عملية إنشاء الاقتراح، يتلقى مقدم العرض شهادة تعريف من الشبكة المستهدفة.
3. إنشاء الاقتراح: يقوم مقدمو العروض المؤهلون (الحاصلون على شهادة تعريف وحقوق اقتراح كافية) بإنشاء مقترحات على إيثريوم باستخدام عقد الحوكمة الأساسي، وتحديد الشبكة للكود المقدم.
4. بدء الاقتراح: بعد فترة التأخير، يمكن لروبوتات Aave أو أي عنوان إيثيريوم آخر بدء الاقتراح وإكمال لقطة لحالة بلوكتشين.
5. إرسال قيمة Block Hash: يقدم العقد الأساسي للحوكمة معلومات الاقتراح (تجزئة كتلة Ethereum) إلى البنية التحتية متعددة السلاسل لـ Aave.
6. تسوية حالة الشبكة المستهدفة: على شبكة التصويت المستهدفة، تقوم روبوتات Aave أو العناوين الأخرى بوضع اللمسات الأخيرة على تسوية الحالة العالمية المستخدمة للتحقق من التصويت. يتضمن ذلك قيم تجزئة كتلة إيثريوم وشجرة حالتها وشجرة حالة أصول التصويت.
7. بدء التصويت: يبدأ التصويت على الشبكة المستهدفة.
8. التصويت على الاقتراح: يمكن لكل مستخدم لديه حقوق التصويت على Ethereum التصويت على الشبكة المستهدفة من خلال عقد التصويت.
9. إغلاق التصويت: تستدعي برامج Aave bots أو العناوين الأخرى آلية التصويت لإغلاق التصويت.
10. تسوية النتائج: يتم إرسال نتائج التصويت، في شكل «نعم» و «لا»، إلى شبكة إيثريوم الرئيسية عبر البنية التحتية متعددة السلاسل لـ Aave.
11. انتظر التنفيذ: تصل نتائج التصويت إلى عقد الحوكمة الأساسي على Ethereum. بعد التحقق من المعلومات وتأكيدها، تنتظر التنفيذ.
12. تنفيذ الاقتراح: تقوم روبوتات Aave أو العناوين الأخرى بتنفيذ التعليمات البرمجية المحدثة.
13. التنفيذ عبر السلاسل: يتم إرسال الكود إلى عقد التنفيذ المقابل على Ethereum أو شبكة أخرى، مما يؤدي إلى بدء فترة القفل الزمني.
14. انتظر التنفيذ: بالنسبة للتحديثات خارج Ethereum، يتم وضع المحتوى في قوائم الانتظار على وحدة التحكم المعنية.
15. تنفيذ الاقتراح: بمجرد انتهاء فترة القفل، تقوم روبوتات Aave أو العناوين الأخرى بتنفيذ التعليمات البرمجية المحدثة على الشبكة المستهدفة.

بنية التنفيذ

من خلال معرفة الإطار التشغيلي أعلاه، يمكننا فهم المكونات الأساسية لـ Aave Governance V3 بشكل أفضل:

• عقد حوكمة Ethereum الأساسي: مسؤول عن تحديد التسوية لجميع وحدات الحوكمة. إنه يتحقق من حقوق تصويت المستخدم، ولقطات الدولة، ويقرر رموز التصويت، ويحدد منطق قواعد التصويت، ويلغي المقترحات الضارة من خلال Guardian، ويعيد توجيه المقترحات إلى الشبكة المستهدفة، ويحافظ على معظم المبادئ التشغيلية لـ Aave Governance V2.
• عقد حوكمة الشبكة المستهدفة (Aave Voting Machine): مسؤول عن عمليات الحوكمة على الشبكة المستهدفة. يتضمن قبول كود مقدمي العروض وتفاعلاتهم، وتنفيذ منطق التصويت، وإرجاع نتائج التصويت.
• البنية التحتية للاتصالات عبر السلاسل: مرفق اتصال جديد عبر السلاسل مصمم لتلبية احتياجات الجسور لمختلف الشبكات المستقبلية. تشمل ميزاته الرئيسية الاتصال ثنائي الاتجاه والوظائف المخصصة وآليات الباب الخلفي للطوارئ.
• Aave Robot: ينفذ معظم وظائف الحوكمة تلقائيًا، حيث يتحمل كل من تكاليف التفاعل وتفاعلات الشبكة مباشرة بواسطة Aave DAO، ويختار Chainlink Automation كنواة له. وتشمل الوظائف الرئيسية تشغيل المقترحات بعد فترة التأخير، وتوفير أدلة الحالة للشبكة المستهدفة، وتنفيذ تحديثات التعليمات البرمجية على كل من إيثريوم والشبكة المستهدفة.

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

لا توجد حاليًا أي مقترحات لهذه الواجهة الأمامية(المصدر)

مزايا حوكمة الموجة V3

• انخفاض كبير في تكاليف التصويت:

من خلال التصويت على الشبكات الخارجية، باستخدام مستوى الرسوم الحالي على Polygon كمثال، ستكون تكلفة التصويت بين 0.05 دولار و 0.1 دولار. هذا أرخص بحوالي 100 مرة من تكلفة التصويت الحالية في Aave Governance V2. حتى أنه قد يمكّن المشاركين من التصويت مجانًا تمامًا. في المستقبل، يُقترح أن تغطي DAO تكاليف تصويت جميع المشاركين. إذا كان هناك 10000 مشارك، فستكون التكلفة الإجمالية 750 دولارًا فقط، وهو أمر ميسور التكلفة.

• انخفاض التكاليف التشغيلية للرموز الأصلية:

لن تكون هناك لقطات من سجل الرصيد لـ AAVE و Stkaave بعد الآن. مع ترقيات العقود الذكية في Aave Governance V3، من المتوقع أن يكون نقل AAVE و STKAave أرخص بنسبة 75٪ تقريبًا.

• التشغيل الآلي بدون إذن:

على الرغم من أن Aave Governance V3 يتضمن العديد من المراحل التي تتطلب التفاعل مع بلوكتشين لتوليد انتقالات الحالة، يمكن تشغيل هذه المراحل تلقائيًا من خلال Aave Robot. هذا أكثر ملاءمة بكثير من V2، والذي يتطلب التشغيل اليدوي من قبل المستخدمين.

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

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