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

Введение

С выпуском Agave 4.0 основной валидаторный клиент Solana делает ещё один шаг вперёд: повышает производительность ключевых компонентов и готовит сеть к увеличению блоков и долгожданному обновлению консенсуса Alpenglow.

Значимые обновления цикла выпуска Agave 4.0

• XDP значительно ускоряет ретрансляцию Turbine
• Replay Stage с меньшей задержкой
• Готовность к Alpenglow: маркеры быстрой передачи лидерства и проверка идентификаторов связанных блоков*
• Расширенная поддержка криптографии: арифметика G2 и системные вызовы BLS12-381*
• Улучшенная сериализация с Wincode
• Увеличение минимального делегирования стейка с Stake Program v5*
• Повторное включение ZK ElGamal Proof program*
• Поддержка программ SBPFv3*

* обновления, управляемые функциональными флагами

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

На момент написания Agave v4.0.0-rc.0 считается кандидатом на обновление mainnet (MUC), а Anza ищет добровольцев, которые помогут довести долю стейка этого выпуска до 25%. Валидаторы, пора обновляться!

XDP готов к широкому внедрению

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

Это важно, поскольку при переходе Solana к более высоким лимитам блоков Turbine становится основным узким местом. Лидеры должны распределять шреды между сотнями пиров, а крупные валидаторы уже сейчас могут отправлять почти 150 000 пакетов в секунду. По мере приближения сети к давней цели — блокам на 100 миллионов CU — производительность отправки и ретрансляции пакетов должна масштабироваться вместе с пропускной способностью исполнения. XDP создаёт необходимый запас, значительно ускоряя распространение блоков.

В Agave 4.0 XDP готов к более широкому внедрению среди валидаторов. Его протестировали под нагрузкой в различных конфигурациях, дополнительно усилили и улучшили маршрутизацию. Результаты в рабочей среде крайне обнадёживают: ретрансляция Turbine стала на несколько порядков быстрее.

Alessandro Decina

@alessandrod

one of the largest validators turbine retransmit from 600ms to ~0.8ms agave 4.0 w/ XDP is going to be the biggest solana upgrade to date https://t.co/cKwqVnpH2g

22 апр. 2026 г., 5:25 AM

Подробнее о том, почему XDP обеспечивает столь значительное улучшение, читайте в нашем предыдущем интервью с инженером Anza Alessandro Decina.

Более быстрый Replay Stage

Agave 4.0 ускоряет воспроизведение, выводя два ресурсоёмких этапа проверки из критического пути потоков воспроизведения. В v4.0 проверка записей и подписей транзакций выполняется асинхронно. Воспроизведение продолжает обработку, пока фоновые задачи подтверждают действительность слота.

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

На практике Replay Stage блокируется гораздо реже, особенно в загруженных слотах, где объём проверок подписей растёт вместе с количеством транзакций.

Дальнейшее внедрение Wincode

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

В Agave 4.0 дополнительные критичные для производительности пути сериализации переходят с bincode на wincode. Поскольку почти все данные, записываемые на диск или передаваемые по сети в Solana, используют bincode, оптимизация этих путей даёт масштабный эффект.

Увеличение минимального делегирования стейка (Stake Program v5)

В Agave 4.0 появится значительное обновление Stake Program. Это изменение, управляемое функциональным флагом и описанное в SIMD-0490, готовит Solana к более масштабному снижению залогов стейка, также известных как рента.

Самое заметное изменение: минимальный делегируемый стейк увеличивается с 1 лампорта до 1 SOL. Это не позволит стоимости создания и обслуживания аккаунтов стейка стать слишком низкой при снижении требований к ренте, что могло бы создать потенциальный вектор атаки. Хотя существует много небольших аккаунтов стейка ниже этого порога, на них приходится лишь 0,02% всего активного стейка. После запуска обновления для них сохранятся прежние условия.

Обновление также упрощает несколько аспектов работы с аккаунтами стейка. Для расчёта ренты вместо сохранённого в каждом аккаунте значения rent_exempt_reserve теперь используется системная переменная Rent. Входные данные аккаунтов системных переменных становятся необязательными для операций программы стейкинга, а реализация Split переписывается для устранения давних пограничных случаев. 

Сообщество операторов валидаторов поддержало новый минимум в 1 SOL. Инструментам и dapp, взаимодействующим с программой стейкинга, потребуется проверить свою логику с учётом нового минимального значения.

Улучшенная поддержка криптографии 

Несколько функциональных флагов, активируемых в течение цикла выпуска Agave 4.0, расширят встроенные криптографические возможности Solana. Это улучшит поддержку современных сценариев, включая доказательства ZK и подписи BLS.

