Подтверждения и финальность Ethereum: проверяйте блок, а не только Success

Включённая в Ethereum транзакция может показывать Success до финализации содержащего её блока. Success описывает исполнение; подтверждения описывают блоки, добавленные после включения, по правилам подсчёта инструмента. Финальность является отдельным состоянием консенсуса. Проверяйте блок транзакции и финализированную цепочку сети, а не считайте эти метки взаимозаменяемыми.

Руководство относится к Ethereum Mainnet после перехода на proof of stake. У роллапов, мостов, других сетей и кастодиальных сервисов есть дополнительные правила. Это проверка уже имеющейся транзакции только для чтения, а не рекомендация отправить, отменить или повторить платёж.

Разделяйте включение, исполнение и финальность

Справочник квитанций JSON-RPC возвращает номер и хеш содержащего транзакцию блока вместе со статусом исполнения. У ожидающей транзакции ещё нет квитанции включения. Статус 1, представленный как 0x1 в исходном JSON-RPC, означает успешное исполнение; 0 или 0x0 означает неудачу.

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

Наблюдение	Что оно сообщает	Чего оно не решает
Квитанция с блоком	Провайдер сообщает о включении туда	Финализирован ли этот блок
Статус квитанции Success	Исполнение верхнего уровня успешно	Получены ли нужные токены и есть ли финальность
Число подтверждений	Инструмент сообщает глубину после включения	Универсальное правило финальности или зачисления
Финализированная цепочка включает блок	Финальность консенсуса охватывает этот блок	Безопасность контракта или зачисление биржей

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

Что Ethereum понимает под финализацией

Объяснение proof of stake в Ethereum описывает голосование валидаторов за контрольные точки. Финальность даёт более сильную гарантию, чем простая близость к текущей вершине цепочки: отмена финализированного блока потребовала бы серьёзного сбоя консенсуса с тяжёлыми экономическими последствиями. Она не обещает безопасность каждого приложения или актива в блоке.

Объяснение уровня приложений от Ethereum Foundation различает safe head и финализированные блоки. Safe является промежуточным уровнем уверенности, а не синонимом finalized. API исполнения предоставляет метки блоков latest, safe и finalized, чтобы запросить нужную вершину.

Используйте эти метки в контексте Ethereum. Роллап может использовать похожие слова для этапов с секвенсором и родительской цепочкой. Не применяйте процедуру Mainnet без изменений к переводу через мост и не предполагайте, что финализированная транзакция исходной сети завершает действие в сети назначения.

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

Сверьте транзакцию с финализированной цепочкой

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

1. Зафиксируйте транзакцию. Запишите Ethereum Mainnet и полный хеш транзакции. Прочтите квитанцию, отметив номер и хеш содержащего блока и статус исполнения. Недоступная квитанция оставляет вопрос открытым; проверьте сеть и провайдера, прежде чем объявлять транзакцию неудачной.
2. Прочтите сообщаемое состояние финальности. Используйте документированную метку блока обозревателя. В средстве чтения JSON-RPC метод eth_getBlockByNumber с finalized запрашивает текущую финализированную вершину. Сохраните возвращённый номер блока и время наблюдения. Неподдерживаемое или неудачное чтение остаётся непроверенным.
3. Сравните идентичность блока вместе с высотой. Если финализированная вершина ниже содержащего транзакцию блока, это наблюдение ещё не охватывает транзакцию. Если она достигла или прошла эту высоту, заново прочтите канонический блок на высоте включения и сравните его хеш с хешем блока из квитанции. Используйте согласованного провайдера с актуальными данными и перепроверьте квитанцию при несовпадении хешей.
4. Учитывайте границы вывода. Совпавший содержащий блок на уровне финализированной вершины или позади неё подтверждает финальность в сообщённой цепочке. Устаревший или несогласованный провайдер всё ещё может вводить в заблуждение. Сохраните расхождения и обратитесь к официальному статусу или поддержке провайдера вместо попыток получить ответ из смешанных снимков.
5. Отдельно проверьте требование приложения. Установите, что фактически сделала транзакция и зачислил ли её принимающий сервис по своим правилам. Не отправляйте второй платёж только потому, что галерея или страница пополнения не обновилась.

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

Внимательно читайте меняющееся число подтверждений

Допустим, гипотетическая квитанция помещает транзакцию в блок 100, а средство чтения сообщает финализированную вершину 98. Транзакция уже может показывать Success, но это наблюдение вершины не охватывает блок 100. Если более позднее согласованное чтение сообщает финализированную вершину 102, прежде чем отметить блок транзакции охваченным, проверьте, что канонический блок на высоте 100 всё ещё имеет хеш из квитанции.

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

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

Завершите записью блока с датой

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

Финальность не доказывает, что правильный токен дошёл правильному получателю, что контракт заслуживает доверия или что кастодиальный сервис завершил свой учёт. Расхождение баланса портфеля после финализации также может быть проблемой отображения, покрытия или цены.

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