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

Введение

В Agave 4.4 основной валидаторный клиент Solana развивает внедрение Alpenglow: упрощает проверку блоков и расчет вознаграждений за стейкинг, а также снижает объем SOL, необходимый для хранения программ и данных аккаунтов. Эти изменения повышают повседневную эффективность и закладывают дополнительную основу для асинхронного выполнения. Недавнее сокращение целевого времени слота до 200 мс уменьшает продолжительность эпох примерно до одного дня, что позволяет еще быстрее активировать функциональные флаги.

Важные изменения цикла выпуска Agave 4.4

• Разрешение недействительных плательщиков комиссий: важный шаг к асинхронному выполнению
• Автоматическое изменение размера программ: возврат излишка арендного депозита при обновлении программ
• Стандартизация шредов: протокол теперь требует наборы FEC из 32 шредов данных и 32 шредов кодирования
• Исключение неактивного стейка: неактивный стейк исключается из расчета вознаграждений
• Снижение арендного депозита: три последних запланированных этапа сокращения залога за состояние на 90%

Разрешение недействительных плательщиков комиссий

Функциональный флаг SIMD-0290: ослабление ограничения для плательщика комиссии, как ожидается, активируют в цикле выпуска Agave 4.4. Он меняет обработку блока с транзакцией, плательщик комиссии которой не прошел проверку, например из-за недостатка SOL. Раньше включение такой транзакции делало недействительным весь блок. По новым правилам консенсуса транзакция остается в блоке, а валидаторы пропускают ее выполнение, не изменяя состояние аккаунтов.

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

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

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

SIMD-0290 применяется только к транзакциям, использующим недавний хеш блока в качестве ограничителя срока действия. Транзакции с долговечным nonce требуют дополнительной обработки, которая отдельно описана в SIMD-0297: ослабление ограничения для недействительных транзакций с nonce. Изменение полностью обратно совместимо: все ранее действительные транзакции и блоки остаются действительными.

Автоматическое изменение размера программ при обновлении

Agave 4.4 включает активацию функционального флага SIMD-0433: Loader V3 — установка размера данных программы по длине ELF, благодаря которому при обновлении программы автоматически меняется размер аккаунта с ее скомпилированным кодом.

Loader v3 (то есть текущий стандартный загрузчик для развертывания и обновления программ Solana) хранит скомпилированный бинарный файл ELF программы в аккаунте ProgramData вместе с метаданными, например данными о полномочиях на обновление. Раньше разработчики могли только увеличивать этот аккаунт, но не уменьшать его. Поэтому после перехода на бинарный файл меньшего размера оставалось неиспользуемое пространство, а SOL, необходимые для освобождения этого пространства от арендной платы, оставались заблокированы в аккаунте.

После этого изменения инструкция Upgrade устанавливает размер аккаунта, равный размеру заголовка метаданных плюс длина нового ELF. При переходе на бинарный файл меньшего размера избыточные лампорты переводятся в резервный аккаунт обновления — назначенному получателю оставшихся средств. Для бинарного файла большего размера аккаунт расширяется автоматически, поэтому при обычных обновлениях отдельный этап расширения больше не нужен. Аккаунты ProgramData и буфера должны уже содержать достаточно лампортов для выполнения нового требования по арендному депозиту, иначе обновление завершится ошибкой.

Таким образом, разработчики, переходящие на бинарные файлы меньшего размера, смогут вернуть SOL при следующем обновлении. Любой ранее зарезервированный запас емкости также удаляется. Для обновлений, вызываемых через CPI, по-прежнему действует ограничение на увеличение аккаунта в 10 КиБ: для более значительного увеличения требуется предварительное расширение или инструкция обновления верхнего уровня. Перед обновлением разработчикам следует проверить адрес резервного аккаунта, чтобы средства поступили нужному получателю.

Это изменение мотивирует разработчиков переходить на более новые и производительные библиотеки и фреймворки, такие как Pinocchio. Оно также уменьшает объем пространства, занимаемого программами в Accounts DB.

Стандартизация шредов

Agave 4.4 ужесточает правила распространения блоков Solana, изложенные в SIMD-0317: обязательные 32 шреда данных + 32 шреда кодирования. Это стандартизирует структуру, которую валидаторы используют для распространения и восстановления данных блоков.

Solana распространяет блоки через Turbine, который разбивает данные блока на шреды и передает их через уровни валидаторов. Шреды объединяются в наборы прямого исправления ошибок (FEC), состоящие из шредов данных и шредов кодирования с информацией для восстановления. Если набор из 32 шредов данных и 32 шредов кодирования сформирован правильно, получатель может восстановить исходные данные по любым 32 из 64 шредов, что повышает устойчивость к потере пакетов.

Каждый шред также содержит доказательство Merkle, связывающее его с корнем Merkle набора, подлинность которого подтверждается подписью лидера. Для набора из 64 шредов это доказательство состоит из шести элементов, соответствующих шести уровням между листом и корнем. Проверка размера доказательства в Agave требует размер, соответствующий этой фиксированной структуре 32:32.

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

Фиксированная структура также упрощает обнаружение неоднозначности, когда лидер распространяет противоречащие друг другу версии одних и тех же данных. Два шреда из одного набора FEC с разными корнями Merkle и действительными подписями лидера служат доказательством такого конфликта. Таким образом, стандартизация формата снижает сложность реализации и упрощает выявление неоднозначности.

Исключение неактивного стейка из расчета вознаграждений

Цикл выпуска Agave 4.4 включает активацию функционального флага SIMD-0599: исключение неактивных стейков из делегированного стейка, который упрощает обработку неактивных стейкинговых аккаунтов валидаторами при распределении вознаграждений по разделам в начале каждой эпохи. Неактивные стейкинговые аккаунты могут содержать SOL сверх минимального баланса для освобождения от арендной платы, но не иметь активного или активируемого стейка. Их SOL не делегированы или полностью завершили деактивацию.

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

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

Дальнейшее снижение арендного депозита

Ожидается, что Agave 4.4 принесет три заключительные активации поэтапного снижения арендного депозита в Solana. Согласно плану из SIMD-0437, минимальный баланс на каждый байт хранилища аккаунта за пять этапов снижается с первоначальных 6 960 до 696 лампортов (то есть на 90%).

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

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

Оценки Ghost показывают, что можно вернуть более 3 миллионов SOL (~300 млн долларов). Для возврата избыточных SOL из аккаунтов пользователей разработано несколько инструментов.

Заключение

Ключевые изменения Agave 4.4 развивают Alpenglow и продвигают давно ожидаемые улучшения вознаграждений за стейкинг, развертывания программ и стоимости аккаунтов. Вместе они помогают Solana двигаться к более быстрой и доступной сети. Следующим событием станет Breakpoint London, а затем выйдет Agave 4.5.

Дополнительные ресурсы

• График выпуска Agave 4.4
• График отслеживания функциональных флагов
• Журнал изменений Agave 4.4
• Запросы на включение изменений Agave 4.4