Aave Labs уточнила, что предлагаемое обновление безопасности V3.8 сохранит ликвидации через флеш-займы. Ответ от 23 октября поясняет, как защита от повторного входа будет взаимодействовать с существующими интеграциями.
Кратко: Предложенная защита Aave V3.8 исключает точки входа для флеш-займов. Одобрение со стороны управления и аудиты безопасности остаются в ожидании.
Предложение, опубликованное 21 октября, добавляет защиту для операций пула. Такие защиты ограничивают возможность внешнего обратного вызова повторно входить в защищенные функции контракта до завершения предыдущего вызова. Aave Labs сообщает, что flashLoan() и flashLoanSimple() будут исключены, что позволит их обратным вызовам продолжать вызывать действия пула, включая ликвидации.
Почему обратный вызов важен
Смарт-контракт, получающий флеш-займ, нуждается во времени внутри транзакции, чтобы что-то сделать с заимствованными активами. Руководство для разработчиков Aave описывает последовательность, при которой Pool переводит активы, вызывает смарт-контракт получателя, а затем проверяет условия расчета.
Для простого флеш-займа получатель должен предоставить сумму займа и необходимую комиссию для погашения. Если транзакция не может выполнить свои условия, она отменяется. Более широкий интерфейс флеш-займа может охватывать несколько активов и, при разрешенных условиях, открывать позицию с обеспечением в виде залога.
Эти механизмы объясняют, почему важно, чтобы охранник охватывал определённый объём. Интеграция ликвидации может потребовать взять в долг актив, погасить нездоровую позицию и завершить остальную часть транзакции до расчёта. Блокировка всех последующих взаимодействий с пулом без исключения нарушит эту последовательность.
Важный вопрос дизайна — какие маршруты обратно в протокол являются преднамеренными. Эффективная граница безопасности должна учитывать шаблоны транзакций, от которых зависят интеграции, включая вызовы, происходящие после того, как активы покинули Пул, но до проверки возврата.
Блокировка по длине транзакции
Предлагаемая реализация использует временное хранилище, введенное через Ethereum’s EIP-1153. Это хранилище доступно в течение транзакции и удаляется по ее завершении. Оно может использоваться для передачи временного состояния блокировки, чтобы отслеживать, запущена ли уже защищенная операция.
Спецификация идентифицирует блокировки повторного входа как использование и объясняет, почему временное хранилище может стоить меньше, чем запись временного состояния в постоянное хранилище. Для широко используемого протокола DeFi вопрос проектирования включает стоимость, накладываемую на обычные транзакции, а также защиту, предоставляемую защитным механизмом.
Предложенный путь Aave включает сбор отзывов, голосование через Snapshot, проверку безопасности и предложение об улучшении в цепочке. Certora и другие рецензенты должны оценить изменения до этого финального этапа.
Для интеграторов на Ethereum и других затронутых сетях данное уточнение предоставляет конкретную точку совместимости для проверки по сравнению с окончательным кодом. Проверенная реализация должна сохранять предполагаемую последовательность транзакций при соблюдении нового ограничения. Заявление о намерениях в дизайне полезно в ходе этой работы; поведение после развертывания будет зависеть от того, какую реализацию в конечном итоге одобрит управление.
Написано редакцией новостей и отредактировано Самуэлем Рэем.