Смарт-контракты Ethereum — это программы в блокчейне, которые выполняются одинаково у всех узлов сети и меняют состояние (балансы, права, параметры протокола) строго по правилам кода. Если коротко объяснить, как работают смарт-контракты: вы отправляете транзакцию, EVM исполняет код, проверяет условия, списывает газ и либо фиксирует изменения, либо откатывает их. И вот здесь главный парадокс: смарт-контракты дают “автоматизацию без посредника”, но ломаются они обычно не из-за “хакерских магий”, а из-за банальных мест в логике — неверные права доступа, опасные внешние вызовы, прокси-апгрейды, оракулы цен и ошибки интеграций.

База терминов, если нужно освежить: смарт-контракт, EVM.

1) Как смарт-контракт вообще исполняется в Ethereum

1.1 Транзакция → EVM → изменение состояния

Любое действие со смарт-контрактом начинается с транзакции: вы подписываете её кошельком, сеть принимает, затем валидаторы включают её в блок. Дальше происходит исполнение в EVM (виртуальной машине Ethereum):

• контракт читает текущее состояние (storage),
• выполняет код шаг за шагом (опкоды),
• может вызывать другие контракты,
• в конце либо фиксирует изменения, либо откатывает всё (revert).

Ключевой момент: в блокчейне важен детерминизм. Один и тот же вход (транзакция + текущее состояние) должен давать один и тот же результат у всех узлов.

1.2 Зачем нужен gas и почему “ошибка” — это тоже результат

Gas — это “счётчик ресурсов”, чтобы никто не мог заставить сеть выполнять бесконечные вычисления. Вы задаёте лимит газа и цену, EVM тратит газ на операции. Если газ закончился — транзакция откатывается (изменения состояния не фиксируются), но газ уже потрачен на попытку исполнения. Поэтому типовая боль новичка: “ничего не произошло, но комиссия списалась”. На уровне EVM это логично: сеть работала, вычисляла, и за это берёт плату.

1.3 Состояние (storage), события (events) и “почему UI иногда врёт”

Контракт хранит данные в storage — это “постоянная память” в блокчейне. Кроме этого, контракт может эмитить events — события для логов. Интерфейсы (кошельки, обозреватели, DeFi-дашборды) часто строят отображение именно по событиям, потому что так быстрее. Но важно помнить:

• состояние — источник истины;
• events — удобные “записи в журнал”, которые могут не покрывать все случаи или быть интерпретированы по-разному.

2) Почему смарт-контракты ломаются: 8 типовых “классов поломок”

Почти все инциденты можно разложить на повторяющиеся шаблоны. Ниже — самые частые, с объяснением “почему” и “как это выглядит” с точки зрения пользователя.

3) Где именно “ломается” чаще всего: разбор по местам

3.1 Контроль доступа: “кто имеет право нажать красную кнопку”

Самая неочевидная для новичка причина потерь — не хак, а неправильно сконфигурированные права. Типовые сюжеты:

• функции админа могут менять критические параметры (комиссии, адреса, лимиты) без ограничений;
• owner хранится в одном ключе без задержек и без процедур;
• в контракте есть “пауза/заморозка”, но нет прозрачной политики её применения.

Для пользователя это выглядит так: “протокол внезапно поменял правила” или “выводы остановились”. Технически — это дизайн управления.

3.2 Внешние вызовы: когда вы “вышли из своего кода”

Смарт-контракт редко живёт один. Он вызывает токены, DEX, лендинги, оракулы. Как только контракт делает внешний вызов, он сталкивается с тем, что другой контракт может:

• вернуть неожиданный результат,
• вызвать обратный вызов,
• потребовать больше газа, чем вы ожидали,
• вести себя нестандартно (особенно токены с комиссией или ребейсом).

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

3.3 Reentrancy: классика, которая до сих пор актуальна

Reentrancy — это когда контракт отправляет средства/вызывает внешний контракт, а тот “заходит обратно” в вашу функцию до того, как вы обновили внутреннее состояние. В результате можно повторить вывод или повторно воспользоваться “старым” балансом. Это всё ещё один из самых известных классов ошибок в DeFi.

Почему это продолжает происходить в 2025+: потому что реэнтрантность появляется не только в “withdraw()”. Она всплывает в новых местах: в хуках, в колбэках DEX, при работе с ERC-777-подобными механиками, при сложной многоконтрактной архитектуре.

