Что такое риск смарт-контракта?

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

Почему это важно

После развёртывания смарт-контракта в блокчейне его код становится публичным и неизменяемым (за исключением случаев, когда сам контракт предусматривает механизм обновления). Это означает, что любая уязвимость в коде может быть обнаружена и использована любым человеком в мире, а атака обычно завершается за секунды — остановить её вручную невозможно.

Значительная доля потерь в DeFi, исчисляемых десятками миллиардов долларов, обусловлена именно дефектами кода смарт-контрактов. Официальная документация по аккаунтам Ethereum и базовые технические стандарты, такие как EIP-712, постоянно совершенствуются — в том числе для сокращения пространства для подобных рисков на уровне протокола.

Распространённые типы уязвимостей смарт-контрактов

1. Атака повторного входа (Reentrancy Attack)

Это наиболее известный тип уязвимости в истории DeFi. Инцидент с The DAO (2016 год) унёс около 60 млн USD и напрямую спровоцировал хардфорк Ethereum.

Принцип: когда контракт А переводит средства внешнему адресу, если получатель — другой контракт Б, то Б при получении средств может повторно вызвать контракт А и снять деньги повторно — ещё до того, как А обновит состояние баланса. Такой рекурсивный вызов может продолжаться до полного опустошения средств контракта А.

Защита: применение паттерна «Проверки-Эффекты-Взаимодействия» (Checks-Effects-Interactions) — обновление внутреннего состояния контракта всегда должно происходить до инициации внешних вызовов.

2. Переполнение и нижнее переполнение целых чисел (Integer Overflow/Underflow)

До версии Solidity 0.8.0 целочисленные операции не проверяли границы автоматически. Без ручного добавления проверок безопасности вредоносный ввод мог вызывать «обёртывание»: максимальное беззнаковое целое плюс 1 превращалось в 0, или 0 минус 1 становилось очень большим числом.

Начиная с Solidity 0.8.0 защита от переполнения включена по умолчанию, однако следует проявлять осторожность при работе с контрактами, скомпилированными под старые версии, или использующими блоки unchecked.

3. Отсутствие контроля доступа

Если чувствительные функции контракта (вывод средств, изменение параметров, уничтожение контракта) не имеют надлежащих ограничений доступа, их может вызвать любой адрес. Например, отсутствие модификатора onlyOwner или ошибка в логике проверки условий могут привести к несанкционированным операциям.

4. Манипуляция ценовым оракулом

Часть протоколов использует мгновенные цены on-chain (например, текущую цену сделки на DEX) в качестве источника данных оракула. Злоумышленник может через флеш-займ в рамках одной транзакции значительно сдвинуть цену, а затем запустить зависящую от неё логику протокола (ликвидации при кредитовании или арбитраж) и вернуть флеш-займ — всё это без собственного капитала.

5. Логические ошибки

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

6. Риски реализации обновляемых контрактов

В протоколах, использующих паттерн прокси-контракта (Proxy Pattern), ненадлежащая реализация механизма обновления может привести к конфликтам слотов хранения, повторному вызову функций инициализации и другим проблемам. Такие стандарты, как EIP-2612, вводя новые функции, одновременно продолжают стандартизировать безопасность взаимодействия контрактов.

Как пользователям снизить риск смарт-контракта

1. Взаимодействуйте только с зрелыми контрактами, имеющими длительный послужной список — время является важным фильтром безопасности контракта.
2. Изучайте аудиторские отчёты и обращайте внимание на наличие неустранённых критических уязвимостей (подробнее в статье 25).
3. Управляйте разрешениями контрактов: выдавайте только необходимые лимиты, регулярно отзывайте неиспользуемые разрешения через Revoke.cash — это снизит потенциальный ущерб при возникновении проблем с уже авторизованными контрактами.
4. Диверсифицируйте: избегайте концентрации крупных сумм в одном контракте.
5. Следите за платформами мониторинга безопасности: читайте новости о безопасности DeFi и уведомления безопасности конкретных протоколов.

Сценарии использования

Сценарий первый: Вы собираетесь внести активы в протокол ликвидности, запущенный две недели назад, и обнаруживаете, что его контракт использует собственную логику защиты от повторного входа вместо стандартной библиотеки ReentrancyGuard. Считая, что кастомные реализации сложнее достаточно охватить при аудите, вы решаете подождать более длительного подтверждения в реальных условиях.

Сценарий второй: Проверяя историю разрешений на Revoke.cash, вы обнаруживаете, что год назад выдали неограниченное разрешение USDC протоколу, который уже прекратил работу. Немедленно отзываете это разрешение, устраняя потенциальную зону риска.

Как начать в OneKey App

OneKey App предоставляет следующие возможности в области безопасности смарт-контрактов:

• Предпросмотр подписи: каждая транзакция перед подписанием отображает адрес целевого контракта и детали операции, помогая выявлять аномальные контракты;
• Интеграция с аппаратным кошельком: в сочетании с аппаратным кошельком OneKey даже при компрометации программной части физическое подтверждение остаётся последним рубежом защиты подписи;
• Поддержка структурированной подписи EIP-712: для DeFi-операций, использующих стандарт EIP-712, OneKey разбирает и отображает структурированное содержание подписи — вместо того чтобы пользователь вслепую подтверждал строку хеша.

Посетите OneKey для получения дополнительной информации о функциях безопасности.

Риски и важные замечания

• Риск смарт-контракта нельзя полностью устранить — участие в DeFi предполагает принятие соответствующих рисков на себя.
• Аудиторские отчёты лишь снижают вероятность уязвимостей известных типов, но не гарантируют нулевой риск.
• Данная статья не является инвестиционной или операционной рекомендацией.
• Любой контракт, сколько бы долго он ни работал, может оказаться подверженным ранее неизвестным уязвимостям.

FAQ

В1: Могут ли пользователи вернуть средства после атаки на смарт-контракт? Как правило, это крайне сложно. Неизменяемость блокчейна означает, что подтверждённую транзакцию атаки отменить невозможно. В некоторых случаях команда протокола или «белые хакеры» могут путём переговоров или отслеживания вернуть часть средств, однако это ненадёжный механизм защиты.

В2: Нужно ли управлять разрешениями при использовании аудированных контрактов? Да. Аудит проводится только для кода на момент его представления — он не может предвидеть новые уязвимости, которые могут появиться в будущем. Управление разрешениями снижает потенциальный ущерб при возникновении проблем с контрактом в будущем и является самостоятельной мерой безопасности, дополняющей аудит.

В3: Как быстро оценить базовый уровень безопасности контракта? Можно проверить в блокчейн-обозревателе (например, Etherscan), является ли контракт открытым, и когда он был развёрнут, а на официальном сайте протокола найти ссылки на аудиторские отчёты. Комбинация «открытый код + аудит известной организации + длительный срок работы» — относительно базовый фильтр безопасности.

В4: Могут ли флеш-займы использоваться обычными пользователями для атак? Флеш-займы — нейтральный инструмент, технически доступный любому, однако реализация атаки с их использованием требует обнаружения конкретной уязвимости и написания соответствующего атакующего контракта — это требует определённых технических знаний. Понимание принципа работы флеш-займов помогает понять, почему протоколы, использующие единственный источник ценовых данных, несут повышенный риск.

Действуйте прямо сейчас

Проверьте текущий список разрешений контрактов через Revoke.cash и отзовите высокорисковые разрешения, которые больше не нужны. Скачайте OneKey App и перед каждым DeFi-взаимодействием используйте предпросмотр подписи для верификации адреса контракта — изучите также возможности аппаратного кошелька для более полной защиты подписи.