simulateTransaction в Solana: что показывает симуляция и чего она не доказывает

Симуляция проверяет сообщение на выбранном срезе состояния

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

Указывайте commitment, согласованный с получением blockhash и отправкой. Симуляция показывает, как инструкции исполняются на выбранном банке в момент запроса, а не резервирует аккаунты и не обещает такой же результат на следующем блоке.

• endpoint и commitment симуляции сохранены
• контекст состояния соответствует цели проверки
• симуляция не принята за broadcast

Сначала проверьте err, затем используйте логи как объяснение

В результате могут присутствовать err, logs, unitsConsumed, loadedAccountsDataSize, fee и replacementBlockhash; набор зависит от запроса и версии RPC. err показывает исход моделируемого исполнения. Логи помогают найти программу и инструкцию, где возникла ошибка. unitsConsumed – оценка вычислительной работы в симуляции, а не гарантия будущего бюджета при изменившемся ходе исполнения.

Сопоставляйте путь инструкции, адрес программы, входные данные и ошибки. Не считайте лог успешным доказательством изменения аккаунта: изменения симуляции не сохраняются как транзакция. Если RPC не вернул поле, не подставляйте ноль без проверки схемы и ответа endpoint.

• err прочитан до интерпретации логов
• unitsConsumed принят за оценку
• отсутствующие поля не заменены нулями

sigVerify и replaceRecentBlockhash меняют цель проверки

При sigVerify=true RPC проверяет подписи перед симуляцией. Если проверка выключена, успешный прогон не подтверждает, что сформированная транзакция имеет действительные подписи. Для диагностики устаревшего хеша можно запросить replaceRecentBlockhash: RPC использует заменённый хеш в симуляции и может вернуть replacementBlockhash.

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

• sigVerify проверен
• replaceRecentBlockhash ограничен симуляцией
• изменение сообщения требует новой подписи

Состояние может измениться до фактического исполнения

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

sendTransaction по умолчанию делает preflight: проверяет подписи и моделирует транзакцию на выбранном уровне перед ретрансляцией. Но ответ sendTransaction всё ещё не является подтверждением обработки. После отправки отслеживайте signature, commitment и err отдельно. Если preflight отключён, вы берёте на себя эти предварительные проверки и всё равно должны отслеживать результат.

Чек-лист: simulatetransaction в solana: что показывает симуляция и чего она не доказывает

• commitment и источник состояния записаны;
• err проверен до интерпретации логов;
• значение unitsConsumed не принято за гарантию;
• известно, выполнялась ли проверка signature;
• replaceRecentBlockhash не спутан с обновлением подписанной транзакции;
• перед отправкой сообщение и состояние пересверены;
• после broadcast статус проверяется отдельно.

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