Співзасновник Solana Анатолій Яковенко заявив, що Alpenglow міг би бути випущений удвічі швидше через простішу зміну програми голосування, напередодні міграції консенсусу 21 жовтня, яка видалить транзакції голосування валідаторів з блоків.
Резюме
- Яковенко сказав, що простіша зміна програми голосування могла б удвічі скоротити час розробки Alpenglow.
- Видалення транзакцій голосування валідаторів знизить загальні показники TPS без обов'язкової зміни активності користувачів.
- Спалена вступна плата у розмірі 0,8 SOL за епоху замінить індивідуальні плати за голосування.
- Деякі RPC-вузли можуть отримувати оновлення фінальності пізніше за цільовий показник Alpenglow у 150 мілісекунд.
Яковенко в публікації в X від 21 жовтня зробив цю заяву, цитуючи коментар, який вітав заплановане видалення голосувань в мережі та висміював повторювану критику, що більшість транзакцій Solana за секунду складаються з голосувань валідаторів.
«Alpenglow був би випущений удвічі швидше, якби вони просто змінили програму голосування на машину станів ag»
Опублікований дизайн Anza описує заміну TowerBFT — системи, яку валідатори використовували для узгодження блоків, — на пряме голосування та компактні сертифікати.
Міграція в mainnet була запланована на 21 жовтня, як раніше повідомляло crypto.news, висвітлюючи заплановану передачу консенсусу. Оновлені вказівки Solana Foundation визначають епоху 1064 як тригер і оцінюють її початок приблизно о 13:20 UTC.
Сторінка міграції Anza відокремлює активацію функції від передачі консенсусу. Межа міграції настає на 5 000 слотів пізніше, коли блоки тимчасово містять лише голосування, поки валідатори завершують перехід.
Alpenglow видаляє голосування із загальних підрахунків транзакцій
Вказівки Solana Foundation щодо міграції радять оглядачам та аналітичним сервісам скинути базові показники підрахунку транзакцій і TPS, оскільки транзакції голосування зникнуть з блоків. Загальна кількість, що включає голосування, впаде, навіть якщо платежі, торги та інші транзакції без голосування залишаться незмінними.
Фонд зазначає, що сервіси, які відстежують участь валідаторів, повинні замінити своє читання інструкцій програми Vote на дані сертифікатів у футерах блоків. У його вказівках зазначено, що повідомлення футера gRPC від Yellowstone ще не передає ці сертифікати.
Розробники мали доступ до зміненої поведінки, коли Alpenglow досяг devnet у вересні, після переходу testnet. Матеріал від 26 вересня описував, як оглядачі повинні тримати конкуруючі блоки-кандидати окремо до підтвердження, зберігаючи вибраний блок замість об'єднання їхніх транзакцій.
Документація Anza для операторів пояснює, як плагіни отримують метадані заміни. Agave 4.3 надає необов'язкове сповіщення футера блоку, яке сервіси повинні ввімкнути та реалізувати, якщо їм потрібні дані футера. Ці сповіщення зберігають своє впорядкування відносно сповіщень про записи.
Згідно з тією ж документацією, годинник ланцюга зберігає свій існуючий формат і точність до цілої секунди. Під час виконання транзакції його позначка часу оцінює, коли завершився батьківський блок, і операторам наказано продовжувати вважати це значення приблизним.
Плати валідаторів переходять до окремої плати за епоху
Документація Solana Foundation щодо плат зазначає, що видалення голосувань у мережі припиняє плати, сплачені за окремі транзакції голосування. Натомість валідатори сплачують фіксовану вступну плату у розмірі 0,8 SOL за епоху, причому вся сума спалюється.
Кошти надходять з акаунта голосування, замінюючи акаунт ідентичності як джерело платежів, пов'язаних з голосуванням. Згідно з тією ж вказівкою, оператори повинні утримувати плату вище мінімуму, що звільняє акаунт від оренди.
Оплата здійснюється на одну епоху наперед. Перша плата на початку епохи 1064 покриває участь в епосі 1065, і валідатор, який не може сплатити, втрачає дозвіл голосувати або виробляти блоки в наступній епосі.
Фонд зазначає, що реєстрація публічного ключа BLS стала доступною в mainnet 8 липня, тоді як функція вступної плати активувалася 22 липня. Ці підготовчі зміни самі по собі не активували консенсус Alpenglow.
Перед міграцією її контрольний список вимагає версії 4.3.2 Agave, Jito-Solana або Harmonic Salsa. Firedancer і Frankendancer не підтримуються під час передачі, згідно з інструкціями оператора Фонду.
Два шляхи голосування замінюють TowerBFT
Anza описує Votor як такий, що працює з двома шляхами голосування одночасно. Один фіналізує блок за один раунд із відповідями від 80% частки, тоді як другий використовує два раунди та пороги 60%.
Голоси стають прямими повідомленнями, підписаними за допомогою криптографії BLS, що дозволяє об'єднувати кілька підписів у компактний сертифікат. Anza зазначає, що валідатори використовують власні таймери, щоб визначити нечутливого лідера та проголосувати за його пропуск.
Опублікована пропозиція SIMD-0326 документує альтернативи, розглянуті під час розробки. Дизайн без однораундової фінальності пропонував простішу роботу та 33% стійкості до візантійських збоїв, але його автори вказали гіршу затримку та нижчу стійкість до збоїв серед недоліків.
Інша альтернатива використовувала спрямований ациклічний граф із можливою економією пропускної здатності. Автори пропозиції вказали затримку та складність повного використання пропускної здатності серед її недоліків.
Пропозиція обмежує допущений набір до 2000 валідаторів, надаючи пріоритет операторам із найбільшою часткою. Її автори пояснюють, що обмеження допомагає зберігати сертифікати достатньо малими для одного UDP-повідомлення, тоді як записи про участь підтримують винагороди для валідаторів, які активно голосують.
Схвалення врядування передувало впровадженню. У вересні 2025 року пропозиція Alpenglow пройшла з 98,27% підтримки серед поданих голосів, тоді як частка учасників становила 52% від загальної, згідно з опублікованими цифрами завершеного голосування.
Доставка RPC може відставати від фінальності консенсусу
Документація оператора Anza уточнює цільову фінальність приблизно 150 мілісекунд, пояснюючи, що вузли поза допущеним набором валідаторів можуть отримати результат пізніше.
Через типовий шлях ці вузли дізнаються про фінальність із сертифікатів, включених у наступний блок. Anza зазначає, що це може додати до одного інтервалу створеного блоку, з довшими очікуваннями, коли блоки пропускаються або затримуються.
Допущений валідатор може надсилати повідомлення консенсусу безпосередньо партнерському вузлу, залишаючи мережеву затримку між партнерами як основну додану затримку. Якщо кожен налаштований партнер стає недоступним, одержувач повертається до вивчення фінальності з пізніших нижніх колонтитулів блоків.
