Обновление Agave 4.2: всё, что нужно знать

Введение

В Agave 4.2 основной клиент валидатора Solana продолжает осваивать новые рубежи. Этот крупный выпуск сосредоточен на трёх долгожданных обновлениях, активируемых через feature gate: слотах длительностью 200 мс, снижении залога за состояние на 90% и транзакциях размером 4096 байт в новом формате transaction v1. В него также входит полностью готовая реализация Alpenglow перед запланированной активацией в следующем выпуске, а передача через XDP теперь включена по умолчанию.

Ключевые обновления

• Увеличение размера транзакций в 3,3 раза благодаря новому стандарту Transaction v1 *
• Снижение залога за состояние (ренты) на 90% *
• Сокращение длительности слота до 200 мс *
• Полностью готовая реализация Alpenglow
• Новые инструменты управления (связанные с SIMD)

* Обновления, активируемые через feature gate

Более крупные транзакции (Transaction v1)

Цикл выпуска Agave 4.2 включает активацию через feature gate более крупных транзакций размером до 4096 байт вместо прежнего ограничения в 1232 байта. Повышенный лимит, формально определённый в SIMD-0296: увеличение размера транзакции, примерно в 3,3 раза выше и применяется исключительно к новому формату transaction v1, представленному в SIMD-0385: формат Transaction V1. Транзакции legacy и v0 продолжат работать без изменений и по-прежнему будут ограничены 1232 байтами.

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

Изначальный лимит в 1232 байта был унаследован от прежней сетевой архитектуры Solana. Транзакции передавались как отдельные UDP-дейтаграммы и должны были помещаться в минимальный максимальный передаваемый блок (MTU) IPv6 размером 1280 байт. После вычета 40-байтового заголовка IPv6 и восьмибайтового заголовка UDP для самой транзакции оставалось 1232 байта. Размещение каждой транзакции в одном пакете сокращало фрагментацию и делало передачу более предсказуемой.

Solana уже давно перешла с UDP на QUIC для приёма транзакций. Потоки QUIC не ограничены полезной нагрузкой одной сетевой дейтаграммы, поэтому прежний предел в 1232 байта больше не нужен. Клиентам всё ещё требуется явная верхняя граница для входного контроля, выделения памяти и консенсусной валидации, но теперь её можно выбирать с учётом требований среды выполнения и приложений, а не MTU IPv6.

Списки аккаунтов часто занимают значительную часть доступного объёма. Каждый открытый ключ Ed25519 или адрес, производный от программы, занимает 32 байта, а транзакция должна указывать каждый аккаунт, который читают или изменяют её инструкции. Ранее из-за этого фактический предел составлял около 32 полных ключей аккаунтов. Чтобы обойти это ограничение, в транзакциях V0 появились таблицы поиска адресов (ALT), которые заменяют каждый 32-байтовый ключ однобайтовым индексом таблицы. Благодаря этому транзакции могут достигать установленного средой выполнения лимита в 64 аккаунта.

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

Эту проблему разработчиков решают транзакции v1. Они достаточно велики, чтобы вместить полный набор аккаунтов, который сейчас поддерживается через ALT: 64 полных открытых ключа размером 2048 байт. Поэтому при миграции с v0 приложение может разрешить записи таблицы поиска и включить полученные адреса непосредственно в транзакцию v1.

Кроме того, размер транзакции в 1232 байта особенно сильно ограничивает криптографические функции, например доказательства с нулевым разглашением и реализации BLS без нативных прекомпиляций. Такие нагрузки могут содержать сотни или тысячи байт данных доказательств либо подписей. Лимита в 4096 байт достаточно для многих распространённых криптографических сценариев. 

Спецификация Transaction V1

Сериализованная транзакция v1 начинается с байта версии 0x81. За ним следуют трёхбайтовый заголовок сообщения в стиле legacy, 32-битная маска конфигурации транзакции, 32-байтовый параметр срока действия, количества инструкций и адресов, полный массив 32-байтовых адресов, значения конфигурации, заголовки инструкций фиксированного размера, непрерывные полезные данные инструкций и, наконец, подписи. 

