Ошибки транзакций Solana: истекший blockhash и транзакции без включения

2026-08-12

Одну транзакцию Solana можно одновременно описывать на нескольких уровнях. Сообщение описывает предполагаемые инструкции и их контекст, подписанная транзакция несёт авторизацию для этого сообщения, ответ RPC сообщает, что принял или наблюдал один сервис, а запись кластера служит свидетельством на указанном уровне commitment. Эти уровни могут давать разные формулировки статуса и не противоречить друг другу. Поэтому чтение сообщения об истечении срока или о невключенной транзакции начинается с определения уровня, который его выдал. Локальный тайм-аут, ошибка RPC, ответ о статусе и финализированная запись описывают разные точки пути отправки, а не один универсальный вывод о состоянии.

Схема состояний транзакции Solana от сообщения до записанного результата

Статус транзакции и путь отправки

Транзакция Solana содержит инструкции, подписи аккаунтов, авторизующие изменения, и recent blockhash. При обработке сеть рассматривает её инструкции как единое атомарное целое: сбой одной инструкции не позволяет зафиксировать предполагаемые изменения состояния вместе. До появления такого результата транзакция может пройти разные стадии формирования сообщения, подписания, передачи узлу RPC, приёма участниками сети, обработки и наблюдения на уровне commitment. Метка статуса имеет смысл только тогда, когда понятна её стадия.

Метод RPC sendTransaction сообщает первую подпись транзакции, когда служба RPC принимает подписанную нагрузку для ретрансляции. Официальная документация прямо отделяет это немедленное принятие от обработки или подтверждения кластером. В обычной речи dropped transaction часто означает отсутствие последующей записи кластера после раннего события, связанного с отправкой. Это не единый консенсусный статус с одной неизменной причиной. Выражение может использовать клиент, служба RPC или наблюдатель, и каждый из них может иметь в виду разный отсутствующий переход на этом пути.

Роль blockhash

Recent blockhash в сообщении транзакции является предоставляемой сетью ссылкой на свежесть. Метод getLatestBlockhash возвращает и blockhash, и lastValidBlockHeight, связывая эту ссылку с границей высоты, а не с гарантированной длительностью по настенным часам. Благодаря этому протокол может оценить, остаётся ли транзакция с такой ссылкой в окне обработки. Blockhash является частью оцениваемого сообщения, поэтому он относится к идентичности транзакции и контексту проверки, а не к более позднему отображению в обозревателе.

Высота блока, продвижение слотов и прошедшее время связаны между собой, но их не следует считать взаимозаменяемыми часами. Точный параметр процессингового возраста, число слотов в документации и время, которое представляют эти слоты, зависят от соответствующей версии протокола и программного обеспечения, а также от условий сети. Поэтому recent blockhash правильнее понимать как зависящее от версии окно действительности. Устойчивый факт состоит в наличии границы; точная длительность не является универсальным обещанием.

Истечение и отсутствие — разные вещи

Истечение описывает результат проверки действительности: recent blockhash больше не пригоден для обработки транзакции по применимым правилам. Это относится к ограниченной во времени ссылке транзакции, а не является общей меткой каждой неудачной ретрансляции или отсутствующей записи. Когда люди используют поисковую фразу solana transaction expired, они часто называют видимый в клиенте результат, соответствующий этой границе жизненного цикла. Одна фраза не говорит, что именно получил отдельный узел RPC, и не описывает самостоятельный результат перевода.

Blockhash not found solana — поисковая фраза, которая часто соединяет строку интерфейса с названием сети. Фактическое сообщение blockhash-not-found может означать, что узел в своём текущем представлении и на данном уровне commitment не может разрешить указанный хеш для нужного контекста проверки. Такое наблюдение не тождественно автоматически доказательству, что последняя допустимая высота пройдена везде. Состояние узла, commitment, версия API, момент времени и формулировка клиента меняют представление одного широкого условия, поэтому эти две фразы не следует сводить к одному неизменному диагнозу.

Подписано, но не включено в блок

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

Методы статуса JSON-RPC явно показывают пределы наблюдения. getSignatureStatuses возвращает текущие статусы для переданных подписей, а его поиск по умолчанию ограничен недавним кэшем статусов, если не включён поиск истории транзакций. getTransaction возвращает подтверждённую транзакцию по подписи или null, когда она не найдена либо не подтверждена на запрошенном уровне commitment. Следовательно, ответ null имеет заданную область, а не является универсальным утверждением, что никакого события не было в сохранённом представлении каждого узла.

Различия между наблюдениями RPC, клиента и сети

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

Зависимость от версии важна на каждом уровне. Программное обеспечение узла Solana, клиентские библиотеки, конфигурация RPC, поддержка версии транзакций, значения commitment по умолчанию, хранение статусов и формулировки интерфейса могут меняться. Поэтому корректное толкование сначала определяет наблюдателя и область наблюдения, а затем придаёт смысл метке ошибки. Оно не предполагает, что фраза из одного интерфейса переносимо описывает каждый узел, каждый commitment или каждый выпуск программного обеспечения.

Почему повторная отправка не является универсальным ответом

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

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

Устойчивый словарь диагностики и границы риска

Устойчивый словарь помогает не смешивать уровни. Сообщение называет инструкции, аккаунты, recent blockhash и другие авторизуемые данные. Подпись идентифицирует подписанную транзакцию для API, ориентированных на статус. Отправка называет событие ретрансляции RPC, тогда как обработка, подтверждение и финализация называют разные уровни наблюдения сети. Commitment — это запрошенный порог видимости, используемый методами RPC. Истечение относится к ссылке на свежесть, а dropped обычно описывает неполный наблюдаемый путь, а не вердикт протокола с одним стандартизированным значением.

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

Дисклеймер: эта статья — образовательный материал Bitbase Academy, только для информационных целей. Она не является инвестиционным, торговым, налоговым или финансовым советом. Криптоактивы волатильны — оценивайте риски самостоятельно. Написано в августе 2026 года; сверяйтесь с актуальной официальной информацией.