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

Важные обновления цикла выпуска Agave 2.1 

• Масштабная оптимизация производительности
• Увеличение лимитов блока
• Внедрение жадного планировщика (экспериментальная функция)
• Нативная поддержка проверки подписей Secp256r1 (обновление: перенесено на Agave 2.2)
• Отключение сбора арендной платы и перезаписи данных для аренды
• Смягчение ограничений при сбоях загрузки транзакций
• Перенос программ config и address look-up table в core BPF

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

Развертывание функций

На момент написания статьи 88% стейка уже работает на Agave версии 2.1.11. Активацию функций через feature gate в mainnet временно приостановили, чтобы ускорить переход на v2.1. Ожидается, что она вскоре возобновится в соответствии с запланированным порядком активации. 

Большинство новых полноценных функций, описанных в следующих разделах, пока недоступны. Ожидается, что их развернут в течение цикла выпуска 2.1 с помощью системы feature gate. Функции активируются в определенные эпохи с учетом относительного приоритета и порядка их активации в кластерах testnet и devnet.

Повышение производительности

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

Время блока

Благодаря ускорению создания блоков в Solana среднее время слота снизилось до менее чем 400 мс. Последние эпохи завершаются менее чем за два дня — это самый высокий показатель скорости в истории сети. Оба клиента готовы к дальнейшему сокращению времени блока. Такое ускорение не только повышает пропускную способность транзакций. Вознаграждения за стейкинг связаны с инфляционной эмиссией, которая рассчитывается по «эпохальным годам», а не по календарным. Поэтому валидаторы и участники стейкинга получают дополнительную выгоду. Эпохальный год включает 182,5 эпохи исходя из стандартной продолжительности эпохи в два дня. Чем короче эпохи, тем больше их укладывается в один и тот же период. Это фактически увеличивает скорость распределения вознаграждений за стейкинг.

Время безотказной работы

На протяжении 2024 и в начале 2025 года Solana демонстрировала почти идеальную надежность: сеть работала без сбоев более года. Последний зафиксированный сбой произошел 6 февраля 2024 года, когда известная ошибка временно нарушила финализацию блоков в Mainnet. Проблему быстро выявили и исправили. С тех пор Solana бесперебойно создает блоки даже в периоды чрезвычайно высокой сетевой активности — например, во время недавнего всплеска, вызванного запуском токенов семьи Трампа. Это подтверждает устойчивость сети к высокой нагрузке.

Доля пропущенных слотов

Доля пропущенных слотов показывает, как часто валидатор, назначенный лидером определенного слота, не успевает создать блок за отведенное время. Примерно с эпохи 700 в ноябре 2024 года доля пропущенных слотов резко снизилась. Несколько лет она колебалась от 2% до 5%, но теперь у большинства хорошо оптимизированных валидаторов приблизилась к нулю.  

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

Кроме того, Timely Vote Credits (TVC), внедренные в ноябре 2024 года, мотивируют валидаторов своевременно голосовать и препятствуют задержке голосов. Сокращая число валидаторов, которые намеренно удерживают голоса, TVC ускоряет сходимость кластера, подтверждение и финализацию. Этот механизм помогает свести к минимуму форки и сократить их продолжительность. Поскольку оценка TVC теперь влияет на рейтинг пулов стейкинга, операторы обновляют оборудование и оптимизируют конфигурации валидаторов для повышения производительности.

Число транзакций в секунду (TPS)

Более высокое число транзакций в секунду (TPS) указывает на рост пропускной способности блокчейна. TPS Solana без учета голосов (также «реальный TPS») стабильно растет с конца 2023 года. Последние данные за первую неделю февраля 2025 года показывают, что среднее значение сети на 50-м процентиле составило 1 228 TPS, а пиковая производительность на 99-м процентиле достигла 2 520 TPS.  

Исторический максимум TPS зафиксировали в неделю аирдропа токена PENGU, завершившуюся 23 декабря 2024 года. Тогда среднее значение на 50-м процентиле составило 1 260 TPS, а пиковое значение на 99-м процентиле достигло 3 252 TPS. Этот устойчивый рост подчеркивает постоянное масштабирование Solana и повышение эффективности обработки транзакций.

Приоритетные комиссии

Наконец, сравнение приоритетных комиссий, собранных Agave 2.1 и предыдущей версией 2.0 с 27 января по 4 февраля 2025 года, показывает, что Agave 2.1 стабильно собирает немного более высокие приоритетные комиссии.

Повышение лимитов блока

Увеличение лимитов блока, предложенное в SIMD-0207: повышение лимита блока до 50M, запланировано на цикл выпуска Solana 2.1. Сейчас протокол ограничивает общий объем вычислительных ресурсов на блок до 48 миллионов Compute Units (CU). Лимиты блока позволяют нодам успевать за сетью, ограничивая объем работы, который лидер может включить в блок. Команда основателей эмпирически определила текущий лимит с учетом объема данных, который валидаторы могут обрабатывать при времени блока в 400 миллисекунд. 

Однако текущая активность mainnet не ограничена временем выполнения. Поэтому блоки могут включать больше транзакций без превышения целевого показателя в 400 мс. Это обновление предусматривает умеренное увеличение на 4%, чтобы постепенно наращивать пропускную способность сети: лимит вычислений на блок вырастет с 48M до 50M CU. Более значительное увеличение, например удвоение лимита, возможно, но его сочли слишком рискованным для первого изменения. Расширение лимитов блока влияет не только на валидаторов, но и на критически важную инфраструктуру: RPC-ноды, индексаторы и архивные сервисы. Они должны масштабироваться соответствующим образом.

