Skip to main content
Метод RPC getTransaction позволяет получить подробную информацию о подтвержденной транзакции по ее подписи. Эта информация включает слот транзакции, время блока, метаданные (например, комиссии, статус и изменения баланса), а также структуру самой транзакции.
Для повышения производительности не объединяйте запросы в пакетыПакетное выполнение архивных методов значительно увеличивает задержку. Пакеты размером более 100 запросов не допускаются.

Распространенные сценарии использования

  • Проверка транзакции: подтверждение обработки транзакции и проверка ее результата (успех или ошибка).
  • Отображение истории транзакций: отображение пользователям сведений об их прошлых транзакциях в кошельке или обозревателе.
  • Аудит и анализ: изучение деталей транзакции, включая выполненные инструкции, уплаченные комиссии и задействованные аккаунты.
  • Отладка неуспешных транзакций: проверка полей logMessages и err в метаданных, чтобы понять причину сбоя транзакции.
  • Индексирование данных: извлечение определенной информации из транзакций для хранения и анализа вне блокчейна.

Параметры запроса

  1. transactionSignature (строка, обязательный): подпись транзакции в кодировке base58, которую требуется запросить.
  2. options (объект, необязательный): необязательный объект конфигурации, который может включать:
    • commitment (строка, необязательный): задает уровень подтверждения (например, "finalized", "confirmed"). Если параметр не указан, используется уровень подтверждения узла по умолчанию (обычно "finalized").
    • encoding (строка, необязательный): кодировка данных transaction. Распространенные значения:
      • "json": возвращает данные транзакции в структурированном формате JSON (однако инструкции могут по-прежнему быть закодированы в base64).
      • "jsonParsed": возвращает данные транзакции, по возможности преобразуя инструкции конкретных программ в удобочитаемую структуру JSON. Эта кодировка часто наиболее удобна для анализа.
      • "base58": возвращает данные транзакции в виде строки в кодировке base58.
      • "base64": возвращает данные транзакции в виде строки в кодировке base64.
      • Если Helius не задает значение, по умолчанию используется "json", однако значение по умолчанию в Solana может отличаться. Рекомендуется указывать этот параметр явно.
    • maxSupportedTransactionVersion (число, необязательный): максимальная версия транзакции, которую должна обрабатывать конечная точка RPC.
      • Установите значение 1, чтобы включить устаревшие транзакции, а также транзакции v0 и v1.
      • Если параметр не указан или его значение ниже версии транзакции, запрос завершается ошибкой JSON-RPC -32015 (Transaction version (1) is not supported by the requesting client). Всегда устанавливайте для него значение 1. См. раздел Поддержка транзакций v1.

Структура ответа

Метод возвращает null, если транзакция не найдена (например, еще не обработана или подпись указана неверно) либо не подтверждена на указанном уровне. В противном случае он возвращает объект со следующими полями:
  • slot (u64): номер слота, в котором транзакция была включена в блок.
  • blockTime (i64 | null): приблизительная временная метка Unix (количество секунд с начала эпохи), соответствующая моменту создания блока с транзакцией. Если значение недоступно, может быть null.
  • meta (объект | null): объект с метаданными о выполнении транзакции. Может иметь значение null, если транзакция завершилась с ошибкой до обработки или метаданные недоступны.
    • err (объект | null): объект ошибки, если транзакция завершилась с ошибкой; в противном случае — null.
    • fee (u64): комиссия за транзакцию в лампортах.
    • preBalances (массив u64): балансы задействованных аккаунтов в лампортах до обработки транзакции.
    • postBalances (массив u64): балансы задействованных аккаунтов в лампортах после обработки транзакции.
    • preTokenBalances (массив объектов | null): балансы токенов на задействованных токен-аккаунтах до транзакции.
    • postTokenBalances (массив объектов | null): балансы токенов на задействованных токен-аккаунтах после транзакции.
    • innerInstructions (массив объектов | null): массив инструкций, выполненных в рамках CPI (межпрограммных вызовов) в этой транзакции.
    • logMessages (массив строк | null): массив сообщений журнала, созданных инструкциями транзакции и всеми внутренними инструкциями.
    • loadedAddresses (объект, необязательный): указывает аккаунты, загруженные из таблиц поиска адресов для этой транзакции. Содержит массивы открытых ключей writable и readonly.
    • returnData (объект, необязательный): данные, возвращенные транзакцией через sol_set_return_data и sol_get_return_data. Содержит programId (строка) и data (массив: [string, encoding]).
    • computeUnitsConsumed (u64, необязательный): количество вычислительных единиц, использованных этой транзакцией.
  • transaction (объект | массив): структура самой транзакции. Формат зависит от параметра encoding:
    • Если encoding имеет значение "jsonParsed" или "json": объект с message (содержащим accountKeys, instructions, recentBlockhash и т. д.) и signatures (массив строк).
    • Если encoding имеет значение "base58" или "base64": массив [encoded_string, encoding_format_string].
  • version (“legacy” | число | undefined): версия транзакции. Для старых транзакций может иметь значение "legacy", а для версионированных — числовое значение (0 или 1). Значение undefined, если параметр maxSupportedTransactionVersion не задан, а транзакция является версионированной. Транзакция v1 также содержит объект transactionConfig в своем message с бюджетом вычислений (computeUnitLimit, heapSize, loadedAccountsDataSizeLimit, priorityFee), который заменяет инструкции программы ComputeBudget. Поле priorityFee содержит общую комиссию в лампортах, а не количество микролампортов на вычислительную единицу.
Пример ответа (кодировка jsonParsed):

Примеры кода

Рекомендации разработчикам

  • Финализация транзакции: запрашивайте данные с подходящим уровнем commitment. При запросе транзакции, которая не достигла указанного уровня подтверждения, будет возвращено значение null.
  • Объем данных: объект ответа может быть очень большим, особенно для сложных транзакций с множеством инструкций или подробным журналированием. Учитывайте это при обработке данных.
  • jsonParsed и json: хотя jsonParsed очень удобен, поддержка синтаксического анализа зависит от возможностей узла RPC для конкретных программ. Если программа не распознана, ее инструкции могут быть представлены в менее структурированном формате даже при использовании jsonParsed.
  • Версионированные транзакции: всегда задавайте maxSupportedTransactionVersion: 1 в параметрах запроса, чтобы ваше приложение могло обрабатывать как устаревшие, так и версионированные транзакции. В противном случае вы можете пропустить данные или столкнуться с ошибками при работе с новыми форматами транзакций.
  • Различия между поставщиками RPC: хотя основной API стандартизирован, некоторые поставщики RPC могут предлагать расширенный синтаксический анализ или дополнительные поля. Например, Helius обеспечивает подробный анализ транзакций.
В этом руководстве представлен исчерпывающий обзор метода RPC getTransaction, который поможет вам получать и понимать подробные данные о транзакциях Solana.