Solana утраивает размер транзакций до 4 096 байт с форматом V1

Каждый, кто хоть раз реализовывал мультисиг на Solana, знает этот ритуал: операция делится на три транзакции, склеивается бандлером, и остаётся только молиться, чтобы вторая транзакция прошла раньше, чем изменится состояние. Именно этот костыль и призван уничтожить новый формат Transaction V1. Он заработал во вторник около 01:00 UTC, и эффекты второго порядка ударят по командам индексеров раньше, чем по конечным пользователям.

Что произошло

Solana Foundation выпустил Transaction V1 — новый формат транзакций, который поднимает максимальный объём данных в одной транзакции до 4 096 байт с прежнего жёсткого лимита в 1 232 байта. Как сообщил CoinDesk, обновление более чем утраивает пространство, доступное для инструкций, подписей и другых метаданных выполнения внутри одной транзакции.

Это не изменение пропускной способности. Solana не стала обрабатывать больше транзакций в секунду благодаря V1. Сеть просто позволяет каждой транзакции нести больше данных. Различие важно, потому что многие заголовки будут смешивать эти понятия, и любому руководителю продукта, читающему пересланную новость в Slack, нужно исправить эту формулировку до того, как CTO начнёт спрашивать о показателях TPS.

Прежний потолок в 1 232 байта был структурным узким местом. Разработчики, создающие что-либо насыщенное данными — корпоративные мультисиг-кошельки, доказательства с нулевым разглашением, сложные многоходовые сделки — вынуждены были разбивать логику на несколько транзакций или объединять их на стороне клиента. У Ethereum никогда не было такого жёсткого ограничения на уровне протокола. Он использует гибкий лимит газа в блоке и позволяет пользователям платить больше, чтобы вместить тяжёлые операции в один вызов. Эта модель, задокументированная в документации Ethereum, объясняет, почему сложная DeFi-хореография переместилась на EVM-цепочки, несмотря на преимущества Solana по скорости и стоимости.

V1 сокращает этот разрыв. Но не закрывает его. Газовая эластичность Ethereum по-прежнему превосходит фиксированный потолок в 4 096 байт для самых больших нагрузок. Но для 80% сценариев, где разработчики дробили операции только ради того, чтобы уложиться в 1 232 байта, это реальный прорыв. Старые форматы остаются поддерживаемыми, так что на стороне отправки ничего не ломается.

Техническая анатомия

Инженерный сдвиг прост на бумаге и сложен на практике. Transaction V1 расширяет контейнер. Правила рантайма — что в него помещается, подписи, ссылки на аккаунты, данные инструкций — по духу не изменились. Просто стало больше места. Модель аккаунтов из документации Solana по-прежнему применяется. Меняется потолок композиции.

Главная семантическая победа — атомарность. При старом лимите рабочий процесс, которому требовалось, скажем, семь инструкций в трёх программах, разбивался на две или три отдельные транзакции. Разработчики объединяли их в бандлы, но бандлы не имеют той же гарантии на уровне сети, что каждый шаг либо выполнится, либо откатится вместе с остальными. Если второй шаг прошёл, а третий упал — вы в аду выверки. Я видел производственные инциденты в финтех-компаниях, где состояния частичного исполнения из пакетных блокчейн-вызовов разгребали днями, потому что никто не написал компенсирующую логику для пятнадцати пограничных случаев, которых никто не предвидел.

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

Второй технический факт важнее, чем следует из маркетинговых материалов: чтение V1-транзакций не имеет обратной совместимости. Любой индексер, RPC-сервис, кошелёк или аналитическая платформа, не получившие обновления, будут падать на запросах отдельных V1-транзакций. Хуже того, запрос целого блока может упасть, если этот блок содержит хотя бы одну V1-транзакцию. Foundation называет это предупреждениями о совместимости, а не свидетельством массовых сбоев. Справедливо. Но в операционных терминах сбой чтения на уровне блока, который роняет эндпоинт баланса кошелька в 2 часа ночи, очень похож на аварию для вашего дежурного.

