Чем безопасность смарт-контрактов отличается от безопасности обычного программного обеспечения?

Безопасность смарт-контрактов имеет свою специфику: их код открыт, они часто напрямую хранят денежные средства, а после развёртывания их обычно нельзя изменить. Ошибку в веб-приложении можно исправить за ночь; ошибку в контракте может обнаружить любой, кто читает код, и использовать её, пока команда ещё спит. По оценке Ethereum.org, потери из-за дефектов смарт-контрактов превышают миллиард долларов; в качестве раннего примера сайт приводит взлом DAO в 2016 году.

Рассмотрим вымышленную студию «Ларкспер Лабс» из четырёх человек, которая создаёт простой общий накопительный фонд: участники вносят средства и выводят свою долю. Разработчик Кофи оставляет замечания перед развёртыванием: 'withdraw отправляет средства, а затем устанавливает баланс в 0. setFee доступна всем, ограничу позже. использую старую версию компилятора из учебного материала. цена токена вознаграждения берётся из одного небольшого биржевого пула. тесты: один раз вручную попробовал внести + вывести, работает'. Каждая строка описывает известный класс уязвимостей.

Какие уязвимости смарт-контрактов встречаются чаще всего?

Самые распространённые уязвимости смарт-контрактов — недостатки контроля доступа, манипуляции ценовыми оракулами, логические ошибки, отсутствие проверки входных данных и повторный вход. Они возглавляют OWASP Smart Contract Top 10 за 2025. Ethereum.org рассматривает те же основные классы уязвимостей.

Повторный вход

Контракт переводит средства или вызывает другой контракт до обновления собственных записей. Злоумышленник на стороне получателя выполняет повторный вызов, пока ещё отображается прежний баланс, и снова выводит средства. Функция вывода средств Кофи, которая сначала выплачивает деньги и только затем обнуляет баланс, — классический пример такой уязвимости. Обычное исправление — сначала обновлять состояние и лишь в конце взаимодействовать с другими контрактами. Этот порядок часто называют «проверки, изменения состояния, взаимодействия».

Управление доступом

Критически важные функции, которые может вызвать кто угодно. Общедоступная функция setFee у Кофи позволяет любому постороннему изменить комиссию. Ethereum.org описывает такие подходы, как роль владельца, доступ на основе ролей и подтверждение несколькими подписями.

Переполнение и выход за нижнюю границу целочисленного типа

Арифметика, при которой выход за пределы допустимого диапазона приводит к переходу на другой его конец, так что баланс ниже нуля становится огромным числом. Ethereum.org отмечает, что Solidity 0.8.0 и более поздние версии по умолчанию отклоняют такие операции, а в старом коде нужны явные проверки. Именно поэтому важно, что Кофи использует старый компилятор.

Манипулирование оракулом

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

Ошибки логики и проверки данных

Правила, не соответствующие задуманной логике, или входные данные, которые никогда не проверяются, например нулевая сумма или неожиданный адрес.

Как команды тестируют и проверяют смарт-контракты?

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

1. Модульные тесты и тесты на основе свойств

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

2. Статический анализ

Ethereum.org перечисляет такие инструменты, как Slither, Mythril и Aderyn, которые проверяют код на известные опасные шаблоны.

3. Проверьте сети

Перед развёртыванием в основной сети выполните развёртывание в публичной тестовой сети. Ethereum.org рекомендует Sepolia для разработки приложений и контрактов; эфир в тестовой сети не должен иметь реальной стоимости, поэтому ошибки ничего не стоят.

4. Экспертная проверка и проверенные библиотеки

Используйте контроль версий, независимую проверку каждого изменения и тщательно проверенные библиотеки, например OpenZeppelin Contracts, вместо того чтобы писать механизмы контроля доступа с нуля.

5. Аудит, вознаграждения за обнаружение уязвимостей и мониторинг

Независимые аудиты обеспечивают дополнительную проверку, но, как отмечает ethereum.org, не выявляют все ошибки. Оставшиеся риски снижают программы вознаграждения за найденные уязвимости, функции аварийной приостановки и мониторинг событий.

Как выглядят неудачная и улучшенная проверки безопасности?

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

Улучшенная проверка: Повторный вход: withdraw теперь обнуляет баланс перед отправкой средств, а тест использует вредоносный контракт-получатель, который пытается выполнить повторный вызов. Управление доступом: setFee доступна только роли владельца из библиотеки, прошедшей аудит; тест подтверждает, что вызов постороннего пользователя отклоняется. Компилятор: обновлён до актуальной версии 0.8, поэтому проверки переполнения включены. Оракул: цена из одного пула заменена децентрализованным источником ценовых данных, добавлено ограничение на резкие изменения. Тестирование: модульные тесты, прогон фаззинга и статический анализ с объяснением каждой находки, затем две недели в Sepolia, в течение которых коллега пытается найти уязвимости. Внешний аудит запланирован до приёма любых реальных средств.

Какие ошибки часто допускают при обеспечении безопасности смарт-контрактов?

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

К какому разделу Tosheo.ai относится этот урок?

Это урок с программированием в категории «Блокчейн» и в курсе по блокчейну. На этой бесплатной странице каждый шаг объясняется текстом. Полная практическая версия, в которой вы проверяете и исправляете реальный код контрактов и запускаете тесты в тестовой сети, доступна после регистрации в дополнительном направлении «Программирование». Если вы ещё не знакомы с основами, начните с объяснения смарт-контрактов. Tosheo.ai — не интенсивная программа обучения с полной занятостью и не профессиональная квалификация аудитора. Ничто здесь не является инвестиционной рекомендацией; контрактам, управляющим реальными ценностями, необходим аудит специалиста.

Источники и границы рассмотрения

ethereum.org, безопасность смарт-контрактов (проверено 19 October 2026) ↗

OWASP: 10 главных рисков безопасности смарт-контрактов, 2025 (проверено 19 October 2026) ↗

ethereum.org, сети и тестовые сети (проверено 19 October 2026) ↗