VersionByte (u8)
LegacyHeader (u8, u8, u8) 
TransactionConfigMask (u32) -- Bitmask of which config requests are present.
LifetimeSpecifier [u8; 32]
NumInstructions (u8)
NumAddresses (u8)
Addresses [[u8; 32]] -- Length matches NumAddresses
ConfigValues [[u8; 4]] -- Length equal to the popcount (number of set bits)
  of TransactionConfigMask. See section TransactionConfigMask for details.
InstructionHeaders [(u8, u8, u16)] -- Length of NumInstructions. Values are
  (ProgramAccountIndex, NumInstructionAccounts, NumInstructionDataBytes)
InstructionPayloads [InstructionPayload] -- Length = NumInstructions.
  Each InstructionPayload is the concatenation of the following byte arrays:
    InstructionAccountIndexes [u8] -- Length = NumInstructionAccounts from the
    corresponding InstructionHeader
    InstructionData [u8] -- Length = NumInstructionDataBytes from the
    corresponding InstructionHeader
Signatures [[u8; 64]]

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

Транзакции V1 по-прежнему ограничены 12 подписями, 64 адресами аккаунтов, 64 инструкциями и 255 индексами аккаунтов на инструкцию. Крупные транзакции всё ещё должны укладываться в запрошенный лимит вычислительных единиц, лимит загружаемых данных аккаунтов, правила блокировки аккаунтов и доступную вычислительную ёмкость блока.

Существующие парсеры не могут обрабатывать v1 как v0 с увеличенной максимальной длиной. Индексаторы, RPC, SDK и инфраструктура подписания, которые анализируют сериализованные транзакции, должны распознавать префикс 0x81 и поддерживать новый порядок полей. Особенно важно, что подписи v1 находятся в конце транзакции, а не перед сообщением, как в транзакциях legacy и v0.

Transaction v1 заменяет инструкции настройки программы Compute Budget полями в заголовке транзакции. Начальный `TransactionConfigMask` может задавать:

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

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

Снижение залога за состояние (ренты)

Высокие требования к залогу за состояние, который обычно называют «рентой», остаются одним из главных препятствий для приложений, активно использующих аккаунты в Solana. Название несколько вводит в заблуждение: рента — это не регулярная плата за хранение, а возвращаемый залог, который должен находиться на аккаунте, пока его состояние хранится ончейн. Обычно лампорты можно вернуть при закрытии аккаунта, но до этого момента они остаются капиталом, который разработчик или пользователь должен внести заранее и заморозить.

Agave 4.2 содержит активируемую через feature gate реализацию SIMD-0437: постепенное снижение lamports_per_byte до 696, которая снижает константу `lamports_per_byte` с 6960 до 696. Это снижает ренту на 90% (точнее, минимальный баланс для освобождения от ренты) через пять независимых feature gate: 6960 → 6333 → 5080 → 2575 → 1322 → 696. 

При активации одного из feature gate Agave обновляет конфигурацию ренты Bank и публикует новое значение через сисвар Rent. Поэтапное развёртывание позволяет сети отслеживать реакцию приложений на каждом уровне стоимости и остановиться до следующего снижения, если рост состояния или потребление ресурсов валидатора начнут вызывать опасения.

Минимальный баланс аккаунта для освобождения от ренты рассчитывается на основе выделенного размера данных и фиксированных накладных расходов на хранение в 128 байт:

minimum_balance = (128 + account_data_size) × lamports_per_byte

Сам механизм ренты при этом не меняется: аккаунтам по-прежнему нужен минимальный баланс, который можно вернуть при закрытии аккаунта. Меняется только объём SOL, который необходимо внести в качестве залога.

Размер стандартного аккаунта SPL Token составляет 165 байт. С учётом накладных расходов в 128 байт его эффективный размер равен 293 байтам. Снижение ренты на 90% уменьшает стоимость SOL для такого аккаунта примерно с ~$0,16 до менее чем 2 центов. 

