Материал предназначен только для обучения и не является инвестиционной рекомендацией. Транзакции со смарт-контрактами могут привести к необратимым потерям.
Краткий ответ
Смарт-контракт — это программа, развёрнутая в блокчейне или аналогичной распределённой сети исполнения. Она содержит код, а на многих платформах — и постоянное состояние. Транзакция или другой контракт может вызвать её функции; узлы исполняют одинаковые правила и принимают итоговое изменение состояния через проверку и консенсус сети.
Слово «смарт» не означает, что программа понимает намерение, а слово «контракт» не делает её автоматически юридически исполнимым соглашением. Термин обозначает код, способный обеспечивать заданные условия в пределах возможностей и данных среды исполнения.
Смарт-контракты могут:
- хранить или переводить цифровые активы по запрограммированным условиям;
- записывать и обновлять состояние приложения; и
- сочетаться с другими контрактами для создания бирж, кредитных систем, игр, инструментов управления и других ончейн-приложений.
Предсказуемость ограничена реализованным кодом и входными данными. Контракт может исполниться точно по коду и всё же дать нежелательный результат из-за дефекта, вредоносной конструкции, скомпрометированных полномочий или неверных внешних данных.
Как это работает
Обычное взаимодействие проходит так:
- Разработчики пишут и тестируют исходный код, при необходимости компилируют его и развёртывают полученную программу транзакцией.
- При развёртывании программа получает ончейн-идентификатор или адрес; также могут инициализироваться её состояние и административные роли.
- Пользователь, приложение или другой контракт отправляет вызов с селектором функции, параметрами и иногда активами.
- Каждый проверяющий узел исполняет вызов по одинаковым правилам виртуальной машины и протокола. При невыполнении условия вызов может откатиться, однако комиссия за транзакцию всё равно может взиматься.
- Если вызов успешен и включён сетью, изменения состояния и выпущенные события становятся частью записи блокчейна.
Исполнение детерминировано только для информации, доступной в согласованном контексте. Контракт не может сам получить из интернета погоду, рыночную цену или банковский платёж. Приложениям с внешними фактами нужны оракул, подписанное сообщение, мост или привилегированный оператор, что добавляет допущения о доверии и сбоях помимо кода.
Развёрнутый код не всегда равен всей системе. Некоторые контракты неизменяемы, но прокси и механизмы управления могут направлять вызовы к новой логике или менять параметры. Поэтому кроме интерфейса нужно проверить ключи обновления, полномочия администратора, функцию паузы, устройство оракула и связанные контракты.
Перед подписью проверьте:
- сеть и полный адрес контракта по независимому надёжному источнику;
- декодированную функцию, параметры, суммы активов и получателя;
- разрешения на токены или права оператора, создаваемые вызовом;
- проверен ли контракт, допускает ли обновление, приостановлен ли он и контролируют ли его привилегированные аккаунты; и
- охватывает ли небольшая пробная операция предполагаемые пути входа и выхода, когда это возможно.
Пример
Рассмотрим эскроу-контракт для цифровой услуги. Покупатель вносит 1,000 USDC, а контракт записывает покупателя, продавца, сумму и условие расчёта. Если покупатель подтверждает доставку, средства перечисляются продавцу. Если условие не выполнено в течение 24 часов, становится доступен запрограммированный возврат.
Контракт не знает, удовлетворительна ли услуга, если конструкция не предоставляет этот факт. Если подтверждение зависит от ключа покупателя, компрометация ключа может разрешить выплату. Если исход определяет оракул или администратор, эта сторона входит в модель доверия. Ошибка контроля доступа или обработки токена тоже может нарушить правило эскроу. Автоматизация сокращает ручные операции, но не устраняет необходимость оценивать каждую зависимость.
Риски и меры контроля
- Дефекты кода: повторный вход, неверный учёт, небезопасные внешние вызовы или граничные случаи могут привести к потере или блокировке активов. Предпочитайте небольшие, хорошо протестированные конструкции и проверяйте развёрнутый код, а не только значок аудита.
- Риск полномочий и обновления: администратор может приостановить систему, заменить логику, изменить комиссии или переместить активы. Узнайте, кто контролирует роли, применяется ли задержка или мультиподпись и что можно изменить.
- Риск оракула и интеграции: правильный код может действовать по устаревшим, искажённым или неверно масштабированным данным, а сбои токенов, мостов и других контрактов могут распространяться через композицию.
- Риск транзакции и разрешений: вредоносный интерфейс может показать неверный адрес, функцию, получателя или неограниченное разрешение. Декодируйте запрос и ограничивайте права нужным объёмом.
- Риск экономической конструкции: корректные транзакции всё равно могут вызвать ликвидацию, манипуляцию ценой, сбой стимулов или набег на ограниченную ликвидность. Корректность кода не равна экономической платёжеспособности.
- Операционный риск: перегрузка, реорганизация цепи, сбой секвенсора или недоступный интерфейс могут задержать действие, хотя контракт остаётся развёрнутым.
- Необратимость: в публичных сетях обычно нет возврата платежа. Средства, отправленные через неверную функцию или враждебному контракту, могут быть невозвратны.
Аудит — свидетельство о конкретной версии кода и области проверки, а не гарантия. Сверьте развёрнутый байт-код или проверенный исходный код с изученной версией и выясните, не выходят ли последующие обновления, зависимости или настройки за область аудита.
Распространённые заблуждения
- «Код исполняется автоматически без транзакции». Большинству функций, меняющих состояние, нужна транзакция или другой ончейн-вызов; действия по времени могут требовать внешнего исполнителя.
- «Код невозможно изменить». Неизменяемый контракт не переписывает свой байт-код, однако прокси, управление и миграции могут изменить логику, к которой обращается пользователь.
- «Открытый код безопасен». Открытость помогает проверке, но не доказывает корректность, честность управления или устойчивость экономики.
- «Аудит гарантирует безопасность». Проверки ограничены временем и объёмом, могут пропустить дефекты или не охватывать операционные и экономические риски.
- «Успешная транзакция означает, что произошло задуманное». Успех означает лишь отсутствие отката вызванного кода; нужно проверить адрес, события, перемещение активов и итоговые разрешения.
Связанные темы
Источники
- Обзор технологии блокчейна - NIST (дата обращения: 2026-08-21)
- Введение в смарт-контракты - Ethereum.org (дата обращения: 2026-08-21)
- Вопросы безопасности - Solidity documentation (дата обращения: 2026-08-21)