Смарт-контракт — программа, развёрнутая в блокчейне и исполняемая по правилам сети. Она может хранить состояние и менять его в ответ на транзакции: например, переводить токены или проверять условие выпуска. Контракт не является автоматически безопасным и не может сам знать, что происходит во внешнем мире. В документации Ethereum контракт описан как программа в сети; там же разобраны взаимодействие, оракулы и ограничения внешних данных (Ethereum: smart contracts).
Как пользователь вызывает контракт
Пользователь открывает приложение, которое формирует транзакцию с адресом контракта и данными вызова. Кошелёк показывает запрос и просит подпись. После отправки сеть проверяет подпись и исполняет код в заданных условиях. Вызов может читать данные, менять состояние или отправлять токены.
Пример: обменный контракт принимает токен A и выдаёт токен B, если соблюдены правила и доступна ликвидность. Для ERC-20 может понадобиться отдельный approve: в распространённой реализации ERC-20 владелец задаёт allowance для spender, а transferFrom использует это разрешение (OpenZeppelin ERC20 API). Пользователь должен сверить адрес получателя, сумму, сеть, комиссию и возможный минимальный результат.
Код автоматизирует правила, но не устраняет ошибки
Если в коде ошибка, контракт может выполнить её точно так же автоматически, как и правильное правило. Ошибка контроля доступа, расчёта, цены или обновления может привести к блокировке, неверной выплате или потере активов. Аудит и тесты снижают риск, но не доказывают полную безопасность. Важно проверить, какой именно адрес и версия контракта были исследованы, и менялся ли код после проверки.
Некоторые Ethereum-приложения используют proxy: вызов идёт через постоянный адрес proxy к заменяемой реализации, а доступ к обновлению задаётся конкретной схемой управления. Это позволяет менять логику, но создаёт полномочия обновляющей роли. Уточни, кто её контролирует, и как устроены задержка, мультиподпись или голосование, если они есть; наличие названия механизма само по себе не доказывает безопасность (Ethereum: upgrading, OpenZeppelin: proxy pattern).
Откуда берутся внешние данные
Контракт обычно не может сам обратиться к сайту, бирже, погодному API или банковской системе. Для внешних данных используются оракулы или другие механизмы доставки. Если данные неверны, задержаны или манипулированы, контракт может корректно исполнить действие по неправильному входу. Это ограничение описано в документации Ethereum об оракулах (Ethereum: smart contracts).
Комиссия, ошибки и необратимость
В Ethereum исполнение потребляет gas; при revert изменения состояния откатываются, но потраченный gas не возвращается. Для других сетей проверяй их правила отдельно (Ethereum: gas). Подтверждённая Ethereum-транзакция обычно не отменяется через поддержку сети (Ethereum: security). Поэтому проверяй сеть, адрес, параметры и сообщение кошелька до подписи.
У контрактов бывает composability: один код вызывает другой. Это позволяет собирать сложные приложения, но добавляет зависимости. Если протокол опирается на мост, оракул, пул и токенизированный залог, риск одного компонента может повлиять на остальные.
Чеклист чтения контракта
- Адрес и сеть подтверждены официальной документацией?
- Проверен ли исходный код и совпадает ли он с развернутым?
- Кто может менять параметры или обновлять логику?
- Есть ли внешние оракулы, мосты или права на паузу?
- Какие разрешения выдаёт кошелёк?
- Каков худший сценарий и есть ли путь выхода?
Смарт-контракт — исполнимое правило, а не юридический договор по умолчанию, гарантия платежа или признак безопасности. Следующие темы: риски DeFi, DEX и токены.
Состояние, события и чтение транзакции
Контракт может записать событие в журнал транзакции; в Solidity события читаются вне контракта через логи, а не как обычное хранимое состояние (Solidity: events). В Ethereum receipt через eth_getTransactionReceipt содержит статус исполнения и логи; JSON-RPC документация описывает его поля (Ethereum JSON-RPC API). Успех транзакции не доказывает, что приложение честное или пользователь получил ожидаемый продуктовый результат; для точного статуса сверяй документацию выбранной сети и инструмента.
Перед взаимодействием сопоставь адрес контракта с опубликованным адресом проекта и сетью. Сходное имя или символ токена легко подделать. Если контракт обновляемый, проверяй текущую реализацию и полномочия обновления. Изучение исходного кода требует компетенции; не делай вид, что поверхностного просмотра достаточно для аудита.
Простой сценарий и точка человеческого контроля
Представь цифровой пропуск: контракт проверяет, есть ли у адреса нужный токен, и открывает функцию. Код может выполнить эту проверку без ручного решения оператора, но пользователь всё ещё должен получить токен, оплатить комиссию и подписать вызов. Если токен выдан ошибочно, контракт не обязан понимать намерение сторон. Если правила меняются, выясни, кто способен обновить программу. Автоматизация убирает часть ручной обработки, но переносит доверие в код, сеть и управление.