Как Address Lookup Tables решают проблему лимита транзакций в Solana

Каждая транзакция в Solana жёстко ограничена размером в 1 232 байта. Это не прихоть разработчиков, а следствие работы сети через IPv6: пакет должен помещаться в один сетевой пакет, чтобы минимально задерживать распространение.

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

Почему аккаунты съедают весь бюджет

Программы (смарт-контракты) в Solana не хранят состояние. Каждый объект, с которым работает транзакция — токен-аккаунт, состояние пула, минт, волатеть, оракул, системная программа, — нужно явно перечислить в массиве ссылок на аккаунты прямо внутри транзакции.

В легаси-формате каждая ссылка — это 32 байта (стандартный ключ Ed25519). Возьмём маршрут из трёх пулов:

1. Пул A: токен A → токен B
2. Пул B: токен B → токен C
3. Пул 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 байт. Сравни:

Получается, что маршрут, который раньше занимал больше 1 200 байт, теперь ужимается до пары сотен байт. Сложные роуты снова проходят.

Практические детали для разработчика

Если ты строишь интерфейс для свопов (или просто работаешь с RPC), версионные транзакции обязательны для надёжного исполнения. Но есть нюансы.

Таблицы нужно тянуть с ноды

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

ALT нельзя создать и использовать в одном слоте

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

Библиотеки требуют явной работы с v0

Большинство клиентских SDK различают легаси-объект Transaction и VersionedTransaction. Если собрать инструкции в старом формате, ALT-индексы просто не будут работать. Нужно сознательно использовать конструктор версионных транзакций.

Коротко

Лимит 1 232 байта — это фундаментальное ограничение сетевой архитектуры Solana. Address Lookup Tables и v0-транзакции позволяют обойти его, сохраняя глубокие маршруты и плотно упаковывая данные. Для разработчиков это означает переход на новые стандарты клиентских библиотек и внимательное управление жизненным циклом таблиц — но зато пользователь получает лучшую цену на свопах без компромиссов по размеру транзакции.