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

Введение

В Agave 4.1 основной клиент валидатора Solana продолжает стабильно развиваться. Уже сейчас он повышает производительность и одновременно закладывает основу для более крупных блоков, слотов длительностью 200 мс и последующего развертывания Alpenglow.

Ключевые обновления цикла выпуска 4.1

• Более частый выпуск версий: теперь основные релизы выходят каждые шесть недель
• Продолжение подготовки к Alpenglow, включая управление открытыми ключами BLS*, Validator Admission Tickets* и кластер для тестирования сообществом
• Распространение XDP превысило критически важный для сети порог
• Дополнительные программы переписаны на Pinocchio, включая p-memo и p-ATA
• Снижено потребление оперативной памяти валидаторами
• Подготовка к слотам длительностью 200 мс**

* Улучшения, активируемые через feature gate

** Ожидается в Agave 4.2

Параллельно с работой над основным клиентом Anza и более широкая экосистема развивают несколько крупных инициатив:

• Constellation: Constellation предлагает первую формальную реализацию Multiple Concurrent Proposers (MCP) на уровне протокола в работающем блокчейне крупного масштаба. Вместо того чтобы предоставлять одному лидеру широкие полномочия по включению транзакций, Constellation вводит предлагающих и аттестующих участников, которые ограничивают возможность лидера исключать транзакции из валидного блока.
• Защита от квантовых угроз: исследовательская команда Anza начала изучать, как защитить Solana от будущих квантовых противников. Исследования охватывают постквантовые подписи, миграцию аккаунтов, подписи консенсуса, распространение блоков и ончейн-проверку подписей.
• Экономические обновления: готовится новая волна предложений по токеномике. SIMD-550 предлагает удвоить темп снижения инфляции Solana с -15% до -30%, а SIMD-553: плата за ресурсы и включение предлагает разделить текущую комиссию за подпись на базовую комиссию за включение, выплачиваемую лидеру, и сжигаемую комиссию за ресурсы, размер которой зависит от запрошенных единиц вычислительной стоимости.
• Новые инструменты управления: улучшенная инфраструктура управления также влияет на следующий этап экономических предложений. Новые инструменты позволяют не только валидаторам, но и стейкерам напрямую участвовать в управлении Solana. Благодаря этому больше участников смогут высказываться об изменениях основного протокола.

Сейчас происходит очень многое.

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

На момент написания Agave v4.1.0-rc.1 уже рекомендован для общего использования в mainnet. Валидаторы, пора обновляться!

Готовность к Alpenglow

Значительная часть основы для обновления консенсуса Alpenglow появится в течение цикла выпуска Agave 4.1. Эти изменения готовят сеть к переходу с Tower BFT на Alpenglow. Они включают управление ключами BLS в программе голосования, Validator Admission Tickets и маркеры Fast Leader Handover.

Кластер для тестирования сообществом

Оставшаяся подготовка к активации Alpenglow в mainnet теперь во многом зависит от масштабного тестирования в реальных условиях. С мая кластер примерно из 100 географически распределенных валидаторов сообщества тестирует обновление в работающей сети. До активации в mainnet они проверяют переход между текущим консенсусом Solana на базе Tower BFT и Alpenglow.

Цель — сделать процесс запуска максимально спокойным. Валидаторы в кластере переключались между Tower BFT и Alpenglow, проверяя путь миграции в реальных условиях работы операторов, а не только в контролируемых внутренних тестах. Обсуждения проходят в канале `ag-community-cluster` в Solana Tech Discord. За активностью кластера в реальном времени можно следить на дашбордах сообщества от Valid Blocks, Staking Facilities и Noders.

Управление открытыми ключами BLS

SIMD-0387: управление открытыми ключами BLS в аккаунте голосования будет активировано в течение цикла выпуска Agave 4.1. Обновление добавляет необходимую инфраструктуру программы голосования, чтобы валидаторы могли зарегистрировать открытые ключи BLS в своих аккаунтах голосования до запуска Alpenglow. Alpenglow использует агрегированные подписи BLS, чтобы снизить стоимость агрегации и проверки голосов. При этом открытые ключи BLS отличаются от используемых сейчас ключей полномочий голосования Ed25519. 

Валидаторы могут добавить открытые ключи BLS в аккаунты голосования и продолжить работу с существующими ключами полномочий голосования Ed25519. После активации Alpenglow аккаунты голосования без зарегистрированного открытого ключа BLS не смогут участвовать в новом процессе голосования.

