Solana утроила размер транзакций до 4096 байт с запуском основной сети V1

Solana планирует утроить объем данных, которые может содержать одна транзакция. Согласно предложению SIMD-0296 на GitHub, новый лимит в 4096 байт помещается в одну страницу памяти размером 4 КиБ аппаратного валидатора.

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

Технология QUIC сделала ограничение в 1232 байта бессмысленным

Первоначальное ограничение Solana было связано с предупреждением о проблемах в сети. Сеть работала с MTU IPv6 в 1280 байт.

В результате после вычета накладных расходов протокола для полезной нагрузки транзакции осталось 1232 байта, пишут авторы SIMD-0296. Это логично, учитывая, что каждое сообщение должно было проходить через MTU без фрагментации.

В 2022 году Solana перешла на QUIC в качестве стандартного способа обработки транзакций. RFC 9000 не устанавливает максимальный размер потока, поэтому более крупные данные могут передаваться без проблем на сетевом уровне.

Ограничение в 1232 байта превратилось в правило, не имеющее технического обоснования.

Оба документа были составлены инженерами компании Anza, Джейкобом Кричем и Эндрю Фицджеральдом. SIMD-0296 увеличивает лимит размера.

Вспомогательный модуль SIMD-0385определяет defiсообщений v1, который содержит дополнительные байты. Эта пара решает проблему, которую разработчики игнорировали с момента запуска блокчейна.

Предлагаемый размер в 4096 байт предпочтительнее максимального размера, разрешенного протоколом QUIC, чтобы транзакция могла поместиться в одну стандартную страницу памяти валидатора размером 4 КиБ. Ни одна транзакция никогда не пересекает границу страницы.

Управление памятью для каждой транзакции обходится недорого. Каждая транзакция ограничена одной страницей.

Чтобы определить ограничение в 4096 байт, Крич и Фицджеральд проанализировали, как разработчики использовали пакеты Jito для обхода старых ограничений:

• 50% представленных пакетов имели размер 2048 байт или меньше.
• 65% составляло менее 6144 байт.
• 100% осталось меньше 9216 байт.

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

В разделе «Влияние» предложения SIMD-0296 показано распределение размеров пакетов Jito в байтах, использованное для обоснования ограничения в 4096 байт. Источник: Solana GitHub.

В Solana неподготовленные вызовы RPC теперь вызывают ошибку -32015

Дополнительная емкость позволяет запускать рабочие нагрузки, превышающие лимит в 1232 байта.

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

Для решения этой проблемы разработчики объединяли несколько вызовов в цепочки или отказывались от атомарных зашифрованных передач. Новый лимит в 4096 байт позволяет использовать доказательства с нулевым разглашением в одной транзакции.

Агрегация подписей BLS и крупные конфигурации мультиподписей также выигрывают от этого изменения. В документе SIMD-0296 в качестве одной из основных причин указывается вложенная мультиподпись, тип мультиподписи, используемый институциональными казначействами и DAO через Squads.

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

В этом формате отказались от таблиц поиска адресов, которые использовались в версии 0 для ссылки на 64 учетные записи с короткими индексами. Таблицы усложняют систему без каких-либо преимуществ, поскольку теперь имеется 64 встроенных 32-байтовых адреса, которые занимают всего 2048 байт, что значительно меньше максимального значения.

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

Пакеты Jito позволяют разработчикам объединять до пяти транзакций в последовательность по принципу «всё или ничего», чтобы решить проблему ограничения размера в байтах.

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

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

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

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

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

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

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

Anza требует от поставщиков RPC-услуг перейти на Agave версии 4.2. Компания Helius выпустила контрольный список миграции с подробным описанием необходимых работ.

Транзакция v1 была активирована в тестовой сети Solana во время эпохи 1025 1 сентября. Anza официально запланировала развертывание в основной сети на 9 сентября.

Источник