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

Краткий обзор Agave 2.0

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

• Масштабный рефакторинг и оптимизация кодовой базы
• Распределённые по эпохе вознаграждения
• Выплата валидаторам полной комиссии за приоритет
• Новый центральный планировщик теперь включён по умолчанию
• Программа ZK ElGamal Proof
• Системный вызов Get-Sysvar
• Системный вызов GetEpochStake
• MoveStake и MoveLamports
• Удаление устаревших методов RPC
• Переименование крейтов

Этот подробный обзор обновления Agave 2.0 поможет вам понять и использовать последние нововведения — независимо от того, управляете ли вы валидатором, разрабатываете на платформе или активно пользуетесь Solana.

Почему Agave 2.0 считается мажорным обновлением?

Единого «валидатора Solana» больше нет. Agave 2.0 соответствует новой модели Solana с несколькими клиентами и окончательно отделяется от старого репозитория Solana Labs на GitHub. Репозиторий Solana Labs будет архивирован и перестанет принимать новые запросы на включение изменений и сообщения о проблемах. Ранее этот репозиторий зеркалировал активность из репозитория Agave. Если разработчики ещё не перенесли свою работу в репозиторий Anza Agave на GitHub, им следует это сделать. Процесс миграции с Solana Labs на Agave начался 1 марта и публично отслеживается на GitHub.

По мере развития экосистемы операторам необходимо адаптироваться к работе с одним или несколькими клиентами. В связи с этим несколько крейтов переименовывают, освобождая пространство имён для поддержки нескольких клиентов — прежде всего Firedancer, который разрабатывает независимая команда. Крейты, поддерживаемые Anza, теперь будут иметь префикс "agave", поэтому их легко определить как зависимости Anza в среде с несколькими клиентами.

‍Изменения затронут следующие крейты: 

• solana-validator
• solana-ledger-tool
• solana-watchtower
• solana-install
• solana-geyser-plugin-interface
• solana-cargo-registry

Как указано в нашем предыдущем руководстве по переходу, обновление 2.0 содержит несколько несовместимых изменений. Главное из них — удаление нескольких неактуальных и устаревших эндпоинтов. Все разработчики Solana уже должны знать об этих ключевых изменениях. Полный список изменений RPC приведён в конце статьи.

Внедрение функций

На момент написания статьи версия 2.0.14 работает примерно у 20,7% валидаторов. Активация функций через шлюзы в mainnet временно приостановлена, чтобы внедрение v2.0 точнее соответствовало активациям в testnet и devnet. После широкого внедрения v2.0 в кластере mainnet активации функций через шлюзы, как ожидается, возобновятся согласно запланированному порядку активации. 

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

Выплата валидаторам полной комиссии за приоритет

Это долгожданное и активно обсуждавшееся экономическое обновление теперь реализуется в соответствии с предложением SIMD-0096, по которому в мае прошло голосование валидаторов. Голосование завершилось в конце эпохи 620. В нём участвовало 51,17% стейка, а 77,77% голосов было отдано за предложение. Обновление, активируемое через шлюз функций, принципиально изменит работу сети с комиссиями за приоритет. Вместо текущей модели, в которой 50% комиссий сжигается, а 50% выплачивается валидаторам, новая модель будет направлять валидаторам 100% комиссий за приоритет.

Хотя технически комиссии за приоритет необязательны, рост экономической активности в Solana сделал их стандартной практикой. Эти комиссии рассчитываются в микролампортах (миллионных долях лампорта) на единицу вычислений по формуле:

‍комиссия за приоритет = цена единицы вычислений (в микролампортах) x лимит единиц вычислений

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

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

Распределённые по эпохе вознаграждения

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

При новом подходе расчёт и распределение вознаграждений за стейк на границе эпохи делятся на два отдельных этапа:

• Этап расчёта вознаграждений: на этом этапе рассчитываются вознаграждения за эпоху для всех активных стейк-аккаунтов, а распределение разбивается на запланированные части.
• Этап распределения вознаграждений: заранее рассчитанные вознаграждения за эпоху распределяются между активными стейк-аккаунтами.

