Проверка совместимости перед переходом на формат транзакций Solana v1 на 4096 байт

Новый формат транзакций Solana (SOL) v1 проходит проверку совместимости инфраструктуры перед активацией в основной сети. Изменение заключается в увеличении максимального размера одной транзакции с 1232 байт до 4096 байт, однако основным вопросом является то, смогут ли RPC, индексаторы и спонсоры комиссий правильно обрабатывать новый формат, а не возникнут ли проблемы с консенсусом цепи.

Фонд Solana сообщил на странице обновления сети, что Agave 4.2 был запущен в основной сети, но функция "Более крупные размеры транзакций" находится в состоянии ожидания активации на 4 сентября 2026 года. Эта функция включает в себя увеличение существующего лимита транзакций примерно в 3,3 раза через формат транзакций v1.

Это изменение не является простым увеличением размера. SIMD-0296 и SIMD-0385 были предложены в контексте крупных мультиподписей, доказательства с нулевым разглашением (ZK proof) и пакетной передачи. В v1 будет уменьшена зависимость от таблицы адресов, используемой в существующих транзакциях, а информация о комиссиях и ограничениях ресурсов будет перенесена в отдельные настройки под названием transactionConfig.

Существующий способ чтения системы может стать проблемой на этом этапе. Если индексатор и спонсор комиссии просто просматривают инструкцию ComputeBudget, чтобы сначала рассчитать комиссию или лимит вычислительных единиц, они могут пропустить лимит комиссии v1 или прочитать его как 0. Примерный репозиторий фонда Solana объясняет, что сообщения v1 содержат TransactionConfig вместо инструкции ComputeBudget.

Документация Solana RPC указывает, что при вызовах getTransaction, getBlock и blockSubscribe необходимо включить maxSupportedTransactionVersion: 1. Если это значение пропустить или установить в 0, при поступлении транзакции v1 getTransaction может выдать ошибку, а getBlock может не удастся прочитать весь блок.

Подписка по веб-сокету также не является исключением. Если настройки не совпадают, blockSubscribe может вернуть block: null. Документация разработчиков Solana указывает, что это следует рассматривать не как пустой блок, а как сбой. Транзакции v1 идентифицируются по первому байту сериализованной транзакции 129, то есть 0x81.

На путях gRPC и Geyser могут возникнуть менее заметные ошибки. Документация разработчиков Solana предупреждает, что в gRPC нет опционального значения, такого как maxSupportedTransactionVersion, и устаревший прототип protobuf может игнорировать поле Message.config. В этом случае система не остановится, но транзакции v1 могут рассматриваться как v0, что приведет к пропуску настройки комиссии.

Примерный репозиторий фонда Solana предлагает минимальные версии @solana/kit 8.0.0, yellowstone-grpc-proto 12.6.0 и yellowstone-grpc geyser 15.1.1. Также предоставляются отдельные примеры для чтения, передачи, индексирования блоков и gRPC.

Проверка инструментов ядра также продолжается. Проблема #831 в solana-sdk от anza-xyz подняла вопрос о том, что максимальный размер v1 в 4096 байт не принудительно применяется в десериализаторе и санитайзере. Тем не менее, страница состояния Solana показывает, что на 4 сентября 2026 года узлы RPC основной сети Beta работают, и на тот день не было зарегистрировано инцидентов.

Данный вопрос имеет сильный характер проверки совместимости инфраструктуры, связанной с увеличением лимита транзакций Solana v1. Если ранее обсуждались лимиты в 4096 байт и активация функций по кластерам, то теперь ключевым моментом является то, сможет ли бэкэнд-система правильно обрабатывать новую структуру при поступлении реальных транзакций v1.

Страница обновлений Solana указывает, что функция "Более крупные размеры транзакций" находится в состоянии ожидания активации на 4 сентября 2026 года. Этот срок больше похож на техническую дорожную карту, которую должны последовательно подготовить кошельки, RPC, индексаторы и инструменты разработки, чем на единичное событие, которое изменяет структуру обработки Solana сразу.

С технической точки зрения транзакции v1 не заменяют существующие v0 и устаревшие транзакции. Существующий формат продолжит работать, но приложения, использующие большие размеры транзакций и transactionConfig, должны поддерживать новый формат. Обычно в обновлениях инфраструктуры блокчейна совместимость систем, которые читают и хранят данные, влияет на реальные операционные риски, а не только правила консенсуса.

Спонсоры комиссий и индексаторы могут быть особенно затронуты. Неправильное чтение лимитов комиссии или вычислительных единиц может подвергнуть сервисы, которые берут на себя расходы вместо пользователей, неожиданной структуре затрат, а системы анализа транзакций также могут неправильно записывать настройки ресурсов транзакций v1. Это не то же самое, что сбой цепи, но это область, требующая отдельной проверки для операторов услуг.

Национальные биржи или операторы кошельков также не могут избежать тех же проблем, если они управляют вводом и выводом Solana и мониторингом в цепочке. Им необходимо убедиться, что пути поиска блоков, транзакций, индексирования, мониторинга рисков и расчета комиссий обрабатывают структуру сообщений v1. Особенно в случае использования внешних поставщиков узлов или данных на основе Geyser необходимо проверить воспроизводимость protobuf и версии библиотек.

До фактического поступления транзакций v1 ключевыми пунктами проверки являются: △ настройка maxSupportedTransactionVersion: 1 для вызовов RPC △ отражение пути сохранения transactionConfig △ регенерация прототипа gRPC protobuf △ распознавание префикса версии 0x81. По состоянию на страницу обновлений Solana функция "Более крупные размеры транзакций" находится в состоянии ожидания активации на 4 сентября 2026 года.