Три факта перед повтором
- Recent blockhash ограничивает срок обработки обычной транзакции; ориентир — lastValidBlockHeight, а не таймер в приложении.
- Compute unit limit ограничивает вычисления, а compute unit price формирует priority fee; запрошенный лимит и фактический расход — разные поля.
- Итог читают по commitment, meta.err, fee, computeUnitsConsumed, logMessages и изменениям балансов, а не по одному push-уведомлению.
Signature относится к конкретному сообщению
Solana-транзакция состоит из signatures и message. Cluster здесь означает выбранную сеть и её общую историю; slot — позицию, в которой leader-валидатор может предложить блок; commitment — требуемую степень закрепления результата. В message записаны права аккаунтов, recent blockhash и последовательность compiled instructions. Первая signature принадлежит fee payer и используется как transaction ID. Если приложение меняет blockhash, instruction, account или compute budget и просит подписать снова, получается другое сообщение и другая signature — это уже новая попытка, а не продолжение старой.
| Наблюдение | Что оно означает | Чего пока нет |
|---|---|---|
| Кошелёк показал signature | Сообщение было подписано и, возможно, отправлено RPC | Доказательства, что лидер включил его в slot |
| RPC sendTransaction вернул signature | RPC принял сериализованные bytes без немедленной ошибки | Гарантии обработки, подтверждения и успеха instructions |
| getSignatureStatuses вернул slot | Cluster наблюдает статус этой signature | Полных logs и изменений token balances |
| getTransaction вернул meta | Есть включённая транзакция и execution metadata | Личности контрагента или экономической добросовестности токена |
- Наблюдение
- Кошелёк показал signature
- Что оно означает
- Сообщение было подписано и, возможно, отправлено RPC
- Чего пока нет
- Доказательства, что лидер включил его в slot
- Наблюдение
- RPC sendTransaction вернул signature
- Что оно означает
- RPC принял сериализованные bytes без немедленной ошибки
- Чего пока нет
- Гарантии обработки, подтверждения и успеха instructions
- Наблюдение
- getSignatureStatuses вернул slot
- Что оно означает
- Cluster наблюдает статус этой signature
- Чего пока нет
- Полных logs и изменений token balances
- Наблюдение
- getTransaction вернул meta
- Что оно означает
- Есть включённая транзакция и execution metadata
- Чего пока нет
- Личности контрагента или экономической добросовестности токена
Формат строки встречается только в контексте выбранной сети и RPC. Для обычной проверки перевода сохраните саму signature, cluster, slot и commitment, а затем сопоставьте публичные поля с исходными реквизитами.
Recent blockhash задаёт окно обработки
Обычное message содержит recent blockhash. Валидатор принимает его, пока blockhash находится в допустимом недавнем диапазоне. Современный клиент получает вместе с ним lastValidBlockHeight: именно эта граница помогает решить, может ли старая подпись ещё попасть в блок. Перевод секунд в интерфейсе приблизителен, потому что длительность slots и скорость продвижения block height меняются.
Жизненный цикл обычной транзакции
- Получен recent blockhash
Клиент строит message и запоминает lastValidBlockHeight.
- Зафиксированы все instructions
Любое изменение message требует новой подписи.
- RPC передаёт bytes в cluster
Узел может выполнить preflight и повторять relay, но успешный ответ не гарантирует processing, inclusion или confirmation.
- Возможны resend и проверка статуса
Повторяют те же подписанные bytes, не создавая второй платёж вслепую.
- Blockhash истёк
Для новой обычной попытки нужен свежий blockhash и новая подпись.
Лимит вычислений и цена приоритета отвечают на разные вопросы
Compute unit (CU) измеряет работу runtime. Compute unit limit задаёт максимальный бюджет исполнения, а compute unit price — ставку в micro-lamports за запрошенную CU для optional prioritization fee. По действующей на 18 августа 2026 года официальной формуле priority fee равна округлённому вверх произведению CU price и CU limit, делённому на миллион. Она рассчитывается по запрошенному лимиту, а не по фактически использованным CU; базовую комиссию и эту надбавку полезно проверять раздельно.
| Поле | Что контролирует | Типичная ошибка |
|---|---|---|
| CU limit | Потолок вычислений одной транзакции | Считать большой limit фактическим расходом |
| CU price | Доплату за единицу запрошенного бюджета | Принимать её за полную fee в lamports |
| Priority fee | Доплату за scheduling priority | Считать её гарантией включения |
| computeUnitsConsumed | Фактическую работу исполненной попытки | Искать поле у транзакции, которая не была включена |
| fee | Списанную network fee по meta | Вычитать только priority component |
- Поле
- CU limit
- Что контролирует
- Потолок вычислений одной транзакции
- Типичная ошибка
- Считать большой limit фактическим расходом
- Поле
- CU price
- Что контролирует
- Доплату за единицу запрошенного бюджета
- Типичная ошибка
- Принимать её за полную fee в lamports
- Поле
- Priority fee
- Что контролирует
- Доплату за scheduling priority
- Типичная ошибка
- Считать её гарантией включения
- Поле
- computeUnitsConsumed
- Что контролирует
- Фактическую работу исполненной попытки
- Типичная ошибка
- Искать поле у транзакции, которая не была включена
- Поле
- fee
- Что контролирует
- Списанную network fee по meta
- Типичная ошибка
- Вычитать только priority component
Статус сети и результат программы читаются отдельно
Commitment processed, confirmed и finalized описывает, насколько cluster закрепил slot. Execution result находится в metadata. Значение meta.err=null означает, что instructions завершились без зафиксированной runtime error; ненулевой err показывает failure. Для failed transaction изменения состояния instructions откатываются атомарно, но network fee удерживается. Если обозреватель отстаёт или отвечает неоднозначно, отдельный узел и RPC дают независимую точку проверки.
Диагностика по публичным данным
- 1Зафиксируйте cluster и signature
Mainnet и test environments имеют разные истории. Не ищите одну строку во всех сетях и не делайте вывод по первому совпадению интерфейса.
- 2Получите confirmationStatus и slot
Сначала запросите getSignatureStatuses с searchTransactionHistory=true; затем проверьте err и commitment. Отсутствие status само по себе не различает задержку RPC, непринятый packet и истёкший blockhash.
- 3Откройте getTransaction metadata
Сверьте fee, preBalances, postBalances, preTokenBalances, postTokenBalances, logMessages и computeUnitsConsumed.
- 4Свяжите изменение с нужной instruction
Program logs и innerInstructions объясняют путь вызова. Тикер в интерфейсе не заменяет mint address и token account.
- 5Сформулируйте результат одной фразой
Например: finalized, meta.err=null, получатель и mint совпадают; либо confirmed, instruction error, fee списана, token balance не изменился.
| Что видно | Вероятная классификация | Следующее действие |
|---|---|---|
| Status есть, meta.err=null | Instruction execution успешен | Сверить balances, mint и ожидаемый recipient |
| Status есть, meta.err задан | Транзакция включена, программа завершилась ошибкой | Прочитать logs; не повторять до устранения причины |
| Status нет, blockhash ещё valid | Попытка могла не дойти до лидера или RPC отстаёт | Проверить другой RPC и rebroadcast тех же bytes |
| Status нет, lastValidBlockHeight пройдена | Blockhash уже не допускает новое включение, но recent cache не доказывает, что signature не включалась раньше | Проверить history=true и getTransaction в том же cluster; только при отсутствии записи строить новое message |
- Что видно
- Status есть, meta.err=null
- Вероятная классификация
- Instruction execution успешен
- Следующее действие
- Сверить balances, mint и ожидаемый recipient
- Что видно
- Status есть, meta.err задан
- Вероятная классификация
- Транзакция включена, программа завершилась ошибкой
- Следующее действие
- Прочитать logs; не повторять до устранения причины
- Что видно
- Status нет, blockhash ещё valid
- Вероятная классификация
- Попытка могла не дойти до лидера или RPC отстаёт
- Следующее действие
- Проверить другой RPC и rebroadcast тех же bytes
- Что видно
- Status нет, lastValidBlockHeight пройдена
- Вероятная классификация
- Blockhash уже не допускает новое включение, но recent cache не доказывает, что signature не включалась раньше
- Следующее действие
- Проверить history=true и getTransaction в том же cluster; только при отсутствии записи строить новое message
Для SPL-токена важны mint и token accounts
Успешная signature может создавать associated token account, перемещать SPL-токен и вызывать дополнительные programs в одной атомарной операции. Проверяйте не только SOL balances: нужное изменение может находиться в preTokenBalances и postTokenBalances. Важны mint, owner token account, decimals и raw amount. Одинаковое название токена не доказывает одинаковый mint.
Если интерфейс получателя не показал депозит, но транзакция successful и token balances изменились, проблема перемещается с уровня Solana execution на правила зачисления конкретного сервиса. Не отправляйте второй перевод, пока поддержка не получит signature, cluster, mint, recipient token account и slot.
Новая попытка допустима только после классификации старой
Перед повторной подписью должны быть известны
- исходная signature и cluster;
- lastValidBlockHeight либо факт durable nonce;
- confirmationStatus и meta.err, если запись существует;
- точная instruction error или причина отсутствия inclusion;
- ожидаемые program ID, mint, recipient и amount;
- новые CU limit и price, если ошибка действительно связана с budget или приоритетом.
Проверяемый финал — это не слово Success в кошельке, а связка из signature, cluster, slot, commitment, meta.err и ожидаемого изменения balances. Такой набор позволяет отличить сетевую доставку от выполнения программы и не превращать диагностику в серию дублирующих переводов.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- Solana Docs — Transaction Structure Solana · Проверено 18 августа 2026 г. в 22:30 GMT+5
- Solana Docs — Transaction Confirmation & Expiration Solana · Проверено 18 августа 2026 г. в 22:30 GMT+5
- Solana Docs — Fee Structure Solana · Проверено 18 августа 2026 г. в 22:30 GMT+5
- Solana RPC — getSignatureStatuses Solana · Проверено 18 августа 2026 г. в 22:30 GMT+5
- Solana RPC — getTransaction Solana · Проверено 18 августа 2026 г. в 22:30 GMT+5
- Solana RPC — sendTransaction Solana · Проверено 18 августа 2026 г. в 22:56 GMT+5