هل Web3 DAO مفهوم زائف؟ تحليل معمق لسبب تعرض Bonk لهجوم حوكمي

الكاتب: Biteye؛ المصدر: X، @BiteyeCN

ماذا؟ هل يمكن لمهاجم باستخدام 4 ملايين دولار أن ينهب خزينة DAO بقيمة 20 مليون دولار؟

في الساعات الأولى من أمس، تعرضت BONK DAO لهجوم على الحوكمة. استغل المهاجم عيوبًا في التصميم مثل انخفاض عتبة الحوكمة لـ BONK، وآلية التصويت بالأغلبية البسيطة، وغياب آلية التأخير (Timelock)، وذلك من خلال اقتراح خبيث لمحاولة تحويل أموال الخزينة.

فكيف يُصمم مسار الحوكمة لـ DAO ناضج حقًا؟ ولماذا تقلل بروتوكولات مثل Aave وENS وLido من المخاطر عبر الحوكمة متعددة الطبقات، بينما تكون BONK أكثر عرضة لهجمات الحوكمة؟

ستقوم هذه المقالة بتفكيك مسار حوكمة DAO إلى خمس مراحل: الاقتراح → مناقشة المجتمع → اختبار Snapshot المبدئي → التصويت على السلسلة → تنفيذ Timelock

1. مرحلة الاقتراح (Proposal)

في نظام DAO، تعتبر مرحلة الاقتراح نقطة البداية لجميع إجراءات الحوكمة.

يتضمن المحتوى الأساسي للاقتراح الرسمي عادةً تعديل معاملات البروتوكول، وإدراج أصل جديد، وتوزيع أموال الخزينة (Treasury)، وترقية العقود، وتعديل خطط الحوافز، وإعادة هيكلة قواعد الحوكمة.

لتحقيق توازن بين كفاءة الحوكمة ومنع الاقتراحات غير المرغوب فيها، تفرض البروتوكولات المختلفة عتبات مختلفة من رموز الحوكمة أو التفويض على مقدمي الاقتراح:

• Aave: عتبة عالية، تتطلب حوالي 0.5% من حقوق التصويت لـ AAVE.
• ENS: تتطلب الاقتراحات التنفيذية تفويض 100,000 ENS، بينما تتطلب الاقتراحات الاجتماعية حوالي 10,000 ENS.
• Lido: يتطلب مناقشة في المنتدى أولاً، مع استيفاء عتبة لا تقل عن 1,000 LDO.
• BONK: عتبة منخفضة، تتطلب فقط 100 مليون BONK (بقيمة 425.99 دولارًا)، وهذا هو سبب تعرض BONK لهجوم الحوكمة.

2. مرحلة مناقشة المجتمع (Governance Forum)

مناقشة المجتمع هي مرحلة مراجعة مسبقة قبل التصويت الرسمي. تطلب معظم DAOs الناضجة من الاقتراح دخول منتدى الحوكمة الرسمي أولاً، لإكمال ما يلي من خلال النقاش العام:

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

لكن ليس كل DAO لديها هذه المرحلة. على سبيل المثال، لا يوجد لدى BONK DAO عملية منتدى حوكمة رسمية، بل يتم تقديم اقتراحات BIP والتصويت عليها مباشرة عبر Solana Realms.

عادةً ما تشكل DAOs الناضجة جدار حماية للحوكمة من خلال آليات متعددة الطبقات مثل Governance Forum وSnapshot وTimelock، بينما تميل DAOs من نوع Meme مثل BONK إلى التصويت المباشر لزيادة كفاءة اتخاذ القرار، لكن هذا يخفض أيضًا عتبة الهجوم.

3. اختبار Snapshot المبدئي (تصويت خارج السلسلة)

قبل التصويت الرسمي على السلسلة، تجري العديد من DAOs تصويتًا خارج السلسلة عبر Snapshot كاختبار لرغبة المجتمع.

تُعرف هذه المرحلة عادةً باسم: Temperature Check (اختبار المزاج)

وظائفها الرئيسية:

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

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

وبسبب عدم تصميم BONK DAO لهذه الطبقة المهمة من التأمين المضاد للسرقة (Snapshot)، تمكن "اللص" من اقتحام الباب بسهولة.

4. التصويت الرسمي على السلسلة (On-chain Governance)

بعد مناقشة المجتمع واختبار Snapshot المبدئي (إذا كان المشروع يتبعه)، يدخل الاقتراح مرحلة الحوكمة الرسمية على السلسلة.

تتولى هذه المرحلة أطر الحوكمة على السلسلة، مثل:

• عقد Governor (شائع في نظام Ethereum)
• Aragon (إطار إدارة DAO)
• Realms (إطار حوكمة Solana)

لضمان جدية وأمان التصويت على السلسلة، تتحقق العقود الذكية بدقة من المؤشرين الأساسيين التاليين عند التسوية.

