Reentrancy, DELEGATECALL, CREATE2 и SELFDESTRUCT после EIP-6780 — это четыре “узких места” безопасности Ethereum, которые регулярно всплывают в инцидентах DeFi. Они относятся к разным уровням: reentrancy ломает логику при внешних вызовах, delegatecall — ломает границы доверия в прокси-архитектуре, CREATE2 даёт детерминированные адреса и открывает класс атак на “ожидаемые” контракты, а SELFDESTRUCT после EIP-6780 поменял семантику “самоуничтожения”, из-за чего старые допущения в коде и аудите стали неверными.

Ниже — практичный разбор: как это работает, где чаще ошибаются, какие последствия для пользователей и что именно проверять в аудите. Справочные страницы в нашей Wiki: Reentrancy, DELEGATECALL, CREATE2, SELFDESTRUCT после EIP-6780.

1) Карта темы: что именно “ломается” в каждом случае

2) Reentrancy: почему “порядок действий” важнее, чем кажется

2.1 Что происходит

Reentrancy возникает, когда контракт делает внешний вызов (например, отправка ETH или вызов другого контракта) до того, как обновит своё внутреннее состояние. Внешний контракт (или fallback/receive) может выполнить код и войти обратно в вашу функцию, пока у вас ещё “старые” значения баланса, лимитов или флагов.

2.2 Где чаще всего ошибаются

• Withdraw-логика: “сначала отправим, потом уменьшим баланс”.
• Сложные маршруты: один вызов запускает цепочку из нескольких контрактов и возвращается в исходный.
• Токены/хуки: контракты, которые вызывают колбэки при трансфере/получении, расширяют поверхность входа.
• Смешение учёта и эффектов: расчёты завязаны на внешнее состояние, которое меняется в процессе.

2.3 Мини-пример (упрощённо)

// ПЛОХО: внешний вызов до изменения состоянияfunction withdraw(uint256 amount) external { require(balances[msg.sender] >= amount, "no funds"); (bool ok,) = msg.sender.call{value: amount}(""); require(ok, "send failed"); balances[msg.sender] -= amount;}

Если msg.sender — контракт, он может в fallback снова вызвать withdraw() и пройти require(), пока balances ещё не уменьшен.

2.4 Как защищаются (без “магии”)

• Checks-Effects-Interactions: сначала проверки, потом обновление состояния, и только потом внешний вызов.
• Reentrancy guard: блокировка повторного входа в чувствительные функции.
• Pull-payments: вместо “отправить сейчас” — записать долг и дать пользователю забрать отдельно.
• Минимизировать внешние вызовы внутри одной функции и делать их в конце.

3) DELEGATECALL: почему прокси — это “исполняем чужой код у себя дома”

3.1 Суть delegatecall

DELEGATECALL позволяет выполнить код другого контракта, но в контексте вашего storage и вашего адреса. Это фундамент прокси-паттернов: у вас есть “прокси-контракт” (адрес, который знают пользователи) и “имплементация” (логика), которую можно менять.

Ключевой эффект: если злоумышленник заставит прокси делегировать вызов “не той” имплементации — он получает контроль над состоянием прокси: балансами, правами, настройками, адресами внешних контрактов.

3.2 Где чаще всего ломаются

• Неправильная инициализация: забыли закрыть initializer — кто-то становится админом.
• Storage collision: несовместимый layout переменных между версиями (или между прокси и логикой).
• Управление апгрейдом: апгрейд доступен без задержек/контроля/ограничений.
• delegatecall в “библиотеку”, которой нельзя доверять: подмена адреса библиотеки, уязвимый registry.

3.3 Почему это опасно для пользователей

Прокси — это нормально и распространено. Риск появляется, когда “контракт” на известном адресе может стать другим завтра, а правила апгрейда завязаны на ключ/DAO/мультисиг, и в критический момент апгрейд может:

• изменить комиссии и лимиты,
• поменять адреса стратегий/хранилищ,
• изменить логику вывода/депозита,
• в худшем случае — открыть возможность вывода средств.

4) CREATE2: детерминированные адреса и “ловушки на ожидании”

4.1 Что даёт CREATE2

