Смарт-контракт работает ровно так, как написан. Проблема в том, что ошибка в логике может стоить проекту миллионов. Ниже — 3 самые известные уязвимости, которые важно понимать разработчикам, аудиторам и даже пользователям Web3.
Reentrancy (повторный вход)
Это уязвимость, при которой внешний контракт успевает повторно вызвать функцию до того, как завершилось обновление состояния.
Как это происходит:
- контракт отправляет ETH пользователю
- до обновления баланса вызывается внешний адрес
- злоумышленник через fallback/receive повторно вызывает вывод средств
- деньги списываются много раз
Почему опасно:
- можно опустошить пул ликвидности или vault
- классический пример — взлом The DAO
Как защищаться:
- использовать паттерн Checks-Effects-Interactions
- сначала менять состояние, потом делать внешние вызовы
- применять ReentrancyGuard
- по возможности избегать ненужных external call
Overflow / Underflow (переполнение / отрицательное переполнение)
Возникает, когда число выходит за пределы типа. Раньше в Solidity это была критическая проблема: например, `uint8(255) + 1` превращалось в `0`.
Чем опасно:
- обход лимитов
- некорректный расчет балансов
- возможность искусственно занизить или завысить сумму
Что важно знать:
- в Solidity 0.8+ арифметика по умолчанию проверяется, и такие операции вызывают revert
- в старых контрактах часто использовали SafeMath
- риск все еще актуален при работе с `unchecked`
Как защищаться:
- использовать Solidity 0.8+
- минимизировать `unchecked` блоки
- тестировать граничные значения: 0, max uint, большие циклы
Frontrunning (опережающая транзакция)
Это атака на уровне мемпула. Злоумышленник видит неподтвержденную транзакцию и отправляет свою с более высокой комиссией, чтобы попасть в блок раньше.
Где встречается:
- DEX и swap-операции
- NFT mint
- аукционы
- liquidation в DeFi
Чем опасно:
- ухудшение цены для пользователя
- sandwich-атаки
- перехват выгодной сделки
Как защищаться:
- использовать commit-reveal там, где подходит
- задавать slippage tolerance разумно, а не “с запасом”
- применять private mempool / MEV-protection решения
- проектировать логику так, чтобы порядок транзакций не давал критического преимущества
Что проверять в смарт-контракте в первую очередь 🧠
- есть ли внешние вызовы до изменения state
- где используется арифметика и `unchecked`
- зависит ли результат от порядка транзакций
- можно ли повторно вызвать функцию
- есть ли защита от манипуляций ценой и мемпулом
Вывод
Reentrancy ломает логику вывода средств, overflow искажает расчеты, а frontrunning эксплуатирует сам механизм публикации транзакций. Безопасность смарт-контрактов — это не только синтаксис Solidity, но и понимание поведения EVM, мемпула и экономических атак 🚨
📌 Сохраняйте пост как мини-шпаргалку по базовым уязвимостям Web3.
И загляните в подборку каналов про IT — там много полезного по разработке, безопасности и инфраструктуре.