Solana раскрывает ошибку, которая может заморозить сетевые ридеры

Главное за минуту:

• Формат транзакций Solana v1 увеличивает размер данных с 1,232 байта до 4,096 байт — рост в 3,3 раза;
• RPC-клиенты, индексеры и релеи без обновления могут зависать или показывать нулевые бюджеты без ошибок;
• Обновление активно в testnet, devnet работает с эпохи 1140, mainnet пока ждет активации;
• Минимальные версии для совместимости: @solana/kit 8.0.0, web3.js 3.0.0-rc.3, Rust 4.2.x.

Команда Octobit разобрала технические детали и риски для операторов инфраструктуры.

Что меняет v1 и где угроза

Формат транзакций v1 — это не косметический патч. Максимальный размер данных растет с 1,232 байтов до 4,096 байтов, что дает разработчикам втрое больше места для сложных операций. Старые форматы legacy и v0 остаются рабочими, поэтому пользователи могут не мигрировать немедленно.

Проблема в том, что v1 переносит лимиты compute-unit, данные загруженных аккаунтов и приоритетные комиссии из инструкций ComputeBudget в новый объект transactionConfig. Если RPC-потребитель не передает параметр maxSupportedTransactionVersion: 1, система падает. По данным xroot.dev, запрос getTransaction возвращает ошибку -32015, getBlock ломается для всего блока, а blockSubscribe останавливается на первом пораженном слоте с выводом block: null.

Это не теоретическая угроза. Индексеры, которые продолжают сканировать инструкции ComputeBudget, показывают нулевой compute budget для каждой v1-транзакции без выброса ошибки — тихий сбой, который разрушает аналитику. Похожие кейсы по другим 👉 блокчейн-сетям мы регулярно разбираем в разделе 👉 новости альткоинов.

Кто под ударом

RPC-клиенты и индексеры — первая линия уязвимости. Если вы используете Geyser или gRPC, есть ловушка: флажок versioned в protobuf равен true как для v0, так и для v1. Устаревший потребитель может ошибочно маркировать v1 как v0 и сохранять пустой бюджет.

Решение: регенерировать protobuf stubs и проверять наличие Message.config (поле 7) перед чтением флажка. Без этого шага вы постепенно накапливаете неправильные данные.

Релеи, paymasters и другие серверные подписанты сталкиваются с риском контроля политики. Спонсор, ограничивающий комиссию через сканирование ComputeBudget instructions, теряет связующий кап — эти инструкции могут появляться в v1, но выполняются как no-ops. Серверы должны идентифицировать префикс 0x81 для v1 и применять лимиты из transactionConfig. По информации из официального changelog Solana, опубликованного 28 августа 2026, это не консенсусная уязвимость, но контроль приложений может провалиться.

Onchain-программы в худшей позиции: ни один текущий sysvar или syscall не раскрывает конфигурацию сообщения v1. Программы, блокирующие поведение на основе интроспекции ComputeBudget instructions, должны прекратить полагаться на эту проверку после активации v1.

Yellowstone и gRPC: отдельная история

Пользователи Yellowstone нуждаются как минимум в yellowstone-grpc-proto 12.6.0, geyser plugin 15.1.1, gRPC client 12.0.0 или @triton-one/yellowstone-grpc 6.0.0 — в зависимости от стека.

Создание v1-транзакций опционально, но если вы решили использовать новый формат, нужно:

• Установить compute-unit и лимиты данных явно — по умолчанию оба равны нулю;
• Удалить no-op ComputeBudget instructions;
• Прекратить использование address lookup tables;
• Применять base64 для payload размером свыше 1,232 байта.

Немедленный дедлайн — это не массовая миграция кошельков. Это проверка каждого сервиса, который может столкнуться с v1-транзакцией других пользователей.

🔮 Чего ждать дальше?

Обновление v1 расширяет возможности Solana, но создает технический разрыв между подготовленными и неготовыми операторами. Если вы запускаете RPC-узел, индексер или платежный шлюз — обновление критично. Mainnet активация может произойти без предупреждения, и ваш сервис просто зависнет или будет выдавать пустые данные. Риск не в консенсусе, а в инфраструктуре.