Повторное включение ZK ElGamal Proof program

ZK ElGamal Proof program — это нативная программа Solana, которая проверяет доказательства с нулевым разглашением для конфиденциальных переводов Token-2022. Она позволяет проверять зашифрованные балансы и транзакции, не раскрывая исходные данные. Программа служит универсальным верификатором криптографических доказательств на основе ElGamal и является ключевым компонентом функций конфиденциальности токенов Solana. 

Программу отключили в mainnet после инцидента безопасности в июне 2025 года. Из-за ошибки в логике проверки доказательств — отсутствующего элемента при хешировании транскрипта Fiat-Shamir — стало возможно создавать поддельные доказательства, которые проходили проверку. Эксплуатации уязвимости в реальных условиях не зафиксировали, но из-за потенциальных последствий программу отключили функциональным флагом, а конфиденциальные переводы приостановили до завершения исправлений и аудитов. Теперь проблемы устранены, реализация усилена, а повторная активация программы в mainnet запланирована.

Арифметика G2 для alt_bn128

SIMD-0302: добавление системных вызовов G2 для alt_bn128 расширяет существующие криптографические системные вызовы BN254 (alt_bn128) в Solana, добавляя поддержку нативных операций над точками кривой G2, включая сложение, вычитание и скалярное умножение. G1 и G2 — две группы эллиптических кривых, используемые в криптографии на основе спаривания. G2 определена над более крупным полем расширения.

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

Из-за отсутствия нативной поддержки G2 некоторые проекты использовали собственные реализации, например solana-alt-bn128-bls — комплексную библиотеку подписей BLS, которую Dean Little из Blueshift создал на основе существующих системных вызовов. Поддержка операций G2 на уровне системных вызовов устранит необходимость в таких обходных решениях и упростит создание готовых к рабочей среде криптографических протоколов непосредственно в Solana.

Поддержка обратного порядка байтов для alt_bn128

SIMD-0284: добавление совместимости alt_bn128 с обратным порядком байтов расширяет существующие криптографические системные вызовы alt_bn128 в Solana, добавляя поддержку форматов ввода и вывода с обратным порядком байтов. Ранее эти системные вызовы принимали только кодировку с прямым порядком байтов. Это создавало трудности для разработчиков, использующих инструменты и библиотеки, особенно из экосистемы Ethereum, поскольку большинство команд ZK в Solana используют ark-bn254 с обратным порядком байтов. Изменение сохраняет обратную совместимость и расширяет поддержку существующих сценариев с операциями над эллиптической кривой alt_bn128.

Системные вызовы BLS12-381

Наконец, SIMD-0388: системные вызовы BLS12-381 добавляет нативную поддержку криптографических операций над эллиптической кривой BLS12-381. Эта современная кривая, оптимизированная для спаривания, обеспечивает 128-битную защиту в программах Solana. До сих пор для криптографии на основе спаривания Solana использовала BN254 (alt_bn128), которая не соответствует этому стандарту безопасности и ограничивает совместимость с другими широко распространёнными экосистемами, такими как Ethereum.

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

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

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

Системные вызовы BLS12-381 — лишь одна из нескольких функций, активируемых в течение цикла выпуска Agave 4.0 и закладывающих основу для обновления консенсуса Alpenglow. Ниже перечислены дополнительные функции, способствующие внедрению. Сейчас его запуск в mainnet запланирован на третий квартал 2026 года вместе с Agave 4.1.

Проверка идентификаторов связанных блоков

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

Это изменение вводит явные правила проверки цепочки, которые гарантируют, что каждый блок правильно ссылается на родительский. Это предотвращает расхождение и помогает сети прийти к единой истории. В TowerBFT для этого наборы FEC должны ссылаться на корень Merkle родительского блока как внутри слотов, так и между ними. Alpenglow использует конструкцию с двойным корнем Merkle для всех наборов FEC в слоте. Если эти проверки завершаются неудачно, блок или слот помечается как неактивный. Эти правила повышают безопасность консенсуса и позволяют валидаторам восстанавливаться после получения неверных или конфликтующих блоков.

Маркеры быстрой передачи лидерства

SIMD-0337: маркеры быстрой передачи лидерства Alpenglow определяет явные правила сигнализации, позволяющие валидаторам установить, когда родительский слот полностью завершён и на его основе можно безопасно строить следующий блок. Это необходимое условие для быстрой смены лидера. Изменение вводит более строгие требования к размещению DATA_COMPLETE_SHRED и новый маркер «родитель готов», чтобы завершённость блока можно было однозначно определить по самому потоку шредов.

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

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