Alpenglow Validator Admission Tickets (VAT)

Цикл выпуска Agave 4.1 также включает активацию в mainnet SIMD-0357, реализующего Validator Admission Tickets (VAT). VAT призваны сохранить схожую структуру затрат валидаторов после отказа Solana от текущей модели транзакций голосования в Tower BFT.

Сейчас валидаторы постоянно платят комиссию за транзакции голосования. Для валидаторов, которые голосуют регулярно, общая сумма достигает ~2,1 SOL за эпоху. В Alpenglow эти транзакции голосования заменяет новый механизм консенсуса, поэтому SIMD-0357 вводит вместо них плату за допуск один раз за эпоху. Каждый валидатор, допущенный к голосованию Alpenglow, платит VAT в размере 1,6 SOL за эпоху. Это сохраняет сопоставимый экономический барьер и снижает риск немедленного неконтролируемого расширения набора валидаторов после запуска Alpenglow.

Механизм срабатывает на границе эпох. При переходе к новой эпохе среда выполнения рассчитывает набор валидаторов для следующей эпохи. Она отбирает аккаунты голосования, в которых зарегистрирован открытый ключ BLS и достаточно лампортов для покрытия VAT и ренты, а затем списывает VAT с аккаунтов голосования принятых валидаторов. Эти лампорты отправляются напрямую на аккаунт для сжигания. Если требованиям соответствуют более 2 000 валидаторов, набор голосующих ограничивается по весу стейка: выбираются подходящие валидаторы с наибольшим весом.

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

Маркеры Fast Leader Handover

Наконец, активация SIMD-0337: маркеры для Alpenglow Fast Leader Handover добавит новые маркеры блоков. Они позволят лидеру Alpenglow объявить родительский блок в начале блока и при необходимости обновить его во время потоковой передачи блока. Эти маркеры поддерживают Fast Leader Handover, который сокращает задержки синхронизации между лидерами.

Более широкое внедрение XDP и путь к 100 миллионам CU

XDP (eXpress Data Path) — это высокопроизводительный сетевой путь, который Agave использует для ускорения Turbine. Он позволяет Agave загружать программу eBPF рядом с сетевой картой, благодаря чему трафик шредов обходит значительную часть стандартного пути обработки пакетов Linux. Внедрение XDP необходимо, чтобы сеть достигла давней цели — блоков на 100 миллионов CU. 

Уровень внедрения уже преодолел важный порог. В начале этого месяца в сети произошло «переворачивание»: лидеров, использующих XDP, стало больше, чем лидеров без него. Сейчас XDP активировали более двух третей сети. В Agave 4.1 этот уровень зрелости отражен удалением статуса экспериментальной функции у поддержки XDP и заменой старых флагов `--experimental-retransmit-xdp-*` на `--xdp-interface`, `--xdp-cpu-cores` и `--xdp-zero-copy`. В Agave 4.2 XDP планируется включить по умолчанию.

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

Другие программы, переписанные на Pinocchio

Недавний успешный запуск p-token доказал, что целевое переписывание наиболее востребованных программ Solana может заметно снизить вычислительные затраты всей сети. p-token полностью заменяет программу SPL Token и сокращает потребление вычислительных единиц (CU) примерно на 95%. Для стандартных транзакций с токенами это дает прирост эффективности примерно в 19 раз. Ранее инструкции программы токенов потребляли около 10% всех CU блока. Снижение их стоимости примерно до 5% от прежнего уровня позволило p-token освободить почти 9,5% общей емкости блока.

Буква «p» в названии p-token означает Pinocchio — разработанную Anza оптимизированную и производительную библиотеку без зависимостей для создания программ Solana. Pinocchio заменяет стандартный крейт solana-program, который активно использует типы с доступом без копирования для обработки данных инструкций и аккаунтов.

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

Программа p-memo

Первый пример — p-memo, реализация программы SPL Memo на Pinocchio, которая уже работает в mainnet. Программа Memo невелика, но прирост эффективности все равно впечатляет. Без подписантов p-memo потребляет 287 CU против 2 022 CU у текущей программы Memo — около 14% прежней стоимости. При наличии подписантов разница становится еще заметнее: с одним подписантом p-memo использует 513 CU против 13 525 CU, с двумя — 628 CU против 25 111 CU, а с тремя — 743 CU против 36 406 CU. Таким образом, при большом количестве подписантов p-memo снижает потребление вычислительных ресурсов до 2–4% от стоимости текущей программы.

