Новости Solana планирует обновление Transaction v1

[vitel59]

9 сентября 2026 года в основной сети Solana активируется обновление Transaction v1, которое увеличит максимальный размер одной транзакции с текущих 1 232 байт до 4 096 байт . Это изменение, инициированное предложениями SIMD-0296 и SIMD-0385, направлено на устранение давнего технического ограничения и расширение возможностей для разработчиков сложных приложений .

​

Важно​

- Устранение технического ограничения: Прежний лимит в 1 232 байта был установлен, когда транзакции Solana должны были помещаться в один сетевой пакет IPv6 (1 280 байт) . В 2022 году сеть перешла на протокол QUIC, сняв это ограничение, но лимит на размер транзакции сохранялся . Обновление формально устраняет это устаревшее ограничение .
- Новые возможности для сложных операций: Увеличение объема позволяет упаковывать ресурсоемкие операции в одну атомарную транзакцию, которая либо полностью выполняется, либо полностью отклоняется . Это особенно критично для следующих сценариев:

1. Крупные криптографические доказательства: Например, доказательства с нулевым разглашением (ZK-proofs), используемые в приватных переводах, теперь могут быть переданы в рамках одной транзакции .
2. Мультиподписи: Для корпоративных кошельков или DAO, где требуется несколько подписей, это значительно упрощает и ускоряет процесс утверждения платежей .
3. Конфиденциальные переводы: Операции, требующие дополнительных криптографических "упаковок", теперь не будут упираться в ограничение по объему данных .

​

Технические детали и обратная совместимость​

- Новый формат: Transaction v1 — это новый формат транзакции. Существующие форматы legacy и v0 продолжат поддерживаться, но не получат возможности увеличения размера . Это дает разработчикам свободу выбора в зависимости от нужд их приложения.
- Без Address Lookup Tables: В новом формате v1 отказываются от использования Address Lookup Tables (ALT) — механизма, который сжимал адреса аккаунтов для экономии места . В v1 все 32-байтовые адреса должны быть указаны непосредственно в транзакции . Это компромисс, который частично "съедает" выгоду от увеличения размера для некоторых типов операций .
- Ограничение по аккаунтам: Ключевое ограничение — максимум 64 аккаунта на одну транзакцию — остается неизменным . То есть, разработчики получат больше места для данных, но не для количества взаимодействующих аккаунтов .

​

Риски для инфраструктуры​

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

- RPC-провайдеры, кошельки и блок-эксплореры: Сервисы, которые считывают данные из блокчейна, должны быть обновлены для корректной обработки транзакций формата v1. В противном случае они будут возвращать ошибки при их чтении .
- Некорректное отображение комиссий: В старом формате (v0) комиссия приоритета указывалась внутри инструкций, а в новом (v1) — на уровне конфигурации сообщения . Необновленные сервисы могут отображать нулевую комиссию, даже если пользователь ее заплатил .

Таким образом, обновление Transaction v1 — это важный технический шаг, который убирает архитектурные ограничения для разработчиков, но одновременно создает серьезные вызовы для всей инфраструктуры сети Solana, требующие скоординированных действий от всех участников экосистемы.

 

[ForumOK]

Нормальный и давно назревший апдейт. Лимит в 1232 байта реально выглядел артефактом старой сетевой архитектуры, и после перехода на QUIC держать его дальше особого смысла не было.

Самое важное тут, на мой взгляд, не просто “транзакция стала больше”, а то, что Solana становится удобнее для более сложных сценариев в одном атомарном действии. Для ZK, мультисигов, приватных механик и всяких составных DeFi-операций это может быть очень заметно.

Но есть и ложка дегтя:
- 64 аккаунта не увеличили, а для части кейсов это не менее важный потолок, чем байты;
- отказ от ALT в v1 спорный момент, потому что часть выигрыша по размеру действительно будет съедаться явным перечислением адресов;
- инфраструктура может знатно посыпаться на переходе, если кто-то вовремя не обновит парсеры, RPC и эксплореры.

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

В целом апдейт выглядит полезным, но не “волшебной таблеткой”. Ограничение снимают важное, однако узкие места у Solana на этом не заканчиваются. Тут скорее хороший фундамент под следующие итерации, чем финальное решение.