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

Введение

Крупный выпуск Agave v3.0 стал очередной важной вехой для Solana. Он включает ряд обновлений, направленных на повышение производительности сети, оптимизацию работы валидаторов и улучшение опыта разработчиков.

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

• Переработка кеша: ускоряет обработку транзакций на 30–40%
• Повышенный лимит вычислений для одной учетной записи: повышает лимит одной учетной записи до 40% CU блока
• Новая структура планировщика TransactionView: повышает эффективность планирования
• eXpress Data Path (XDP) для Turbine: обязательное условие для блоков на 100 миллионов CU
• Увеличенная глубина вложенности CPI: повышает лимит вложенности CPI с 4 до 8
• Ослабление ограничений для записей: упрощает логику планирования и необходимо для асинхронного выполнения
• Ускоренный запуск: ноды теперь быстрее возвращаются в сеть
• Спецификация размера загруженных данных транзакций: стандартизирует расчет объема загруженных данных транзакций
• Улучшения RPC: более быстрые и надежные обновления в реальном времени для dApps, использующих PubSub WebSockets

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

Тенденции, связанные с клиентами

Прежде чем подробно рассматривать новые функции Agave v3.0, разберем, как свежие данные отражают прогресс сети Solana и клиента Agave: ускорение циклов выпуска, более широкое внедрение клиентов и устойчивую производительность при высокой нагрузке.

Периодичность выпусков Agave

В этом году Anza заметно ускорила выпуск обновлений, сократив интервал между минорными версиями Agave до менее чем трех месяцев. Серия Agave 2.2.* оставалась версией сверхбольшинства всего 11 недель, и Agave 2.3 следует похожему графику.

Сеть с несколькими клиентами

За последние месяцы внедрение Firedancer в основной сети значительно продвинулось. Сейчас 21,6% стейка работает на клиенте Jito-Frankendancer. В течение года этот показатель медленно, но стабильно рос (см. график ниже). Ожидается, что внедрение останется на уровне около 20%, пока полноценный клиент Firedancer не будет готов к промышленному развертыванию в основной сети.

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

Также примечательно, что доля стейка на стандартном клиенте Agave, то есть Agave без сторонних MEV-модификаций наподобие Jito, снизилась примерно с 6% в начале года до приблизительно 2% сегодня. Тем временем внедрение Paladin-Agave в последние месяцы выросло, и теперь на него приходится около 6% общего стейка.

Стресс-тест сети

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

На пике Solana выдерживала шестикратное превышение обычного объема трафика: лидеры принимали около 100 000 пакетов транзакций в секунду, одновременно создавая полные блоки с лимитом 60 миллионов CU.

Даже в этих условиях Solana демонстрировала наиболее стабильную динамику комиссий среди всех крупных сетей, обрабатывая при этом на порядок больше транзакций. Реальный TPS (без учета голосующих транзакций) на пике активности превысил 3 200.

В течение примерно двухчасового пикового периода медианная комиссия за транзакцию (P50) в Solana выросла лишь до $0,007 — менее одного цента. Средняя комиссия ненадолго достигла $0,10, а для верхнего 1% транзакций (P99) пиковое значение лишь немного превысило $1,00. Такая динамика демонстрирует эффективность локальных рынков комиссий, благодаря которым высокие комиссии затронули только транзакции, взаимодействовавшие с востребованными учетными записями, за доступ к которым шла конкуренция. Обычные пользователи, выполнявшие простые переводы, например платежи в стейблкоинах, изменений не заметили.

Для сравнения: в основной сети Ethereum и Arbitrum медианная комиссия за транзакцию за тот же период ненадолго превысила $100. В управляемой Coinbase сети L2 Base также наблюдался скачок: медианная комиссия достигла пикового значения выше $3. В этих сетях нет локальных рынков комиссий, поэтому глобальные корректировки комиссий при высокой нагрузке одинаково повышают расходы для всех пользователей.

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

Недавно Solana преодолела важный рубеж роста ончейн-состояния: общее число учетных записей превысило 1 миллиард. Почти 67% этих учетных записей принадлежат Token Program, из них 89,45% — связанные учетные записи токенов, а 10,55% — учетные записи выпуска токенов.

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

Обновления цикла выпуска Agave 3.0

Переработка кеша

Agave 3.0 значительно сокращает количество избыточных операций среды выполнения. Полная переработка кеша программ устраняет сотни лишних обращений к учетным записям на каждый пакет транзакций. Во внутренних тестах это ускорило обработку транзакций примерно на 30–40%.

Повышение лимита учетной записи до 40% CU блока

В рамках цикла выпуска Agave 3.0 в Solana будет активирован документ SIMD-0306: повышение лимитов CU для учетной записи. Он повышает лимит CU на учетную запись с фиксированных 12 млн до 40% лимита CU блока. Сейчас каждая учетная запись может потреблять до 12 миллионов CU на блок. Как видно на приведенном ниже графике Anza, наиболее востребованные учетные записи, за доступ к которым идет конкуренция, часто достигают этого потолка.

После этого изменения лимит на учетную запись сначала вырастет с 12 до 24 миллионов CU, а после активации SIMD-0286 (блоки на 100 млн CU) — до 40 миллионов CU. Вместе с такими обновлениями, как внедрение программы P-token, это значительно повысит пропускную способность для востребованных учетных записей, к которым часто обращаются внутри каждого блока.

Другие ограничения останутся без изменений, включая:

• Максимальное число единиц голосования: лимит общего количества CU голосующих транзакций на блок — 36 миллионов CU
• Максимальное изменение размера данных учетных записей в блоке: лимит общего объема изменений данных учетных записей на блок — 100 мегабайт.

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

