TLDR: ERC-4626 — это стандарт для токенизированных хранилищ.
До введения ERC-4626 каждое хранилище имело свою собственную спецификацию и детали реализации. Это делает интеграцию сложной, подверженной ошибкам и расточительной трате ресурсов.
ERC-4626 пытается решить эту проблему с помощью стандартной спецификации, чтобы уменьшить усилия по интеграции и создать более последовательную и надежную модель реализации, как и ERC-20.
Что такое ERC-4626?
ERC-4626 — это стандарт, улучшающий технические параметры доходных хранилищ. Он предоставляет стандартный API для доходных хранилищ, представляющих доли одного базового токена ERC-20.
Токенизированные хранилища стали чрезвычайно распространенной моделью в DeFi. Агрегаторы доходности, кредитные рынки, производные инструменты для ставок и многие другие dApps используют токенизированные хранилища и полагаются на них. Примеры токенизированных хранилищ включают Yearn и Balancer. В качестве агрегатора доходности Yearn Vault позволяет пользователям вносить цифровые активы и получать доход. Balancer — это автоматизированный менеджер портфеля и поставщик ликвидности, который полагается на хранилища в основе своей бизнес-логики. Эти хранилища управляют токенами в различных пулах. При этом они отделяют управление токенами от логики самого пула.
Протокол повышает ликвидность и гибкость за счет токенизации своих хранилищ. Токенизированные хранилища упрощают транзакции и использование активов на платформах DeFi. Кроме того, они позволяют создавать разнообразные взаимосвязанные финансовые продукты. Промышленность отстаивает эту парадигму, которую часто называют «Лего за деньги».
Однако компонуемость без надлежащей адаптивности или стандартизации представляет собой проблему. Это не только усложняет разработчикам соблюдение отраслевых стандартов, таких как ERC-20, но также может сбить с толку новых разработчиков. Без надлежащей адаптации или стандартизации сложно просматривать новые изменения и проверять детали реализации интеграций.
Поэтому ERC-4626 был предложен для решения этой проблемы и упрощения интеграции, позволяя участникам DeFi, наконец, принять более безопасную и надежную спецификацию унифицированного хранилища. Это, в свою очередь, уменьшит возможную поверхность атаки протокола при интеграции токенов в несколько протоколов.
Какие проблемы безопасности может предотвратить ERC-4626?
Предоставляя единый стандарт, ERC-4626 ускоряет построение межпротокольной интеграции. Знакомые, согласованные стандарты также легче понять разработчикам, что снижает вероятность ошибок кодирования. Это помогает предотвратить проблемы компоновки. Стандартизация также предотвращает дублирование усилий, поскольку сообществу необходимо разработать хранилище только один раз, а не индивидуально для каждого протокола. Поскольку эти усилия по проектированию часто подвержены ошибкам, они помогают избежать дублирования установленных, но широко распространенных недостатков проектирования.
Мы представим здесь два тематических исследования, чтобы показать, какие проблемы может предотвратить ERC-4626.
Событие Rari Capital
У Rari Capital было украдено токенов на сумму около 11 миллионов долларов, что эквивалентно 60% всех средств пользователей в пуле Rari Capital Ethereum.
В целом Rari Capital был взломан из-за небезопасной реализации кросс-протокола. Его пул Ethereum включает ETH в токен-контракт ibETH Alpha Finance в качестве стратегии вывода. Эта конкретная стратегия отслеживает значение своего курса обмена ibETH/ETH через определенные контракты и формулы (в частности, функцию ibETH.totalETH / ibETH.totalSupply), которые могут иметь ошибочные выходные данные в этом сценарии атаки, например, при вызове ibETH.work ( ), значения долга могут быть искусственно завышены.
Злоумышленник может исчерпать возможности Rari Fund Manager, просто многократно вызывая функции депозита и вывода средств в контракте RariFundManager. Функции депозита и снятия должны получить баланс пула, чтобы рассчитать количество токенов REPT, которые будут выданы вызывающей стороне, или количество ETH, которое будет выдано вызывающей стороне.Эта операция вызовет функцию getBalance пула Alpha. , вызовите контракт ibETH и его функцию totalETH. Рари не знает о возможности манипулирования этой функцией.
В контракте ibETH есть еще одна функция: ibETH.work. Эта функция может вызывать любой контракт, указанный пользователем. Это позволяет функциям ввода и вывода средств Rari повторно входить и вызываться несколько раз.
Рабочая функция является платной функцией, что означает, что пользователь может контролировать количество ETH в контракте ibETH через рабочую функцию, тем самым изменяя значение, возвращаемое функцией 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 не должна использовать переменную decimals хранилища EIP-4626, по-прежнему настоятельно рекомендуется отражать десятичные дроби базового токена, где это возможно. Эта практика помогает устранить потенциальные источники путаницы и упрощает интеграцию для различных внешних пользователей и пользователей вне сети.
округление
Согласно спецификации, разработчики хранилища должны знать, что в различных изменяемых методах и методах представления требуются определенные и противоположные направления округления, поскольку во время вычислений безопаснее отдавать предпочтение самому хранилищу, а не его пользователям:
Если он рассчитывает количество акций, которые будут выпущены пользователю на сумму некоторого базового токена, который они предлагают, или если он работает для передачи определенной доли базового токена пользователю, это значение следует округлить в меньшую сторону.
Если он вычисляет, сколько акций пользователь должен отдать, чтобы получить определенное количество базовых токенов, или если он вычисляет, сколько базовых токенов должен отдать пользователь, чтобы получить определенное количество долей, он должен быть округленным.
Где предпочтительное направление округления будет неоднозначным, так это в функции convertTo. Чтобы обеспечить согласованность во всех реализациях хранилища EIP-4626, укажите, что эти функции всегда должны округляться в меньшую сторону. Интеграторы могут сами имитировать сводную версию, например, добавляя к результату Wei.
Сумма базовых активов, которую пользователь получает, выкупив свою долю в хранилище (previewRedeem), может значительно отличаться от суммы, которую нужно было бы заплатить, чтобы выпустить ту же сумму доли (previewMint). Эти различия могут быть небольшими (например, из-за ошибок округления) или большими (например, хранилище взимает комиссию за снятие или депозит). Таким образом, интеграторы должны позаботиться о том, чтобы использовать функции предварительного просмотра, которые лучше всего подходят для их варианта использования, и никогда не предполагать, что они взаимозаменяемы.
Переопределить основные функции
Чтобы реализовать или расширить предполагаемую функциональность, рекомендуется использовать существующие хуки вместо изменения основной функциональности. Эта практика обеспечивает более управляемый след для эффективного тестирования и аудита кода.
Нулевая доля
Первоначальная спецификация ERC-4626 не описывала, как обрабатывать крайний случай отсутствия общих ресурсов в хранилище и должно ли хранилище вести себя как обычно или выполнять откат. Это может быть потенциальным источником путаницы и ошибок.
Хранилища как ценовые оракулы
Что касается риска атак манипулирования ценами оракула, значения, возвращаемые этими методами предварительного просмотра, максимально приближены к точным. Таким образом, они могут работать, изменяя условия в сети, и их не всегда безопасно использовать в качестве ценовых оракулов. Спецификация ERC-4626 включает метод convert и метод totalAssets, которые допускают неточность и, таким образом, могут быть реализованы как мощный ценовой оракул. Например, при конвертации между активами и акциями правильно использовать средневзвешенную по времени цену для реализации метода конвертации.
Конкретные проблемы реализации
Перед дальнейшей интеграцией интеграторы должны проверить любую реализацию токенизированного хранилища, поскольку могут существовать вредоносные реализации, которые соответствуют спецификации интерфейса, но чьи основные функции состоят из совершенно других спецификаций дизайна.
Прямой доступ к EOA
Если к хранилищу нужно получить прямой доступ, его реализация должна иметь функции, которые можно использовать для компенсации потерь из-за проскальзывания или случайных ограничений на ввод/вывод средств. В отличие от смарт-контрактов, EOA не имеет отказоустойчивого механизма отката транзакций, и если при вызове основной функции не достигается точный вывод, откат невозможен.
Расширенное хранилище
По мере того, как все больше игроков начнут принимать стандарт ERC-4626, мы увидим больше расширений, реализованных для стандарта. Например, Superform разработала экспериментальное расширение Multi Vault, которое поддерживает использование различных вычислений в рамках одного контракта Vault. Естественно, чем больше реализация отклоняется от исходного стандарта, тем выше вероятность внедрения новых уязвимостей. Разработчики и аудиторы могут найти наилучший вариант на основе варианта использования, чтобы определить фактическую ценность, подверженную риску.
Важно отметить, что к катастрофическим событиям приводит не наименьшее добавление каждого протокола, а их сумма при интеграции.
Упомянутые выше потенциальные векторы атак являются одними из наиболее обсуждаемых вопросов, связанных со стандартом ERC-4626. По мере роста внедрения мы обязательно изучим больше вариантов использования реализации и более подходящие сценарии для интеграции с хранилищами ERC-4626.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Понимание 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. Кроме того, они позволяют создавать разнообразные взаимосвязанные финансовые продукты. Промышленность отстаивает эту парадигму, которую часто называют «Лего за деньги».
Однако компонуемость без надлежащей адаптивности или стандартизации представляет собой проблему. Это не только усложняет разработчикам соблюдение отраслевых стандартов, таких как ERC-20, но также может сбить с толку новых разработчиков. Без надлежащей адаптации или стандартизации сложно просматривать новые изменения и проверять детали реализации интеграций.
Поэтому ERC-4626 был предложен для решения этой проблемы и упрощения интеграции, позволяя участникам DeFi, наконец, принять более безопасную и надежную спецификацию унифицированного хранилища. Это, в свою очередь, уменьшит возможную поверхность атаки протокола при интеграции токенов в несколько протоколов.
Какие проблемы безопасности может предотвратить ERC-4626?
Предоставляя единый стандарт, ERC-4626 ускоряет построение межпротокольной интеграции. Знакомые, согласованные стандарты также легче понять разработчикам, что снижает вероятность ошибок кодирования. Это помогает предотвратить проблемы компоновки. Стандартизация также предотвращает дублирование усилий, поскольку сообществу необходимо разработать хранилище только один раз, а не индивидуально для каждого протокола. Поскольку эти усилия по проектированию часто подвержены ошибкам, они помогают избежать дублирования установленных, но широко распространенных недостатков проектирования.
Мы представим здесь два тематических исследования, чтобы показать, какие проблемы может предотвратить ERC-4626.
Событие Rari Capital
У Rari Capital было украдено токенов на сумму около 11 миллионов долларов, что эквивалентно 60% всех средств пользователей в пуле Rari Capital Ethereum.
В целом Rari Capital был взломан из-за небезопасной реализации кросс-протокола. Его пул Ethereum включает ETH в токен-контракт ibETH Alpha Finance в качестве стратегии вывода. Эта конкретная стратегия отслеживает значение своего курса обмена ibETH/ETH через определенные контракты и формулы (в частности, функцию ibETH.totalETH / ibETH.totalSupply), которые могут иметь ошибочные выходные данные в этом сценарии атаки, например, при вызове ibETH.work ( ), значения долга могут быть искусственно завышены.
Злоумышленник может исчерпать возможности Rari Fund Manager, просто многократно вызывая функции депозита и вывода средств в контракте RariFundManager. Функции депозита и снятия должны получить баланс пула, чтобы рассчитать количество токенов REPT, которые будут выданы вызывающей стороне, или количество ETH, которое будет выдано вызывающей стороне.Эта операция вызовет функцию getBalance пула Alpha. , вызовите контракт ibETH и его функцию totalETH. Рари не знает о возможности манипулирования этой функцией.
В контракте ibETH есть еще одна функция: ibETH.work. Эта функция может вызывать любой контракт, указанный пользователем. Это позволяет функциям ввода и вывода средств Rari повторно входить и вызываться несколько раз.
Рабочая функция является платной функцией, что означает, что пользователь может контролировать количество ETH в контракте ibETH через рабочую функцию, тем самым изменяя значение, возвращаемое функцией 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 не должна использовать переменную decimals хранилища EIP-4626, по-прежнему настоятельно рекомендуется отражать десятичные дроби базового токена, где это возможно. Эта практика помогает устранить потенциальные источники путаницы и упрощает интеграцию для различных внешних пользователей и пользователей вне сети.
округление
Согласно спецификации, разработчики хранилища должны знать, что в различных изменяемых методах и методах представления требуются определенные и противоположные направления округления, поскольку во время вычислений безопаснее отдавать предпочтение самому хранилищу, а не его пользователям:
Если он рассчитывает количество акций, которые будут выпущены пользователю на сумму некоторого базового токена, который они предлагают, или если он работает для передачи определенной доли базового токена пользователю, это значение следует округлить в меньшую сторону.
Если он вычисляет, сколько акций пользователь должен отдать, чтобы получить определенное количество базовых токенов, или если он вычисляет, сколько базовых токенов должен отдать пользователь, чтобы получить определенное количество долей, он должен быть округленным.
Где предпочтительное направление округления будет неоднозначным, так это в функции convertTo. Чтобы обеспечить согласованность во всех реализациях хранилища EIP-4626, укажите, что эти функции всегда должны округляться в меньшую сторону. Интеграторы могут сами имитировать сводную версию, например, добавляя к результату Wei.
Сумма базовых активов, которую пользователь получает, выкупив свою долю в хранилище (previewRedeem), может значительно отличаться от суммы, которую нужно было бы заплатить, чтобы выпустить ту же сумму доли (previewMint). Эти различия могут быть небольшими (например, из-за ошибок округления) или большими (например, хранилище взимает комиссию за снятие или депозит). Таким образом, интеграторы должны позаботиться о том, чтобы использовать функции предварительного просмотра, которые лучше всего подходят для их варианта использования, и никогда не предполагать, что они взаимозаменяемы.
Переопределить основные функции
Чтобы реализовать или расширить предполагаемую функциональность, рекомендуется использовать существующие хуки вместо изменения основной функциональности. Эта практика обеспечивает более управляемый след для эффективного тестирования и аудита кода.
Нулевая доля
Первоначальная спецификация ERC-4626 не описывала, как обрабатывать крайний случай отсутствия общих ресурсов в хранилище и должно ли хранилище вести себя как обычно или выполнять откат. Это может быть потенциальным источником путаницы и ошибок.
Хранилища как ценовые оракулы
Что касается риска атак манипулирования ценами оракула, значения, возвращаемые этими методами предварительного просмотра, максимально приближены к точным. Таким образом, они могут работать, изменяя условия в сети, и их не всегда безопасно использовать в качестве ценовых оракулов. Спецификация ERC-4626 включает метод convert и метод totalAssets, которые допускают неточность и, таким образом, могут быть реализованы как мощный ценовой оракул. Например, при конвертации между активами и акциями правильно использовать средневзвешенную по времени цену для реализации метода конвертации.
Конкретные проблемы реализации
Перед дальнейшей интеграцией интеграторы должны проверить любую реализацию токенизированного хранилища, поскольку могут существовать вредоносные реализации, которые соответствуют спецификации интерфейса, но чьи основные функции состоят из совершенно других спецификаций дизайна.
Прямой доступ к EOA
Если к хранилищу нужно получить прямой доступ, его реализация должна иметь функции, которые можно использовать для компенсации потерь из-за проскальзывания или случайных ограничений на ввод/вывод средств. В отличие от смарт-контрактов, EOA не имеет отказоустойчивого механизма отката транзакций, и если при вызове основной функции не достигается точный вывод, откат невозможен.
Расширенное хранилище
По мере того, как все больше игроков начнут принимать стандарт ERC-4626, мы увидим больше расширений, реализованных для стандарта. Например, Superform разработала экспериментальное расширение Multi Vault, которое поддерживает использование различных вычислений в рамках одного контракта Vault. Естественно, чем больше реализация отклоняется от исходного стандарта, тем выше вероятность внедрения новых уязвимостей. Разработчики и аудиторы могут найти наилучший вариант на основе варианта использования, чтобы определить фактическую ценность, подверженную риску.
Важно отметить, что к катастрофическим событиям приводит не наименьшее добавление каждого протокола, а их сумма при интеграции.
Упомянутые выше потенциальные векторы атак являются одними из наиболее обсуждаемых вопросов, связанных со стандартом ERC-4626. По мере роста внедрения мы обязательно изучим больше вариантов использования реализации и более подходящие сценарии для интеграции с хранилищами ERC-4626.