«Puffer — это децентрализованный протокол нативного ликвидного рестейкинга (nLRP), построенный на базе Eigenlayer». Всего за несколько дней он привлек более 600 миллионов долларов США TVL (общей заблокированной стоимости). Контроль доступа является важным аспектом безопасности, позволяющим предотвратить злонамеренные действия в отношении протокола.
В этом блоге мы рассматриваем архитектуру механизма контроля доступа и его текущую конфигурацию в протоколе Puffer. Это поможет сообществу лучше понять работу протокола. Обратите внимание, что результаты анализа основаны на текущем состоянии (блок 19177155, 7 февраля 2024 г., 15:17:35 UTC) в сети Ethereum.
Адреса контрактов
В следующей таблице перечислены смарт-контракты, используемые в этом блоге.
| Адрес | Реализация | |
|---|---|---|
| PufferDepositor | 0x4aa799c5dfc01ee7d79 0e3bf1a7c2257ce1dceff | 0x7276925e42f9c4054af a2fad80fa79520c453d6a |
| PufferVault | 0xD9A442856C234a39a81 a089C06451EBAa4306a72 | 0x39ca0a6438b6050ea2a c909ba65920c7451305c1 |
| AccessManager | 0x8c1686069474410E624 3425f4a10177a94EBEE11 | - |
| TimeLock | 0x3c28b7c7ba1a1f55c9c e66b263b33b204f2126ea | - |
| Operation SafeWallet | 0xC0896ab1A8cae8c2C1d 27d011eb955Cca955580d | 0xd9db270c1b5e3bd161e 8c8503c55ceabee709552 |
| Community SafeWallet | 0x446d4d6b26815f9bA78 B5D454E303315D586Cb2a | 0xd9db270c1b5e3bd161e 8c8503c55ceabee709552 |
| Pausing SafeWallet | 0x1ba8e3aA853F73ae809 3E26B7B8F2520c3620Df4 | 0xd9db270c1b5e3bd161e 8c8503c55ceabee709552 |
Архитектура
Весь протокол в основном включает два смарт-контракта, связанных с активами пользователей. Первый — это PufferDepositor, второй — PufferVault.
Основная функциональность PufferDepositor заключается в приеме пользовательских активов и последующем их внесении в PufferVault. Если внесенные пользователями активы не являются stETH, протокол автоматически выполняет обмен через DEX.
PufferVault — это основной контракт, который хранит активы пользователей. Он также является точкой входа для депозитов в EigenLayer. Основной контроль доступа ко всему протоколу реализован именно в этом смарт-контракте.
Механизм контроля доступа
Весь контроль доступа реализован с использованием модуля AccessManager от OpenZeppelin. Смарт-контракт AccessManager управляет полномочиями контрактов PufferDepositor и PufferVault.
AccessManager определяет различные роли, которые включают различные адреса. Каждая роль может быть назначена для вызова различных функций внутри контрактов с управлением доступом (то есть PufferDepositor и PufferVault). AccessManager поддерживает отложенное выполнение определенных функций. Это означает, что при предоставлении роли адресу можно указать, должны ли операции, инициированные этим адресом в рамках данной роли, выполняться немедленно или с задержкой по времени.
Текущие конфигурации контроля доступа
Тем не менее, эффективность контроля доступа зависит от его настройки. Мы наблюдали многочисленные случаи, когда ошибочная конфигурация правил ACL (списка контроля доступа) приводила к уязвимостям безопасности.
Чтобы решить эту проблему, мы изучили текущую конфигурацию протокола Puffer и представляем результаты ниже. Обратите внимание, что эти результаты отражают состояние только по состоянию на блок 19177155 (7 февраля 2024 г., 15:17:35 UTC).
Роли
Ниже представлена таблица с описанием текущих ролей в системе и связанных с ними адресов.
| ID роли | Адреса с этой ролью | Отложенное выполнение | Примечание |
|---|---|---|---|
| 0 | TimeLock 0x3c28b7c7ba1a1f55c9ce66b263b33b204f2126ea | Нет | Роль ADMIN |
| 1 | Operation SafeWallet 0xc0896ab1a8cae8c2c1d27d011eb955cca955580d | Да, 604800 секунд (7 дней) | Обновление целевых контрактов (PufferDepositor и PufferVault) |
| 1 | Community SafeWallet 0x446d4d6b26815f9ba78b5d454e303315d586cb2a | Нет | Обновление целевых контрактов (PufferDepositor и PufferVault) |
| 22 | Operation SafeWallet 0xc0896ab1a8cae8c2c1d27d011eb955cca955580d | Нет | Перемещение активов в EigenLayer и инициация запроса на вывод из EigenLayer |
Существуют различные пути выполнения функций внутри контракта PufferVault. Один путь связан с контрактом TimeLock (с ролью ADMIN — путь 1 на рисунке), другой путь позволяет напрямую вызывать функции внутри хранилища с ролью, назначенной вызывающему лицу. В обоих случаях вызов должен проходить через AccessManager.
Тип I: Вызов из контракта TimeLock
Обратите внимание, что при вызове функции из контракта TimeLock назначенной ролью является ADMIN. Это обозначение возникает из-за того, что с точки зрения хранилища вызывающим объектом является контракт TimeLock, который обладает ролью ADMIN. Следовательно, контракт TimeLock включает дополнительный уровень механизма отложенного выполнения.
- Operation SafeWallet: Этот компонент может вызывать функции внутри целевого контракта с задержкой в 604 800 секунд (примерно 7 дней).
- Community SafeWallet: Этот компонент обладает способностью немедленно вызывать функции внутри целевого контракта. Он также обладает полномочиями отменять любое ожидающее выполнение в очереди, отправленное Operation SafeWallet.
- Pausing SafeWallet: Этот компонент имеет право только на приостановку целевого контракта и не уполномочен выполнять какие-либо другие функции.
Тип II: Прямой вызов контракта Vault
Следующий метод предполагает прямые вызовы функций внутри контракта Vault. Важно отметить, что AccessManager диктует, какие функции могут быть вызваны адресами, связанными с каждой ролью.
| ID роли | Целевой контракт | Целевая функция |
| 1 | PufferVault | upgradeToAndCall(address,bytes)
0x4f1ef286 |
| 22 | PufferVault | depositToEigenLayer (0x008e0590)
initiateETHWithdrawalsFromLido (0x593961de) initiateStETHWithdrawalFromEigenLayer (0x402064a7) |
Как Operation SafeWallet, так и Community SafeWallet имеют возможность напрямую вызывать функцию upgradeToAndCall для обновления целевого контракта. Ключевое различие заключается во времени: Community SafeWallet выполняет это действие без какой-либо задержки, тогда как Operation SafeWallet подлежит задержке.
Более того, Operation SafeWallet оснащен функциями для немедленного перевода активов в EigenLayer и инициации запросов на вывод средств.
Обновлено [8 февраля 2024 г., 10:02:59 UTC]
Запланирована операция по удалению Operation SafeWallet из роли 1. Эта операция намечена к выполнению после блока 1707940908, что соответствует расчетной задержке примерно в 7 дней. Моделирование этих транзакций в очереди было проведено с использованием BlockSec Phalcon.
- Смоделированная транзакция в Phalcon Fork для выполнения отложенного вызова 18 февраля 2024 г. в 17:59:07 (UTC), десять дней спустя.
- Смоделированная транзакция для проверки того, осталась ли у Operation SafeWallet роль 1 (возвращает false).
Обновлено [16 февраля 2024 г., 20:10:23 UTC]:
- Транзакция по удалению Operation SafeWallet из роли 1 была выполнена. Мы можем проверить результат на Etherscan.
Конфигурации Safe Wallet
Конфигурация кошелька Safe также влияет на безопасность протокола.
| Кошелек | Владельцы | Порог |
|---|---|---|
| 0xC0896ab1A8cae8c2C1d 27d011eb955Cca955580d | [0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76] [0xD6475ce37d964d4816715FdafFEeAAf2958948bE] [0xD70aa9d7280E6FEe89B86f53c0B2A363478D5e94] [0xa5F84b556d5FD8959165Eff0324DCFEa164fA089] [0xf061f1FceFa32b3bbD5d18c5A623DB64bfBc107D] [0x206846dE1F372A9a603e672ba97A5238cC89aeAA] | 3 |
| 0x446d4d6b26815f9bA78 B5D454E303315D586Cb2a | [0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76] [0x3B16821A5dBBFF86E4a88eA0621EC6be016cd79A] [0x648aA14e4424e0825A5cE739C8C68610e143FB79] [0x27c7CEd729280060577A68A54A94075D18614D19] [0xa9aE3B8FC1CBaAed74fE5889260f7cD743c50363] [0x161f479021044cB1C9e3DEF98aF945A8D972D3B2] | 3 |
| 0x1ba8e3aA853F73ae809 3E26B7B8F2520c3620Df4 | [0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76] [0x3B16821A5dBBFF86E4a88eA0621EC6be016cd79A] [0x648aA14e4424e0825A5cE739C8C68610e143FB79] [0x27c7CEd729280060577A68A54A94075D18614D19] [0xa9aE3B8FC1CBaAed74fE5889260f7cD743c50363] [0x161f479021044cB1C9e3DEF98aF945A8D972D3B2] [0xD6475ce37d964d4816715FdafFEeAAf2958948bE] [0xD70aa9d7280E6FEe89B86f53c0B2A363478D5e94] [0xa5F84b556d5FD8959165Eff0324DCFEa164fA089] [0xf061f1FceFa32b3bbD5d18c5A623DB64bfBc107D] [0x206846dE1F372A9a603e672ba97A5238cC89aeAA] [0xaACA1eDbb656206Ce2a82Da7d7BD3e1Bb8138F22] | 1 |
Обновлено [8 февраля 2024 г., 10:02:59 UTC]:
- Адрес 0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76 был удален из Operation SafeWallet, что изменило его настройки авторизации до 3/5.
- Инициирована транзакция по удалению 0xb7d83623906AC3fa577F45B7D2b9D4BD26BC5d76 из Community SafeWallet, которая в настоящее время ожидает одобрения мультиподписью от сообщества.
- Три кошелька были удалены из Pausing SafeWallet, теперь его конфигурация скорректирована до 1/9.
Итог
В этом блоге мы рассмотрели механизмы безопасности, используемые протоколом Puffer. В целом, дизайн всей системы разрешений является комплексным.
Сообщество должно активно следить за потенциальными рисками:
- Безопасность закрытых ключей владельцев Community SafeWallet имеет первостепенное значение. Если три закрытых ключа будут скомпрометированы, это может позволить злоумышленнику обновить хранилище.
- Безопасность зависимых протоколов, таких как EigenLayer, также должна находиться под активным мониторингом.
