Смарт-контракт: программа в блокчейне

Когда программа начинает действовать

Обычно для изменения состояния требуется транзакция или вызов из другой исполняемой операции. Условия контракта не обязательно проверяются непрерывно сами собой. Например, действие «когда наступит дата» может потребовать участника или внешней службы, которая отправит соответствующую транзакцию. Течение времени и наличие записанного условия ещё не доказывают, что действие уже выполнено.

Сеть проверяет допустимость операции и учитывает её исполнение. За вычисления и изменение состояния могут взиматься сетевые расходы. Даже неудачная операция способна потратить gas по правилам сети, хотя желаемое изменение не произошло. Для проверки результата нужен статус и фактическое состояние, а не только кнопка подтверждения в приложении.

Почему контракт не знает весь внешний мир

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

Это особенно заметно в финансовых протоколах. Если оценка залога зависит от рынка с малой ликвидностью или от неполных данных, правила кредитования и ликвидации могут работать иначе, чем ожидал пользователь. Поэтому важно выяснить не только адрес контракта, но и откуда берутся значимые входные параметры. Слово decentralized не описывает все эти зависимости автоматически.

Может ли код измениться после запуска

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

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

Обмен токена завершился иначе, чем ожидал пользователь

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

В обоих случаях слово «автоматически» не объясняет качество результата. Нужно проверить контракт, параметры подписи, состояние сети и фактический выход. Удаление страницы из браузера не отменяет уже подтверждённое действие. Для будущих операций полезно разобраться с допуском исполнения и сохранёнными разрешениями, а не просто искать другое оформление той же кнопки обмена.

Что проверить

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