Это особенно важно для платежей в стейблкоинах, распределения токенов, программ лояльности и прямых аирдропов. Кошелёк не хранит токены SPL напрямую: обычно для каждого минта ему нужен ассоциированный токен-аккаунт (ATA). Если у получателя ещё нет нужного ATA, отправитель может создать его вместе с переводом, но также должен пополнить освобождённый от ренты баланс получателя. Как правило, это однократная стоимость подключения для каждой пары «кошелёк — минт», а не затраты на каждый последующий платёж. Но в больших масштабах она может быть достаточно высокой, чтобы бизнесу пришлось решать, субсидировать подключение или переложить расходы на пользователей.

Рост состояния Solana

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

Согласно недавнему анализу Solana Foundation, файлы хранилища AccountsDB занимают примерно 495 ГБ при рекомендуемом объёме в 1 ТБ. После запланированного снижения ренты, чтобы исчерпать этот запас, злоумышленнику потребуется выделить SOL примерно на $17,2 млн. Увеличение рекомендуемого объёма хранилища валидатора до 2 ТБ повышает требуемый капитал злоумышленника до $51 млн.

С учётом создания новых и закрытия старых аккаунтов состояние растёт примерно на 0,3 ГБ в день.

Снимок состояния, сделанный в эпохе 997, показывает, что потребление пространства сильно сконцентрировано. Аккаунты SPL Token были крупнейшей категорией, а аккаунты OpenBook и Serum занимали около 30% активного состояния из-за сложной архитектуры ончейн-книг ордеров. Согласно анализу, примерно 30% пространства SPL Token также было связано с активами, созданными через лаунчпады токенов наподобие Pump.fun.

Меры безопасности

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

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

1. минимум по текущей ставке ренты
2. баланс аккаунта до выполнения

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

SIMD-0438: защита при повышении минимального баланса для освобождения от ренты добавляет отдельный защитный feature gate, который возвращает `lamports_per_byte` к прежнему значению 6960. Его предполагается активировать только в том случае, если снижение ренты приведёт к чрезмерному росту состояния или другой серьёзной эксплуатационной проблеме. Поскольку feature gate будет существовать до начала снижения, основным разработчикам не придётся проектировать, проверять и развёртывать новое изменение консенсуса в разгар инцидента, связанного с ростом состояния.

Вместе пять feature gate для снижения, правила сохранения прежних условий из SIMD-0392 и механизм отката из SIMD-0438 делают развёртывание обратимым на уровне протокола. Сеть может постепенно снижать залог, наблюдать за активным состоянием и хранилищем валидаторов, остановиться на промежуточном значении или восстановить исходное требование без необходимости немедленно пополнять каждый существующий аккаунт.

Сокращение длительности слота до 200 мс

Одно из самых ожидаемых улучшений производительности Solana — сокращение целевой длительности слота с 400 до 200 мс. Главное преимущество — меньшая задержка. При слотах длительностью 200 мс окно лидера из четырёх слотов в Solana сократится с 1,6 секунды до 800 мс. Это уменьшит время подтверждения и ограничит период, в течение которого недобросовестный лидер может задерживать, переупорядочивать или выборочно включать транзакции. Более короткие слоты также обеспечат приложениям, например потребителям данных оракулов и маркетмейкерам, более точную ончейн-синхронизацию.

Предложение предусматривает сохранение существующей экономики и пропускной способности Solana. Параметры инфляции, стоимость Validator Admission Ticket в Alpenglow и лимиты работы на слот корректируются пропорционально. Однако если слоты длительностью 200 мс появятся до Alpenglow, затраты валидаторов на голосование могут примерно удвоиться, поскольку им придётся голосовать вдвое чаще.

Подробнее о слотах длительностью 200 мс читайте в нашем предыдущем обзоре Agave 4.1.

Другие важные обновления

В цикле выпуска Agave 4.2 планируется активировать ещё несколько менее масштабных, но важных улучшений.

Готовность Alpenglow

Agave 4.2 поставляется с полностью готовой реализацией Alpenglow, но не активирует новый протокол консенсуса в mainnet. Основные инженерные команды используют этот цикл выпуска для дополнительного тестирования, аудита и усиления защиты перед миграцией консенсуса, которая теперь ожидается в Agave 4.3. Поэтому валидаторы на версии 4.2 уже содержат полную реализацию Alpenglow, включая механизм голосования Votor и его компоненты проверки сертификатов BLS. 

