Агава 2.0 Огляд

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

‍

• Розширені рефакторинги кодової бази та оптимізації
• Розділені винагороди епохи
• Винагорода повної пріоритетної комісії для валідаторів
• Новий центральний планувальник зараз увімкнено за замовчуванням
• Програма доказу ZK ElGamal
• Отримати системний виклик Sysvar
• Отримати виклик функції GetEpochStake
• MoveStake і MoveLamports
• Видалення застарілих методів RPC
• Перейменування ящиків

‍

Незалежно від того, чи ви запускаєте перевіряльника, будуєте на платформі чи активно використовуєте Solana, цей всебічний огляд оновлення Agave 2.0 надасть вам усі необхідні уявлення, щоб зрозуміти та скористатися цими останніми інноваціями.

Що робить 2.0 великим оновленням версії?

Більше не існує одного 'Solana валідатора.' Agave 2.0 приймає новий багатоклієнтський світ Solana і робить чистий розрив зі старимСховище GitHub компанії Solana Labs. Репозиторій Solana Labs буде заархівовано, і нові запити на витяг або проблеми більше не будуть прийматися. Раніше цей репозиторій відображав діяльність репозиторію Agave. Розробники повинні мігрувати всю діяльність доRepozytorium Anza Agave na 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 наведені в кінці цього статті.

Впровадження функцій

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

‍

Нові повні можливості, про які йшлося в наступних розділах, наразі не доступні і будуть повільно впроваджуватися протягом життєвого циклу 2.0 за допомогою системи воріт функцій. Функції активуються в певні епохи на основі відносного пріоритету та порядку їх активації в кластерах тестової мережі та devnet.

‍

Винагорода Повна Пріоритетна Комісія для Валідаторів

Це дуже очікувано ідуже обговорюване економічне оновлення зараз виконується відповідно до пропозиції,SIMD-0096, яка пройшла голосування за управління валідатором в травні. Голосування завершилося в кінці епохи 620, при участі 51,17% частки і 77,77% голосували в підтримку. Оновлення з функцією-воротами фундаментально змінить обробку мережі Пріоритетні збори. Замість поточної моделі, яка розділяє комісії з 50% спалених і 50% винагороди валідаторам, нова модель розподілятиме 100% пріоритетних комісій безпосередньо валідаторам.

Вище: щотижневі пріоритетні комісії Solana в доларовому еквіваленті ( джерело)

‍

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

‍

‍пріоритетна плата = ціна обчислювальної одиниці (мікро-лампорти) x ліміт обчислювальної одиниці

‍

Надалі всі пріоритетні винагороди будуть надаватися блок-продюсерам. Це створює більш сильну взаємодію стимулів та зменшує ймовірність того, що валідатори будуть займатися позапротокольними угодами з включення транзакцій, що було проблемою в минулому.

‍

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

‍

Розділені нагороди епохи

Розділені нагороди епохимають на меті розподілитивинагороди за утриманнячерез кілька блоків, що полегшує проблеми з продуктивністю, пов'язані з концентрацією розподілу винагороди в першому блоку кожної нової епохи. Головним обмеженням в цьому процесі є необхідність записувати оновлення до зростаючої кількості активних рахунків ставок в мережі, яка наразі становить приблизно 1,4 мільйона.

За цим новим підходом розрахунок та розподіл винагороди за ставкою на межі епохи буде розділено на дві відмінні фази:

‍

• Етап розрахунку винагород: На цьому етапі розраховуються винагороди для всіх активних облікових записів зацікавлених сторін, і розподіл розбивається на заплановані частини.
• Фаза розподілу винагород: Попередньо розраховані епохальні винагороди для активних облікових записів ставок розподіляються відповідно.

‍

Для полегшення та контролю процесу, створено обліковий запис Sysvar,EpochRewards, буде відстежувати та підтверджувати розподіл винагород протягом фази розподілу. Системна змінна EpochRewards фіксує, чи триває фаза розподілу винагород і інформацію, необхідну для відновлення розподілу при запуску зі снапшоту.

Розрахунок винагороди

Розрахунки винагороди будуть проводитися на першому блоку епохи. Після розрахунку винагороди розділяються на частини для розподілу, зберігаються в банку і будуть розподілені під час фази розподілу винагороди.

‍

Щоб мінімізувати вплив на час обробки блоку під час фази розподілу винагород та забезпечити те, щоб кожен блок розподіляв підмножину винагород в детермінований спосіб, на кожний блок буде розподілятися цільова кількість з 4,096 винагород за ставкою. Щоб захистити від радикального зростання кількості облікових записів ставки, кількість блоків обмежена 10% від загальної кількості слотів у епосі. Тільки у випадку досягнення цього обмеження блоків облікові записи на кожну партіцію можуть перевищити цільові 4,096.

Розподіл винагород

Розподіл винагород починається безпосередньо після фази обчислення винагороди, починаючи з другого блоку епохи. Розподіл винагород відбувається у верхній частині блоку перед звичайною обробкою транзакцій.

‍

В результаті користувачі можуть бачити нарахування винагород на своїх стейк-рахунках декілька блоків пізніше, ніж раніше. Однак, загальний досвід залишається схожим, оскільки тривала час першого блоку на межі епохи раніше затримувала доступ користувача до стейк-рахунків. Додатковою перевагою цього підходу є те, що операції, не пов'язані зі стейкінгом, можуть продовжувати обробку без перешкод, тоді як раніше вони були заблоковані під час розподілу винагород.

‍

У зв'язку з порівняно низькою кількістю облікових записів для голосування, приблизно 1 500, існуючий механізм розподілу винагород за голосування на першому блоку межі епохи залишиться без змін. Тільки винагороди за ставку будуть розподілені протягом кількох блоків.

