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 байт позволяет обрабатывать подавляющее большинство многотранзакционных рабочих нагрузок за один вызов, оставаясь при этом в рамках аппаратных ограничений валидатора.
В 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 сентября.
Подписывайтесь на страницы новостей криптовалют -
