9 сентября Solana включает на основной сети формат Transaction v1: предельный размер одной транзакции вырастет с 1 232 до 4 096 байт — втрое. Изменение уже отработано на тестовой сети, где оно активировалось 1 сентября в эпохе 1025. Для пользователей это ничего не ломает, для разработчиков кошельков, RPC-провайдеров и индексаторов — день, к которому нужно подготовиться.

Коротко

Два предложения по улучшению сети работают в паре: SIMD-0296 поднимает потолок размера, SIMD-0385 задаёт сам формат сообщения v1. В новом формате признак версии переехал в нулевую позицию, подписи — в хвост сообщения, а настройки вычислительного бюджета вместо отдельных инструкций описываются 32-битной маской по фиксированному смещению. Транзакции старого формата продолжают работать.

Зачем нужен запас в 4 096 байт

Предел в 1 232 байта достался Solana от размера UDP-пакета и держался с запуска. В него не помещается ряд операций, которые сегодня приходится разбивать на несколько транзакций и связывать вручную: доказательства с нулевым разглашением целиком, агрегированные BLS-подписи для многосторонних подтверждений, крупные институциональные кошельки с мультиподписью на много участников.

Разбиение стоит дорого не в комиссиях, а в надёжности: пока части идут отдельными транзакциями, между ними существует состояние, в котором операция выполнена наполовину. Запас в 4 096 байт убирает этот класс проблем для целого пласта сценариев — от приватных платежей до кворумных подписей в казначействах.

Что ломается у разработчиков

Что Как проявится
Вызовы RPC без maxSupportedTransactionVersion: 1 Ошибка с кодом −32015
Подписки по WebSocket Остановка на слотах с транзакциями v1
Индексаторы, ищущие инструкции вычислительного бюджета Вернут нули вместо реальных значений
Минимальные версии SDK @solana/kit 8.0.0, @solana/web3.js 1.99.0-beta.0 (чтение), Rust-крейты solana-* 4.2.x

Отдельного внимания требуют сервисы, которые парсят транзакции по смещениям байтов, а не через библиотеку: перенос подписей в конец сообщения ломает такой разбор молча, без ошибки.

Как проходила подготовка

Локальное тестирование формата открыли 24 августа, 1 сентября функция активировалась в тестовой сети на эпохе 1025, основная сеть идёт следом — 9 сентября. Порядок обычный для Solana: сначала клиент с выключенной по умолчанию функцией, затем включение по эпохам, кластер за кластером.

Само по себе увеличение лимита пропускную способность сети не поднимает: блок остаётся прежнего объёма, и чем крупнее отдельная транзакция, тем меньше их поместится рядом. Выигрыш здесь не в скорости, а в том, что операция, которая раньше не помещалась в блокчейн одним куском, теперь помещается.

Что делать держателям SOL

Ничего. Кошельки обновятся сами, адреса и балансы не меняются, ставки в стейкинге не затрагиваются. Единственное практическое замечание — в день переключения возможны кратковременные сбои у сервисов, которые не обновили библиотеки: приложение может не увидеть свежую транзакцию, хотя в сети она прошла. Проверять такие случаи стоит в обозревателе блоков, а не в интерфейсе кошелька.

Частые вопросы

Транзакции станут дороже

Формула комиссии не меняется. Крупная транзакция расходует больше места в блоке, но правила расчёта платы за подпись и за вычисления остаются прежними.

Старые транзакции перестанут работать

Нет, прежний формат остаётся валидным. Новый добавляется рядом, и приложение само решает, каким пользоваться.

Это и есть Alpenglow

Нет. Alpenglow — смена механизма консенсуса, её ждут не раньше осени вместе с очередной версией клиента. Transaction v1 — отдельное и более узкое изменение.

Что будет, если сервис не обновил библиотеку

Запросы без указания поддерживаемой версии транзакции вернут ошибку −32015, а индексаторы начнут отдавать нулевые значения вычислительного бюджета. Данные в сети при этом корректны.

Зачем вообще нужен такой размер

Чтобы в одну транзакцию помещались доказательства с нулевым разглашением, агрегированные подписи и мультиподписные схемы с большим числом участников.

Источники