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

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

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

QUIC сделал бессмысленным лимит в 1,232 байт

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

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

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

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

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

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

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

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

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

• 50% отправленных пакетов были размером 2,048 байт или меньше.
• 65% было менее 6,144 байт.
• 100% осталось менее 9,216 байт.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Anza требует от провайдеров RPC обновиться до Agave v4.2. Helius выпустила чек-лист миграции, детализирующий работу.

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