Для выполнения и отслеживания этого процесса аккаунт Sysvar EpochRewards будет контролировать и проверять распределение вознаграждений на всём соответствующем этапе. Sysvar EpochRewards фиксирует, выполняется ли этап распределения вознаграждений, а также хранит информацию, необходимую для возобновления распределения при запуске из снимка состояния. 

Расчёт вознаграждений

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

Чтобы минимизировать влияние на время обработки блоков во время распределения вознаграждений и обеспечить детерминированное распределение части вознаграждений в каждом блоке, целевое значение установлено на уровне 4 096 вознаграждений за стейк на блок. Для защиты от резкого роста числа стейк-аккаунтов количество блоков ограничено 10% от общего числа слотов в эпохе. Число аккаунтов в одном разделе может превысить целевое значение 4 096 только при достижении этого лимита блоков.

Распределение вознаграждений

Распределение вознаграждений начинается сразу после этапа расчёта — со второго блока эпохи. Вознаграждения распределяются в начале блока, до обычной обработки транзакций.

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

Из-за сравнительно небольшого числа аккаунтов для голосования — около 1 500 — существующий механизм распределения вознаграждений за голосование в первом блоке на границе эпохи останется без изменений. По нескольким блокам будут распределяться только вознаграждения за стейк.

Центральный планировщик теперь включён по умолчанию

Центральный планировщик впервые появился в обновлении v1.18 и ранее назывался просто «планировщиком». По умолчанию он был отключён, поэтому операторам приходилось включать его флагом --block-production-method central-scheduler при запуске валидатора. Теперь он включён по умолчанию. Предыдущая реализация планировщика имела несколько проблем, которые могли отрицательно влиять на производительность. Узкие места при обработке транзакций часто приводили к колебаниям или непоследовательности в их упорядочивании и приоритизации.

Новая реализация заменяет прежнюю модель с четырьмя независимыми банковскими потоками, каждый из которых отдельно управлял приоритизацией и обработкой транзакций. В обновлённой архитектуре центральный планировщик становится единственным получателем транзакций с этапа SigVerify блока TPU. Он создаёт приоритетную очередь и использует граф зависимостей prio-graph для более эффективной обработки и приоритизации конфликтующих транзакций. Новая архитектура планировщика повышает масштабируемость и гибкость. Теперь число потоков можно увеличивать без прежнего риска роста конфликтов блокировок. Первоначальное внедрение центрального планировщика показало рост вознаграждений и доходов многих операторов. В нашей предыдущей статье Helius об обновлении Solana v1.18 подробно описано, как работает центральный планировщик.

Программа ZK ElGamal Proof

Программа ZK Token Proof, которую изначально планировали включить в выпуск 1.17, теперь признана устаревшей. Её заменит более универсальная и не зависящая от конкретного приложения программа ZK ElGamal Proof. Новая программа ZK ElGamal Proof сохраняет части ZK Token Proof, применимые в разных приложениях, например проверку действительности открытого ключа или диапазона значений, зашифрованных в шифротексте ElGamal. При этом она не включает элементы, специфичные для отдельных приложений, например проверку доказательств с нулевым разглашением для инструкций перевода SPL Token. Новая программа ZK ElGamal Proof будет добавлена в список встроенных программ по адресу ZkE1Gama1Proof11111111111111111111111111111

Подробнее о программе ZK Token Proof читайте в нашей первоначальной статье в блоге Helius.

Системный вызов Get-Sysvar

Syscalls, или системные вызовы, запрашивают службы ядра операционной системы. В контексте Solana системный вызов позволяет программам, работающим в виртуальной машине Solana (SVM), взаимодействовать с внешними ресурсами и службами. 

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

Системный вызов Get-Sysvar, впервые предложенный инженером Anza Joe Caulfield в SIMD-127, создаёт единый интерфейс системных вызовов для доступа к данным Sysvar. Обновление позволяет получать ранее недоступные данные Sysvar, включая SlotHashes и StakeHistory. С новым интерфейсом разработчики могут обращаться к отдельным фрагментам данных Sysvar — например, вызывать SlotHashes::get_slot(slot) и StakeHistory::get_entry(epoch) — без необходимости дублировать целые структуры данных.

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

