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

Введение

Выпуск v2.3 клиента валидатора Agave знаменует ещё один важный этап развития Solana. Как и предыдущие обновления, эта версия содержит важные улучшения производительности сети и опыта разработчиков.

Основные обновления Agave 2.3 

• Новый клиент TPU tpu-client-next
• Оптимизация AccountsDB со снижением дискового ввода-вывода
• Расписание лидеров теперь использует аккаунты голосования валидаторов в качестве ключей
• Проверка событий, за которые предусмотрен слэшинг
• Жадный планировщик включён по умолчанию
• Улучшения снапшотов
• Обновления gossip
• Более быстрые переходы между эпохами

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

Anza ускоряет темп выпуска Agave. Менее чем через три месяца после версии 2.2 уже запущена версия 2.3, и сейчас на версиях нового клиента работает 13% общего стейка. Ожидается, что в ближайшие недели уровень внедрения будет быстро расти. На время развёртывания активации функциональных шлюзов в основной сети приостановлены. Вскоре они возобновятся в рамках запланированной последовательности активации.

Новый клиент TPU

В Agave 2.3 появилась новая реализация клиента Transaction Processing Unit (TPU), которая заменяет прежний ConnectionCache. Этот клиент TPU отвечает за отправку сериализованных транзакций валидаторам по сети через протокол QUIC. Новая реализация под названием tpu-client-next полностью переработана для значительного повышения производительности, сокращения потребления ресурсов и упрощения общей архитектуры.

Клиент TPU используется в двух основных сценариях: в ForwardingStage, где валидаторы перенаправляют транзакции следующему лидеру, и в SendTransactionService, который RPC используют для ретрансляции транзакций лидеру.

Предыдущая реализация, ConnectionCache, поддерживала протоколы UDP и QUIC, что излишне усложняло её. Вместо явного канала ConnectionCache использовал внутреннюю асинхронную очередь для хранения транзакций и включал логику прогрева кеша, которая отправляла пустые пакеты. Также сохранялись проблемы с управлением конечными точками Quinn — реализации QUIC на Rust.

Новый tpu-client-next решает эти проблемы благодаря упрощённой асинхронной архитектуре. Внутри используется модель на основе агентов, в которой отдельные рабочие задачи обрабатывают каждое соединение QUIC. Эти задачи взаимодействуют с централизованным ConnectionWorkersScheduler через асинхронные каналы. 

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

tpu-client-next демонстрирует явный прирост производительности. 

• В экспериментах с RPC в тестовой сети старый и новый клиенты показали схожий средний TPS под нагрузкой, однако у tpu-client-next наблюдалось заметно меньше колебаний. 
• В сценариях использования валидаторами ForwardingStage обеспечил увеличение объёма перенаправляемых транзакций на 10%, более стабильные профили трафика и снижение загрузки CPU на 30%.
• Закрытый инструмент Anza для нагрузочного тестирования transaction-bench, создан на основе нового клиента. Он генерирует вдвое больше транзакций в секунду, чем предыдущий инструмент тестирования bench-tps.

tpu-client-next полностью обратно совместим и теперь используется по умолчанию на нодах Agave. При возникновении проблем операторы могут вернуться к прежнему поведению, запустив ноду с флагом --use-connection-cache, который восстанавливает старую реализацию.

Итак, преимущества tpu-client-next:

• Удобная для асинхронной работы архитектура на основе агентов
• Стабильный трафик с меньшими колебаниями
• Снижение потребления CPU и памяти
• Настраиваемые политики планирования и управления очередями
• Упрощённая интеграция и более понятный API

Расписание лидеров с ключами на основе аккаунтов голосования

В рамках цикла выпуска Agave 2.3 в Solana будет активирован документ SIMD-0180: использование адреса аккаунта голосования в качестве ключа расписания лидеров. Это изменение затрагивает способ определения валидаторов, назначенных для создания блоков: вместо адресов идентификации валидаторов основными ключами в расписании лидеров станут адреса аккаунтов голосования.

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

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

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

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

Проверка событий, за которые предусмотрен слэшинг

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

Существуют две основные модели слэшинга:

Социальный слэшинг (текущая система Solana)

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

Программный слэшинг (слэшинг на уровне протокола)

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

Слэшинг включает два основных этапа:

• Обнаружение и атрибуция нарушения: выявление неправомерного поведения и ответственного валидатора.
• Применение санкций: экономическое наказание нарушителя путём слэшинга его стейка и привлечение к ответственности.

В рамках цикла выпуска Agave 2.3 в Solana планируется активировать функциональный шлюз для Slashing Program, как описано в документе SIMD-0204: проверка событий, за которые предусмотрен слэшинг. Это первый шаг к программному слэшингу в Solana с акцентом на обнаружение и атрибуцию нарушений. Новая ончейн-программа позволяет любому пользователю сообщать о поведении, за которое предусмотрен слэшинг, и регистрировать его. Так создаётся основа для будущего автоматического применения санкций.

Эта программа не изменяет стейки или вознаграждения, а только проверяет и регистрирует нарушения, формируя ончейн-реестр неправомерных действий валидаторов. Ранний прототип программы развёрнут в Testnet (например, пример транзакции DuplicateBlockProof). 

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

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

После успешной проверки доказательства результаты сохраняются по адресу, производному от программы (Program-derived Address, PDA), для дальнейшего использования. Это упрощает создание панелей мониторинга с данными о слэшинге: достаточно выполнить getProgramAccounts для программы слэшинга. Валидаторы могут проверить, поступали ли сообщения об их нарушениях, и при необходимости принять меры.

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

