Я только что написал анализ проблемы повторного вызова — вопроса безопасности, который многие разработчики всё ещё игнорируют при создании смарт-контрактов.

Проще говоря, reentrancy — это ситуация, когда смарт-контракт вызывается повторно до завершения первого вызова. Представьте так: ContractA выполняет функцию, вызывает ContractB, а ContractB в свою очередь вызывает обратно ContractA, пока тот ещё не завершил выполнение. Это — уязвимость, которую злоумышленник может использовать.

Конкретный пример: EtherStore содержит 10 Ether, ContractB уже отправил 1 Ether. Когда ContractB вызывает функцию вывода, он проверяет, есть ли у него баланс больше нуля, и если да — отправляет Ether обратно. Но тут кроется опасность — обновление баланса до нуля происходит после отправки. Поэтому злоумышленник может создать fallback-функцию, которая при получении Ether снова вызывает функцию вывода. Этот цикл будет продолжаться, пока все Ether не будут выведены.

Я расскажу о трёх способах защиты от reentrancy:

Первый — использование модификатора nonReentrant. Этот способ блокирует контракт во время выполнения функции, чтобы никто не мог повторно вызвать её. Простое, но эффективное решение для отдельной функции.

Второй — применение шаблона Checks-Effects-Interactions. Вместо обновления баланса после отправки, делайте это заранее. Так, даже если произойдет повторный вызов, баланс уже будет равен нулю, и проверка не пропустит.

Третий — создание отдельного глобального контракта GlobalReentrancyGuard. Этот метод использует общий флаг состояния для контроля reentrancy во многих контрактах одновременно. Особенно полезно, если ваш проект включает взаимодействие нескольких контрактов. Вместо проверки в каждом контракте, вы делаете это централизованно.

Проблема reentrancy не нова, но остаётся одной из самых распространённых уязвимостей. Я вижу, что многие разработчики всё ещё не применяют эти меры последовательно. Если вы работаете с Solidity, убедитесь, что хорошо понимаете эту проблему и внедряете хотя бы один из трёх методов в свой проект. Безопасность смарт-контрактов — не опция, а обязательное требование.