Skip to main content

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

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

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

Транзакция v1 должна быть сериализована каноническим кодировщиком этого формата. В Rust это wincode. Прежний путь через bincode и serde даёт правильные байты для legacy и v0, но неправильные байты для v1, и транзакция будет отклонена как некорректная. Клиент на Rust предоставляет правильный кодировщик как apex_sender_client::serialize_transaction. Для legacy и v0 он побайтово идентичен bincode, а для v1 даёт корректный результат. ApexSenderClient::send_transaction использует его внутри, поэтому вызывать его самостоятельно нужно, только когда вам нужны байты, например для HTTP-маршрутов. В других языках используйте версию библиотеки 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. В дополнение к зависимостям из раздела Быстрый старт ей нужна solana-message = "=4.4.1".
Отправка более 4096 байт завершается локальной ошибкой Error::TooLarge до того, как что-либо попадёт в сеть.

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

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