Розуміння ERC-4626 в одній статті: новий стандарт для токенізованих сховищ DeFi

TLDR: ERC-4626 є стандартом для токенізованих сховищ.

До появи ERC-4626 кожне сховище мало власну специфікацію та деталі впровадження. Це робить інтеграцію складною, схильною до помилок і зайвою витратою ресурсів.

ERC-4626 намагається вирішити цю проблему за допомогою стандартної специфікації, щоб зменшити зусилля інтеграції та створити більш узгоджену та надійну модель реалізації, як ERC-20.

Що таке ERC-4626?

ERC-4626 - це стандарт, який покращує технічні параметри сховищ. Він надає стандартний API для сховищ доходності, що представляють акції одного базового токена ERC-20.

Токенізовані сховища стали надзвичайно поширеною моделлю в DeFi. Агрегатори дохідності, ринки кредитування, похідні інструменти стейкингу та багато інших dApps використовують і покладаються на токенізовані сховища. Приклади токенізованих сховищ включають Yearn і Balancer. Як агрегатор прибутку, Yearn Vault дозволяє користувачам вносити цифрові активи та отримувати дохід. Balancer — це автоматизований менеджер портфеля та постачальник ліквідності, який покладається на сховища в основі своєї бізнес-логіки. Ці сховища керують токенами в різних пулах. У той же час вони відокремлюють управління токеном від логіки самого пулу.

Протокол покращує ліквідність і гнучкість завдяки токенізації своїх сховищ. Токенізовані сховища спрощують транзакції та використання активів на платформах DeFi. Крім того, вони дозволяють створювати різноманітні взаємопов’язані фінансові продукти. Індустрія відстоює цю парадигму, яку часто називають «грошовим Lego».

Однак компонування без належної адаптованості чи стандартизації створює проблеми. Розробникам це не тільки ускладнює дотримання таких галузевих стандартів, як ERC-20, але й може заплутати нових розробників. Без належної адаптації чи стандартизації важко переглядати нові зміни та перевіряти деталі реалізації інтеграцій.

Тож ERC-4626 було запропоновано для вирішення цієї проблеми та спрощення інтеграції, дозволяючи учасникам DeFi нарешті прийняти більш безпечну та надійну уніфіковану специфікацію сховища. Це, у свою чергу, зменшить можливу поверхню атаки протоколу, інтегруючи токени в кілька протоколів.

Які проблеми безпеки може запобігти ERC-4626?

Забезпечуючи уніфікований стандарт, ERC-4626 прискорює побудову міжпротокольної інтеграції. Знайомі узгоджені стандарти також легше зрозуміти розробникам, зменшуючи ймовірність помилок кодування. Це допомагає запобігти проблемам компонування. Стандартизація також запобігає дублюванню зусиль, оскільки спільноті потрібно спроектувати сховище лише один раз, а не окремо для кожного протоколу. Оскільки таке проектування часто є схильним до помилок, воно допомагає уникнути дублювання встановлених, але поширених недоліків дизайну.

Ми представимо два приклади, щоб показати, яким проблемам може запобігти ERC-4626.

Подія Rari Capital

У Rari Capital було вкрадено токенів на суму приблизно 11 мільйонів доларів, що еквівалентно 60% усіх коштів користувачів у пулі Rari Capital Ethereum.

Загалом Rari Capital було зламано через незахищену реалізацію крос-протоколу. Його пул Ethereum використовує ETH у контракті Alpha Finance на токени ibETH як вихідну стратегію. Ця спеціальна стратегія відстежує значення обмінного курсу ibETH/ETH за допомогою певних контрактів і формул (зокрема, функції ibETH.totalETH / ibETH.totalSupply), які можуть мати помилкові результати в цьому сценарії атаки, наприклад, під час виклику ibETH.work ( ) функції, вартість боргу може бути штучно завищена.

