Solana увеличивает пропускную способность транзакций втрое с обновлением v1

SOL
Transaction V1масштабируемостьОбновлениеосновная сетьSolana
12 часов назадИсточник: crypto.news
Solana увеличивает пропускную способность транзакций втрое с обновлением v1

Solana нацелена на 9 сентября для Transaction v1, нового формата, который увеличивает максимальный размер сериализованной транзакции с 1 232 байт до 4 096 байт.

Резюме

  • Solana планирует увеличить максимальный размер транзакции с 1 232 байт до 4 096 байт в среду в основной сети.
  • Transaction v1 остается опциональной, в то время как legacy и v0 форматы продолжают работать в рамках существующих ограничений размера.
  • Приложения, читающие блоки, должны поддерживать версию один или рисковать ошибками при обнаружении нового формата.
  • V1 удаляет таблицы поиска адресов и хранит лимиты ресурсов непосредственно в метаданных конфигурации каждой транзакции.
  • Официальная дорожная карта Solana помечает активацию основной сети как ожидающую, поэтому график на 9 сентября может быть изменен.

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

Ранее крупные операции приходилось разделять на несколько транзакций, когда их инструкции, подписи и информация об аккаунтах превышали предел в 1 232 байта. Этот процесс добавлял сложности, потому что одна транзакция могла завершиться успешно, а другой шаг мог завершиться неудачей.

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

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

Существующие транзакции Solana останутся действительными

Transaction v1 является опциональной. Кошельки и приложения могут продолжать отправлять legacy и v0 транзакции в рамках существующего лимита в 1 232 байта. Пользователям не нужно мигрировать токены, обменивать SOL или завершать претензию перед активацией.

Разработчики должны сознательно принять новый формат, чтобы получить доступ к его большей емкости. Документация Solana определяет три поддерживаемых формата: legacy, v0 и v1. Каждый формат по-разному организует адреса аккаунтов и лимиты ресурсов.

Формат v0 использует таблицы поиска адресов (ALT) для представления адресов аккаунтов через сжатые однобайтовые индексы. V1 удаляет ALT и помещает полные 32-байтовые адреса аккаунтов непосредственно в транзакцию.

Это создает компромисс. V1 предоставляет больший общий конверт, но приложения, которые сильно полагаются на таблицы поиска, могут тратить больше байтов на представление тех же аккаунтов. Технический анализ Solana показал, что 90% проанализированных транзакций добавили бы менее 1 400 байт при преобразовании из v0 в v1.

Поставщики инфраструктуры должны обновить свое программное обеспечение

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

Индексаторы, обозреватели и аналитические сервисы также должны изменить способ получения лимитов ресурсов. Legacy и v0 транзакции размещают лимиты вычислений и настройки приоритетной комиссии внутри инструкций ComputeBudget. V1 хранит их в специальной конфигурации транзакции.

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

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

9 сентября остаётся целевой датой активации

Вице-президент по технологиям Solana Foundation Джейкоб Крич назвал 9 сентября запланированной датой для основной сети. Как ранее сообщалось в crypto.news, обновление включено в развёртывание Agave 4.2 от Anza.

Однако официальная дорожная карта по-прежнему помечает функцию основной сети как «не активирована». Также говорится, что график выпуска Anza является «предварительным и может быть изменён». Согласно последней странице статуса Фонда, тестовая сеть и сеть разработчиков уже активировали эту функцию.

Увеличение размера происходит из-за SIMD-0296, а SIMD-0385 определяет формат v1. Джейкоб Крич и Эндрю Фицджеральд являются соавторами обоих предложений.

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

Транзакция v1 остаётся отдельной от снижения арендной платы Solana, более коротких целей слотов и редизайна консенсуса Alpenglow. В связанном материале crypto.news сообщил, что Alpenglow нацелен на финальность примерно за 150 миллисекунд, при этом октябрь остаётся целевой датой разработки, а не гарантированной датой активации.