ارتفاع حماس إعادة الرهان: تحليل متعمق لمخاطر المشاريع الرئيسية وأفضل الممارسات

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

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

نظرة عامة على نقاط المخاطر

تتكون بروتوكولات إعادة التخزين المتاحة حاليًا في السوق بشكل أساسي على أساس EigenLayer، مما يعني أن المشاركة في إعادة التخزين تعرض المستخدمين للمخاطر التالية:

مخاطر العقود

1. يتطلب المشاركة في إعادة التخزين التفاعل مع عقد المشروع، ويجب على المستخدم تحمل مخاطر تعرض العقد للهجوم؛
2. سيتم تخزين أموال المشاريع المبنية على EigenLayer في النهاية في عقود بروتوكول EigenLayer، وإذا تم الهجوم على عقود EigenLayer، ستتكبد أموال المشاريع ذات الصلة خسائر؛
3. يوجد نوعان من إعادة التخزين في EigenLayer: إعادة تخزين native ETH و إعادة تخزين LST. يتم تخزين أموال إعادة تخزين LST مباشرة في عقد EigenLayer، بينما يتم تخزين أموال إعادة تخزين native ETH في سلسلة ETH Beacon. وهذا يعني أن المستخدمين الذين يقومون بإعادة تخزين LST قد يتعرضون لخسائر بسبب مخاطر عقد EigenLayer.
4. يوجد لدى فريق المشروع صلاحيات عالية المخاطر، وفي بعض الحالات يمكن أن يتمكنوا من تحويل أموال المستخدمين من خلال صلاحيات حساسة.

مخاطر LST

قد يكون هناك احتمال لانفصال رموز LST، أو أن ترقية عقد LST/الهجمات قد تؤدي إلى انحراف وفقدان قيمة LST.

خروج المخاطر

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

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

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

نظرًا لأن EigenLayer هو حجر الزاوية لجميع المشاريع، هناك أيضًا نقاط أخرى يجب أن ينتبه لها المستخدمون بخلاف ما ذُكر أعلاه:

1. تم نشر EigenLayer حاليًا في عقود الشبكة الرئيسية، ولم يتم تنفيذ جميع الوظائف الموجودة في ورقة بيانه بشكل كامل (AVS، slash ). حيث إن وظيفة slash قد تم تنفيذ الواجهات ذات الصلة فقط، ولم يتم بعد وجود منطق كامل محدد. وفقًا لشفرة العقد، يتم تفعيل slash حاليًا من خلال مالك عقد StrategyManager ( صلاحيات admin الخاصة بالمشروع )، وطريقة التنفيذ مركزيّة نسبيًا؛
2. عند إجراء إعادة تخزين ETH الأصلية عبر EigenLayer، بالإضافة إلى ضرورة إنشاء عقد EigenPod لإدارة أموال إعادة التخزين، يجب أيضًا تشغيل خدمة عقدة Beacon chain الخاصة بك، وتحمل مخاطر الاقتطاع من Beacon chain. يُنصح المستخدمون عند إجراء إعادة تخزين ETH الأصلية باختيار مزودي خدمة العقدة الموثوق بهم. علاوة على ذلك، نظرًا لأن ETH محفوظ في Beacon chain، فإن عملية السحب تتطلب من المستخدم الشروع فيها ومساعدة مزود خدمة العقدة في سحب الأموال ذات الصلة من Beacon chain.
3. نظرًا لأن EigenLayer لم تنفذ بعد آلية AVS وSlash بشكل كامل، يُنصح المستخدمون بعدم تفعيل ميزة deleGate في بروتوكول EigenLayer دون فهم كافٍ للمخاطر ذات الصلة، وإلا فقد يؤدي ذلك إلى خسائر مالية معينة.

كيف يمكن تقليل مخاطر المشاركة في Restaking بفعالية؟

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

تخصيص الأموال

بالنسبة للمستخدمين الذين يستخدمون أموالًا كبيرة للمشاركة في Restaking ، فإن المشاركة المباشرة في إعادة ستاكينغ Native ETH من EigenLayer هي خيار جيد. السبب في ذلك هو أن أصول ETH المودعة في إعادة ستاكينغ Native ETH لا تُخزن في عقد EigenLayer ، بل تُخزن في عقد Beacon chain. حتى في أسوأ الأحوال، إذا حدث هجوم على العقد، فلن يتمكن المهاجم من الحصول على أصول المستخدمين على الفور.

بالنسبة للمستخدمين الذين يرغبون في المشاركة بأموال كبيرة ولكن لا يرغبون في تحمل فترات استرداد طويلة، يمكنهم اختيار stETH كأصل مشارك للمشاركة مباشرة في EigenLayer.

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

إعدادات المراقبة

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

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