Наконец, стоит отметить недавнее предложение SIMD-0370: удаление лимита вычислительных единиц блока. В нем рассматривается полный отказ от лимитов блока на основе CU. Вероятно, к этому направлению вернутся после обновления Alpenglow.

eXpress Data Path (XDP) для Turbine

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

Поддержка XDP в Turbine впервые появилась в Agave v2.3.8, а начиная с Agave 3.1 она будет включена по умолчанию. При увеличении лимитов блоков до 100 млн CU Turbine становится главным узким местом масштабирования. Лидеры передают свои шреды 200 пирам, создавая высокую сетевую нагрузку. В текущих условиях крупные валидаторы с большим числом лидерских слотов могут отправлять почти 150 000 пакетов в секунду. XDP напрямую устраняет это узкое место и ускоряет отправку пакетов до 100 раз, позволяя валидаторам гораздо эффективнее распространять более крупные блоки. 

Читатели, которые хотят подробнее изучить реализацию XDP в Agave, могут обратиться к руководству по настройке валидатора и нашему предыдущему интервью с инженером Anza Alessandro Decina, который руководил интеграцией XDP в клиент Agave.

Спецификация размера загруженных данных транзакций

В рамках продолжающейся работы по упрощению и стандартизации модели выполнения Solana документ SIMD-0186: спецификация размера загруженных данных транзакций планируется активировать в основной сети в течение цикла выпуска Agave 3.0.

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

Сейчас логика определения размера данных транзакций в Solana чрезмерно сложна. Текущая реализация нестандартно обрабатывает программы LoaderV3 и BPF Upgradeable Loader, из-за чего фактический размер загруженных данных программ часто занижается. Эти расхождения затрудняли реализацию совместимой логики независимыми командами клиентов.

В SIMD-0186 правила определения размера сформулированы явно и понятны:

• Каждая загруженная учетная запись учитывается ровно один раз
• Для программ, использующих BPF Upgradeable Loader, учитываются связанные с ними данные программы
• Размер каждой загруженной учетной записи определяется как длина ее данных в байтах до выполнения транзакции плюс 64 байта метаданных
• Каждая таблица поиска адресов (ALT) добавляет фиксированные 8 248 байт

Эта спецификация стандартизирует определение размера транзакций во всех клиентах и делает поведение транзакций более предсказуемым для разработчиков.

Лимит размера загруженных данных выполняет ту же функцию, что и лимит CU на транзакцию: обеспечивает предсказуемый учет ресурсов валидаторных нод. По умолчанию каждая транзакция может загрузить до 64 МБ данных учетных записей, расходуя восемь вычислительных единиц (CU) на каждые загруженные 32 КБ. Это соответствует базовой стоимости в 16 000 CU, даже если фактически загружается меньше данных. Разработчики могут снизить этот лимит с помощью инструкции setLoadedAccountsDataSizeLimit, чтобы сократить вычислительные затраты и повысить эффективность планирования.

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

Структура планировщика TransactionView

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

Ускоренный запуск

В выпуске Agave v3.0 производительность запуска клиента продолжает улучшаться. Это заметно упрощает работу операторов валидаторов и RPC. После сбоя, обновления или планового обслуживания ноды теперь могут возвращаться в сеть значительно быстрее.

При запуске из архива снимка время запуска сократилось до менее чем трех с половиной минут — это меньше половины времени, необходимого в Agave v2.2 (см. график ниже). Такое улучшение критически важно для производительности: ускоренный запуск напрямую повышает устойчивость сети и время безотказной работы валидаторов, поскольку ноды быстрее возвращаются к участию в консенсусе.

В Agave v3.1 этот процесс упростится еще больше благодаря удалению фоновой проверки учетных записей. Валидаторы смогут начинать голосование сразу после запуска воспроизведения.

Повышение лимита вложенности CPI

Документ SIMD-0268: повышение лимита вложенности CPI увеличивает максимальную глубину вызовов Cross-Program Invocation (CPI) с 4 до 8. Фактически это удваивает количество вызовов других программ, которые программа Solana может выполнить в рамках одной транзакции.

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

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

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

Ослабление ограничений для записей

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

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

Улучшения RPC

Agave v3.0 повышает скорость отклика сервера подписок. Теперь он отдает приоритет входящим сообщениям, таким как запросы на подписку и PING, перед исходящими уведомлениями. Это обеспечивает более быстрые и надежные обновления в реальном времени для dApps, использующих PubSub WebSockets.

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

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

• Начиная с Agave v3.0.0, Anza прекратила публиковать предварительно собранные бинарные файлы agave-validator. Теперь операторы валидаторов должны самостоятельно компилировать бинарные файлы из исходного кода, следуя предоставленным инструкциям по сборке.
• В Agave v3.0 интервал создания снимков по умолчанию увеличен до одного снимка каждые 100 000 слотов — по сравнению с 50 000 в v2.3 и 25 000 в v2.2. Увеличение интервала значительно повышает производительность диска и сокращает скачки IOPS (операций ввода-вывода в секунду) при создании снимков.
• Удалено множество устаревших аргументов и флагов CLI (полный список).
• Сейчас инструкция advance nonce в транзакции может указать любую учетную запись этой транзакции как учетную запись для увеличения nonce. После активации функционального переключателя для SIMD-0242: только статическая учетная запись nonce инструкция advance nonce сможет увеличивать nonce только для статически включенной учетной записи.

Заключение

Agave v3.0 — крупное обновление клиента, которое ускоряет обработку транзакций, повышает вычислительные лимиты, улучшает эффективность планировщика и добавляет ряд оптимизаций для валидаторов и RPC. Вместе эти обновления повышают производительность сети и улучшают опыт разработчиков.

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

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

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