Что изменилось в транзакциях v1
Транзакции устаревшего формата и v0 не изменились. Для большинства интеграций важны две особенности транзакций v1:- Необходимо явно разрешить их получение. В запросах полных данных транзакций требуется
maxSupportedTransactionVersion: 1, а библиотека клиента должна поддерживать десериализацию v1. - Бюджет вычислений переносится в заголовок сообщения. Сообщение v1 содержит объект
transactionConfigс полямиcomputeUnitLimit,heapSize,loadedAccountsDataSizeLimitиpriorityFee. В транзакции v1 нет инструкций программы ComputeBudget.
"version": 1, а ее message содержит transactionConfig:
"priorityFee": 50000 означает, что эта транзакция платит в общей сложности 50 000 лампортов. Поле null означает, что отправитель не задал это значение. В сообщениях устаревшего формата и v0 поле transactionConfig полностью отсутствует.
Задайте для maxSupportedTransactionVersion значение 1
Каждый запрос, возвращающий полные данные транзакции, должен указывать наибольшую поддерживаемую им версию транзакции. ЗадайтеmaxSupportedTransactionVersion: 1 для следующих методов:
getTransactiongetBlockgetTransactionsForAddressсtransactionDetails: "full"transactionSubscribeсtransactionDetails: "accounts"или"full"blockSubscribe
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 layout of a transaction v1 with three addresses and one instruction. The signature sits at the end, after the message.
- Rust:
agave-transaction-viewвыполняет синтаксический анализ устаревшего формата, v0 и v1 без копирования.wincode, совместимый с bincode сериализатор, используемый текущими SDK Solana, также декодирует v1 вVersionedTransaction. - JavaScript / TypeScript:
@solana/kit8.0+ или@solana/web3.jsv3.
0x81 означает v1, а подписи в этом формате находятся после сообщения, а не перед ним.
Контрольный список
- Найдите с помощью grep все упоминания
getBlock,getTransaction,getTransactionsForAddress,transactionSubscribeиblockSubscribe, включая необработанные тела JSON-RPC и обертки SDK, такие какconnection.getParsedTransaction. - Обновитесь до SDK с поддержкой v1.
- Задайте
maxSupportedTransactionVersion: 1во всех вызовах, найденных на шаге 1. - Замените поиск инструкций ComputeBudget проверкой
transactionConfigи интерпретируйтеpriorityFeeкак общее количество лампортов. - Замените декодеры необработанных данных типа
bincodeнаagave-transaction-viewили обновленный SDK. - Обновите зависимости потоковой передачи до версий, указанных в таблице выше.
- После изменения найдите в журналах
-32015с помощью grep, чтобы убедиться, что ошибок больше нет.
Связанные материалы
getTransaction guide
Параметры, структура ответа и примеры получения одной транзакции.
getBlock guide
Получите полный блок со всеми содержащимися в нем транзакциями.
getTransactionsForAddress
Отфильтрованная история транзакций с пагинацией для любого адреса в одном вызове.
Agave 4.2 migration checklist
Все критические изменения Agave 4.2 и шаги по их устранению.