Чтобы расширить аудит безопасности кода, Anza также проводит конкурс по поиску ошибок в Alpenglow с призовым фондом до 50 000 SOL и приёмом заявок с 5 по 19 августа. Ранее во время разработки, миграции монорепозитория и внутренних аудитов Alpenglow не входил в постоянную программу вознаграждений Agave. Конкурс впервые делает его доступным для получения вознаграждений и призван выявить проблемы, которые могли остаться незамеченными при предыдущих проверках.

Переход Stake Program с плавающей точки на фиксированную

Цикл выпуска Agave 4.2 также включает активируемую через feature gate реализацию SIMD-0391: переход Stake Program с плавающей точки на фиксированную. Она заменяет арифметику с плавающей точкой IEEE-754 в расчётах прогрева и охлаждения Stake Program детерминированной целочисленной арифметикой с фиксированной точкой. Основная причина — совместимость со стандартным набором инструментов eBPF, который не поддерживает операции с плавающей точкой. Набор инструментов SBF в Solana может эмулировать их с помощью детерминированных программных процедур, но это неэффективно и препятствует миграции Stake Program на реализацию `no_std`.

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

Новые инструменты управления

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

Главный компонент, svmgov, — программа на базе Anchor, которая управляет созданием предложений, поддержкой, голосованием с учётом размера стейка и завершением голосования. Вес голосов определяется по снимку стейка для конкретной эпохи, который создаёт Node Consensus Network (NCN). Независимые операторы формируют снимок, достигают консенсуса по каноническому корню Merkle и публикуют его ончейн. Затем валидаторы подтверждают свой активный стейк с помощью доказательств Merkle. 

Валидаторы с активным стейком не менее 100 000 SOL могут создавать предложения. Чтобы перейти к голосованию, предложение должно получить поддержку 15% стейка кластера. Репозиторий системы управления также содержит CLI на Rust и веб-интерфейс для голосования и отслеживания поддержки.

Полные документы предложений находятся в отдельном репозитории Solana Governance Proposals и привязываются к конкретному коммиту Git, а ончейн-аккаунт предложения хранит ссылку, состояние жизненного цикла и результаты голосования. Изначально валидаторы голосуют всем делегированным им стейком, но отдельные делегаторы сохраняют контроль над своими SOL. Стейкер может отправить переопределение для конкретного стейкинг-аккаунта, исключив этот стейк из результата валидатора и перераспределив его согласно собственному голосу.

Предложения по управлению Solana (SGP) призваны дополнять, а не заменять SIMD: SGP отвечает на общий вопрос о том, следует ли сети вносить изменение, а связанный SIMD определяет способ его реализации.

Три SGP уже прошли этап поддержки и станут первым раундом голосований по новой системе управления:

• SGP-0001: Конституция Solana предлагает ратифицировать канонический общественный договор управления, который определяет роли разработчиков, валидаторов и стейкеров, а также формально учреждает процесс SGP.
• SGP-0002: удвоение темпа дезинфляции предлагает сети удвоить годовой темп дезинфляции SOL с 15% до 30%, сохранив конечный уровень инфляции в 1,5%. Это сократит расчётный срок достижения конечного уровня примерно с 5,7 до 2,8 года. 
• SGP-0003: комиссия за ресурсы и включение предлагает заменить существующую фиксированную базовую комиссию на комиссию за включение в размере 2500 лампортов, выплачиваемую лидеру, и отдельную комиссию за ресурсы, которая зависит от запрошенных единиц стоимости транзакции и полностью сжигается. Распределение приоритетной комиссии останется без изменений.

Заключение

Agave 4.2 — один из самых значимых выпусков Solana за последнее время. Ускоренные слоты длительностью 200 мс приближают сеть к работе в реальном времени, запланированное снижение залога за состояние на 90% значительно удешевляет создание аккаунтов, а transaction v1 размером 4096 байт предоставляет гораздо больше пространства для сложных инструкций, криптографических доказательств и приложений с большим количеством аккаунтов. Вместе эти изменения делают Solana быстрее, дешевле и функциональнее как для разработчиков, так и для пользователей.

Дополнительные материалы

• График выпуска Agave 4.2
• График отслеживания feature gate
• Журнал изменений Agave 4.2
• Pull request для Agave 4.2