3.4 Прокси и апгрейды: когда контракт “как бы тот же”, но уже другой

Многие протоколы используют прокси-паттерны: адрес контракта остаётся тем же, но логика может обновляться. Это удобно для развития, но добавляет целый пласт рисков:

• storage layout: если вы поменяли порядок переменных/структур, можно повредить состояние;
• инициализация: забыли вызвать initializer — получили “неинициализированный” контракт, который может перехватить злоумышленник;
• админ-права апгрейда: кто и как может обновить логику, есть ли задержки и публичные процедуры.

С точки зрения пользователя это выглядит как “вчера работало, сегодня — нет” или “после апдейта появились странные условия”. Технически — это риск апгрейдируемости.

3.5 Оракулы цен: когда “истина” покупается одним свопом

Многие механики DeFi зависят от цены: займы, ликвидации, выпуск синтетики. Если протокол берёт цену из источника, который можно сместить в одном блоке (тонкий пул, низкая ликвидность), возникают манипуляции. Частые причины:

• использование spot-цены вместо усреднения (TWAP);
• проверки “сверху” отсутствуют или слабые;
• цена в одном месте используется как “святая истина” для расчёта залога.

Результат для пользователя — неожиданные ликвидации или “выгодные” сделки для атакующего.

3.6 MEV: когда порядок транзакций важнее вашей стратегии

MEV — это извлечение прибыли из порядка включения транзакций. Для пользователя это чаще всего проявляется на DEX:

• сэндвич-атаки (вас “обкладывают” сделками до и после);
• ухудшение курса при широком slippage;
• “в моменте всё выглядело нормально”, но итоговая цена хуже ожиданий.

Это не “поломка кода” в чистом виде, но это место, где UX ломается чаще всего: пользователь подписывает то, что формально допустимо, но экономически плохо.

3.7 Математика и округления: тихие ошибки без громкого взрыва

Ошибки округления редко выглядят как “минус все деньги за минуту”. Чаще это:

• перекос распределения долей пула,
• накопление “пыли” и дрейф в учёте,
• неожиданно выгодные условия для арбитража против протокола.

Особенно опасны места, где смешиваются разные decimal (6/8/18), и где в формулах есть целочисленные деления.

3.8 Интеграции токенов: ERC-20 “стандартный”, но не одинаковый

Даже если протокол идеально написан, он может “сломаться” на токене, который ведёт себя необычно:

• fee-on-transfer: вы отправили 100, а пришло 99 (комиссия в токене);
• rebase: баланс меняется независимо от ваших действий;
• нестандартные реализации ERC-20 (возвраты, события, поведение approve).

Для пользователя это выглядит как “депозит не сошёлся”, “вывод меньше”, “контракт завис”. Технически — это несовместимость предположений.

4) Как понять, что протокол “хрупкий”: красные флаги для пользователя

• Слишком много админ-власти без понятных ограничений (можно менять ключевые параметры без задержек).
• Апгрейды без прозрачности (нет понятной процедуры, нет временного окна, нет истории изменений).
• Сложная токеномика + мало времени на рынке (много зависимостей, мало боевого опыта).
• Оракул “из одного пула” или из источника с тонкой ликвидностью.
• Непонятно, что будет при перегрузке: есть ли лимиты, очереди, пауза, что произойдёт при отказе компонента.
• UI говорит одно, а контракт — другое: расхождения в цифрах, странные округления, “плавающие” балансы.

5) Что делать до взаимодействия со смарт-контрактом: чек-лист проверки

• Понимаю действие: что именно делает транзакция (deposit/borrow/swap/approve) и какие последствия у approve.
• Проверяю, апгрейдируем ли контракт и кто контролирует апгрейды/паузы.
• Смотрю на источник цены: откуда берётся цена для залога/ликвидаций.
• Оцениваю зависимости: токены с комиссией, ребейс-токены, внешние DEX/лендинги.
• Делаю тест небольшой суммой, особенно если маршрут новый (новая сеть/мост/протокол).
• Понимаю сценарий выхода: как вывести средства, какие лимиты/очереди, что будет в стресс-период.

Если хотите системно разбираться в качестве кода и отчётах — держите как основу: аудит смарт-контрактов.

FAQ

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

• Смарт-контракт: базовое определение и примеры
• Аудит смарт-контрактов: что он проверяет и чего не гарантирует
• Reentrancy: почему возникает и как защищаются
• DELEGATECALL: риски прокси и подмена логики