Solana готовит обновление формата транзакций v1 с лимитом 4096 байт

Solana (SOL) готовит обновление формата транзакций v1, увеличивая максимальный размер одной транзакции с 1232 байт до 4096 байт. Это технологическое изменение позволит вместить транзакции, которые примерно в 3,3 раза больше существующего лимита.

Фонд Solana в официальном документе об обновлении классифицировал "Более крупные размеры транзакций" как "Ожидаемая активация функции". Это изменение основано на SIMD-0296 и SIMD-0385, а официальный дашборд обновлений указывает, что Agave 4.2 будет выпущен в августе 2026 года, при этом функция увеличения размера транзакций остается в состоянии ожидания активации.

Ключевым моментом этого обновления является лимит транзакций. Существующий лимит размера транзакции Solana составляет 1232 байта, и документ SIMD-0296 объясняет, что этот лимит возник из проектирования IPv6 MTU в 1280 байт. Исключая заголовки и другие данные, в структуре оставалось 1232 байта для фактической нагрузки транзакции.

Solana сообщает, что после внедрения QUIC была создана среда для отправки более крупных транзакций и предлагает новый лимит в 4096 байт. Изменение структуры передачи данных в сети позволяет пересмотреть лимиты транзакций, которые ранее были адаптированы под ограничения размера пакетов.

Формат v1 не заменяет существующий v0 и устаревшие транзакции. Приложения и кошельки, которые хотят использовать более крупные размеры транзакций, должны адаптироваться к новому формату. Документ RPC Solana указывает, что для получения сообщений v1 необходимо установить maxSupportedTransactionVersion: 1 в запросе.

В сообщениях v1 в документации RPC содержатся ограничения на вычисления и размер данных, а также объект transactionConfig, который включает computeUnitLimit, loadedAccountsDataSizeLimit и priorityFee. Это отличается от прежнего способа запроса ресурсов через отдельные инструкции.

Техническая структура также изменится. SIMD-0385 объясняет, что транзакции v1 используют байт версии 129 и содержат запросы ресурсов в маске настроек внутри заголовка транзакции вместо использования существующей инструкции ComputeBudgetProgram. Таблица поиска адресов (ALT) не поддерживается.

Таблица поиска адресов уменьшает пространство, не включая все адреса непосредственно в транзакцию, а ссылаясь на внешнюю таблицу. Предполагается, что v1 часто может содержать список адресов непосредственно в пределах лимита в 4096 байт. Однако в рабочих нагрузках с высокой зависимостью от ALT эффект увеличения лимита может быть ограничен.

Это изменение расширяет возможности для разработчиков в отношении атомарных транзакций. Фонд Solana объяснил, что существующий лимит в 1232 байта затруднял объединение таких операций, как доказательства с нулевым разглашением, крупные мультиподписи, пакетные задачи и некоторые структуры подписи в цепочке. Атомарные транзакции означают, что несколько операций должны успешно завершиться или провалиться вместе.

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

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

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

В локальной среде валидации уже открыты возможности для тестирования. Примерный репозиторий Solana сообщает, что функция enable_tx_v1 уже активирована в solana-test-validator. Однако код выполнения настроен так, что если функция отключена, транзакции v1 будут отклоняться как UnsupportedVersion, поэтому необходимо проверить, активирована ли она для каждого кластера.

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

Это обновление больше связано с изменениями в инфраструктуре разработки, чем с прогнозами цен. Кошельки, RPC, индексаторы и инструменты разработки должны проверить, поддерживают ли они парсинг транзакций v1 и соответствие transactionConfig. Существующие v0 и устаревшие транзакции будут продолжать работать, но для сервисов, желающих использовать транзакции в 4096 байт, требуется поддержка нового формата.

Этот контент предоставляется исключительно в общих информационных целях и не является финансовым, инвестиционным, юридическим или налоговым советом. Любые мероприятия, вознаграждения, онлайн-акции или связанная с ними информация, упомянутые в настоящем документе, не должны рассматриваться как рекомендация, приглашение к покупке, продаже, торговле или иной сделке с какими-либо криптоактивами. Криптоактивы очень волатильны и могут привести к убыткам. Доступность услуг, продуктов WEEX и связанных с ними событий может варьироваться в зависимости от региона. Вы несете ответственность за обеспечение того, чтобы ваше участие соответствовало применимым местным законам и нормативным актам.