Новый системный вызов упрощает изменение и добавление Sysvar. Он значительно снижает сложность интерфейса системных вызовов и затраты на его поддержку. Кроме того, обновление создаёт основу для расширения доступа программ BPF к данным Sysvar. Ончейн-программы смогут считывать больше информации Sysvar без увеличения размера транзакции.

Системный вызов GetEpochStake

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

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

При работе с GetEpochStake разработчики передают 32-байтовый адрес аккаунта для голосования, а системный вызов возвращает целое число u64, представляющее общий активный стейк, делегированный этому аккаунту. Если переданный адрес не соответствует действительному аккаунту для голосования или не существует, системный вызов просто вернёт 0.

MoveStake и MoveLamports

Для передачи ценности между стейк-аккаунтами добавляются две новые инструкции программы стейкинга: MoveStake и MoveLamports. Эти инструкции, впервые предложенные в SIMD-0148, позволяют разработчикам перемещать средства между аккаунтами с совпадающими полномочиями без контроля со стороны полномочия на вывод.

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

MoveStake

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

MoveLamports

MoveLamports: перемещает избыточные лампорты с активного или неактивного аккаунта на другой активный или неактивный аккаунт. «Избыточные лампорты» — это лампорты, которые не относятся к делегированному стейку и не требуются для освобождения от ренты. MoveLamports позволяет выполнять служебные задачи, например возвращать лампорты из объединённых аккаунтов и консолидировать неиспользуемые средства.

Для упрощения реализации эти изменения не поддерживают активацию и деактивацию аккаунтов и не влияют на частично активные стейк-аккаунты. Новые инструкции программы не меняют существующую функциональность.

Бонус: крейт Solana-SVM

Вместе с Agave 2.0 выходит совершенно новый крейт solana-svm, предоставляющий разработчикам прямой доступ к основным компонентам SVM через упрощённый API, не зависящий от полной инфраструктуры валидатора. Это позволяет использовать высокопроизводительную обработку транзакций Solana за пределами валидатора — например, во внечейн-сервисах, облегчённых клиентах, каналах состояния и роллапах.

Отделение API от остальной среды выполнения устраняет необходимость в таких компонентах, как экземпляры Bank, и снижает операционные расходы. Теперь разработчики могут использовать те же надёжные компоненты, на которых работает mainnet-beta Solana, для создания собственных проектов SVM: облегчённых клиентов, каналов состояния, роллапов и внечейн-сервисов. В основе API лежит структура TransactionBatchProcessor. Она позволяет приложениям обрабатывать пакеты проверенных транзакций Solana с полным набором нижележащих компонентов Agave, включая BPF Loader, eBPF и виртуальную машину.

Подробную информацию об этой интересной разработке можно найти в детальном обзоре нового API SVM от Anza.

Удалённые эндпоинты RPC 

Несколько неактуальных и устаревших эндпоинтов RPC Agave v1 были удалены. Команда Helius Devrel связалась со всеми клиентами, использующими эти эндпоинты. Ранее внутренний анализ выявил небольшую группу клиентов, которые активно использовали следующие запланированные к удалению эндпоинты:

• getRecentBlockhash
• getConfirmedSignatureForAddresses2
• getConfirmedTransaction
• getConfirmedBlock
• getStakeActivation
• getFees

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

Несовместимые изменения SDK:

• Поддержка Borsh v0.9 удалена. Используйте v1 или v0.10 (#1440)
• Для Rent и EpochSchedule больше не выводится трейт Copy; используйте clone()
• solana-sdk: удалены устаревшие символы) 
• solana-program: удалены устаревшие символы

Для операторов валидаторов в Agave v2.0 будут удалены несколько устаревших аргументов валидатора. Их полный список доступен здесь.‍

Заключение

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

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

• График выпуска Agave v2.0
• Журнал изменений Agave v2.0
• Версии Agave