Recent blockhash и lastValidBlockHeight в Solana: как проверить срок транзакции

Высота блока превращает срок blockhash в проверяемую границу

При запросе getLatestBlockhash RPC возвращает контекст с номером слота и объект value с blockhash и lastValidBlockHeight. Сохраните оба значения вместе с commitment запроса и endpoint. Поле lastValidBlockHeight относится к высоте блока, а не к номеру слота: getSlot и getBlockHeight отвечают на разные вопросы.

Blockhash остаётся пригоден ограниченное число слотов по правилам runtime, но реальная длительность в секундах меняется вместе с производством блоков. Поэтому нельзя надёжно прибавлять к времени запроса постоянный таймер. Используйте именно границу из ответа, связанного с подписываемой транзакцией.

• blockhash и lastValidBlockHeight сохранены из одного ответа
• высота блока отделена от номера slot
• commitment запроса записан

Сравнивайте высоту на том же уровне commitment

После отправки опрашивайте getBlockHeight на уровне commitment, согласованном с получением blockhash. В руководстве Solana для обычного ожидания описывается confirmed: граница считается пройденной, когда возвращённая высота становится больше lastValidBlockHeight. Не выводите истечение только из времени ожидания или сообщения интерфейса.

Разные RPC-узлы могут видеть разные точки цепочки и отставать друг от друга. Если блокхеш получен у одного провайдера, а высота читается у другого, сохраните endpoint и commitment каждого запроса и учитывайте отставание. Значение isBlockhashValid может дополнительно показать валидность хеша на конкретном узле и выбранном commitment, но не доказывает, что конкретная подписанная транзакция уже исполнена.

• getBlockHeight опрашивается с согласованным commitment
• граница сравнивается строго с lastValidBlockHeight
• отставание RPC учтено

Статус подписи отвечает на вопрос об обработке, а не только о сроке

sendTransaction возвращает первую подпись, если RPC принял запрос к ретрансляции. Успешный JSON-RPC ответ не является подтверждением обработки кластером. Отслеживайте эту подпись через getSignatureStatuses; проверяйте confirmationStatus и поле err. Статус с err показывает, что транзакция была обработана с ошибкой, а не что платёж успешно завершён.

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

• signature и err проверены
• null сопоставлен с областью кэша и поиском истории
• до новой подписи исключено исполнение прежней

Не создавайте новую подпись после сетевого тайм-аута вслепую

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

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

Чек-лист: recent blockhash и lastvalidblockheight в solana: как проверить срок транзакции

• сохранены blockhash и lastValidBlockHeight именно этой транзакции;
• высота проверяется через getBlockHeight, а не getSlot;
• commitment и RPC endpoint записаны;
• подпись проверена, поле err прочитано;
• null проверен с учётом поиска по истории;
• до создания новой подписи исключено исполнение прежней транзакции;
• сетевой повтор не породил новый платёжный запрос.

Материал подготовлен редакцией сайта и проверен 7 ноября 2026 года. Условия бирж, кошельков и блокчейн-сетей могут меняться. Перед операцией сверяйте данные в интерфейсе выбранного сервиса.