Зловмисник може виснажити Rari Fund Manager, просто багаторазово викликаючи функції депозиту та зняття в контракті RariFundManager. Функції депозиту та зняття повинні отримати баланс пулу, щоб обчислити кількість токенів REPT, які будуть видані абоненту, або суму ETH, яка буде видана абоненту. Ця операція викличе функцію getBalance пулу Alpha. , викликати контракт ibETH і його функцію totalETH . Rari не знає про можливість маніпулювання цією функцією.

У контракті ibETH є ще одна функція: ibETH.work. Ця функція може викликати будь-який контракт, указаний користувачем. Це дозволяє функціям депозиту та виведення Rari бути повторним входом і викликатися кілька разів.

Функція work є платною функцією, що означає, що користувач може контролювати кількість ETH у контракті ibETH через функцію work, таким чином змінюючи значення, яке повертає функція totalETH. Що ще гірше, робоча функція також підтримує виклик будь-якого іншого контракту, наприклад RariFundManager.

За допомогою цієї функції зловмисник може знову надіслати ETH і збільшити загальну суму ETH в контракті ibETH, і в той же час викликати зняття в контракті RariFundManager, щоб викупити більше активів.

Цей інцидент підкреслює значні ризики, пов’язані з недостатньою інтеграцією та несумісністю проектів у контрактах DeFi. Він підкреслює, як такі стандарти, як ERC-4626, можуть запобігти таким атакам, додавши критичний рівень безпеки та передбачуваності, а також сприяючи однаковій поведінці та взаєморозумінню.

Кейс Cream Finance

Cream Finance зазнало складної атаки, яка використовувала дві фундаментальні слабкості платформи: маніпульований оракул змішування та необмежену пропозицію токенів. Ключовою частиною атаки було маніпулювання оракулом змішування, що вплинуло на сприйняту вартість токена yUSD. Коли зловмисник надіслав велику кількість токенів Yearn 4-Curve до сховища yUSD, він змінив обмінний курс, повідомлений сховищем, і, таким чином, також вплинув на цінність токенів yUSD для оракула.

Ключовий урок тут полягає в тому, що надійний ціновий оракул, який неможливо маніпулювати, має вирішальне значення для стабільності протоколу DeFi. Оракули середньозваженої ціни (TWAP) можуть допомогти запобігти таким зломам, оскільки вони більш стійкі до раптових маніпуляцій цінами.

Ці проблеми та інші крихкі шаблони проектування можна пом’якшити шляхом ретельного прийняття та впровадження ERC-4626.

Потенційні ризики безпеки в ERC-4626

Завжди є певні компроміси з використанням нового протоколу. Для токенізованих сховищ можуть виникнути потенційні проблеми з їх інтеграцією в смарт-контракти, які потребують особливої уваги.

Керуйте токенами feeOnTransfer

Якщо сховище розроблено для підтримки токенів feeOnTransfer, переконайтеся, що сума та частки в сховищі знаходяться в межах очікуваного діапазону під час передачі активів.

Відповідне використання змінної decimals

Хоча функції convertTo не потрібно використовувати десяткову змінну сховища EIP-4626, все ж настійно рекомендується віддзеркалювати десяткові знаки основного токена, де це можливо. Ця практика допомагає усунути потенційні джерела плутанини та спрощує інтеграцію для різних користувачів інтерфейсу та поза мережею.

округлення

Відповідно до специфікації розробники сховищ повинні знати, що в різних змінних методах і методах перегляду потрібні конкретні та протилежні напрямки округлення, оскільки під час обчислень безпечніше віддавати пріоритет самому сховищу над його користувачами:

  • Якщо він розраховує кількість акцій, які будуть видані користувачеві на суму якогось базового токена, який вони пропонують, або якщо він працює для передачі певної частки базового токена користувачеві, його слід округлити в меншу сторону.

  • Якщо він розраховує, скільки акцій має надати користувач, щоб отримати певну кількість базових токенів, або якщо він обчислює, скільки базових токенів має надати користувач, щоб отримати певну кількість акцій, він повинен бути округленим.

