ГЛАВНАЯ / ИНСТРУКЦИИ / CALLDATA И EVENT LOGS: ГДЕ НАХОДЯТСЯ ВХОД И РЕЗУЛЬТАТ ВЫЗОВА
Calldata и event logs: где находятся вход и результат вызова
Calldata несёт вход вызова: selector функции и закодированные параметры. Event log появляется, если во время исполнения контракт выпустил событие. Это разные данные с разной ролью: первые помогают понять, что запросили, вторые – что код сообщил как результат исполнения.
Calldata – байты, переданные целевому контракту
В транзакции к существующему контракту поле input (его также называют data) содержит байты вызова. Для обычной ABI-функции первые четыре байта часто соответствуют selector, полученному из сигнатуры функции; следующие значения кодируют параметры по правилам ABI. Транзакция создания контракта использует данные иначе – в частности, отправляемое содержимое связано с initcode.
Selector и декодированные слова помогают прочитать предполагаемый вызов, но не объясняют весь эффект автоматически. Для проверки нужны подходящий ABI и версия контракта в нужной сети. Прокси, fallback, нестандартное кодирование или обновившаяся реализация могут сделать описание интерфейса неполным.
| Данные | Когда появляются | Что читать |
|---|---|---|
| Calldata / input | Перед отправкой транзакции | to, selector и ABI-параметры |
| Log | Во время успешного исполнения вызова | Эмитент, topics и data |
| Receipt status | После исполнения | Успех или неуспех верхнего вызова |
| Storage | Изменения состояния контрактов | Чтение состояния на нужном блоке |
Event записывается в log и включается в receipt
Контракт формирует log специальной инструкцией EVM. В записи есть адрес контракта-эмитента, topics для сигнатуры и индексируемых параметров и data для остальных кодированных значений. Receipt собирает логи, оставшиеся после исполнения транзакции. Индексаторы и обозреватели декодируют их по ABI, чтобы показать удобную таблицу событий.
Обычная функция контракта не может прочитать собственные прошлые логи как storage. Событие полезно для внешнего наблюдателя, но само по себе не является постоянной переменной контракта и не заменяет проверку итогового состояния. Для ERC-20, например, Transfer event стоит сопоставлять с эмитентом токена и изменением нужных балансов.
Проверьте эмитента до декодирования похожего события
Сверьте сеть, адрес транзакции, contract address и адрес каждого лога. Затем выберите ABI той же реализации и декодируйте topics и data. Два контракта могут выпускать события с одинаковой сигнатурой, поэтому знакомое название Transfer или Swap не доказывает, что это доверенный токен или пул.
События из вызова, который был отменён из-за revert, не должны трактоваться как сохранённый результат. Проверьте status и receipt целиком, а для цепочки вложенных вызовов при необходимости изучите trace. Вложенный вызов мог завершиться ошибкой, которую родительский контракт обработал; верхний receipt при этом может остаться успешным.
- не декодируйте событие без адреса эмитента;
- учитывайте, что откат удаляет логи отменённого вызова.
Сопоставьте запрос, событие и фактическое состояние
Calldata показывает параметры, с которыми подписали внешний запрос. Log показывает, какое событие записал контракт во время выполнения. Receipt подтверждает итоговый статус верхней транзакции. Это три независимых шага сверки, и ни один из них не раскрывает смысл всех остальных без кода и состояния.
Сохраните хэш, сеть, номер блока, адрес эмитента, темы и декодированные значения. Если интерфейс обозревателя показывает неожиданный результат, откройте raw input и raw log, а затем сравните их с ABI и состоянием на том же блоке. Не считайте зелёную метку события доказательством того, что пользователь получил ожидаемый актив.
- сначала идентифицируйте адрес emit-контракта;
- сверьте декодированный event с изменением состояния.
Частые вопросы
Calldata показывает, что точно выполнит контракт?
Она содержит входные байты, но фактическое поведение зависит от кода и состояния на момент включения.
Event log хранит баланс токена?
Нет. Log сообщает о событии; состояние и баланс проверяются отдельно.
Можно доверять названию события в обозревателе?
Сначала проверьте сеть, адрес эмитента, ABI и исходные topics/data.
Status 1 гарантирует нужный Transfer?
Нет. Он говорит об успехе верхнего вызова; проверьте конкретные логи, адрес токена и состояние.
Может ли контракт прочитать прошлый event?
Обычный EVM-контракт не использует прошлые logs как хранилище; для чтения истории нужны внешние данные или отдельное состояние.
Чек-лист: calldata и event logs: где находятся вход и результат вызова
- сеть и хэш транзакции совпадают;
- input изучен отдельно от receipt;
- selector декодирован подходящим ABI;
- адрес контракта проверен;
- эмитент каждого log проверен;
- topics и data прочитаны;
- status и фактическое состояние сопоставлены.
Материал подготовлен редакцией сайта и проверен 28 октября 2026 года. Условия бирж, кошельков и блокчейн-сетей могут меняться. Перед операцией сверяйте данные в интерфейсе выбранного сервиса.