الحد الأدنى للمشاركة (Quorum): كخط أحمر أمان لحوكمة DAO، يحدد النصاب القانوني الحد الأدنى لإجمالي المشاركة في التصويت اللازم ليكون الاقتراح صحيحًا قانونيًا.

إذا لم يصل إجمالي الرموز المشاركة في التصويت إلى الحد الأدنى، حتى لو كانت نسبة الأصوات المؤيدة 100%، سيتم رفض الاقتراح مباشرة.

على سبيل المثال، في نموذج رمز بإجمالي عرض 100 مليون، إذا تم تعيين النصاب على 5%، فيجب مشاركة 5 ملايين رمز على الأقل. تختلف إعدادات النصاب في DAOs الرئيسية:

• وضعت Lido عتبة عالية نسبيًا بنسبة 5% من إجمالي العرض (حوالي 50 مليون LDO)
• بينما Aave (حوالي 2% من إجمالي العرض) وENS وBONK (1% من إجمالي العرض) هي أكثر تقليدية
• أما Optimism فهي أكثر مرونة، حيث تتراوح بين 3% و30% حسب نوع الاقتراح.

شروط تمرير التصويت: بعد الوصول إلى النصاب (الحد الأدنى للمشاركة)، يجب أن يستوفي الاقتراح النسبة المئوية المطلوبة من الأصوات المؤيدة لتمريره رسميًا.

تستخدم معظم DAOs في حوكمتها اليومية نظام الأغلبية البسيطة (Simple Majority)، أي: الأصوات المؤيدة (YES) > الأصوات المعارضة (NO).

أما بالنسبة للتغييرات الكبرى التي تمس القواعد الأساسية للبروتوكول، مثل تعديل دستور ENS، أو تغيير معاملات الحوكمة الرئيسية، أو ترقية البروتوكول الأساسي، فعادةً ما تلجأ DAOs إلى نظام الأغلبية الفائقة (Super Majority).

مما يتطلب نسبة دعم أعلى، على سبيل المثال: أكثر من 2/3 (حوالي 66.7%) من الأصوات المؤيدة؛ أو نسبة أعلى.

هذه الآلية تمنع كبار حاملي الرموز من دفع تعديلات كبيرة تؤثر على البروتوكول بأكمله من خلال الأغلبية البسيطة.

سبب آخر مهم لتعرض BONK لهجوم الحوكمة هو أن معاملات حوكمة DAO الخاصة بها كانت متساهلة نسبيًا.

الحد الأدنى للمشاركة يتطلب فقط 1% من إجمالي عرض رموز BONK للوصول إلى تصويت صالح. وشرط تمرير التصويت كان بالأغلبية البسيطة: YES > NO

هذا يعني أن المهاجم لم يكن بحاجة إلى الحصول على الغالبية العظمى من رموز BONK، بل فقط السيطرة على حوالي 1% من العرض، وجعل اقتراحه يحصل على دعم الأغلبية لدفع تنفيذ الحوكمة.

5. تنفيذ Timelock المؤجل والتنفيذ على السلسلة (Execution)

عادةً لا تقوم DAOs الناضجة بتنفيذ الاقتراح فور تمريره، بل تضيف آلية Timelock (قفل زمني): تمرير الاقتراح → انتظار Timelock → تنفيذ على السلسلة.

دور Timelock هو توفير وقت احتياطي للمجتمع، مما يسمح للأعضاء بـ:

• فحص كود الاقتراح؛
• اكتشاف مخاطر الهجوم المحتملة؛
• تنظيم المعارضة أو اتخاذ إجراءات طارئة.

بعد انتهاء فترة الانتظار، يتم تنفيذ الاقتراح تلقائيًا بواسطة إطار الحوكمة.

سبب آخر مهم لتعرض BONK لهجوم الحوكمة هو أن مسار الحوكمة الخاص بها يفتقر إلى مرحلة تنفيذ Timelock المؤجل القياسية: تمرير الاقتراح → تنفيذ مباشر

في حادثة هجوم الحوكمة BIP #76، استغل المهاجم بالضبط خاصية غياب آلية التنفيذ المؤجل في حوكمة BONK، حيث نفذ العملية الخبيثة بسرعة بعد تمرير الاقتراح.

كلمة أخيرة

تكشف حادثة هجوم حوكمة BONK عن مشكلة طويلة الأمد في DeFi: إذا لم يشارك أحد في الحوكمة، فهل حقًا هناك حاجة لوجود DAO؟

عندما تتحول حوكمة المجتمع إلى مجرد عرض، هل DAO ضروري حقًا؟ في الواقع، فتور المشاركة في الحوكمة يجعل هيكل DAO عبئًا غير فعال، بدلاً من كونه ضمانًا للبروتوكول.

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

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