Solana активировала функцию txv1 в основной сети примерно в 01:00 UTC 15 сентября, в начале эпохи 1035. Обновление увеличивает максимальный размер транзакции с 1 232 до 4 096 байт, обеспечивая более чем троекратный рост по сравнению с прежней емкостью.

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

Более крупная транзакция — это не более крупный перевод SOL

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

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

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

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

Операции, которым может быть полезно дополнительное пространство

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

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

Большинству пользователей кошельков не требуется предпринимать действия

Активация не требует от пользователей переводить свои SOL, создавать другой адрес или конвертировать существующий аккаунт. Приложения, которые продолжают использовать устаревшие транзакции или транзакции V0, должны работать так же, как до обновления.

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

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

Разработчикам и индексаторам необходимо обновить программное обеспечение

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

RPC-сервисы, извлекающие транзакции или блоки, должны указывать maxSupportedTransactionVersion: 1. Без этой настройки запрос транзакции V1 может завершиться ошибкой. Одна неподдерживаемая транзакция также может привести к сбою запроса всего блока.

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

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

Транзакции размером более 1 232 байт также необходимо отправлять с использованием кодировки base64. Путь отправки через base58 сохраняет прежний предел размера.

V1 увеличивает пространство, но меняет другие ограничения

V1 — это не просто V0 с более крупной полезной нагрузкой. Он позволяет напрямую включать в транзакцию до 64 адресов аккаунтов, но не поддерживает таблицы поиска адресов. Дублирующиеся адреса аккаунтов также отклоняются.

Эти правила создают для команд разработчиков иной выбор при проектировании приложений. V0 сохраняет актуальность, когда таблицы поиска обеспечивают эффективный способ ссылаться на аккаунты, тогда как V1 предназначен для операций, которым важнее дополнительное пространство для инструкций, подписей или доказательств.

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

Более крупные транзакции могут сопровождаться повышенными комиссиями

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

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

V1 выражает приоритетную комиссию как общую сумму в lamports. V0 использует цену за вычислительную единицу, поэтому аналитическим платформам необходимо нормализовать оба формата перед их сравнением.

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

Активация запускает проверку востребованности формата

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

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

Значимость V1 будет зависеть от того, обеспечит ли объединение таких рабочих нагрузок в одну атомарную транзакцию достаточную экономию на координации, подписях и неудачных попытках, чтобы оправдать необходимые обновления инфраструктуры.

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

Источник: Coindoo