Skip to main content

Ограничения размера по форматам

Транзакция v1 использует формат сообщения, введённый в SIMD-0385. Главное изменение для отправителей касается размера: транзакция v1 может занимать до 4096 байт, тогда как для транзакций legacy и v0 остаётся предел 1232. Apex определяет формат по байтам транзакции. Не нужно ни задавать флаг, ни использовать отдельный маршрут.
Для участников бандла действуют те же размеры: до 4096 байт для v1, 1232 для legacy и v0.
Транзакция legacy или v0 больше 1232 байт, как и любая транзакция больше 4096 байт, отклоняется как слишком большая. См. Ошибки и лимиты запросов.

Сериализуйте v1 каноническим кодировщиком

Транзакция v1 должна быть сериализована каноническим кодировщиком этого формата. В Rust это wincode. Прежний путь через bincode и serde даёт правильные байты для legacy и v0, но неправильные байты для v1, и транзакция будет отклонена как некорректная. Клиент на Rust предоставляет правильный кодировщик как orbitflare_apex::serialize_transaction. Для legacy и v0 он побайтово идентичен bincode, а для v1 даёт корректный результат. ApexSenderClient::send_transaction использует его внутри, поэтому вызывать его самостоятельно нужно, только когда вам нужны байты, например для HTTP-маршрутов. Клиент на Go делает то же самое с помощью apex.SerializeTransaction, построенного на поддержке v1 в solana-go. В других языках используйте версию библиотеки Solana, которая реализует сериализацию SIMD-0385. Перед отправкой проверьте, что первый байт вашего сериализованного сообщения является префиксом версии v1.

Правило чаевых то же самое

Транзакции v1 нужны те же чаевые: один перевод SystemProgram верхнего уровня на опубликованный аккаунт для чаевых, оплаченный подписантом, не ниже минимума вашего тарифа. Одно отличие касается вычислительного бюджета. В сообщении v1 он задаётся в собственном TransactionConfig сообщения, а не инструкциями программы ComputeBudget. Каждый лимит, не заданный в TransactionConfig, равен 0, включая размер данных загружаемых аккаунтов. В нашем тесте в mainnet 2026-09-19 транзакция v1, которая полагалась на инструкции ComputeBudget, попала в блок и завершилась в сети ошибкой MaxLoadedAccountsDataSizeExceeded. Поэтому задавайте все три значения: лимит вычислительных единиц, лимит размера данных загружаемых аккаунтов и, для приоритета, комиссию. Приоритетная комиссия задаётся общей суммой в lamports, а не ценой за вычислительную единицу. С такой конфигурацией транзакции v1 размером 276, 741 и 1641 байт попали в блоки mainnet через Apex по QUIC. Транзакция в 1641 байт превышает предел legacy в 1232 байта.

Пример на Rust

Эта программа собирает транзакцию v1 с полезной нагрузкой в стиле memo размером 3,000 байт, которая не поместилась бы в транзакцию legacy, и отправляет её по QUIC. Она использует только зависимости из раздела Быстрый старт; типы сообщений v1 берутся из prelude клиента.
Отправка более 4096 байт завершается локальной ошибкой Error::TooLarge до того, как что-либо попадёт в сеть.

Отправка v1 по HTTP

Когда у вас есть правильно сериализованные байты v1, HTTP-маршруты принимают их точно так же, как любую транзакцию: base64 для sendTransaction и /send, сырые байты для /send-bin и /send-batch.