Агава 2.0 Summary

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

‍

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

‍

Будь то запуск валидатора, создание на платформе или активное использование Solana, эта всесторонняя обзорная статья об обновлении Agave 2.0 даст вам инсайты, необходимые для понимания и использования этих последних инноваций.

Что делает 2.0 крупным обновлением версии?

Больше нет одного «валидатора Solana». Agave 2.0 принимает новый многоагентный мир Solana и делает чистый разрыв с прошлымРепозиторий Solana Labs на GitHubРепозиторий Solana Labs будет заархивирован, и новые запросы на извлечение или проблемы больше не будут приниматься. Ранее этот репозиторий отражал деятельность репозитория Agave. Разработчики должны перенести все действия наРепозиторий Anza Agave на GitHubесли они еще не сделали этого. TheПроцесс миграции от 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 приведены в конце этой статьи.

Распространение функций

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

‍

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

‍

Наградить полную приоритетную комиссию валидаторам

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

Выше: еженедельные приоритетные комиссии Solana в долларах США ( исходный)

‍

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

‍

приоритетный сбор = цена за вычислительную единицу (микро-лампорты) x лимит вычислительной единицы

‍

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

‍

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

‍

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

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

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

‍

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

‍

Для облегчения и контроля процесса используется учетная запись Sysvar,Награды за эпоху, будет отслеживать и проверять распределение наград на протяжении фазы распределения. Переменная 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 Программа доказательства Эль-Гамаля

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

‍

Чтобы узнать больше о программе доказательства токена ZK, прочтите нашоригинальная статья на блоге Helius.

Get-Sysvar Syscall

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

‍

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

‍

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

‍

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

‍

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

‍

Syscall GetEpochStake

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

‍

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

‍

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

‍

MoveStake и MoveLamports

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

‍

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

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

‍

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

‍

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

‍

Бонус: Ящик Solana-SVM

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

‍

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

‍

Выше: процессор пакетной обработки транзакций (источник изображения: Anza)

‍

Прочтите глубокий анализНовый SVM API Anza для получения полной информации об этом захватывающем событии.

‍

Удаленные конечные точки RPC

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

‍

getRecentBlockhash, getConfirmedSignatureForAddresses2, getConfirmedTransaction, getConfirmedBlock, getStakeActivation, getFees

‍

Мы настоятельно рекомендуем всем разработчикам проверить наличие ссылок на эти вызовы и обновить их соответствующими предложенными заменами.

‍

Выше: полный список устаревших и устаревших конечных точек Agave RPC версии 1, которые будут удалены

‍

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

‍

Изменения SDK, включающие:

‍

• Поддержка Borsh v0.9 удалена, пожалуйста, используйте v1 или v0.10 (#1440)
• Копирование свойства больше не происходитна аренду и EpochSchedule; перейти к использованию 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

Disclaimer：

1. Эта статья взята из [ heliusВсе авторские права принадлежат оригинальному авторуLostin]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь с Gate Learn команды, и они оперативно с этим справятся.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно взглядами автора и не являются инвестиционными рекомендациями.
3. Переводы статьи на другие языки выполняются командой gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.