المخاطر وأفضل الممارسات وراء حمى إعادة الاست staking
مع ظهور مفهوم Restaking، ظهرت العديد من مشاريع Restaking المعتمدة على Eigenlayer في السوق. يهدف Restaking إلى مشاركة حصة المستخدمين من التحقق من Ethereum Beacon Layer من خلال مشاركة الثقة، مما يتيح للمستخدمين الحصول على المزيد من العوائد، بينما تتمكن المشاريع الأخرى أيضًا من الاستفادة من الثقة والأمان التي تتساوى مع طبقة ETH Beacon.
لمساعدة المستخدمين على فهم المخاطر التفاعلية بين مشاريع الRestaking المختلفة بشكل أفضل، قمنا بدراسة البروتوكولات الرئيسية للRestaking والأصول الرئيسية LST في السوق، وقمنا بتوضيح المخاطر ذات الصلة، حتى يتمكن المستخدمون من إدارة المخاطر المناسبة أثناء استمتاعهم بالعائدات.
نظرة عامة على نقاط المخاطر
تستند معظم بروتوكولات إعادة التخزين في السوق الحالية إلى EigenLayer. بالنسبة للمستخدمين، فإن المشاركة في إعادة التخزين تعني تعريض أنفسهم للمخاطر التالية:
مخاطر العقود
يتطلب المشاركة في Restaking التفاعل مع عقد المشروع، ويجب على المستخدم تحمل مخاطر هجوم العقد.
سيتم تخزين أموال المشاريع المبنية على EigenLayer في النهاية في عقود بروتوكول EigenLayer، وإذا تم مهاجمة عقد EigenLayer، فإن أموال المشاريع ذات الصلة ستتعرض للخسارة.
يوجد نوعان من إعادة التخزين في EigenLayer: إعادة التخزين الأصلية ETH وإعادة التخزين LST. بالنسبة لإعادة التخزين LST، يتم تخزين الأموال مباشرة في عقد EigenLayer؛ بينما بالنسبة لإعادة التخزين الأصلية ETH، يتم تخزين الأموال في سلسلة Beacon ETH. وهذا يعني أن المستخدمين الذين يقومون بإعادة التخزين LST قد يتعرضون للخسائر بسبب مخاطر عقد EigenLayer.
يمتلك فريق المشروع صلاحيات عالية المخاطر، وفي بعض الحالات قد يقوم بتحويل أموال المستخدمين من خلال صلاحيات حساسة.
مخاطر LST
قد يكون هناك احتمال لفقدان ربط رموز LST، أو قد تؤدي ترقية عقد LST / هجوم إلى انحراف وفقدان قيمة LST.
خروج المخاطر
في الوقت الحالي، لا تدعم بروتوكولات إعادة التخزين الرئيسية في السوق سحب الأموال باستثناء EigenLayer. إذا لم يقم فريق المشروع بترقية منطق السحب المناسب من خلال العقد، فقد لا يتمكن المستخدمون من استرداد أصولهم مباشرة، مما يتطلب منهم الحصول على السيولة للخروج من السوق الثانوية.
استنادًا إلى نقاط المخاطر المذكورة أعلاه، قمنا بإجراء بحث نظامي حول بعض بروتوكولات إعادة التخزين الرئيسية في السوق الحالية، وقدمنا ملخصًا. تشمل الاكتشافات الرئيسية ما يلي:
انخفاض مستوى إنجاز المشروع، معظم المشاريع لم تحقق منطق السحب.
مخاطر المركزية: يتم التحكم في أصول المستخدمين في النهاية بواسطة محفظة متعددة التوقيع، مما يمنح فريق المشروع القدرة على القيام بعملية سحب مفاجئ معينة.
بناءً على النقطة الثانية، عندما يحدث سوء سلوك داخلي أو فقدان مفتاح التوقيع المتعدد، قد يؤدي ذلك إلى خسارة الأصول.
نظرًا لأن EigenLayer هو حجر الزاوية لجميع المشاريع، بالإضافة إلى المخاطر المذكورة أعلاه، يجب الانتباه إلى النقاط التالية:
يتم نشر EigenLayer حاليًا في العقود على الشبكة الرئيسية، ولم يتم تنفيذ جميع الميزات المذكورة في ورقة بيضاء الخاصة بها بشكل كامل (AVS، slash). من بين ذلك، تم تنفيذ وظيفة slash فقط من خلال واجهات برمجة التطبيقات ذات الصلة، ولا توجد منطق كامل محدد بعد. وفقًا لشفرة العقد، يتم تفعيل وظيفة slash حاليًا بواسطة مالك عقد StrategyManager (صلاحيات مسؤول المشروع)، مما يجعل طريقة التنفيذ مركزية نوعًا ما.
خلال عملية إعادة تخزين ETH الأصلية في EigenLayer، بالإضافة إلى ضرورة إنشاء عقد EigenPod لإدارة أموال إعادة التخزين، يجب على المستخدم أيضاً تشغيل خدمة عقدة سلسلة Beacon، وتحمل مخاطر الطرد من سلسلة Beacon. يُنصح المستخدمون عند إجراء إعادة تخزين ETH الأصلية باختيار مزود خدمة عقدة موثوق. علاوة على ذلك، نظراً لحفظ ETH في سلسلة Beacon، فإن عملية السحب تتطلب من المستخدم البدء بها، بينما يساعد مزود خدمة العقدة في إخراج الأموال ذات الصلة من سلسلة Beacon، مما يعني أن عملية الخروج تتطلب موافقة الطرفين.
نظرًا لأن EigenLayer لم يتم تنفيذ آلية AVS و Slash بشكل كامل حتى الآن، يُنصح المستخدمون بعدم تفعيل وظيفة deleGate في بروتوكول EigenLayer قبل فهم المخاطر المرتبطة بشكل كافٍ، وإلا قد يؤدي ذلك إلى خسارة الأموال.
بالإضافة إلى ذلك، من خلال مراجعة الشيفرة، توجد بعض المخاطر في الشيفرة في بعض المشاريع، والتي قد تؤثر على أمان أموال المستخدمين. نقاط المخاطر وبعض ردود أصحاب المشاريع كما يلي:
EigenPie
جميع العقود في البروتوكول حالياً هي عقود قابلة للتحديث، وصلاحيات التحديث هي 3/6 Gnosis Safe، ولكن صلاحيات تحديث عقود MLRT لرموز cbETH و ethX و ankrETH هي عنوان EOA.
أشار فريق المشروع إلى أنه سيتم نقل جميع صلاحيات ترقية رموز MLRT إلى محفظة متعددة التوقيعات خلال 24 ساعة.
KelpDAO
خلال عملية الشحن، يحتاج حساب حصة الـ share التي يحصل عليها المستخدم إلى حساب قيمة الـ share، لكن يجب تحديث rsETHPrice في صيغة الحساب يدويًا وفقًا لـ oracle المعني. باستثناء stETH، يتم استخدام سعر الـ share لعقود الرموز المقابلة كمصدر للسعر. بينما يتم احتساب stETH مباشرةً بنسبة 1:1. عندما يكون هناك خصم على stETH في السوق الثانوية، سيكون هناك مجال معين للتحكيم خلال عملية الشحن.
ردت KelpDAO بأن معدل تبادل عقد Lido محدد بـ 1 stETH = 1 ETH، ونظرًا لأن وظيفة السحب لم تُفتح بعد، لا يمكن للمستثمرين الاستفادة من هذه الاستراتيجية. ستضيف الفريق آلية إيقاف في وقت إطلاق السحوبات للتحقق من سعر سوق stETH، ومقارنته بسعر عقد stETH، وتطبيق الحواجز اللازمة عندما يكون هناك انحراف كبير.
رينزو
يتمثل دور OperatorDelegator في توجيه أموال بروتوكول إلى EigenLayer، مع نسب إعادة شحن مختلفة. ومع ذلك، لم تتحقق البروتوكول أثناء تكوين OperatorDelegator من أن جميع النسب أكبر من 100%، مما قد يؤدي إلى حالات مثل OperatorDelegator-1 (70%) و OperatorDelegator-2 (70%). تؤثر هذه المشكلة بشكل رئيسي على سحب أموال المستخدمين، وبما أن منطق السحب غير مكتمل حاليًا، فلا يمكن تقييم التأثير الدقيق على رأس المال.
ذكرت فريق Renzo أنه في هذه الحالة المحددة، سيتم نقل الأموال إلى عقد OperatorDelegator غير صحيح للإيداع، أو سحبها من OperatorDelegator غير الصحيح. رغم أن هذه المشكلة التقنية قد تؤدي إلى عدم تطابق التوزيع المتوقع لـ Renzo المخصص لمشغلين مختلفين، إلا أنها لن تؤثر على حساب القيمة الإجمالية المقفلة (TVL) أو أمان الأموال. سيقوم الفريق بحل هذه المشكلة في ترقيات العقود المستقبلية.
كيف يمكن تقليل مخاطر المشاركة في إعادة التخزين بشكل فعال؟
الـ Restaking هو مفهوم ناشئ، ولم يتم اختباره بشكل كافٍ سواء على مستوى العقود أو على مستوى البروتوكولات. بالإضافة إلى المخاطر المذكورة أعلاه، قد تكون هناك مخاطر أخرى غير معروفة. فيما يلي اقتراح لمسار تفاعلي يعتبر آمناً نسبياً:
توزيع رأس المال
بالنسبة للمستخدمين الذين يستخدمون أموالاً كبيرة للمشاركة في Restaking، فإن المشاركة مباشرة في إعادة تخزين ETH الأصلي من EigenLayer هي خيار جيد. السبب في ذلك هو أن أصول ETH المودعة في إعادة تخزين ETH الأصلي تُخزن في عقد سلسلة Beacon، وليس في عقد EigenLayer. حتى في حالة حدوث أسوأ هجوم على العقد، لن يتمكن المهاجمون من الوصول إلى أصول المستخدمين على الفور.
بالنسبة للمستخدمين الذين يرغبون في المشاركة برأس مال كبير ولكن لا يريدون تحمل وقت استرداد طويل، يمكنهم اختيار stETH كأصل موثوق للمشاركة مباشرة في EigenLayer.
بالنسبة للمستخدمين الذين يرغبون في كسب عوائد إضافية، يمكنهم اختيار جزء من أموالهم للمشاركة في مشاريع مثل Puffer و KelpDAO و Eigenpie و Renzo التي تم بناؤها على أساس EigenLayer، وفقًا لقدرتهم على تحمل المخاطر. ولكن يجب الانتباه إلى أنه نظرًا لأن المشاريع المذكورة أعلاه لم تحقق بعد منطق السحب المقابل، يجب على المستخدمين المشاركين في مثل هذه البروتوكولات أن يأخذوا في اعتبارهم مخاطر الخروج ذات الصلة، ويجب عليهم مراعاة سيولة LRT ذات الصلة في السوق الثانوية أثناء عملية الاستثمار.
إعدادات المراقبة
حاليًا، جميع المشاريع المذكورة في النص لديها القدرة على ترقية العقود وإيقافها، وفي الوقت نفسه يمكن لفريق المشروع تنفيذ عمليات عالية المخاطر. بالنسبة للمستخدمين المتقدمين، يمكنهم إعداد مراقبة للعقود المعنية لمراقبة ترقية العقود وتنفيذ العمليات الحساسة لفريق المشروع.
في الوقت نفسه، نأمل أن يتمكن الفرق والمستخدمون الذين يرغبون في استثمار ETH في المشاريع من تكوين محفظة متعددة التوقيعات لتفعيل الروبوتات الآلية وتفويض التوقيع الفردي، بناءً على تغييرات TVL في التجمع، وتقلبات سعر ETH، وتحركات الحيتان الكبرى، وذلك لإعداد وظيفة الإيداع التلقائي إلى EigenLayer ومختلف بروتوكولات إعادة الرهن.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تحليل مخاطر إعادة التخزين: أمان المشاريع الرائجة ودليل الممارسات المثلى
المخاطر وأفضل الممارسات وراء حمى إعادة الاست staking
مع ظهور مفهوم Restaking، ظهرت العديد من مشاريع Restaking المعتمدة على Eigenlayer في السوق. يهدف Restaking إلى مشاركة حصة المستخدمين من التحقق من Ethereum Beacon Layer من خلال مشاركة الثقة، مما يتيح للمستخدمين الحصول على المزيد من العوائد، بينما تتمكن المشاريع الأخرى أيضًا من الاستفادة من الثقة والأمان التي تتساوى مع طبقة ETH Beacon.
لمساعدة المستخدمين على فهم المخاطر التفاعلية بين مشاريع الRestaking المختلفة بشكل أفضل، قمنا بدراسة البروتوكولات الرئيسية للRestaking والأصول الرئيسية LST في السوق، وقمنا بتوضيح المخاطر ذات الصلة، حتى يتمكن المستخدمون من إدارة المخاطر المناسبة أثناء استمتاعهم بالعائدات.
نظرة عامة على نقاط المخاطر
تستند معظم بروتوكولات إعادة التخزين في السوق الحالية إلى EigenLayer. بالنسبة للمستخدمين، فإن المشاركة في إعادة التخزين تعني تعريض أنفسهم للمخاطر التالية:
مخاطر العقود
مخاطر LST
قد يكون هناك احتمال لفقدان ربط رموز LST، أو قد تؤدي ترقية عقد LST / هجوم إلى انحراف وفقدان قيمة LST.
خروج المخاطر
في الوقت الحالي، لا تدعم بروتوكولات إعادة التخزين الرئيسية في السوق سحب الأموال باستثناء EigenLayer. إذا لم يقم فريق المشروع بترقية منطق السحب المناسب من خلال العقد، فقد لا يتمكن المستخدمون من استرداد أصولهم مباشرة، مما يتطلب منهم الحصول على السيولة للخروج من السوق الثانوية.
استنادًا إلى نقاط المخاطر المذكورة أعلاه، قمنا بإجراء بحث نظامي حول بعض بروتوكولات إعادة التخزين الرئيسية في السوق الحالية، وقدمنا ملخصًا. تشمل الاكتشافات الرئيسية ما يلي:
نظرًا لأن EigenLayer هو حجر الزاوية لجميع المشاريع، بالإضافة إلى المخاطر المذكورة أعلاه، يجب الانتباه إلى النقاط التالية:
يتم نشر EigenLayer حاليًا في العقود على الشبكة الرئيسية، ولم يتم تنفيذ جميع الميزات المذكورة في ورقة بيضاء الخاصة بها بشكل كامل (AVS، slash). من بين ذلك، تم تنفيذ وظيفة slash فقط من خلال واجهات برمجة التطبيقات ذات الصلة، ولا توجد منطق كامل محدد بعد. وفقًا لشفرة العقد، يتم تفعيل وظيفة slash حاليًا بواسطة مالك عقد StrategyManager (صلاحيات مسؤول المشروع)، مما يجعل طريقة التنفيذ مركزية نوعًا ما.
خلال عملية إعادة تخزين ETH الأصلية في EigenLayer، بالإضافة إلى ضرورة إنشاء عقد EigenPod لإدارة أموال إعادة التخزين، يجب على المستخدم أيضاً تشغيل خدمة عقدة سلسلة Beacon، وتحمل مخاطر الطرد من سلسلة Beacon. يُنصح المستخدمون عند إجراء إعادة تخزين ETH الأصلية باختيار مزود خدمة عقدة موثوق. علاوة على ذلك، نظراً لحفظ ETH في سلسلة Beacon، فإن عملية السحب تتطلب من المستخدم البدء بها، بينما يساعد مزود خدمة العقدة في إخراج الأموال ذات الصلة من سلسلة Beacon، مما يعني أن عملية الخروج تتطلب موافقة الطرفين.
نظرًا لأن EigenLayer لم يتم تنفيذ آلية AVS و Slash بشكل كامل حتى الآن، يُنصح المستخدمون بعدم تفعيل وظيفة deleGate في بروتوكول EigenLayer قبل فهم المخاطر المرتبطة بشكل كافٍ، وإلا قد يؤدي ذلك إلى خسارة الأموال.
بالإضافة إلى ذلك، من خلال مراجعة الشيفرة، توجد بعض المخاطر في الشيفرة في بعض المشاريع، والتي قد تؤثر على أمان أموال المستخدمين. نقاط المخاطر وبعض ردود أصحاب المشاريع كما يلي:
EigenPie
جميع العقود في البروتوكول حالياً هي عقود قابلة للتحديث، وصلاحيات التحديث هي 3/6 Gnosis Safe، ولكن صلاحيات تحديث عقود MLRT لرموز cbETH و ethX و ankrETH هي عنوان EOA.
أشار فريق المشروع إلى أنه سيتم نقل جميع صلاحيات ترقية رموز MLRT إلى محفظة متعددة التوقيعات خلال 24 ساعة.
KelpDAO
خلال عملية الشحن، يحتاج حساب حصة الـ share التي يحصل عليها المستخدم إلى حساب قيمة الـ share، لكن يجب تحديث rsETHPrice في صيغة الحساب يدويًا وفقًا لـ oracle المعني. باستثناء stETH، يتم استخدام سعر الـ share لعقود الرموز المقابلة كمصدر للسعر. بينما يتم احتساب stETH مباشرةً بنسبة 1:1. عندما يكون هناك خصم على stETH في السوق الثانوية، سيكون هناك مجال معين للتحكيم خلال عملية الشحن.
ردت KelpDAO بأن معدل تبادل عقد Lido محدد بـ 1 stETH = 1 ETH، ونظرًا لأن وظيفة السحب لم تُفتح بعد، لا يمكن للمستثمرين الاستفادة من هذه الاستراتيجية. ستضيف الفريق آلية إيقاف في وقت إطلاق السحوبات للتحقق من سعر سوق stETH، ومقارنته بسعر عقد stETH، وتطبيق الحواجز اللازمة عندما يكون هناك انحراف كبير.
رينزو
يتمثل دور OperatorDelegator في توجيه أموال بروتوكول إلى EigenLayer، مع نسب إعادة شحن مختلفة. ومع ذلك، لم تتحقق البروتوكول أثناء تكوين OperatorDelegator من أن جميع النسب أكبر من 100%، مما قد يؤدي إلى حالات مثل OperatorDelegator-1 (70%) و OperatorDelegator-2 (70%). تؤثر هذه المشكلة بشكل رئيسي على سحب أموال المستخدمين، وبما أن منطق السحب غير مكتمل حاليًا، فلا يمكن تقييم التأثير الدقيق على رأس المال.
ذكرت فريق Renzo أنه في هذه الحالة المحددة، سيتم نقل الأموال إلى عقد OperatorDelegator غير صحيح للإيداع، أو سحبها من OperatorDelegator غير الصحيح. رغم أن هذه المشكلة التقنية قد تؤدي إلى عدم تطابق التوزيع المتوقع لـ Renzo المخصص لمشغلين مختلفين، إلا أنها لن تؤثر على حساب القيمة الإجمالية المقفلة (TVL) أو أمان الأموال. سيقوم الفريق بحل هذه المشكلة في ترقيات العقود المستقبلية.
كيف يمكن تقليل مخاطر المشاركة في إعادة التخزين بشكل فعال؟
الـ Restaking هو مفهوم ناشئ، ولم يتم اختباره بشكل كافٍ سواء على مستوى العقود أو على مستوى البروتوكولات. بالإضافة إلى المخاطر المذكورة أعلاه، قد تكون هناك مخاطر أخرى غير معروفة. فيما يلي اقتراح لمسار تفاعلي يعتبر آمناً نسبياً:
توزيع رأس المال
بالنسبة للمستخدمين الذين يستخدمون أموالاً كبيرة للمشاركة في Restaking، فإن المشاركة مباشرة في إعادة تخزين ETH الأصلي من EigenLayer هي خيار جيد. السبب في ذلك هو أن أصول ETH المودعة في إعادة تخزين ETH الأصلي تُخزن في عقد سلسلة Beacon، وليس في عقد EigenLayer. حتى في حالة حدوث أسوأ هجوم على العقد، لن يتمكن المهاجمون من الوصول إلى أصول المستخدمين على الفور.
بالنسبة للمستخدمين الذين يرغبون في المشاركة برأس مال كبير ولكن لا يريدون تحمل وقت استرداد طويل، يمكنهم اختيار stETH كأصل موثوق للمشاركة مباشرة في EigenLayer.
بالنسبة للمستخدمين الذين يرغبون في كسب عوائد إضافية، يمكنهم اختيار جزء من أموالهم للمشاركة في مشاريع مثل Puffer و KelpDAO و Eigenpie و Renzo التي تم بناؤها على أساس EigenLayer، وفقًا لقدرتهم على تحمل المخاطر. ولكن يجب الانتباه إلى أنه نظرًا لأن المشاريع المذكورة أعلاه لم تحقق بعد منطق السحب المقابل، يجب على المستخدمين المشاركين في مثل هذه البروتوكولات أن يأخذوا في اعتبارهم مخاطر الخروج ذات الصلة، ويجب عليهم مراعاة سيولة LRT ذات الصلة في السوق الثانوية أثناء عملية الاستثمار.
إعدادات المراقبة
حاليًا، جميع المشاريع المذكورة في النص لديها القدرة على ترقية العقود وإيقافها، وفي الوقت نفسه يمكن لفريق المشروع تنفيذ عمليات عالية المخاطر. بالنسبة للمستخدمين المتقدمين، يمكنهم إعداد مراقبة للعقود المعنية لمراقبة ترقية العقود وتنفيذ العمليات الحساسة لفريق المشروع.
في الوقت نفسه، نأمل أن يتمكن الفرق والمستخدمون الذين يرغبون في استثمار ETH في المشاريع من تكوين محفظة متعددة التوقيعات لتفعيل الروبوتات الآلية وتفويض التوقيع الفردي، بناءً على تغييرات TVL في التجمع، وتقلبات سعر ETH، وتحركات الحيتان الكبرى، وذلك لإعداد وظيفة الإيداع التلقائي إلى EigenLayer ومختلف بروتوكولات إعادة الرهن.