Другие ограничения протокола не изменятся:

• Лимит вычислений на аккаунт в одном блоке останется на уровне 12M CU.
• Максимальный объем вычислений на транзакцию останется на уровне 1,4M CU.

В дальнейшем ожидается дополнительное повышение лимитов блока в рамках формального процесса SIMD.

Жадный планировщик

Предыстория: центральный планировщик

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

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

Более подробный обзор Agave 1.18 и реализации центрального планировщика приведен в нашей предыдущей статье в блоге Helius.

Новый жадный планировщик

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

• Сначала выбирается транзакция с наивысшим приоритетом.
• Если транзакция не конфликтует с обрабатываемым пакетом, она добавляется в одну из четырех очередей рабочих потоков.
• При возникновении конфликтов текущий пакет финализируется и отправляется на обработку, а транзакция добавляется в новый пакет.

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

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

Рассмотрим сценарий, в котором транзакции разделены на три конфликтующие группы: A, B и C. Транзакции конфликтуют, если одна из них пытается записать данные в аккаунт, который другая транзакция хочет прочитать или изменить. У транзакций группы A приоритетные комиссии выше, чем у транзакций групп B и C.

• Центральный планировщик объединит неконфликтующие транзакции A1, B1 и C1 в один пакет: [A1, B1, C1].
• Жадный планировщик сначала обрабатывает транзакции с наибольшей комиссией. Он планирует A1 как отдельный пакет, а затем переходит к A2 в следующем пакете.

Такая приоритизация ускоряет планирование, но может приводить к формированию меньших пакетов по сравнению с центральным планировщиком.

Нативная программа для проверки подписей Secp256r1

Solana внедряет новую нативную программу для проверки подписей на эллиптической кривой secp256r1. Она добавляет ончейн-поддержку Passkeys, стандарта WebAuthn и новых моделей абстракции аккаунтов, включая двухфакторную аутентификацию (2FA). Это улучшение позволит использовать беспарольную аутентификацию, уже широко распространенную в Web2, в качестве второго фактора ончейн-безопасности.

Эллиптическая кривая secp256r1 — стандартизированная NIST криптографическая кривая. Она широко поддерживается современными устройствами, в том числе:

• WebAuthn: стандарт W3C для аутентификации на основе криптографии с открытым ключом, который поддерживают все основные браузеры.
• Apple Secure Enclave: аппаратная доверенная среда выполнения (TEE), которая подписывает сообщения и доступна только после биометрической аутентификации.
• Android Keystore: API для управления закрытыми ключами и методами подписания, использующий TEE устройства для безопасного хранения ключей.
• Passkeys: стандарт FIDO Alliance и W3C, который заменяет пароли криптографическими парами ключей и совместим с криптографией на эллиптических кривых.

Несколько других сетей, включая Ethereum (EIP-7212), также изучали возможность интеграции поддержки кривой secp256r1.

Сведения о программе Secp256r1

Новая программа будет развернута с идентификатором: Secp256r1SigVerify1111111111111111111111111

Структура инструкции:

• Счетчик u8 указывает количество подписей для проверки.
• Затем следует один байт заполнения.
• Для каждой подписи используется следующая сериализованная структура:

struct Secp256r1SignatureOffsets {
    signature_offset: u16,             // offset to secp256r1 signature of 64 bytes
    signature_instruction_index: u16,  // instruction index to find signature
    public_key_offset: u16,            // offset to public key of 32 bytes
    public_key_instruction_index: u16, // instruction index to find public key
    message_data_offset: u16,          // offset to start of message data
    message_data_size: u16,            // size of message data
    message_instruction_index: u16,    // index of instruction data to get msg data
}

Это обновление основано на предложении команды Bunkr SIMD-0048: нативная программа для Secp256r1 Sigverify. Secp256r1 SigVerify Precompile Program будет работать аналогично существующей в Solana поддержке secp256k1 и подписей ed25519.

Отключение сбора арендной платы и пропуск перезаписей для аренды

Два связанных обновления, предложенных в SIMD-0084: отключение сбора арендной платы и SIMD-0183: пропуск перезаписей для аренды, устранят значительную часть устаревших накладных расходов, связанных с аккаунтами, которые платят аренду.

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

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

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

Смягчение ограничений транзакций: сбои загрузки

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

Создание блоков также усложняет необходимость отфильтровывать транзакции, которые вызывают недопустимые программы или превышают максимальный лимит загружаемых данных аккаунтов в 64 MiB (~67,11 MB). Эти ограничения усложняют сборку блоков и проверку их валидности. Если смягчить эти ограничения, транзакции можно будет включать в блок и взимать за них комиссию без предварительной загрузки и проверки данных программы. Это изменение призвано устранить зависимость проверки блока от состояния аккаунтов.

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

Перенос программ Config и Address Look-Up Table в Core BPF

В рамках продолжающегося перехода от встроенных нативных программ к программам Berkeley Packet Filter (BPF) программы Config и Address Lookup Table будут перенесены в Core BPF. Этот переход отделит критически важные программы от среды выполнения валидатора, упростив их обновление и обслуживание.

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

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

Заключение

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

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

• Репозиторий клиента Agave
• График выпуска Agave v2.1
• Запросы на включение изменений Agave v2.1 с тегами