Программа p-ATA

Также ведется работа над p-ATA — реализацией программы Associated Token Account на Pinocchio. Программа ATA задает стандартное соответствие между кошельком, минтом токена и аккаунтом токена, в котором хранится выпущенный этим минтом токен. Она позволяет детерминированно получить связанный аккаунт токена пользователя и дает любому участнику возможность создать такой аккаунт для получателя, если он еще не существует. 

Программа ATA занимает пятое место по числу вызовов в сети. По оценкам команды Anza, она используется примерно в ~11,9% всех транзакций и отвечает примерно за ~13,3% общего потребления CU. Новая реализация может снизить средневзвешенное потребление CU на 80,9%. Дополнительную экономию должны обеспечить новые инструкции, добавленные вместе с p-ATA. При текущей нагрузке сети это позволит сэкономить около 10% CU во всей mainnet. В выборке Anza p-ATA освобождала более 2,78 миллиона CU в каждом блоке.

Работа вряд ли завершится на p-token, p-memo и p-ATA. Еще одна программа, о переписывании которой часто просят, — Token-2022. В более широком смысле инициатива Anza по переводу основных программ на `no_std` создает основу для переписывания других фундаментальных программ Solana с меньшим числом зависимостей и более низкими вычислительными затратами.

Снижение накладных расходов точки входа программы

Еще одно связанное изменение, запланированное для активации в цикле выпуска Agave 4.1, — SIMD-0449: прямые указатели на аккаунты во входных данных программы, которое оптимизирует точку входа программы. Сейчас программы ABIv1 sBPF должны анализировать сериализованный раздел аккаунтов во входных данных программы, чтобы находить границы аккаунтов и формировать передаваемый программе срез аккаунтов. SIMD-0449 меняет этот механизм: VM добавляет во входные данные программы срез прямых указателей на аккаунты, используя сведения о границах, которые уже известны VM при подготовке вызова.

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

В обновленных бенчмарках стоимость точки входа Pinocchio с 64 аккаунтами снижается с 504 CU до расчетных 7 CU. Наборы с меньшим числом аккаунтов также сходятся к низкой стоимости в 7 CU.

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

Одно из самых ожидаемых улучшений производительности — сокращение целевой длительности слота Solana с 400 до 200 мс. Скорее всего, оно не появится в цикле выпуска Agave 4.1, а выйдет в mainnet вместе с Agave 4.2. Однако стремление как можно скорее внедрить это важное обновление в mainnet усиливается.

SIMD-0525: сокращение длительности слота предлагает поэтапное развертывание: сначала длительность слота сокращается с 400 до 350 мс, затем до 300 мс, 250 мс и, наконец, до 200 мс. Каждый этап активируется через feature gate, чтобы команды клиентов и операторы могли оценить работу сети с более короткими слотами перед переходом к следующему этапу. Anza уже несколько месяцев тестирует слоты длительностью 200 мс внутри компании, и команда считает, что сеть готова к резкому сокращению длительности слотов. Улучшения этапа воспроизведения сделали это изменение более практичным: теперь воспроизведение полного слота длительностью 400 мс занимает около 40 мс.

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

Более короткие слоты также дают приложениям более детальное представление о времени в ончейне. Это важно для систем, которые учитывают актуальность слота, включая потребителей данных оракулов и проприетарных маркет-мейкеров на основе AMM.

Предложение тщательно спроектировано так, чтобы не менять экономику Solana. Значение `slots_per_year` увеличивается обратно пропорционально, сохраняя график инфляции SOL. В Alpenglow стоимость Validator Admission Ticket (VAT) также масштабируется в зависимости от этапа сокращения длительности слота, чтобы плата за допуск оставалась близкой к целевым ~0,8 SOL в день. Кроме того, лимиты работы на слот сокращаются пропорционально уменьшению целевой длительности слота. Поэтому объем работы, который сеть может обрабатывать в секунду, остается примерно прежним. 

Несколько основных параметров остаются без изменений. Период лидерства по-прежнему составляет четыре слота, эпохи включают фиксированные 432 000 слотов, а число тиков на слот остается равным 64. Поскольку количество слотов в эпохе не меняется, слоты длительностью 200 мс сокращают эпоху примерно с двух дней до одного.