‍

Центральний планувальник тепер увімкнено за замовчуванням

Спочатку представлений як функціональний реліз у випуску v1.18, центральний планувальник, раніше відомий як "планувальник", не був увімкнений за замовчуванням і його потрібно було увімкнути операторами за допомогою прапорця —block-production-method central-scheduler при запуску перевіряючого. Тепер він увімкнений за замовчуванням. Попередня реалізація планувальника мала кілька проблем, які могли негативно вплинути на продуктивність. Затори у обробці транзакцій часто призводили до дрібниць або неузгодженості в упорядкуванні та пріоритизації транзакцій.

‍

Новіша реалізація замінює попередню модель чотирьох незалежних банківських потоків, кожен з яких керує власною пріоритезацією транзакцій та обробкою. У цій переглянутій структурі центральний планувальник є єдиним одержувачем транзакцій зі стадії SigVerify TPU. Він будує чергу пріоритетів і розгортає граф залежностей, відомий як пріо-граф, для кращого управління обробкою та пріоритизацією конфліктних транзакцій. Цей новий дизайн планувальника підвищує масштабованість і гнучкість, дозволяючи збільшити кількість потоків без попередніх побоювань щодо збільшення конфліктів блокувань. Було показано, що початкове розгортання центрального планувальника приносить кращі винагороди, що призводить до підвищення прибутку багатьох операторів. Наша попередня публікація про оновлення Solana v1.18 детально висвітлювала Принцип роботи централізованого планувальника.

‍

Програма ZK ElGamal Proof

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

‍

Щоб дізнатися більше про програму доведення ZK Token, прочитайте нашеоригінальний запис на блозі Helius.

Отримати Sysvar Syscall

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

‍

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

‍

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

‍

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

‍

Представлення нового Syscall спрощує процес модифікації та додавання нових Sysvars. Це значно зменшує складність та вимоги до обслуговування інтерфейсу Syscall. Крім того, це оновлення прокладає шлях для розширення доступу BPF-програм до даних Sysvar, що дозволяє програмам на ланцюжку читати більше інформації про Sysvar без впливу на розмір транзакції.

‍

Системний виклик GetEpochStake

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

‍

На даний момент програми не можуть отримувати дані в режимі реального часу про стейки, делеговані конкретним обліковим записам голосування для поточної епохи, що створює бар'єр для використання випадків, таких як управління валідаторами та вторинні механізми згоди. Увімкнення запитів цих даних на ланцюжку розблокує ці додатки та прокладе шлях для майбутніх використань.

‍

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

‍

MoveStake і MoveLamports

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

‍

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

MoveStake: Ця інструкція дозволяє переміщувати активний стейк між рахунками, перекладаючи його з одного активного рахунку на інший або з активного рахунку на неактивний, тим самим реактивуючи рахунок. Якщо переміщується весь делегування початкового рахунку, початковий рахунок стає неактивним. Баланс, який не підлягає сплаті орендної плати, залишається незмінним в усіх сценаріях, і правила мінімального делегування зберігаються для активних рахунків.

‍

MoveLamports: Перемістити зайві лампорти з одного активного або неактивного облікового запису на інший активний або неактивний обліковий запис, де «зайві лампорти» відносяться до лампортів, які не є делегованим стейком або не потрібні для звільнення від орендної плати. MoveLamports дозволяє виконувати роботи з обслуговування, такі як повернення лампортів з об'єднаних облікових записів та консолідація не використовуваних коштів.

‍

Для оптимізації реалізації ці зміни не підтримують активацію або деактивацію облікових записів або не впливають на частково активні облікові записи стейків. Ці нові програмні інструкції не змінюють існуючу функціональність.

‍

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

З виходом Agave 2.0 з'являється Абсолютно новий ящик Solan-SVMнадає розробникам прямий доступ до основних компонентів SVM через спрощений API, незалежний від повного фреймворка валідатора. Це відкриває можливості високопродуктивної обробки транзакцій Solana для застосунків поза валідатором, таких як off-chain сервіси, легкі клієнти, станові канали та rollups.

‍

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

‍

Вище: обробник партій транзакцій (джерело зображення: Anza)

‍

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

‍

Видалені кінцеві точки RPC

Видалено декілька застарілих і застарілих кінцевих точок Agave RPC v1. Команда Helius Devrel зв'язалася з усіма клієнтами, використовуючи ці кінцеві точки. За допомогою внутрішнього аналізу ми раніше виявили невелику групу клієнтів, які активно використовують такі кінцеві точки, які налаштовано для видалення:

‍

getRecentBlockhash, getConfirmedSignatureForAddresses2, getConfirmedTransaction, getConfirmedBlock, getStakeActivation, getFees

‍

Знову ж таки, ми наполегливо рекомендуємо всім розробникам перевіряти наявність посилань на ці виклики та оновлювати їх відповідним чином із запропонованими замінами.

‍

Вище: повний список застарілих та відмінених точок доступу до Agave RPC v1, які будуть видалені

‍

N.B. Альтернативний підхід для отримання інформації про обліковий запис, показаний на зображенні, може бутизнайдено тут.

‍

Зміни в 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

Відмова від відповідальності:

1. Цю статтю перепечатано з [helius)]. Усі авторські права належать оригінальному автору [Загублений]. Якщо є заперечення стосовно цього повторного видання, будь ласка, зв'яжіться з Gate Learnкоманда і вони оперативно з цим впораються.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою навчання воріт. Якщо не зазначено, копіювання, поширення або плагіатування перекладених статей заборонено.