Аналіз ризиків та найкращих практик проєкту Restaking
З появою концепції Restaking на ринку з'явилося багато проектів Restaking на основі Eigenlayer. Restaking має на меті поділитися довірою рівня стейкінгу Beacon Ethereum між користувачами, щоб їх частки стейкінгу могли бути використані іншими проектами, що дозволяє користувачам отримувати більше прибутку, а іншим проектам насолоджуватися такою ж довірою до консенсусу та безпеки, як і рівень ETH Beacon.
Щоб допомогти всім краще зрозуміти взаємні ризики між різними проектами Restaking, команда безпеки провела глибоке дослідження основних протоколів Restaking та основних LST активів на ринку, а також систематизувала відповідні ризики, щоб користувачі могли краще контролювати відповідні ризики, прагнучи до прибутку.
Огляд ризиків
Наразі більшість протоколів Restaking на ринку побудовані на основі EigenLayer, для користувачів участь у Restaking означає, що вони піддаються таким ризикам:
ризик контракту
Участь у Restaking вимагає взаємодії з контрактом проекту, користувачі повинні нести ризик атаки на контракт.
Проекти, побудовані на основі EigenLayer, врешті-решт будуть зберігатися в контракті протоколу EigenLayer. Якщо контракт EigenLayer зазнає атаки, відповідні проектні кошти також зазнають збитків.
В EigenLayer існує два типи Restaking: native ETH Restaking та LST Restaking. Кошти LST Restaking безпосередньо зберігаються в контракті EigenLayer, тоді як кошти Native ETH Restaking зберігаються в ETH Beacon chain. Це означає, що користувачі, які здійснюють LST Restaking, можуть зазнати втрат через ризики контракту EigenLayer.
Команда проекту має високі ризики, у деяких випадках може через чутливі повноваження привласнити кошти користувачів.
LST ризик
Існує ймовірність, що токен LST може втратити прив'язку, або через оновлення контракту LST/атаки може призвести до відхилення та втрати вартості LST.
Вихід з ризику
Окрім EigenLayer, більшість основних протоколів Restaking на ринку наразі не підтримують виведення коштів. Якщо команда проекту не оновить відповідну логіку виведення через контракт, користувачі можуть не змогти безпосередньо забрати активи і їм потрібно буде отримати ліквідність для виходу з вторинного ринку.
Аналіз ризиків основних протоколів повторного стейкингу
Відповідно до вищезгаданих ризиків, команда з безпеки провела системне дослідження деяких основних протоколів Restaking, що є на ринку, і підготувала їх огляд. Основні знахідки включають:
Низький рівень завершення проекту, більшість проектів не реалізували логіку виведення.
Ризик централізації: активи користувачів в кінцевому підсумку контролюються мультипідписаним гаманцем, у команди проекту є певна здатність до Rug Pull.
На основі другого пункту, у разі внутрішніх зловживань або втрати мультипідписного приватного ключа можуть виникнути втрати активів.
Спеціальні попередження про ризики EigenLayer
Оскільки EigenLayer є основою всіх проєктів, крім зазначених вище ризиків, є ще кілька моментів, на які користувачам слід звернути особливу увагу:
EigenLayer наразі розгорнутий у контрактах основної мережі, але ще не реалізував усі функції, зазначені у його білому листі (AVS, slash). При цьому функція slash реалізована лише через відповідні інтерфейси, конкретна повна логіка ще не розроблена. Наразі slash активується через власника контракту StrategyManager (адміністративні права проекту), що робить спосіб виконання досить централізованим.
Під час повторного стейкингу нативного ETH в EigenLayer, окрім створення контракту EigenPod для управління коштами стейкінгу, необхідно самостійно запустити послугу вузла Beacon chain та взяти на себе ризики, пов'язані з можливим штрафом від Beacon chain. Рекомендується вибирати надійного постачальника послуг вузлів. Крім того, оскільки ETH зберігається в Beacon chain, процес виведення, окрім ініціативи користувача, також потребує допомоги постачальника послуг вузлів для виведення відповідних коштів з Beacon chain, тобто процес виведення потребує згоди обох сторін.
Враховуючи, що EigenLayer наразі ще не повністю реалізував механізми AVS і Slash, рекомендується користувачам не активувати функцію deleGate в протоколі EigenLayer, поки вони не ознайомляться з відповідними ризиками, щоб уникнути потенційних втрат коштів.
Аналіз ризиків основних LST токенів
Окрім ризиків самого протоколу, ризики LST також не слід ігнорувати під час процесу повторного стекингу. Команда безпеки провела дослідження провідних токенів LST на ринку, основна увага приділялася таким аспектам, як можливість оновлення контракту, контроль доступу, залежність від Оракула тощо.
Як ефективно знизити ризики участі в Restaking?
Restaking як нова концепція, як на рівні контрактів, так і на рівні протоколів, ще не пройшла достатнього випробування часом. Виходячи з нинішніх дослідницьких висновків, нижче наведено відносно безпечний посібник з взаємодії, метою якого є ефективне зменшення ризиків під час участі у процесі:
Стратегія розподілу коштів
Для користувачів, які використовують значні кошти для участі у Restaking, безпосередня участь у Native ETH restaking на EigenLayer є більш безпечним вибором. Це пояснюється тим, що активи ETH, які поповнюються в Native ETH restaking, зберігаються в контракті Beacon chain, а не в контракті EigenLayer, тому навіть у найгіршому випадку, якщо станеться атака на контракт, зловмисники не зможуть відразу отримати активи користувачів.
Для користувачів, які бажають брати участь з великими сумами, але не хочуть терпіти тривалий час викупу, можна вибрати порівняно стабільний stETH як актив для прямої участі в EigenLayer.
Для користувачів, які прагнуть отримати додатковий дохід, можна в міру особистої здатності до ризику вибрати частину коштів для участі в таких проектах, як Puffer, KelpDAO, Eigenpie та Renzo, які базуються на EigenLayer. Але слід звернути увагу на те, що оскільки ці проекти наразі в більшості випадків не реалізували механізм виведення коштів, учасники повинні також враховувати ризик виходу та слідкувати за ліквідністю відповідного LRT на вторинному ринку.
Рекомендації щодо моніторингу ризиків
З огляду на те, що більшість проектів наразі мають функції оновлення контрактів та призупинення, а також що команда проекту може виконувати високоризикові операції, рекомендується просунутим користувачам налаштувати відповідний моніторинг контрактів, звертаючи увагу на оновлення контрактів та виконання чутливих операцій команди проекту.
Для команд та користувачів, які бажають інвестувати ETH у проекти, слід розглянути можливість налаштування автоматизованого бота з умовами мультипідпису та одноосібного дозволу, заснованого на змінах TVL пулу, коливаннях цін ETH та великих фінансових змінах, щоб налаштувати автоматичну функцію депозиту до EigenLayer та різних протоколів повторного стейкінгу.
Застосовуючи ці стратегії та заходи, учасники можуть з певною мірою знизити ризики під час процесу повторного ставлення, більш безпечно беручи участь у цій новій фінансовій моделі. Однак важливо завжди залишатися насторожі, уважно стежити за ринковою динамікою та розвитком проектів і приймати обґрунтовані інвестиційні рішення відповідно до особистої схильності до ризику.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
20 лайків
Нагородити
20
7
Поділіться
Прокоментувати
0/400
MEVSandwichVictim
· 07-03 02:04
Який високий ризик, а все ще є люди, які йдуть вперед?
Переглянути оригіналвідповісти на0
MercilessHalal
· 07-01 17:27
Проект занадто новий, або боязкий.
Переглянути оригіналвідповісти на0
DegenDreamer
· 07-01 17:27
Ще один новий спосіб обдурювання людей, як лохів
Переглянути оригіналвідповісти на0
SchrodingerAirdrop
· 07-01 17:25
Ризик — це можливість швидкого збагачення.
Переглянути оригіналвідповісти на0
SingleForYears
· 07-01 17:23
Високий прибуток, високий ризик, що тут скажеш.
Переглянути оригіналвідповісти на0
MindsetExpander
· 07-01 17:19
Restaking знову наражається на небезпеку
Переглянути оригіналвідповісти на0
TokenAlchemist
· 07-01 17:12
ngmi з повторним ставленням, чесно кажучи... арбітражна поверхня виглядає підозріло прямо зараз з тими ризиками переходу станів
Повний аналіз ризиків проекту Restaking та найкращі практики
Аналіз ризиків та найкращих практик проєкту Restaking
З появою концепції Restaking на ринку з'явилося багато проектів Restaking на основі Eigenlayer. Restaking має на меті поділитися довірою рівня стейкінгу Beacon Ethereum між користувачами, щоб їх частки стейкінгу могли бути використані іншими проектами, що дозволяє користувачам отримувати більше прибутку, а іншим проектам насолоджуватися такою ж довірою до консенсусу та безпеки, як і рівень ETH Beacon.
Щоб допомогти всім краще зрозуміти взаємні ризики між різними проектами Restaking, команда безпеки провела глибоке дослідження основних протоколів Restaking та основних LST активів на ринку, а також систематизувала відповідні ризики, щоб користувачі могли краще контролювати відповідні ризики, прагнучи до прибутку.
Огляд ризиків
Наразі більшість протоколів Restaking на ринку побудовані на основі EigenLayer, для користувачів участь у Restaking означає, що вони піддаються таким ризикам:
ризик контракту
LST ризик
Існує ймовірність, що токен LST може втратити прив'язку, або через оновлення контракту LST/атаки може призвести до відхилення та втрати вартості LST.
Вихід з ризику
Окрім EigenLayer, більшість основних протоколів Restaking на ринку наразі не підтримують виведення коштів. Якщо команда проекту не оновить відповідну логіку виведення через контракт, користувачі можуть не змогти безпосередньо забрати активи і їм потрібно буде отримати ліквідність для виходу з вторинного ринку.
Аналіз ризиків основних протоколів повторного стейкингу
Відповідно до вищезгаданих ризиків, команда з безпеки провела системне дослідження деяких основних протоколів Restaking, що є на ринку, і підготувала їх огляд. Основні знахідки включають:
Спеціальні попередження про ризики EigenLayer
Оскільки EigenLayer є основою всіх проєктів, крім зазначених вище ризиків, є ще кілька моментів, на які користувачам слід звернути особливу увагу:
EigenLayer наразі розгорнутий у контрактах основної мережі, але ще не реалізував усі функції, зазначені у його білому листі (AVS, slash). При цьому функція slash реалізована лише через відповідні інтерфейси, конкретна повна логіка ще не розроблена. Наразі slash активується через власника контракту StrategyManager (адміністративні права проекту), що робить спосіб виконання досить централізованим.
Під час повторного стейкингу нативного ETH в EigenLayer, окрім створення контракту EigenPod для управління коштами стейкінгу, необхідно самостійно запустити послугу вузла Beacon chain та взяти на себе ризики, пов'язані з можливим штрафом від Beacon chain. Рекомендується вибирати надійного постачальника послуг вузлів. Крім того, оскільки ETH зберігається в Beacon chain, процес виведення, окрім ініціативи користувача, також потребує допомоги постачальника послуг вузлів для виведення відповідних коштів з Beacon chain, тобто процес виведення потребує згоди обох сторін.
Враховуючи, що EigenLayer наразі ще не повністю реалізував механізми AVS і Slash, рекомендується користувачам не активувати функцію deleGate в протоколі EigenLayer, поки вони не ознайомляться з відповідними ризиками, щоб уникнути потенційних втрат коштів.
Аналіз ризиків основних LST токенів
Окрім ризиків самого протоколу, ризики LST також не слід ігнорувати під час процесу повторного стекингу. Команда безпеки провела дослідження провідних токенів LST на ринку, основна увага приділялася таким аспектам, як можливість оновлення контракту, контроль доступу, залежність від Оракула тощо.
Як ефективно знизити ризики участі в Restaking?
Restaking як нова концепція, як на рівні контрактів, так і на рівні протоколів, ще не пройшла достатнього випробування часом. Виходячи з нинішніх дослідницьких висновків, нижче наведено відносно безпечний посібник з взаємодії, метою якого є ефективне зменшення ризиків під час участі у процесі:
Стратегія розподілу коштів
Для користувачів, які використовують значні кошти для участі у Restaking, безпосередня участь у Native ETH restaking на EigenLayer є більш безпечним вибором. Це пояснюється тим, що активи ETH, які поповнюються в Native ETH restaking, зберігаються в контракті Beacon chain, а не в контракті EigenLayer, тому навіть у найгіршому випадку, якщо станеться атака на контракт, зловмисники не зможуть відразу отримати активи користувачів.
Для користувачів, які бажають брати участь з великими сумами, але не хочуть терпіти тривалий час викупу, можна вибрати порівняно стабільний stETH як актив для прямої участі в EigenLayer.
Для користувачів, які прагнуть отримати додатковий дохід, можна в міру особистої здатності до ризику вибрати частину коштів для участі в таких проектах, як Puffer, KelpDAO, Eigenpie та Renzo, які базуються на EigenLayer. Але слід звернути увагу на те, що оскільки ці проекти наразі в більшості випадків не реалізували механізм виведення коштів, учасники повинні також враховувати ризик виходу та слідкувати за ліквідністю відповідного LRT на вторинному ринку.
Рекомендації щодо моніторингу ризиків
З огляду на те, що більшість проектів наразі мають функції оновлення контрактів та призупинення, а також що команда проекту може виконувати високоризикові операції, рекомендується просунутим користувачам налаштувати відповідний моніторинг контрактів, звертаючи увагу на оновлення контрактів та виконання чутливих операцій команди проекту.
Для команд та користувачів, які бажають інвестувати ETH у проекти, слід розглянути можливість налаштування автоматизованого бота з умовами мультипідпису та одноосібного дозволу, заснованого на змінах TVL пулу, коливаннях цін ETH та великих фінансових змінах, щоб налаштувати автоматичну функцію депозиту до EigenLayer та різних протоколів повторного стейкінгу.
Застосовуючи ці стратегії та заходи, учасники можуть з певною мірою знизити ризики під час процесу повторного ставлення, більш безпечно беручи участь у цій новій фінансовій моделі. Однак важливо завжди залишатися насторожі, уважно стежити за ринковою динамікою та розвитком проектів і приймати обґрунтовані інвестиційні рішення відповідно до особистої схильності до ризику.