Ризики та найкращі практики за хвилею повторного ставлення
З виникненням концепції Restaking на ринку з'явилося багато проектів Restaking на базі Eigenlayer. Restaking має на меті поділити частки стейкінгу користувачів з іншими проектами, шляхом використання довіри стейкінг-шару Ethereum Beacon, що дозволяє користувачам отримувати більше прибутку, а іншим проектам насолоджуватися консенсусною довірою та безпекою на рівні 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 наразі розгорнуто в контракті основної мережі, але ще не повністю реалізовано всі функції, зазначені в його білому документі (AVS, slash). Зокрема, функція slash реалізована лише через відповідні інтерфейси, без конкретної повної логіки. Відповідно до коду контракту, поточний slash активується через owner контракту StrategyManager (адміністративні права проекту), що робить спосіб виконання досить централізованим.
Під час проведення нативного ETH Restaking на EigenLayer, крім створення контракту EigenPod для управління засобами Restaking, також потрібно самостійно запустити сервіс вузла Beacon chain та взяти на себе ризик накладення штрафів з боку Beacon chain. Користувачам, які здійснюють нативний ETH Restaking, рекомендується обирати надійних постачальників послуг вузлів. Крім того, оскільки ETH зберігається в Beacon chain, процес зняття коштів вимагає ініціювання з боку користувача, а постачальник послуг вузлів повинен допомогти вивести відповідні кошти з Beacon chain, тобто процес виходу потребує згоди обох сторін.
Оскільки EigenLayer наразі ще не повністю реалізував механізми AVS та Slash, рекомендуємо користувачам не активувати функцію deleGate в протоколі EigenLayer, не ознайомившись повністю з відповідними ризиками, інакше це може призвести до втрати коштів.
Крім того, через код-рев'ю деякі проекти також мають певні ризики в коді, які можуть вплинути на безпеку коштів користувачів. Деякі ризикові точки та відповіді проектів наведені нижче:
EigenPie
Наразі всі контракти протоколу є оновлюваними контрактами, права на оновлення належать 3/6 Gnosis Safe, але права на оновлення контрактів MLRT токенів cbETH, ethX, ankrETH належать адресі EOA.
Команда проекту повідомила, що протягом 24 годин всі права на оновлення токенів MLRT будуть передані до мультипідписного гаманця.
KelpDAO
Під час процесу поповнення рахунку для розрахунку частки, яку отримує користувач, необхідно обчислити вартість частки, але формула розрахунку містить rsETHPrice, який потрібно оновлювати вручну відповідно до oracle. За винятком stETH, використовуються відповідні контракти токенів як джерело цін для розрахунку share price. StETH безпосередньо використовує обмін 1:1. Коли стETH має знижку на вторинному ринку, під час процесу поповнення рахунку існує певний простір для арбітражу.
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 є новою концепцією, яка не пройшла відповідного випробування часом ні на рівні контрактів, ні на рівні протоколів. Окрім вказаних вище ризиків, можуть існувати й інші невідомі ризики. Нижче наведено відносно безпечну пропозицію щодо взаємодії:
Розподіл коштів
Для користувачів, які використовують великі кошти для участі в Restaking, безпосередня участь у Native ETH restaking на EigenLayer є хорошим вибором. Причина в тому, що для Native ETH restaking внесені ETH активи зберігаються в контракті Beacon chain, а не в контракті EigenLayer. Навіть у разі найгіршої атаки на контракт, зловмисник не зможе негайно отримати активи користувача.
Для користувачів, які хочуть брати участь з великими коштами, але не бажають терпіти тривалий час викупу, можна вибрати відносно безпечний stETH як актив для безпосередньої участі в EigenLayer.
Для користувачів, які хочуть отримати додатковий прибуток, можна вибрати частину коштів для участі в таких проектах, як Puffer, KelpDAO, Eigenpie та Renzo, які побудовані на базі EigenLayer, відповідно до їхньої здатності витримувати ризики. Однак слід звернути увагу на те, що наразі вищезгадані проекти не реалізували відповідну логіку виведення, тому користувачі, які беруть участь у таких протоколах, повинні також враховувати відповідний ризик виходу, а під час інвестування слід враховувати ліквідність відповідних LRT на вторинному ринку.
Налаштування моніторингу
В даний час всі проекти, перераховані в тексті, мають можливість оновлення контрактів і призупинення, а також команда проекту може виконувати ризиковані операції з мультипідписом. Для просунутих користувачів можна налаштувати моніторинг відповідних контрактів, щоб стежити за оновленнями контрактів і виконанням чутливих операцій команди проекту.
Одночасно, ми сподіваємось, що команди та користувачі, які інвестують ETH для участі в проєкті, можуть налаштувати умови мультипідпису для активації автоматизованого бота та авторизації з одною підписом, на основі змін TVL в пулі, коливань ціни ETH та дій великих китів, щоб налаштувати автоматичну функцію депозиту до EigenLayer та різних протоколів повторної застави.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
16 лайків
Нагородити
16
4
Поділіться
Прокоментувати
0/400
MetadataExplorer
· 08-06 01:32
Інвестування ризиковане й непередбачуване, хто наважиться на це?
Переглянути оригіналвідповісти на0
IronHeadMiner
· 08-06 01:31
Шахрайство ризик також не малий...
Переглянути оригіналвідповісти на0
AirdropLicker
· 08-06 01:23
Знову прийшли збирати гроші!
Переглянути оригіналвідповісти на0
WalletWhisperer
· 08-06 01:18
Такий великий ризик, а ви все ще граєте? Не боїтеся, що вас обдурять, як лохів?
Аналіз ризиків повторного стейкінгу: безпека основних проектів та посібник з найкращих практик
Ризики та найкращі практики за хвилею повторного ставлення
З виникненням концепції Restaking на ринку з'явилося багато проектів Restaking на базі Eigenlayer. Restaking має на меті поділити частки стейкінгу користувачів з іншими проектами, шляхом використання довіри стейкінг-шару Ethereum Beacon, що дозволяє користувачам отримувати більше прибутку, а іншим проектам насолоджуватися консенсусною довірою та безпекою на рівні ETH Beacon.
Щоб допомогти користувачам краще зрозуміти взаємні ризики між різними проектами Restaking, ми провели дослідження основних Restaking протоколів та популярних LST активів на ринку і систематизували пов'язані ризики, щоб користувачі могли краще контролювати відповідні ризики, насолоджуючись при цьому прибутками.
Огляд ризикових точок
Наразі більшість протоколів Restaking на ринку побудовані на основі EigenLayer, і для користувачів участь у Restaking означає піддавати себе таким ризикам:
Ризик контракту
Ризик LST
Існує можливість, що токени LST можуть втратити прив'язку, або оновлення/атака контракту LST можуть призвести до відхилення та втрати вартості LST.
Вихід з ризику
Зараз, крім EigenLayer, основні протоколи Restaking на ринку не підтримують виведення коштів. Якщо розробники не оновлять відповідну логіку виведення через контракт, користувачі можуть ніколи не зможуть безпосередньо повернути свої активи і змушені будуть отримувати ліквідність для виходу з вторинного ринку.
Відповідно до вказаних ризикових моментів, ми провели системне дослідження деяких основних протоколів Restaking на поточному ринку та здійснили їх упорядкування. Основні висновки включають:
Оскільки EigenLayer є основою всіх проектів, крім зазначених ризиків, також слід звернути увагу на такі моменти:
EigenLayer наразі розгорнуто в контракті основної мережі, але ще не повністю реалізовано всі функції, зазначені в його білому документі (AVS, slash). Зокрема, функція slash реалізована лише через відповідні інтерфейси, без конкретної повної логіки. Відповідно до коду контракту, поточний slash активується через owner контракту StrategyManager (адміністративні права проекту), що робить спосіб виконання досить централізованим.
Під час проведення нативного ETH Restaking на EigenLayer, крім створення контракту EigenPod для управління засобами Restaking, також потрібно самостійно запустити сервіс вузла Beacon chain та взяти на себе ризик накладення штрафів з боку Beacon chain. Користувачам, які здійснюють нативний ETH Restaking, рекомендується обирати надійних постачальників послуг вузлів. Крім того, оскільки ETH зберігається в Beacon chain, процес зняття коштів вимагає ініціювання з боку користувача, а постачальник послуг вузлів повинен допомогти вивести відповідні кошти з Beacon chain, тобто процес виходу потребує згоди обох сторін.
Оскільки EigenLayer наразі ще не повністю реалізував механізми AVS та Slash, рекомендуємо користувачам не активувати функцію deleGate в протоколі EigenLayer, не ознайомившись повністю з відповідними ризиками, інакше це може призвести до втрати коштів.
Крім того, через код-рев'ю деякі проекти також мають певні ризики в коді, які можуть вплинути на безпеку коштів користувачів. Деякі ризикові точки та відповіді проектів наведені нижче:
EigenPie
Наразі всі контракти протоколу є оновлюваними контрактами, права на оновлення належать 3/6 Gnosis Safe, але права на оновлення контрактів MLRT токенів cbETH, ethX, ankrETH належать адресі EOA.
Команда проекту повідомила, що протягом 24 годин всі права на оновлення токенів MLRT будуть передані до мультипідписного гаманця.
KelpDAO
Під час процесу поповнення рахунку для розрахунку частки, яку отримує користувач, необхідно обчислити вартість частки, але формула розрахунку містить rsETHPrice, який потрібно оновлювати вручну відповідно до oracle. За винятком stETH, використовуються відповідні контракти токенів як джерело цін для розрахунку share price. StETH безпосередньо використовує обмін 1:1. Коли стETH має знижку на вторинному ринку, під час процесу поповнення рахунку існує певний простір для арбітражу.
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 є новою концепцією, яка не пройшла відповідного випробування часом ні на рівні контрактів, ні на рівні протоколів. Окрім вказаних вище ризиків, можуть існувати й інші невідомі ризики. Нижче наведено відносно безпечну пропозицію щодо взаємодії:
Розподіл коштів
Для користувачів, які використовують великі кошти для участі в Restaking, безпосередня участь у Native ETH restaking на EigenLayer є хорошим вибором. Причина в тому, що для Native ETH restaking внесені ETH активи зберігаються в контракті Beacon chain, а не в контракті EigenLayer. Навіть у разі найгіршої атаки на контракт, зловмисник не зможе негайно отримати активи користувача.
Для користувачів, які хочуть брати участь з великими коштами, але не бажають терпіти тривалий час викупу, можна вибрати відносно безпечний stETH як актив для безпосередньої участі в EigenLayer.
Для користувачів, які хочуть отримати додатковий прибуток, можна вибрати частину коштів для участі в таких проектах, як Puffer, KelpDAO, Eigenpie та Renzo, які побудовані на базі EigenLayer, відповідно до їхньої здатності витримувати ризики. Однак слід звернути увагу на те, що наразі вищезгадані проекти не реалізували відповідну логіку виведення, тому користувачі, які беруть участь у таких протоколах, повинні також враховувати відповідний ризик виходу, а під час інвестування слід враховувати ліквідність відповідних LRT на вторинному ринку.
Налаштування моніторингу
В даний час всі проекти, перераховані в тексті, мають можливість оновлення контрактів і призупинення, а також команда проекту може виконувати ризиковані операції з мультипідписом. Для просунутих користувачів можна налаштувати моніторинг відповідних контрактів, щоб стежити за оновленнями контрактів і виконанням чутливих операцій команди проекту.
Одночасно, ми сподіваємось, що команди та користувачі, які інвестують ETH для участі в проєкті, можуть налаштувати умови мультипідпису для активації автоматизованого бота та авторизації з одною підписом, на основі змін TVL в пулі, коливань ціни ETH та дій великих китів, щоб налаштувати автоматичну функцію депозиту до EigenLayer та різних протоколів повторної застави.