CREATE2 позволяет заранее знать адрес контракта, ещё до его деплоя: адрес зависит от (1) адреса деплойера, (2) salt, (3) хэша init-кода. Это удобно для “counterfactual” сценариев (например, кошельки/аккаунт-абстракция/предварительные адреса), но создаёт новые классы угроз.

4.2 Типовые риски CREATE2

• Фронт-ран/подмена ожиданий: если вы “ждёте”, что по адресу появится ваш контракт, но условия вычисления адреса можно воспроизвести/подменить — атакующий может занять адрес “своей” логикой (или создать ловушку в маршруте деплоя).
• Опасные allowlist/доверие по адресу: “разрешим этому адресу, потому что он будет нашим контрактом”. Адрес сам по себе — не гарантия того, какой код там окажется.
• Депозиты на ‘пустой адрес’: отправка средств на адрес будущего контракта без строгой гарантии корректного деплоя и контроля над salt/init_code.
• Метаморфные сценарии: исторически CREATE2 пытались сочетать с SELFDESTRUCT для “переиспользования” адреса под новый код. После EIP-6780 это сильно ограничено, но в аудите всё равно проверяют, не полагается ли система на старую логику.

4.3 Практичный вывод

CREATE2 безопасен как инструмент, но опасны допущения вокруг него: “адрес известен” ≠ “код неизменен/правильный”. Любая логика, завязанная на доверие к адресу без проверки кода/инициализации/прав, требует повышенного внимания.

5) SELFDESTRUCT после EIP-6780: что реально изменилось и почему это важно

5.1 Как было “раньше” (упрощённо)

Исторически SELFDESTRUCT воспринимали как “удалить контракт”: уничтожить код и storage, отправить ETH на получателя и освободить ресурсы. Из этого выросли опасные паттерны:

• “kill-switch” (нажмём кнопку — контракт исчезнет),
• “миграция через самоуничтожение”,
• “освободим storage и вернём газ”.

5.2 Как стало после EIP-6780 (главный факт)

После EIP-6780 SELFDESTRUCT обычно больше не удаляет код и storage. В большинстве случаев он работает как операция, которая переводит ETH на указанный адрес, но оставляет контракт (код/хранилище) на месте.

Исключение: если SELFDESTRUCT вызывается контрактом, который был создан в той же транзакции, тогда “старое” поведение удаления может сохраниться для этого частного случая. Это важная деталь для аудита сложных фабрик и сценариев “создал → использовал → уничтожил” в одном tx.

5.3 Что ломается в проектах из-за этого

• Иллюзия “удалили контракт”: пользователи и даже разработчики думают, что адрес пустой и безопасный — но код остаётся.
• Ломаются схемы address-recycle: попытки “переиспользовать адрес” под новый код через selfdestruct становятся непредсказуемыми/неработающими в старом смысле.
• Нельзя рассчитывать на “освобождение storage” как на механизм управления ресурсами и газ-рефанд.
• Kill-switch должен быть логическим (pause/withdraw/upgrade), а не “магическим исчезновением”.

6) Чек-лист аудита: что проверять именно по этим 4 классам рисков

• Reentrancy: внешние вызовы идут после обновления состояния (или есть guard); нет повторного входа через колбэки/хуки.
• DELEGATECALL: initializer закрыт; апгрейд защищён (роль/мультисиг/задержки); storage layout совместим между версиями.
• CREATE2: нет доверия “по адресу” без проверки кода; salt/init_code контролируются; нет депозитов на адрес “когда-нибудь появится”.
• SELFDESTRUCT: не используется как “удаление контракта”; нет критической логики, завязанной на адрес-recycle или gas-refund; исключение “создан в той же tx” рассмотрено.
• Интеграции: внешние контракты считаются недоверенными; ошибки/возвраты проверяются; нет скрытых reentrancy через токены/DEX.
• Операционные права: кто может менять имплементацию/паузы/адреса зависимостей — и что будет при компрометации ключа.

7) FAQ

Полезные ссылки

• Аудит смарт-контрактов: как читать отчёт и что должно насторожить
• Риски CREATE2: предсказуемые адреса, ловушки и типовые ошибки