Более быстрые переходы между эпохами

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

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

Оптимизация AccountsDB

В этом выпуске значительно повысилась эффективность хранилища. Объём дискового ввода-вывода сократился примерно на 75%, а количество запросов на восстановление — приблизительно на 85%. Вместе эти оптимизации делают работу нод более стабильной и надёжной, особенно в периоды высокой сетевой нагрузки.

Жадный планировщик включён по умолчанию

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

Подробнее о жадном планировщике можно узнать в нашей предыдущей статье в блоге Helius.

Версия шредов в gossip

Agave 2.3 строже контролирует соответствие версий шредов в сети gossip. Теперь ноды могут устанавливать входящие gossip-соединения, только если их версия шредов совпадает с версией кластера. Это помогает быстро отклонять неверно настроенные ноды.

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

Это обновление продолжает недавнюю работу по снижению издержек gossip. За последние месяцы входящий gossip-трафик сократился примерно на 61% благодаря отказу от трёх типов gossip-сообщений и прекращению публикации слотов эпохи валидаторами без стейка.

Симуляции RPC включают данные об использовании ресурсов

Чтобы повысить прозрачность использования ресурсов транзакциями, в результат стандартного метода RPC `simulateTransaction` добавлено новое поле: `loadedAccountsDataSize`. В нём указывается общий объём данных аккаунтов в байтах, загруженных во время симуляции.

Это дополнение позволяет разработчикам точнее оценивать стоимость транзакций и настраивать приоритетные комиссии. Загрузка данных аккаунтов расходует вычислительные единицы (CU) из расчёта 8 CU на 32 КБ, что соответствует размеру страницы кучи Solana. Благодаря этой метрике разработчики могут эффективнее оптимизировать затраты при создании и отправке транзакций.

Улучшения снапшотов

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

В этом выпуске реализовано несколько практических улучшений работы со снапшотами:

• Обновлён интервал по умолчанию: интервал создания полных снапшотов по умолчанию увеличен с 25 000 до 50 000 слотов, благодаря чему они создаются реже.
• Новый флаг для отключения снапшотов: добавлен новый флаг `--no-snapshots`, который явно отключает создание снапшотов. Предыдущий метод с использованием `--snapshot-interval-slots 0` теперь считается устаревшим.
• Улучшена работа Geyser: при восстановлении из снапшота уведомления об аккаунтах, отправляемые через Geyser, больше не дедуплицируются.

Ещё одно преимущество увеличенного интервала снапшотов — более стабильная работа диска и уменьшение пиков IOPS (операций ввода-вывода в секунду).

Улучшения инструментария SBPF

Agave 2.3 содержит несколько практических улучшений для разработчиков, работающих с инструментарием SBPF:

• Выбор целевой версии: теперь при компиляции программ разработчики могут явно выбирать конкретные версии BPF VM (v0–v3), получая больше контроля.
• Только Rust для SBPFv3: начиная с SBPFv3 поддерживается только инструментарий на основе Rust. Устаревший инструментарий C несовместим с будущими версиями.
• Новый флаг оптимизации: добавлен новый флаг сборки `--optimize-size`, позволяющий создавать для развёртывания бинарные файлы программ меньшего размера. Это может сократить объём хранилища, хотя расход вычислительных единиц (CU) может немного увеличиться.

Другие изменения

В этот выпуск также вошли следующие обновления:

• Автоматическое восстановление кластера: добавлена новая функция восстановления кластера `wen-restart`, которая автоматически запускает перезапуск кластера в случае сбоя блокчейна.
• Обновлённый ABI журналирования: ABI журналирования `TimedTracedEvent` обновлён и теперь включает новые диагностические данные. Для совместимости валидаторам необходимо обновить все внешние инструменты трассировки и аналитики, использующие эти журналы. После обновления следует удалить существующие данные трассировки, чтобы избежать несовпадения форматов.
• Улучшения CLI: добавлена команда withdraw-stake AVAILABLE, упрощающая вывод всех лампортов, не участвующих в стейкинге. Кроме того, solana-test-validator теперь по умолчанию привязывает сервисы RPC к localhost (127.0.0.1) для повышения безопасности.
• Более быстрый запуск: время запуска валидатора значительно сократилось. Теперь запуск ноды и загрузка реестра занимают около 3 минут, а синхронизация с вершиной блокчейна — примерно 5 минут. Однако для быстрой загрузки теперь требуется корректное завершение работы с новым флагом --wait-for-exit. Перед перезапуском операторы должны дождаться полного самостоятельного завершения процесса валидатора, а не отправлять команду немедленного перезапуска.

Заключение

Agave 2.3 — ещё один важный этап развития протокола Solana. Среди ключевых нововведений — запуск нового клиента TPU (`tpu-client-next`), значительное сокращение дискового ввода-вывода благодаря оптимизации AccountsDB, улучшенная производительность снапшотов, обновления сети gossip, а также более быстрые переходы между эпохами и запуск. Все эти изменения повышают надёжность сети и улучшают опыт разработчиков и операторов валидаторов.

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

Далее — Agave 3.0!

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

• График выпуска Agave 2.3
• Журнал изменений Agave 2.3
• Запросы на слияние Agave 2.3
• Примечания к обновлению Agave 2.3 — блог Anza 
• Презентация tpu-client-next — звонок сообщества Solana Core, 20 июня 2025 года