Там, де бажаний напрямок округлення буде неоднозначним, це функція convertTo. Щоб забезпечити узгодженість у всіх реалізаціях сховищ EIP-4626, вкажіть, що ці функції мають завжди округляти вниз. Інтегратори можуть самі імітувати підсумкову версію, наприклад, додавши Wei до результату.

Сума базових активів, яку отримує користувач, викупивши свою частку в сховищі (previewRedeem), може суттєво відрізнятися від суми, яку потрібно було б заплатити, щоб випустити ту саму суму частки (previewMint). Ці відмінності можуть бути невеликими (наприклад, через помилки округлення) або великими (наприклад, сховище застосовує комісію за зняття або депозит). Таким чином, інтегратори повинні подбати про те, щоб використовувати функції попереднього перегляду, які найкраще відповідають їх сценарію використання, і ніколи не вважати їх взаємозамінними.

Перевизначити основні функції

Щоб реалізувати або розширити заплановану функціональність, рекомендується використовувати існуючі хуки замість зміни основної функціональності. Ця практика забезпечує більш керований слід для ефективного тестування та аудиту коду.

Нульова частка

Оригінальна специфікація для ERC-4626 не вказувала, як обробляти кутовий випадок відсутності спільних ресурсів у сховищі, і чи має сховище поводитись як зазвичай, чи має відкотитися. Це може бути потенційним джерелом плутанини та помилок.

Сховища як цінові оракули

Що стосується ризику атак маніпулювання цінами Oracle, значення, які повертаються цими методами попереднього перегляду, максимально наближені до точних. Таким чином, вони можуть працювати, змінюючи умови в мережі, і їх не завжди безпечно використовувати як цінові оракули. Специфікація ERC-4626 включає метод конвертації та метод totalAssets, які дозволяють неточні дані, і тому можуть бути реалізовані як потужний ціновий оракул. Наприклад, під час конвертації між активами та акціями правильно використовувати зважену за часом середню ціну для реалізації методу конвертації.

Конкретні проблеми впровадження

Інтегратори повинні переглянути будь-яку реалізацію токенізованого сховища перед подальшою інтеграцією, оскільки можуть бути зловмисні реалізації, які, здається, відповідають специфікації інтерфейсу, але чиї основні функції складаються з абсолютно інших специфікацій дизайну.

Прямий доступ EOA

Якщо потрібно отримати прямий доступ до сховища, його реалізація повинна мати функції, які можна використовувати для врахування втрат від прослизання або випадкових лімітів на депозит/вилучення. На відміну від смарт-контрактів, EOA не має відмовостійкого механізму для відкату транзакції.Якщо точний результат не досягається під час виклику основної функції, неможливо відкотити.

Розширене сховище

Оскільки все більше гравців почнуть приймати стандарт ERC-4626, ми побачимо більше розширень для цього стандарту. Наприклад, Superform розробила експериментальне розширення Multi Vault, яке підтримує використання різних обчислень в рамках одного контракту Vault. Природно, чим більше реалізація відхиляється від початкового стандарту, тим вище ймовірність появи нових уразливостей. Розробники та аудитори можуть знайти найкращий варіант на основі сценарію використання, щоб визначити фактичну вартість ризику.

Важливо зазначити, що до катастрофічних подій призводить не найменше додавання кожного протоколу, а їх сукупність.

Потенційні вектори атак, згадані вище, є одними з найбільш обговорюваних питань, що стосуються стандарту ERC-4626. У міру того, як впровадження зростатиме, ми обов’язково досліджуватимемо більше варіантів використання та більш відповідні сценарії для інтеграції зі сховищами ERC-4626.

Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
  • Нагородити
  • Прокоментувати
  • Поділіться
Прокоментувати
0/400
Немає коментарів
  • Закріпити