> ## Documentation Index > Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Поддержка транзакций v1 > Подготовьте интеграцию с Solana к транзакциям v1: задайте для maxSupportedTransactionVersion значение 1, обновите SDK до версии с поддержкой v1 и считывайте приоритетные комиссии из transactionConfig. Agave 4.2 вводит транзакции v1 ([SIMD-0385](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md)). После активации этой функции в основной сети кошельки и программы начнут отправлять транзакции v1, а в запросах полных данных транзакций потребуется явно разрешить их получение. На этой странице описано, что изменится, какие конечные точки Helius будут затронуты и как обновить код. Полный список действий для перехода на Agave 4.2, включая типы вознаграждений, семантику обновления учетных записей и расчет времени слотов, см. в [списке действий для перехода на Agave 4.2](https://www.helius.dev/blog/agave-4-2-migration-checklist). ## Что изменилось в транзакциях v1 Транзакции устаревшего формата и v0 не изменились. Для большинства интеграций важны две особенности транзакций v1: * **Необходимо явно разрешить их получение.** В запросах полных данных транзакций требуется `maxSupportedTransactionVersion: 1`, а библиотека клиента должна поддерживать десериализацию v1. * **Бюджет вычислений переносится в заголовок сообщения.** Сообщение v1 содержит объект `transactionConfig` с полями `computeUnitLimit`, `heapSize`, `loadedAccountsDataSizeLimit` и `priorityFee`. В транзакции v1 нет инструкций программы ComputeBudget. Двоичный формат также изменился: добавлен новый байт версии, а подписи перенесены в конец транзакции. Однако это влияет только на код, декодирующий необработанные байты транзакций. См. раздел [Декодирование необработанных байтов транзакции](#декодируйте-необработанные-байты-транзакций-с-помощью-парсера-поддерживающего-v1) ниже. В ответах JSON транзакция v1 сообщает `"version": 1`, а ее `message` содержит `transactionConfig`: ```json theme={"system"} { "version": 1, "transaction": { "signatures": ["..."], "message": { "accountKeys": ["..."], "instructions": [ { "programIdIndex": 3, "accounts": [0, 1], "data": "3Bxs4..." } ], "recentBlockhash": "...", "transactionConfig": { "computeUnitLimit": 200000, "heapSize": null, "loadedAccountsDataSizeLimit": 200000, "priorityFee": 50000 } } } } ``` `"priorityFee": 50000` означает, что эта транзакция платит в общей сложности 50 000 лампортов. Поле `null` означает, что отправитель не задал это значение. В сообщениях устаревшего формата и v0 поле `transactionConfig` полностью отсутствует. ## Задайте для maxSupportedTransactionVersion значение 1 Каждый запрос, возвращающий полные данные транзакции, должен указывать наибольшую поддерживаемую им версию транзакции. Задайте `maxSupportedTransactionVersion: 1` для следующих методов: * [`getTransaction`](/docs/ru/rpc/guides/gettransaction) * [`getBlock`](/docs/ru/rpc/guides/getblock) * [`getTransactionsForAddress`](/docs/ru/rpc/gettransactionsforaddress) с `transactionDetails: "full"` * [`transactionSubscribe`](/docs/ru/rpc/websocket/transaction-subscribe) с `transactionDetails: "accounts"` или `"full"` * [`blockSubscribe`](/docs/ru/api-reference/rpc/websocket/blocksubscribe) Запрос без этого параметра или со значением `0` завершается ошибкой JSON-RPC `-32015`, как только обращается к транзакции v1: ```json theme={"system"} { "jsonrpc": "2.0", "error": { "code": -32015, "message": "Transaction version (1) is not supported by the requesting client. Please use \"maxSupportedTransactionVersion\" in your request." }, "id": 1 } ``` Для `getBlock` одна транзакция v1 в любой части блока приводит к сбою всего запроса. Если в журналах присутствует `-32015`, проект уже не может обработать версионированные транзакции. ```json getTransaction theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "getTransaction", "params": [ "2id3YC2jK9G5Wo2phDx4gJVAew8DcY5NAojnVuao8rkxwPYPe8cSwE5GzhEgJA2y8fVjDEo6iR6ykBvDxrTQrtpb", { "encoding": "jsonParsed", "commitment": "confirmed", "maxSupportedTransactionVersion": 1 } ] } ``` ```json getBlock theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "getBlock", "params": [ 341197053, { "encoding": "jsonParsed", "transactionDetails": "full", "maxSupportedTransactionVersion": 1 } ] } ``` ```json getTransactionsForAddress theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "getTransactionsForAddress", "params": [ "86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY", { "transactionDetails": "full", "encoding": "jsonParsed", "limit": 100, "maxSupportedTransactionVersion": 1 } ] } ``` ```json transactionSubscribe theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "transactionSubscribe", "params": [ { "accountInclude": ["86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY"] }, { "commitment": "confirmed", "encoding": "jsonParsed", "transactionDetails": "full", "maxSupportedTransactionVersion": 1 } ] } ``` ## Обновите SDK перед увеличением значения Параметр `maxSupportedTransactionVersion: 1` сообщает узлу, что нужно возвращать транзакции v1. Однако библиотека клиента должна уметь их десериализовать. Сначала обновите ее, а затем измените параметр: | Клиент | Минимальная версия с поддержкой транзакций v1 | | - | - | | `@solana/kit` | 8.0 | | `@solana/web3.js` | v3 | | Rust `solana-sdk` / `solana-transaction-status` | Выпуск, собранный на пакетах Agave 4.2 | | `yellowstone-grpc-client` | 13.3.0 | | `yellowstone-grpc-proto` | 12.6.0 | | `helius-laserstream` (JavaScript) | 0.8.4 | | `helius-laserstream` (Rust) | 0.6.3 | | `helius-laserstream` (Go) | 0.2.0 | Старые реализации `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`, а единицы измерения отличаются: | Формат | Где хранится комиссия | Единица измерения | | - | - | - | | Устаревший, v0 | Инструкция `setComputeUnitPrice` | Микролампорты на единицу вычислений | | v1 | `transactionConfig.priorityFee` | Общее количество лампортов за транзакцию | Не переносите вычисление `price × computeUnitLimit ÷ 1e6` из устаревшего формата на `priorityFee`. Это значение уже представляет собой итоговую сумму. ```typescript priority-fee.ts theme={"system"} import bs58 from "bs58"; const COMPUTE_BUDGET = "ComputeBudget111111111111111111111111111111"; /** Total priority fee in lamports for a `json`-encoded transaction. */ function priorityFeeLamports(tx: any): number { const message = tx.transaction.message; // v1: the header carries the total directly. if (message.transactionConfig) { return message.transactionConfig.priorityFee ?? 0; } // Legacy and v0: derive it from ComputeBudget instructions. let microLamportsPerCu = 0n; let computeUnitLimit: bigint | null = null; let otherInstructions = 0; for (const ix of message.instructions) { if (message.accountKeys[ix.programIdIndex] !== COMPUTE_BUDGET) { otherInstructions++; continue; } const data = bs58.decode(ix.data); const view = new DataView(data.buffer, data.byteOffset, data.byteLength); if (data[0] === 2) computeUnitLimit = BigInt(view.getUint32(1, true)); if (data[0] === 3) microLamportsPerCu = view.getBigUint64(1, true); } // Without an explicit limit, the runtime grants 200,000 CU per non-ComputeBudget instruction, capped at 1,400,000. const limit = computeUnitLimit ?? BigInt(Math.min(otherInstructions * 200_000, 1_400_000)); return Number((microLamportsPerCu * limit) / 1_000_000n); } ``` Выбирайте ветвь по `transactionConfig` (или `version === 1`), а не по наличию инструкций ComputeBudget, поскольку в транзакции устаревшего формата без приоритетной комиссии они также отсутствуют. ## Декодируйте необработанные байты транзакций с помощью парсера, поддерживающего v1 Этот раздел применим, только если вы получаете необработанные байты транзакций, например из [preconfSubscribe](/docs/ru/pre-confirmations/preconf-subscribe), [preprocessedSubscribe](/docs/ru/preprocessed-transactions/preprocessed-subscribe) или ответа 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 Пошаговое описание каждого поля двоичного формата v1 см. в разделе [Транзакции v1 в статье о версиях транзакций Solana](https://www.helius.dev/blog/solana-transaction-versions#transaction-v1). Используйте декодер, который поддерживает структуру v1: * **Rust:** [`agave-transaction-view`](https://docs.rs/agave-transaction-view) выполняет синтаксический анализ устаревшего формата, v0 и v1 без копирования. [`wincode`](https://docs.rs/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](https://www.helius.dev/blog/solana-transaction-versions). ## Связанные материалы Параметры, структура ответа и примеры получения одной транзакции. Получите полный блок со всеми содержащимися в нем транзакциями. Отфильтрованная история транзакций с пагинацией для любого адреса в одном вызове. Все критические изменения Agave 4.2 и шаги по их устранению. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.