Большое спасибо 0xIchigo и Брайану Вонгу за рецензирование ранних версий этой работы.
Введение
Основной релиз Agave v3.0 отмечает еще один этап для Solana, представляя ряд обновлений, направленных на улучшение производительности сети, операций валидаторов и опыта разработчиков.
Значительные обновления Agave 3.0
Переработка кеша: обеспечивает обработку транзакций на 30–40% быстрее
Повышенный лимит вычислений для одной учетной записи: увеличивает лимит для одной учетной записи до 40% от CUs блока
Новая структура Scheduler 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 на mainnet значительно продвинулось в последние месяцы. На данный момент 21,6% стейка выполняют клиент Jito-Frankendancer — эта доля медленно и стабильно росла в течение всего года (см. график ниже). Ожидается, что внедрение будет оставаться около порога в 20%, пока полный клиент Firedancer не будет готов к промышленному развертыванию на mainnet.
Это важная веха для многоклиентской стратегии Solana — давней цели, направленной на повышение безопасности сети, живучести и устойчивости. Увеличение разнообразия клиентов дает операторам валидаторов больше выбора, стимулирует здоровую конкуренцию между командами клиентов и привлекает больше внимания к кодовым базам клиентов. Это также снижает риск того, что один критический баг вызовет аварийную остановку всей сети.
Также примечательно, что доля стейка, работающего на «ванильном» клиенте Agave (то есть Agave без сторонних модификаций MEV, таких как Jito), снизилась с примерно 6% в начале года до около 2% сегодня. Между тем внедрение Paladin-Agave в последние месяцы выросло и теперь составляет примерно 6% от общего стейка.
Тест сетевого стресса
10 октября крипторынок столкнулся с крупнейшим в своей истории событием ликвидации, вызвав экстремальную волатильность во всех крупных блокчейнах. Несмотря на рекордный всплеск активности сети, сеть Solana и клиент-валидатор Agave продемонстрировали впечатляющую устойчивость и стабильность под нагрузкой.
В пиковые моменты Solana поддерживала шестикратный объем трафика от нормы: лидеры принимали около 100 000 пакетов транзакций в секунду, при этом формируя полные блоки на лимите 60 миллионов CU.
Даже в этих условиях Solana демонстрировала самые стабильные динамики комиссий среди любых крупных сетей при обработке на порядок более высокой пропускной способности. Реальная пропускная способность (не vote-транзакции) превышала 3 200 на пике активности.
В течение примерно двухчасового пикового окна медианная комиссия Solana (P50) по транзакциям выросла лишь до $0.007 — меньше одного цента. Средние комиссии кратковременно достигали $0.10, а верхние 1% транзакций (P99) — чуть выше $1.00. Такой паттерн демонстрирует эффективность локальных рынков комиссий: высокие комиссии удерживались только транзакциями, которые взаимодействовали с оспариваемыми горячими аккаунтами, тогда как обычные пользователи, выполняющие простые переводы (например, платежи в стейблкоинах), не испытывали влияния.
Для сравнения: в Ethereum mainnet и Arbitrum медианные комиссии кратковременно превышали $100 за транзакцию за тот же период. L2 Base, управляемая Coinbase, также пережила всплески комиссий: медианная комиссия достигала пика более чем $3. Эти сети не имеют локальных рынков комиссий: они применяют глобальные корректировки комиссий, которые равномерно повышают расходы для всех пользователей во время сетевого стресса.
Рост состояния
Solana недавно перешла важную веху в росте on-chain состояния, превысив 1 миллиард общих аккаунтов. Около 67% из них принадлежат Token Program, из которых 89,45% — это token accounts и 10,55% — аккаунты mint токенов.
Это постепенное расширение объема состояния имеет долгосрочные последствия для клиентов Solana и поставщиков инфраструктуры. По мере роста числа аккаунтов растет и потребность в хранении, размере снапшотов и индексации аккаунтов — всё это может влиять на производительность и требования к оборудованию. Такие решения, как ZK Compression, предлагают многообещающий долгосрочный путь для уменьшения разрастания состояния.
Обновления цикла релиза Agave 3.0
Переработка кеша
Agave 3.0 существенно сокращает избыточные операции в runtime. Полная переработка кэша программ устраняет сотни лишних обращений к аккаунтам на каждую партию транзакций, что приводит примерно к 30–40% более быстрой обработке транзакций во внутренних бенчмарках.
Увеличить лимит аккаунтов до 40% CU блока
В рамках цикла релиза Agave 3.0 Solana активирует SIMD-0306: Raise Account CU Limits. Это увеличивает лимит CU на аккаунт с фиксированной константы 12M до 40% от лимита CU блока. В настоящее время каждый аккаунт может потреблять до 12 миллионов CUs на блок. Как показано на приведенном ниже графике от Anza, наиболее сильно оспариваемые аккаунты часто упираются в этот потолок.
С этим изменением лимит на одну учетную запись сначала вырастет с 12 миллионов до 24 миллионов CU, а в дальнейшем — до 40 миллионов CU после активации SIMD-0286 (100M CU blocks). В сочетании с обновлениями вроде введения программы P-token это существенно увеличит пропускную способность для «горячих» аккаунтов, которые часто используются в каждом блоке.
Остальные ограничения останутся без изменений, включая:
Max Vote Units: ограничение на общее число CU в vote-транзакциях на блок — 36 миллионов CU
Max Block Accounts Data Size Delta: лимит на суммарные изменения данных аккаунтов за блок — 100 мегабайт.
Хотя повышение верхней планки CU на аккаунт улучшает пропускную способность для горячего состояния, это также может увеличить худшее время сериализованного выполнения, потенциально удлиняя проверку блока или длительность слота в сценариях высокой нагрузки.
Наконец, стоит отметить недавнее предложение SIMD-0370: Remove Compute Unit Block Limit, которое рассматривает полное устранение лимитов блоков, основанных на CU. Скорее всего, этот подход будет пересмотрен после обновления Alpenglow.
eXpress Data Path (XDP) для Turbine
eXpress Data Path (XDP) — это технология ядра Linux, предназначенная для высокопроизводительных сетей. Она позволяет приложениям обходить значительную часть стандартного пути обработки пакетов в ядре, уменьшая как число промежуточных копирований данных, так и количество переключений контекста между пользовательским пространством и пространством ядра. Обрабатывая пакеты напрямую с сетевой интерфейсной картой (NIC) в пользовательском пространстве, XDP радикально снижает накладные расходы на пакет.
Поддержка XDP в Turbine впервые была добавлена в Agave v2.3.8 и включится по умолчанию начиная с Agave 3.1. Turbine — основной узкий участок масштабирования, поскольку лимиты блоков растут до 100M CU. Лидеры пересылают свои shreds 200 пирами, создавая сильную сетевую нагрузку. Крупные валидаторы с большим числом слотов лидера могут приближаться к 150 000 исходящих пакетов в секунду при текущих условиях. XDP напрямую решает эту проблему: диспетчеризация пакетов становится до 100 раз быстрее, что позволяет валидаторам гораздо эффективнее распространять более крупные блоки.
Тем, кто заинтересован в более глубоком изучении реализации XDP в Agave, можно обратиться к руководству по настройке валидатора и к нашему более раннему интервью с инженером Anza Алессандро Дечиной, который руководил интеграцией XDP в клиент Agave.
Спецификация размера загруженных данных транзакций
В рамках постоянных усилий по упрощению и стандартизации модели исполнения Solana SIMD-0186: Loaded Transaction Data Size Specification, задано для активации на mainnet во время цикла релизов Agave 3.0.
Это вводит безопасный для консенсуса способ вычисления общего объема данных аккаунтов, загруженных каждой транзакцией. Цель — гарантировать, что все клиенты валидаторов вычисляют идентичные размеры данных транзакций, устраняя скрытые несоответствия, которые иначе могли бы привести к расхождению консенсуса.
В настоящее время логика Solana по определению размера данных транзакций чрезмерно сложна. Существующая реализация отличается своеобразным подходом к обработке программ LoaderV3 и BPF Upgradeable Loader, из‑за чего они зачастую занижают фактический размер загруженных данных программы. Эти расхождения затрудняли для независимых команд клиентов внедрение совместимой логики.
Под SIMD-0186 правила определения размера теперь явные и их легко анализировать:
Каждый загруженный аккаунт учитывается ровно один раз
Программы, использующие BPF Upgradeable Loader, включают вместе с собой связанную с ними программную data
Размер каждого загруженного аккаунта определяется как длина его данных в байтах до выполнения транзакции, с добавлением 64 байт для метаданных
Таблицы поиска адресов (ALTs) добавляют по 8 248 байт каждая
Эта спецификация стандартизирует определение размера транзакций во всех клиентах и делает поведение транзакций более предсказуемым для разработчиков.
Лимит размера загруженных данных выполняет схожую роль с лимитом CU на транзакцию, обеспечивая предсказуемый учёт ресурсов для узлов валидаторов. По умолчанию каждая транзакция может загружать до 64 МБ данных аккаунтов, потребляя восемь compute units (CUs) на каждые 32 КБ загруженных данных, что соответствует базовой стоимости 16 000 CUs, даже если фактически загружено меньше данных. Разработчики могут снизить этот лимит через инструкцию setLoadedAccountsDataSizeLimit, чтобы уменьшить вычислительную стоимость и повысить эффективность планирования.
Поскольку новый метод определения размера может давать разные значения в зависимости от структуры транзакции, разработчикам может понадобиться настроить лимит размера данных загруженных аккаунтов, указанный в их инструкциях compute budget.
Структура Scheduler TransactionView
С Agave 3.0 планировщик вводит новую легковесную структуру данных TransactionView, предназначенную для упрощения того, как транзакции парсятся и обрабатываются. В отличие от более старых типов транзакций SDK, которые требовали десериализации и нескольких выделений памяти, TransactionView предоставляет прямой взгляд на сериализованную транзакцию. Он парсит и кэширует метаданные о компоновке транзакции, не выполняя фактическую десериализацию.
Более быстрые времена запуска
Производительность запуска клиента продолжает улучшаться с выпуском Agave v3.0 — это заметное улучшение уровня «качество жизни» для операторов валидаторов и RPC. Независимо от того, перезапускаетесь ли вы после сбоя, обновления или запланированного обслуживания, узлы теперь возвращаются в онлайн заметно быстрее.
Начиная с архивов снапшотов, времена запуска сокращены до менее чем трех с половиной минут — это меньше половины времени, необходимого при Agave v2.2 (см. график ниже). Это улучшение является критически важным приростом производительности: более быстрый запуск напрямую повышает устойчивость сети и время доступности валидаторов, сокращая период, за который узлы возвращаются к участию в консенсусе.
В перспективе Agave v3.1 упростит этот процесс еще больше за счет устранения проверки аккаунтов в фоне — это позволит валидаторам начать голосование сразу после начала реплея.
Увеличить лимит вложенности CPI
SIMD-0268: Raise CPI Nesting Limit увеличивает максимальную глубину вызовов Cross-Program Invocation (CPI) с 4 до 8. По сути, это удваивает число раз, когда программа Solana может вызывать другие программы внутри одной транзакции.
CPI — это механизм, с помощью которого одна программа Solana вызывает другую. Это фундаментальная возможность runtime Solana, позволяющая программам строить логику поверх логики друг друга.
Сложные on-chain протоколы вроде перпетуальных свопов, смарт-кошельков и систем cross-margin часто полагаются на несколько уровней взаимодействия программ, чтобы управлять позициями, ликвидациями и рисками. Предыдущий лимит CPI на 4 уровня ограничивал такие дизайны, и в некоторых случаях вынуждал разработчиков разносить логику по нескольким транзакциям.
Существующие приложения продолжат работать как раньше (если только они не опираются на старый лимит в своей логике, чтобы намеренно проваливать транзакции). В целом это часто запрашиваемое изменение расширяет пространство для проектирования разработчиков и укрепляет компонуемость Solana.
Ослабить ограничения входа
SIMD-0083: Ослабить ограничения входа, запланировано к активации в Agave 3.0, убирает правило, согласно которому транзакции при входе в блок не должны конфликтовать друг с другом. Раньше любая запись, содержащая конфликтующие транзакции (то есть те, которые одновременно записывают в один и тот же аккаунт, или когда одна читает, а другая пишет), приводила к недействительности всего блока.
С этим обновлением такие конфликты теперь допускаются. Если они возникают, транзакции просто выполняются последовательно в том порядке, в котором они отображаются. Это упрощает правила упаковки блоков, давая лидерам больше гибкости при упорядочивании транзакций и построении блока. Также это необходимое изменение, чтобы Solana могла реализовать асинхронное выполнение.
Улучшения RPC
Agave v3.0 добавляет улучшения отзывчивости в сервер подписок: теперь он отдает приоритет входящим сообщениям, таким как запросы подписки и PING, над исходящими уведомлениями. Это изменение обеспечивает более быстрые и надежные обновления в реальном времени для dApps, использующих PubSub WebSockets.
Кроме того, свойства слота добавлены в данные об ошибках epoch rewards, улучшая отладку и наблюдаемость для разработчиков.
Другие изменения
Начиная с Agave v3.0.0, Anza прекратила публикацию заранее собранных бинарников agave-validator. Операторам валидаторов теперь нужно компилировать бинарники из исходников, следуя инструкциям по сборке, которые предоставляются.
С Agave v3.0 интервал снапшотов по умолчанию увеличен до каждого 100 000 слотов (с 50 000 в v2.3 и 25 000 в v2.2). Увеличение интервала заметно улучшает производительность диска, уменьшая всплески IOPS (input/output operations per second) во время создания снапшотов.
Был удален ряд устаревших старых аргументов CLI и флагов (полный список здесь).
В настоящее время инструкция advance nonce в транзакции может указывать любой аккаунт в транзакции как аккаунт для advance. После активации feature gate для SIMD-0242: Static Nonce Account Only эта инструкция будет ограничена возможностью advance только статически включенного аккаунта.
Итог
Agave v3.0 — это существенное обновление клиента: оно вводит более быструю обработку транзакций, более высокие лимиты вычислений, улучшенную эффективность планировщика, а также набор оптимизаций для валидаторов и RPC. Вместе эти изменения укрепляют как производительность сети, так и удобство для разработчиков.
Данные дополнительно подтверждают этот прогресс: более быстрые циклы релизов, растущее разнообразие клиентов и исключительная стабильность сети при пиковой нагрузке — всё это подчеркивает «взросление» Solana. Теперь сеть работает на Agave 3.0, и Solana продолжает доказывать свою способность масштабироваться.