Один из спорных вопросов — влияние на стоимость голосования валидаторов, если более короткие слоты активируют до Alpenglow. Ускорение слотов означает больше голосов в день и, следовательно, увеличение ежедневных расходов валидаторов на голосование. Транзакции голосования — крупнейшая отдельная статья расходов операторов валидаторов. Для них действует единая цена 0,000005 SOL, и ежедневно эти транзакции обходятся примерно в ~1,086 SOL. При слотах длительностью 200 мс расходы примерно удвоятся.

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

В течение цикла выпуска Agave 4.1 планируется активировать несколько менее крупных, но важных улучшений: от более точных ставок комиссии валидаторов и новых криптографических примитивов до устранения вектора атаки типа «отказ в обслуживании» в обновляемом загрузчике.

Повышение точности ставок комиссии валидаторов

В рамках цикла выпуска Agave 4.1 в mainnet будет активировано управляемое через feature gate обновление SIMD-0291: ставка комиссии в базисных пунктах. Сейчас ставки комиссии валидаторов можно задавать только в целых процентных пунктах. Валидатор может установить комиссию 5% или 6%, но не 5,5%, 5,25% или 5,01%.

После обновления валидаторы получат более точный контроль благодаря установке ставок комиссии в базисных пунктах, где 100 базисных пунктов равны 1%. В программу голосования добавляется новая инструкция `UpdateCommissionBps`. Она позволяет уполномоченному на вывод средств участнику аккаунта голосования с повышенной точностью обновлять комиссию валидатора с инфляционных вознаграждений. Это сделает настройки комиссии валидаторов более гибкими и конкурентоспособными.

Это изменение входит в число нескольких обновлений, связанных с новым Vote Account V4. Оно также помогает подготовить сеть к ожидаемой активации SIMD-0123: распределение дохода от блоков, которое позволит распределять вознаграждения за блоки на уровне протокола.

Системный вызов SHA-512

SIMD-0512: системный вызов Sha512 вводит новый системный вызов, который предоставляет ончейн-программам прямой доступ к хешированию SHA-512 через среду выполнения. Его интерфейс повторяет существующие системные вызовы хеширования, такие как `sol_sha256`, `sol_keccak256` и `sol_blake3`.

SHA-512 — основной примитив, используемый при проверке подписей Ed25519. Он уже существует как внутренняя зависимость в клиентах валидаторов Agave и Firedancer. Однако до сих пор он не был доступен ончейн-программам. Прямое хеширование короткого сообщения в ончейне обходится дорого и потребляет тысячи CU, тогда как системный вызов использует менее 100 CU.

С помощью `sol_sha512` программы могут вычислять хеши SHA-512 по стоимости системного вызова и напрямую получать стандартный 64-байтовый дайджест. Изменение носит дополняющий характер и активируется через feature gate, поэтому оно не влияет на программы, которые не используют новый системный вызов. Существующие системные вызовы хеширования также не меняются.

Повышение безопасности обновляемого загрузчика

В цикле выпуска Agave 4.1 также появится активируемое через feature gate обновление SIMD-0431: Loader V3 — минимальный размер расширения программы, которое добавляет минимальный размер расширения для инструкции `ExtendProgram` в Loader V3. После активации программы потребуется расширять не менее чем на 10 240 байт (10 КиБ), кроме случаев, когда аккаунт данных программы уже находится в пределах 10 КиБ от максимального размера аккаунта в 10 МиБ.

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

Вместо введения разрешений для `ExtendProgram` изменение сохраняет общедоступность инструкции, но делает злоупотребление экономически невыгодным. При новом минимуме в 10 КиБ каждое расширение требует примерно 0,072 SOL в лампортах для освобождения от ренты.

Влияние на штатные обновления программ должно быть ограниченным. Программы, которым требуется менее 10 КиБ дополнительного пространства, придется расширять на полный минимальный объем, но дополнительная емкость останется доступной для будущих обновлений. SIMD также не меняет аккаунты инструкций, требования к подписантам, ограничения CPI и существующие рабочие процессы с мультиподписью.

Заключение

Agave 4.1 — крупное обновление клиента, объединяющее множество улучшений и оптимизаций производительности. В перспективе Agave 4.2 обещает стать еще более значительным выпуском: размер транзакций увеличится до 4096 байт, длительность слотов сократится до 200 мс и, возможно, наконец появится долгожданное обновление консенсуса Alpenglow.

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

• График выпуска Agave 4.1
• График отслеживания feature gate
• Журнал изменений Agave 4.1
• Пул-реквесты Agave 4.1