События и логи Ethereum: как читать topics и data

Поля одного Ethereum log отвечают на разные вопросы
Поле	Что хранит	Что ещё нужно
address	Контракт, выпустивший запись	Сеть, bytecode и ABI этого адреса
topics[0]	Обычно hash сигнатуры non-anonymous event	Проверка anonymous и точной канонической сигнатуры
topics[1…3]	Indexed-параметры	Типы из ABI; dynamic value напрямую не декодируется
data	ABI-кодирование non-indexed-параметров	Порядок и типы параметров
logIndex	Позиция записи в блоке	transactionHash и blockHash для устойчивой ссылки

Поля одного Ethereum log отвечают на разные вопросы

Поле: address
Что хранит: Контракт, выпустивший запись
Что ещё нужно: Сеть, bytecode и ABI этого адреса

Поле: topics[0]
Что хранит: Обычно hash сигнатуры non-anonymous event
Что ещё нужно: Проверка anonymous и точной канонической сигнатуры

Поле: topics[1…3]
Что хранит: Indexed-параметры
Что ещё нужно: Типы из ABI; dynamic value напрямую не декодируется

Поле: data
Что хранит: ABI-кодирование non-indexed-параметров
Что ещё нужно: Порядок и типы параметров

Поле: logIndex
Что хранит: Позиция записи в блоке
Что ещё нужно: transactionHash и blockHash для устойчивой ссылки

Сначала receipt и адрес эмитента, затем имя события

Transaction receipt — квитанция исполнения включённой транзакции. В ней находятся status, использованный gas и массив logs. Поле address каждого log указывает эмитента; это может быть не адрес верхнеуровневого вызова, если тот вызвал другой смарт-контракт. Для post-Byzantium receipt status `0x1` означает успешное верхнеуровневое исполнение, `0x0` — failure. При транзакции reverted изменения состояния и выпущенные внутри откатываемого пути логи не сохраняются как успешный результат.

Паспорт записи до декодирования

chain ID, block number и block hash;
transaction hash, receipt status и logIndex;
полный address контракта-эмитента;
topics и data без сокращения;
ABI либо исходная сигнатура события для этой версии контракта.

Topics пригодны для поиска, data — для последовательного декодирования

Как Solidity раскладывает параметры event
Объявление	Где значение	Ограничение
non-anonymous event	topic0 = Keccak-256 канонической сигнатуры	Имя без типов не определяет hash
indexed address/uint/bytes32	Следующий topic, дополненный до 32 bytes	Нужен правильный тип
indexed string/bytes/array/struct	Keccak-256 специального encoding	Исходное значение из topic не восстановить
non-indexed parameter	Последовательно в data	ABI не самодокументируем: нужны типы и порядок
anonymous event	Нет обязательного signature topic0	До четырёх indexed topics; правило другое

Как Solidity раскладывает параметры event

Объявление: non-anonymous event
Где значение: topic0 = Keccak-256 канонической сигнатуры
Ограничение: Имя без типов не определяет hash

Объявление: indexed address/uint/bytes32
Где значение: Следующий topic, дополненный до 32 bytes
Ограничение: Нужен правильный тип

Объявление: indexed string/bytes/array/struct
Где значение: Keccak-256 специального encoding
Ограничение: Исходное значение из topic не восстановить

Объявление: non-indexed parameter
Где значение: Последовательно в data
Ограничение: ABI не самодокументируем: нужны типы и порядок

Объявление: anonymous event
Где значение: Нет обязательного signature topic0
Ограничение: До четырёх indexed topics; правило другое

ABI не записан внутрь log. Декодер берёт известные типы и трактует 32-byte слова соответствующим образом. Для адреса остаются младшие 20 bytes; integer читается с учётом signedness и размера. У indexed `string` или массива topic содержит hash специального encoding, поэтому интерфейс, показывающий исходный текст без дополнительного источника, делает вывод не только из записи.

Transfer разбирают как доказуемую запись, а не как ярлык интерфейса

1
Открыть receipt
Сверьте chain, transactionHash, blockHash и status; выберите конкретный log по logIndex.
2
Подтвердить эмитента
Сопоставьте полный log.address с ожидаемым token contract, а не только ticker или картинку.
3
Сопоставить ABI
Для стандартного ERC-20 Transfer два indexed address читаются из topics, а raw value — из data.
4
Применить масштаб
Переведите raw value через decimals именно этого контракта; event сам не хранит десятичную запятую.
5
Зафиксировать вывод
Сохраните contract, tx hash, logIndex, raw и decoded values, ABI source и block context.

Если сумма на экране отличается, отдельно проверьте decimals токена: декодированный `uint256` остаётся raw integer. Если receipt status успешный и нужный log найден, это доказывает, что указанный contract записал event в этой транзакции. Это не доказывает цену токена, право требования, доставку offchain-товара или отсутствие других внутренних действий.

eth_getLogs возвращает совпадения фильтра, а не готовую историю продукта

Диагностика результата eth_getLogs
Результат	Возможная причина	Следующее действие
Пусто	Неверная сеть, range, address или позиция topic	Сузить один блок и сверить receipt известной транзакции
Слишком много записей	Фильтр только по topic0	Добавить точный contract address и indexed topic
removed = true	Log исключён реорганизацией	Повторить запрос по canonical block и дождаться нужной finality
Provider отклоняет range	Лимит endpoint, не отсутствие событий	Разбить диапазон и сохранить границы запросов
ABI decode ошибочен	Другая сигнатура, версия или proxy implementation	Проверить bytecode/implementation на этом block

Диагностика результата eth_getLogs

Результат: Пусто
Возможная причина: Неверная сеть, range, address или позиция topic
Следующее действие: Сузить один блок и сверить receipt известной транзакции

Результат: Слишком много записей
Возможная причина: Фильтр только по topic0
Следующее действие: Добавить точный contract address и indexed topic

Результат: removed = true
Возможная причина: Log исключён реорганизацией
Следующее действие: Повторить запрос по canonical block и дождаться нужной finality

Результат: Provider отклоняет range
Возможная причина: Лимит endpoint, не отсутствие событий
Следующее действие: Разбить диапазон и сохранить границы запросов

Результат: ABI decode ошибочен
Возможная причина: Другая сигнатура, версия или proxy implementation
Следующее действие: Проверить bytecode/implementation на этом block

Для воспроизводимой выборки задают fromBlock/toBlock либо один blockHash, address и позиционные topics. Данные одного RPC-узла полезно перепроверить, если provider обрезал историю или вернул ошибку диапазона. Проверка закончена, когда другой аналитик получает тот же receipt/log и тем же ABI воспроизводит decoded fields; при неизвестном адресе, ABI или block context вывод о событии останавливают.

Источники

Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.

Solidity — Contract ABI Specification: Events Solidity Project · Проверено 20 августа 2026 г. в 09:21 GMT+5
Solidity — ABI Errors and Revert Solidity Project · Проверено 20 августа 2026 г. в 09:21 GMT+5
ethereum.org — JSON-RPC API Ethereum Foundation community documentation · Проверено 20 августа 2026 г. в 09:21 GMT+5
Ethereum Execution APIs — eth_getTransactionReceipt Ethereum Execution APIs · Проверено 20 августа 2026 г. в 09:21 GMT+5
ERC-20: Token Standard Ethereum Improvement Proposals · Проверено 20 августа 2026 г. в 09:21 GMT+5

Материал носит информационный характер и не является индивидуальной рекомендацией. Криптоактивы связаны с риском волатильности, технических сбоев, хищения и полной потери средств.