Каждая транзакция в Solana жёстко ограничена размером в 1 232 байта. Это не прихоть разработчиков, а следствие работы сети через IPv6: пакет должен помещаться в один сетевой пакет, чтобы минимально задерживать распространение.
Для обычного перевода токенов такого объёма с запасом хватает. А вот когда ты исполняешь своп через несколько пулов ликвидности, размер упаковки превращается в инженерный барьер.
Почему аккаунты съедают весь бюджет
Программы (смарт-контракты) в Solana не хранят состояние. Каждый объект, с которым работает транзакция — токен-аккаунт, состояние пула, минт, волатеть, оракул, системная программа, — нужно явно перечислить в массиве ссылок на аккаунты прямо внутри транзакции.
В легаси-формате каждая ссылка — это 32 байта (стандартный ключ Ed25519). Возьмём маршрут из трёх пулов:
- Пул A: токен A → токен B
- Пул B: токен B → токен C
- Пул C: токен C → токен D
Каждый пул требует свой program ID, состояние пула, минты входного и выходного токенов, аккаунты для резервов и оракула для цен. На таком маршруте легко набирается от 30 до 40 разных ключей.
Пятнадцать... Стоп, посчитаем: 35 аккаунтов по 32 байта — это уже 1 120 байт. Добавь 64 байта на каждую подпись, 32 байта на недавний blockhash, инструкции и смещения — и транзакция вылезает за лимит ещё до отправки валидатору.
В итоге роутеры вынуждены были выбирать неоптимальные прямые пары, лишь бы влезть в лимит. Это плохо и для цены исполнения, и для ликвидности.
Что изменилось с v0 и Address Lookup Tables
Solana ввела версионные транзакции (v0) и таблицы адресов (Address Lookup Tables, ALT). Идея простая: вынести массив публичных ключей в отдельный аккаунт, а в транзакции ссылаться на него.
ALT — это аккаунт в блокчейне, внутри которого лежит упорядоченный список публичных ключей. Когда таблица создана и загружена, транзакции больше не нужно тащить с собой все 32-байтовые ключи. Вместо этого она указывает на аккаунт таблицы, а каждый аккаунт внутри инструкции адресуется однобайтовым индексом (u8).
Так 32 байта превращаются в 1 байт. Сравни:
| Формат | Ссылка на аккаунт | 35 аккаунтов |
|---|---|---|
| Легаси | 32 байта (публичный ключ) | 1 120 байт |
| v0 + ALT | 1 байт (индекс) + ключ таблицы | около 35 байт + 32 байта на ключ ALT |
Получается, что маршрут, который раньше занимал больше 1 200 байт, теперь ужимается до пары сотен байт. Сложные роуты снова проходят.
Практические детали для разработчика
Если ты строишь интерфейс для свопов (или просто работаешь с RPC), версионные транзакции обязательны для надёжного исполнения. Но есть нюансы.
Таблицы нужно тянуть с ноды
Перед тем как десериализовать v0-транзакцию или запросить подпись у пользователя, клиентская библиотека должна получить текущее состояние таблицы адресов с RPC-узла. Без этого ты не развернёшь индекс в реальный публичный ключ.
ALT нельзя создать и использовать в одном слоте
Расширение таблицы требует паузы на границу слотов. Новые индексы становятся активными только через слот, а не мгновенно. Это защита от манипуляций внутри блока, но для роутера значит, что таблицы нужно создавать заранее и поддерживать в актуальном состоянии.
Библиотеки требуют явной работы с v0
Большинство клиентских SDK различают легаси-объект Transaction и VersionedTransaction. Если собрать инструкции в старом формате, ALT-индексы просто не будут работать. Нужно сознательно использовать конструктор версионных транзакций.
Коротко
Лимит 1 232 байта — это фундаментальное ограничение сетевой архитектуры Solana. Address Lookup Tables и v0-транзакции позволяют обойти его, сохраняя глубокие маршруты и плотно упаковывая данные. Для разработчиков это означает переход на новые стандарты клиентских библиотек и внимательное управление жизненным циклом таблиц — но зато пользователь получает лучшую цену на свопах без компромиссов по размеру транзакции.
Fluxs
Комментарии (5)
Войдите, чтобы комментировать.