Моё мнение: отправка — это простая часть. Каждое серьёзное приложение на Solana должно считать путь чтения сломанным до доказательства обратного и действовать соответственно уже на этой неделе.

Кто пострадает

Три группы команд окажутся под ударом в ближайшие 90 дней — в порядке убывания тяжести последствий.

Первые — сторонние поставщики данных. Если вы управляете индексером, RPC-шлюзом, аналитическим хранилищем или бэкендом кошелька, потребляющего блоки Solana, вы получаете жёсткий дедлайн, которого не выбирали. Как только V1-транзакции начнут появляться в продакшн-блоках — а это случится немедленно — ваш конвейер приёма данных должен их парсить, иначе блочные чтения начнут падать. Команды, с которыми я работал в аналогичных миграциях, всегда недооценивают хвост: проблема не в библиотеке приёма, а в семнадцати внутренних сервисах, которые три года рассчитывали на стабильную схему.

Вторые — фронтенды кошельков и dApp. Даже если ваше приложение продолжает спокойно отправлять транзакции в старом формате, вам всё равно нужно читать новые транзакции других приложений, чтобы отображать актуальное состояние. Портфельные просмотры, история транзакций, ленты активности — всё это незаметно ломается, если V1-данные пропускаются или парсятся неверно. Пользователи не будут писать в поддержку «ошибка парсинга V1». Они скажут «мой баланс неправильный».

Третьи — кастодианы и вендоры соответствия требованиям. Мультисиг-кошельки компаний упоминаются в дизайн-предложении V1 как главный сценарий использования. Это прямой удар по институциональным кастодиальным рабочим процессам. Если ваш compliance-стек проводит инспекцию транзакций на Solana, теперь ему нужно обрабатывать нагрузки в 4 096 байт с большим числом инструкций в конверте. Движки правил, рассчитанные на ограниченное число инструкций, начнут фиксировать ложноотрицательные результаты.

Неудобная правда: это обновление — подарок разработчикам Solana и налог на экосистемные сервисы под ними. Этот налог будет оплачен инженеро-неделями в следующем квартале — неброская работа, без громких анонсов, но совершенно необходимая.

План действий для крипто- и DeFi-команд

Конкретные шаги на эту неделю в порядке приоритета.

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

Добавьте канарейку на уровне блока. Поскольку одна V1-транзакция может уронить весь запрос блока, оснастите индексер метрикой, считающей частичные или неудачные чтения блоков. Поставьте алерт на первую аномалию. Это дёшево в реализации и станет разницей между обнаружением проблемы в мониторинге и обнаружением её в треде клиентской поддержки.

Командам, строящим на Solana: сопротивляйтесь желанию переписать всё в жирные V1-транзакции с первого дня. Крупные атомарные операции мощны, но они также концентрируют точки отказа. Начните с рабочих процессов, которые действительно были сломаны при старом лимите: мультисиг-одобрения, отправка ZK-доказательств, многоходовые DEX-маршруты. Остальное не трогайте, пока экосистема не стабилизируется.

Кастодианам и институциональным игрокам: пересмотрите правила инспекции транзакций до того, как об этом спросит кто-то из клиентов. Считайте, что регуляторы и аудиторы спросят, что изменилось и когда ваши контроли это зафиксировали.

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

Ключевые выводы

• Transaction V1 поднимает лимит данных на транзакцию в Solana с 1 232 до 4 096 байт — это изменение размера, а не пропускной способности.
• Главная победа — атомарность: мультисиг- и ZK-рабочие процессы, которые раньше требовали клиентского бандлинга, теперь помещаются в одну транзакцию по принципу «всё или ничего».
• Риск — в совместимости чтения. Одна V1-транзакция в блоке может вызвать сбой полного запроса блока у непропатченных индексеров и RPC-сервисов.
• Ethereum по-прежнему сохраняет структурное преимущество благодаря гибкой модели газа; Solana сокращает разрыв, но не устраняет его.
• Каждая команда с путём чтения Solana должна проверить парсинг V1 сквозным образом на этой неделе и внедрить метрики сбоев на уровне блоков до того, как это заметят клиенты.