Skip to main content
Agave 4.2 вводит транзакции v1 (SIMD-0385). После активации этой функции в основной сети кошельки и программы начнут отправлять транзакции v1, а в запросах полных данных транзакций потребуется явно разрешить их получение. На этой странице описано, что изменится, какие конечные точки Helius будут затронуты и как обновить код. Полный список действий для перехода на Agave 4.2, включая типы вознаграждений, семантику обновления учетных записей и расчет времени слотов, см. в списке действий для перехода на Agave 4.2.

Что изменилось в транзакциях v1

Транзакции устаревшего формата и v0 не изменились. Для большинства интеграций важны две особенности транзакций v1:
  • Необходимо явно разрешить их получение. В запросах полных данных транзакций требуется maxSupportedTransactionVersion: 1, а библиотека клиента должна поддерживать десериализацию v1.
  • Бюджет вычислений переносится в заголовок сообщения. Сообщение v1 содержит объект transactionConfig с полями computeUnitLimit, heapSize, loadedAccountsDataSizeLimit и priorityFee. В транзакции v1 нет инструкций программы ComputeBudget.
Двоичный формат также изменился: добавлен новый байт версии, а подписи перенесены в конец транзакции. Однако это влияет только на код, декодирующий необработанные байты транзакций. См. раздел Декодирование необработанных байтов транзакции ниже. В ответах JSON транзакция v1 сообщает "version": 1, а ее message содержит transactionConfig:
"priorityFee": 50000 означает, что эта транзакция платит в общей сложности 50 000 лампортов. Поле null означает, что отправитель не задал это значение. В сообщениях устаревшего формата и v0 поле transactionConfig полностью отсутствует.

Задайте для maxSupportedTransactionVersion значение 1

Каждый запрос, возвращающий полные данные транзакции, должен указывать наибольшую поддерживаемую им версию транзакции. Задайте maxSupportedTransactionVersion: 1 для следующих методов: Запрос без этого параметра или со значением 0 завершается ошибкой JSON-RPC -32015, как только обращается к транзакции v1:
Для getBlock одна транзакция v1 в любой части блока приводит к сбою всего запроса. Если в журналах присутствует -32015, проект уже не может обработать версионированные транзакции.

Обновите SDK перед увеличением значения

Параметр maxSupportedTransactionVersion: 1 сообщает узлу, что нужно возвращать транзакции v1. Однако библиотека клиента должна уметь их десериализовать. Сначала обновите ее, а затем измените параметр: Старые реализации VersionedTransaction.deserialize на JavaScript обрабатывают только устаревший формат и v0 и выдают исключение при начальном байте 0x81. Старые protobuf-схемы Yellowstone появились до полей сообщений v1, поэтому потребители gRPC этих версий никогда не получают transactionConfig. Для клиентов gRPC на Go повторно сгенерируйте код из последних protobuf-схем Yellowstone и solana-storage-proto.

Считывайте приоритетные комиссии из transactionConfig

Код, который оценивает приоритетную комиссию транзакции путем поиска инструкций программы ComputeBudget (ComputeBudget111111111111111111111111111111, setComputeUnitPrice, setComputeUnitLimit), определяет комиссию каждой транзакции v1 как нулевую. В v1 значения находятся в message.transactionConfig, а единицы измерения отличаются: Не переносите вычисление price × computeUnitLimit ÷ 1e6 из устаревшего формата на priorityFee. Это значение уже представляет собой итоговую сумму.
priority-fee.ts
Выбирайте ветвь по transactionConfig (или version === 1), а не по наличию инструкций ComputeBudget, поскольку в транзакции устаревшего формата без приоритетной комиссии они также отсутствуют.

Декодируйте необработанные байты транзакций с помощью парсера, поддерживающего v1

Этот раздел применим, только если вы получаете необработанные байты транзакций, например из preconfSubscribe, preprocessedSubscribe или ответа RPC в кодировке base64. Если вы работаете с ответами json или jsonParsed, пропустите его. Транзакции v1 изменяют двоичную структуру двумя способами:
  • Байт версии. Транзакция v1 начинается с 0x81 (десятичное значение 129). Транзакция v0 начинается с 0x80.
  • Подписи перемещаются в конец. В устаревшем формате и v0 сначала идут подписи, а затем сообщение. В транзакции v1 сначала идет сообщение, а подписи находятся в конце, поэтому декодеры типа bincode, ожидающие массив подписей в начале, не могут обработать байты v1.
Byte-by-byte layout of a Solana transaction v1: version byte, header, config mask, lifetime specifier, address and instruction counts, three 32-byte addresses, compute unit config, instruction header, indices, discriminators, lamports, and a 64-byte signature at the end

Byte layout of a transaction v1 with three addresses and one instruction. The signature sits at the end, after the message.

Пошаговое описание каждого поля двоичного формата v1 см. в разделе Транзакции v1 в статье о версиях транзакций Solana. Используйте декодер, который поддерживает структуру v1:
  • Rust: agave-transaction-view выполняет синтаксический анализ устаревшего формата, v0 и v1 без копирования. wincode, совместимый с bincode сериализатор, используемый текущими SDK Solana, также декодирует v1 в VersionedTransaction.
  • JavaScript / TypeScript: @solana/kit 8.0+ или @solana/web3.js v3.
Пользовательские декодеры должны проверять первый байт: 0x81 означает v1, а подписи в этом формате находятся после сообщения, а не перед ним.

Контрольный список

  1. Найдите с помощью grep все упоминания getBlock, getTransaction, getTransactionsForAddress, transactionSubscribe и blockSubscribe, включая необработанные тела JSON-RPC и обертки SDK, такие как connection.getParsedTransaction.
  2. Обновитесь до SDK с поддержкой v1.
  3. Задайте maxSupportedTransactionVersion: 1 во всех вызовах, найденных на шаге 1.
  4. Замените поиск инструкций ComputeBudget проверкой transactionConfig и интерпретируйте priorityFee как общее количество лампортов.
  5. Замените декодеры необработанных данных типа bincode на agave-transaction-view или обновленный SDK.
  6. Обновите зависимости потоковой передачи до версий, указанных в таблице выше.
  7. После изменения найдите в журналах -32015 с помощью grep, чтобы убедиться, что ошибок больше нет.
Подробный технический разбор спецификаций версий транзакций Solana, двоичных форматов и примеров приведен в нашей статье Версионирование транзакций Solana: устаревший формат, v0 и v1.

Связанные материалы

getTransaction guide

Параметры, структура ответа и примеры получения одной транзакции.

getBlock guide

Получите полный блок со всеми содержащимися в нем транзакциями.

getTransactionsForAddress

Отфильтрованная история транзакций с пагинацией для любого адреса в одном вызове.

Agave 4.2 migration checklist

Все критические изменения Agave 4.2 и шаги по их устранению.