Solana 9 сентября (в среду) официально запустит функцию Transaction v1 в основной сети, увеличив максимальный размер транзакции с 1 232 до 4 096 байт — более чем втрое. Обновление определяется двумя предложениями по улучшению Solana: SIMD-0296 («Более крупные транзакции») и SIMD-0385 (формат Transaction v1).
Технические характеристики Transaction v1
Transaction v1 определяется двумя предложениями по улучшению Solana: SIMD-0296 устанавливает увеличенный лимит размера транзакции, а SIMD-0385 определяет формат Transaction v1. Авторами обоих предложений являются Jacob Creech и Andrew Fitzgerald. Новая функция уже некоторое время стабильно работает в тестовой сети и сети разработки, а 9 сентября 2026 года официально станет доступна в основной сети.
Transaction v1 разработан с обратной совместимостью: существующий формат v0 продолжит работать. Кошельки и приложения будут использовать формат v1 только при необходимости дополнительного пространства для транзакции, поэтому обязательная миграция не требуется.
Три сценария транзакций, которые напрямую выиграют от Transaction v1
После увеличения лимита с 1 232 до 4 096 байт наибольшую непосредственную пользу получат следующие три типа транзакций:
Крупные криптографические доказательства: проверочные данные, такие как доказательства с нулевым разглашением (ZK proofs), часто приходилось разделять на несколько транзакций из-за ограничения в 1 232 байта. Transaction v1 позволяет отправлять полный набор данных для проверки ZK в одной транзакции.
Процессы подтверждения мультиподписей: при переводах средств, требующих одобрения нескольких подписантов, например из корпоративного казначейства или в рамках предложения DAO, каждая подпись занимает место. v1 позволяет завершать процесс подтверждения мультиподписью в рамках одной транзакции.
Конфиденциальные переводы: некоторым механизмам конфиденциальных транзакций требуется дополнительная криптографическая упаковка. Недостаточная вместимость раньше приводила к сбоям или снижению эффективности транзакций, а 4 096 байт предоставляют таким операциям достаточно места.
Почему установлен лимит в 4 096 байт
Лимит в 4 096 байт (4 КБ) обусловлен особенностями аппаратного уровня: это стандартный размер страницы памяти, используемый узлами-валидаторами. Если одна транзакция пересекает несколько страниц памяти, стоимость её обработки значительно возрастает, что негативно сказывается на поддержании высокого показателя TPS в Solana. Поэтому 4 КБ — это компромисс между увеличением вместимости и сохранением производительности сети.
Прежнее ограничение в 1 232 байта возникло из первоначальной архитектуры сети Solana: каждая транзакция должна была помещаться примерно в IP-пакет размером 1 280 байт. В 2022 году Solana изменила способ передачи транзакционного трафика, из-за чего этот жёсткий потолок перестал быть необходимым. Запуск Transaction v1 официально устраняет это историческое архитектурное ограничение.
Необходимые обновления RPC-узлов и сервисов чтения
Transaction v1 сильнее повлияет на сервисы, читающие данные из блокчейна, чем на отправку транзакций. Все сервисы, извлекающие данные о блоках и транзакциях, — RPC-узлы, поставщики данных блокчейна и серверная часть кошельков, — должны обновить код. В противном случае при обнаружении транзакции в формате v1 они будут сразу возвращать ошибку.
Ещё одно конкретное изменение касается расположения поля комиссии за приоритет (priority fee): в v1 информация о комиссии за приоритет хранится в поле, отличном от поля в v0. При чтении транзакций v1 старое программное обеспечение будет показывать «нулевую комиссию», даже если пользователь фактически заплатил комиссию за приоритет. Если интерфейсы кошельков, обозреватели блокчейна и приложения для работы с транзакциями не будут обновлены, пользователи увидят некорректную информацию о комиссиях.
Сравнение вместимости с Ethereum
С точки зрения протокольного дизайна, в Ethereum нет ограничения на размер транзакции на уровне протокола: разработчики могут выполнять операции с большим объёмом данных в одной транзакции, уплачивая более высокую комиссию за газ. В прошлом у Solana существовало заметное ограничение на количество инструкций, которые могла вместить одна транзакция. После увеличения лимита до 4 096 байт благодаря Transaction v1 разрыв между двумя сетями сократился, однако для Ethereum L1 4 096 байт всё ещё немного: сложная комбинированная DeFi-транзакция в Ethereum, например арбитраж между несколькими пулами или заимствование и погашение нескольких активов, часто превышает этот размер.
Практическое техническое значение для экосистемы Solana заключается в устранении необходимости в обходных решениях со стороны разработчиков. Раньше при разделении операций на несколько транзакций приходилось обрабатывать зависимости состояния между транзакциями и откатывать изменения при сбоях. Transaction v1 позволяет выполнять сложную логику в рамках одной атомарной операции, что делает её более похожей на традиционные модели программирования.
Часто задаваемые вопросы
Когда состоится запуск Solana Transaction v1, как изменится максимальный размер и какими предложениями он определяется?
Solana Transaction v1 будет запущена в основной сети 9 сентября 2026 года (в среду), а максимальный размер транзакции увеличится с 1 232 до 4 096 байт (более чем втрое). Обновление определяется двумя предложениями — SIMD-0296 и SIMD-0385, авторами которых являются Jacob Creech и Andrew Fitzgerald. До этого функция уже стабильно работала в тестовой сети и сети разработки.
Почему лимит установлен именно на уровне 4 096 байт, а не выше?
4 096 байт — это стандартный размер страницы памяти, используемый узлами-валидаторами. Если одна транзакция пересекает несколько страниц памяти, стоимость её обработки значительно возрастает, что негативно сказывается на поддержании высокого показателя TPS в Solana. Поэтому 4 КБ — это компромисс между увеличением вместимости и сохранением производительности сети.
Как необходимо обновить RPC-узлы и сервисы чтения и каково конкретное влияние изменения поля комиссии за приоритет?
Все сервисы, извлекающие данные о блоках и транзакциях, должны обновить код. В противном случае при обнаружении транзакции v1 они будут сразу возвращать ошибку. В v1 поле комиссии за приоритет расположено иначе, чем в v0, поэтому старое программное обеспечение при чтении будет показывать «нулевую комиссию», даже если пользователь уже заплатил комиссию за приоритет. Если кошельки и обозреватели блокчейна не будут обновлены, они будут отображать некорректную информацию о комиссиях.