Обновление модели стоимости голосующих транзакций

SIMD-0458: отказ от статической стоимости транзакций SimpleVote отменяет фиксированную стоимость CU для голосующих транзакций и переводит их на стандартную модель стоимости, используемую для остальных транзакций. 

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

Фактическое потребление CU во время исполнения голосующих транзакций останется прежним, но их учёт при формировании блоков изменится. В частности, теперь голоса будут включать дополнительные ~16 тысяч расчётных CU, например затраты на загрузку данных аккаунтов. Поэтому при создании блоков лидеры будут заранее резервировать больше CU.

Это изменение следует за SIMD-0387 (управление публичными ключами BLS в аккаунте голосования), который устранил предположение о статическом профиле исполнения Vote program.

Другие значимые обновления

Среди других важных изменений цикла выпуска Agave 4.0 — поддержка программ SBPFv3, возможность создавать заранее пополненные аккаунты и прямой ввод-вывод для распаковки снимков состояния.

Поддержка программ SBPFv3

Цикл выпуска Agave 4.0 включает функциональный флаг, разрешающий развёртывание и исполнение программ SBPFv3. Solana Berkeley Packet Filter (SBPF) — это форк eBPF на базе Rust от Solana: низкоуровневый формат байт-кода и виртуальная машина, для которой компилируются ончейн-программы перед исполнением. Это обновление объединяет изменения из трёх SIMD: SIMD-0178, SIMD-0189 и SIMD-0377. 

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

SIMD-0189 ужесточает допустимую структуру ELF для программ. Более строгая структура файлов сокращает число пограничных случаев, которые должны разбирать валидаторы, и объём неожиданных данных, которые им приходится обрабатывать. Для разработчиков изменение должно пройти незаметно, поскольку набор инструментов компоновки будет автоматически создавать совместимые бинарные файлы.

Наконец, SIMD-0377 обновляет виртуальную машину SBPF, чтобы она лучше соответствовала современному набору инструкций eBPF, создаваемому LLVM. В частности, добавляется поддержка дополнительных инструкций, таких как 32-битные операции перехода. Цель — повысить совместимость виртуальной машины Solana с вышестоящими инструментами и позволить программам компилироваться в более эффективный байт-код. Для разработчиков это означает более быструю загрузку программ, меньшую поверхность атаки и потенциальное снижение потребления вычислительных ресурсов без изменения логики приложения.

Создание заранее пополненных аккаунтов

SIMD-0312: CreateAccountAllowPrefund планируется активировать в mainnet в течение цикла выпуска Agave 4.0. В системной программе появится новая инструкция, которая отменит требование о нулевом балансе лампортов у вновь создаваемых аккаунтов. Аккаунты можно будет пополнять до создания, что упростит распространённый рабочий процесс разработчиков и сократит количество ненужных инструкций.

Ранее инструкция CreateAccount завершалась ошибкой, если на целевом аккаунте уже были лампорты. Поэтому разработчикам приходилось разделять инициализацию аккаунта на несколько этапов: обычно сначала выполнять перевод, а затем allocate и assign. Это повышало сложность и требовало дополнительных вычислительных ресурсов. Такой шаблон особенно распространён в программах, которые заранее пополняют аккаунты.

Новая инструкция объединяет эти этапы в один вызов и позволяет напрямую инициализировать заранее пополненные аккаунты. На практике это снижает накладные расходы CPI и может экономить тысячи вычислительных единиц в распространённых сценариях. Разработчики получают более простой и производительный подход. Поскольку это новая инструкция, а не изменение существующих, полная обратная совместимость сохраняется.

Прямой ввод-вывод при распаковке снимков состояния 

В Agave 4.0 для распаковки снимков состояния по умолчанию используется прямой ввод-вывод вместо записи через страничный кеш операционной системы. Это сокращает время запуска и ускоряет восстановление из снимков состояния. Такой подход особенно полезен, поскольку данные снимка обычно передаются на диск потоком и не должны вытеснять из памяти более востребованные данные валидатора. Если файловая система не поддерживает O_DIRECT, операторы могут отключить эту функцию с помощью --no-accounts-db-snapshots-direct-io. В одном из будущих выпусков прямой ввод-вывод планируется распространить и на создание снимков состояния. 

Заключение

Agave v4.0 — это значительное обновление клиента, которое содержит множество улучшений производительности и оптимизаций среды исполнения. Эти изменения сделают сеть быстрее, безопаснее и удобнее для разработки.

Следующие важные этапы — Agave 4.1 и обновление консенсуса Apenglow.

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

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