Коротко: receipt – результат выполнения включённой EVM-транзакции в конкретном блоке. Поле `status` показывает, завершилось ли исполнение успешно или было отменено ошибкой, а receipt также содержит данные о блоке, использованном gas и событиях logs. Этот объект не сообщает сам по себе, что блок навсегда останется в канонической цепочке, что все ожидания приложения выполнены или что актив уже зачислен другой системой.
Что такое receipt и когда он появляется
После отправки подписанная транзакция сначала распространяется по сети и может ждать включения. Пока она не попала в блок, стандартный запрос `eth_getTransactionReceipt` обычно возвращает `null`: у узла ещё нет результата исполнения, привязанного к блоку. Это не то же самое, что ошибка. Транзакция может оставаться в очереди, быть вытесненной или заменить другой транзакцией с тем же nonce.
Когда транзакцию включили, узел возвращает receipt. В стандартной модели JSON-RPC объект связывает транзакцию с номером блока и его хешем, содержит адрес контракта при создании, кумулятивный расход газа и фактически использованный gas, а также список логов событий. Конкретный клиент может добавлять поля, поэтому для программирования ориентируйтесь на документацию интерфейса, а не на случайный обозреватель.
Receipt полезен вместе с TxID, но не заменяет анализ всей операции. Сначала убедитесь, что смотрите нужную сеть, как объясняется в материале о Chain ID; затем сопоставьте логи с адресом контракта и ожидаемым действием. Похожий разбор статусов для биржевого вывода есть в статье о статусе биржи и подтверждении в блокчейне.
Как читать поле status
Для современных транзакций receipt обычно содержит статус `1` при успешном завершении исполнения и `0` при откате. Успех означает, что выполнение не завершилось исключением, которое откатило изменения этой транзакции. Если вызов контракта завершился ошибкой, изменения состояния внутри транзакции откатываются, но сама транзакция всё равно была обработана блоком: отправитель может заплатить за выполненную работу газа.
Даже статус `1` не гарантирует, что результат совпадает с ожиданием пользователя. Контракт мог корректно выполнить ветку, в которой перевёл меньше токенов из-за комиссии, отказал на уровне бизнес-логики без revert, исполнил другой метод или создал событие с параметрами, которые интерфейс неверно истолковал. Проверяйте calldata, адрес контракта, декодированные события и фактическое состояние, которое интересует задачу.
Старые типы данных и инструменты могут отображать поля иначе. Не делайте вывод по цветной плашке «Success» на одном сайте: проверьте сырой receipt через узел или официальный explorer для выбранной сети. При работе с другой EVM-сетью структура может выглядеть похоже, но правила подтверждения, финальности, форков и RPC-провайдера принадлежат именно этой сети.
Логи, газ и изменения состояния
Массив logs содержит события, выпущенные контрактами во время успешного исполнения. Запись обычно включает адрес контракта, topics и data. ABI помогает декодировать значения, но сначала нужно подтвердить правильность ABI и адреса. Название события не доказывает, что источник доверенный: любой контракт может использовать похожий интерфейс или выпускать внешне знакомый тип события. Смотрите на адрес, сеть и ожидаемую функцию.
Поле gasUsed показывает фактически потраченное транзакцией количество газа, а cumulativeGasUsed – суммарный расход к моменту этой транзакции внутри блока. Это не одно и то же, что денежная комиссия: стоимость зависит от параметров газа и сети. Точное списание следует оценивать по модели соответствующей сети и полям транзакции. Перед подписью сложного вызова можно также прочитать как расшифровать calldata транзакции.
Receipt не является полной копией состояния до и после вызова. Он может показывать события, но не все изменения storage, внутренние вызовы и перемещения, которые приложение считает значимыми. Для более глубокого анализа нужны трассировка, данные блока или чтение состояния через RPC. Поэтому логи удобны для индексации и уведомлений, однако их нельзя путать с универсальным журналом всех причин изменения аккаунта. Подробнее: разница между событиями и состоянием контракта.
Подтверждения, каноническая цепочка и финальность
Receipt содержит номер и хеш блока, в котором транзакция была замечена. По мере добавления новых блоков поверх него растёт число подтверждений. Однако ранний блок может быть исключён при реорганизации: сеть выбирает другую ветку, и транзакция может вернуться в очередь или оказаться включённой повторно в другом блоке. Тогда старый receipt перестаёт описывать текущее каноническое положение транзакции.
Уровень уверенности зависит от механизма консенсуса и правил конкретной сети. У Bitcoin обычно считают глубину цепочки, а proof-of-stake-сети могут иметь понятие экономической финальности. В EVM-совместимом RPC некоторые клиенты поддерживают теги `safe` и `finalized`, но их наличие и семантика зависят от клиента и сети. Не переносите порог подтверждений с одной сети на другую и не воспринимайте количество блоков как универсальную гарантию.
Мост, биржа или платёжный сервис могут применять собственный порог подтверждений до зачисления. Его внутренний статус не обязан обновляться одновременно с receipt. Сначала проверьте исходную операцию, затем узнайте, какие условия использует получатель. Для межсетевого маршрута отдельно проверяются транзакция на исходной стороне, сообщение или доказательство и операция в целевой сети.
Практический порядок проверки
- Сверьте сеть, адрес отправителя, адрес контракта и TxID.
- Если receipt отсутствует, проверьте mempool, nonce и статус отправки у провайдера.
- Если receipt есть, прочитайте status, номер и хеш блока, расход газа и список логов.
- Декодируйте события только проверенным ABI и сопоставьте их с ожидаемым методом.
- Дождитесь требований получателя и финальности, принятых именно в этой сети.
- При расхождении сохраните TxID и исходные RPC-данные, а не только скриншот интерфейса.
Receipt отвечает на важный, но ограниченный вопрос: как узел зафиксировал исполнение транзакции в блоке. Для уверенного вывода нужно вместе проверить входную операцию, контракт, логи, состояние канонической цепочки и правила получателя. Успешный статус – это начало диагностики, а не полная гарантия конечного результата.
