Розробники Solana запланували консенсусне оновлення Alpenglow на 21 жовтня, орієнтуючись на фіналізацію приблизно за 150 мілісекунд, і просять валідаторів та операторів застосунків підготуватися до змін під час переходу в mainnet.
Короткий огляд
- Оновлення Solana Alpenglow заплановане на 21 жовтня з орієнтиром на фіналізацію транзакцій приблизно за 150 мілісекунд.
- Quicknode попереджає про короткочасну паузу в обробці транзакцій і можливі переривання потоків даних під час переходу.
- Валідатори повинні використовувати сумісне програмне забезпечення та поповнити рахунки для голосування для сплати вступного внеску 0,8 SOL.
- Деякі RPC-вузли можуть отримувати інформацію про фіналізацію пізніше, ніж валідатори, які беруть безпосередню участь у консенсусі.
Повідомлення Quicknode про технічне обслуговування визначає середу як запланований день активації, але його останнє оновлення попереджає, що початкова оцінка 14:50 UTC може зміститися на 13:20 UTC у міру просування виробництва блоків. Провайдер просить операторів бути готовими з 13:00 UTC, а консенсусний перехід відбудеться приблизно через 20 хвилин після активації.
Поточна сторінка оновлення Solana Foundation відносить зміну до епохи 1064 і зазначає, що mainnet ще не активовано. Її оновлена оцінка розміщує початок епохи близько 13:20 UTC, роблячи межу епохи відповідним тригером замість фіксованого часу за годинником.
Solana Alpenglow орієнтується на фіналізацію, а не на швидше виконання
За дизайном Anza, Votor замінює логіку голосування та фіналізації TowerBFT. Цільовий показник — приблизно 150 мілісекунд за нормальних умов мережі, а не гарантія, що кожен гаманець, біржа чи торговий застосунок відобразить завершену транзакцію протягом цього періоду.
Фонд заявляє, що виконання транзакцій, поведінка програм і механіка комісій залишаються незмінними. Звичайним користувачам не потрібно змінювати спосіб підписання чи схвалення транзакцій, тоді як окреме оновлення розподілу даних Rotor відкладено до пізнішого випуску. Його документація відокремлює розгортання консенсусу від попередніх скорочень тривалості слота, які визначають, як часто мережа виробляє блоки.
Технічний огляд Quicknode описує два шляхи голосування, що працюють одночасно. Один може фіналізувати блок за один раунд, коли бере участь 80% валідаторів, тоді як інший використовує другий раунд, коли участь досягає 60%.
Провайдер відрізняє цей процес від ранніх підтверджень, які користувачі вже бачать. Його огляд зазначає, що застосунки зазвичай відображають підтвердження протягом двох-трьох секунд за оптимістичних налаштувань, перш ніж стара система досягає повної фіналізації приблизно за 13 секунд.
Жовтневе розгортання відповідає попередній дорожній карті, яка пов'язувала Alpenglow з Agave 4.3. Звіт від 14 серпня задокументував, що код Alpenglow був присутній в Agave 4.2 для тестування, без дозволу на активацію в mainnet у тому випуску.
До 26 вересня оновлення досягло devnet після переходу testnet попереднього дня, як раніше висвітлювало crypto.news. Команди застосунків могли тоді перевірити нову поведінку консенсусу перед розгортанням у мережі, яка обробляє кошти користувачів.
Трейдери зіткнуться з коротким перериванням під час переходу
Quicknode попереджає, що нові транзакції ненадовго перестануть потрапляти в блоки, поки мережа змінює консенсусні системи. Його повідомлення описує паузу тривалістю кілька секунд, із можливим довшим перериванням, якщо перехід займе більше часу.
Подання транзакцій можуть тимчасово повертати помилку передперевірки «node unhealthy», зазначає провайдер. Потоки даних Yellowstone можуть від'єднатися один раз, тоді як підписки, що використовують найраніше оброблене зобов'язання, можуть відображати слоти, які ніколи не досягають підтвердження.
Повідомлення про технічне обслуговування рекомендує підтверджене або фіналізоване зобов'язання для даних, які не повинні бути відкочені. Quicknode зазначає, що його наявні кінцеві точки Solana залишаться на місці, і його команда буде відстежувати мережу протягом усієї зміни.
У технічному огляді провайдера швидше незворотне врегулювання є актуальним для фінансових застосунків, корпоративних казначейських переказів і послуг у реальному часі. Документ подає ці випадки використання як можливості запропонованої консенсусної архітектури, не встановлюючи, що окремі торгові платформи запровадять нові політики врегулювання в день активації.
Готовність валідатора включає програмне забезпечення та фінансування акаунта
Поточний контрольний список Solana Foundation інструктує валідаторів запускати версію 4.3.2 Agave, Jito-Solana або Harmonic Salsa до епохи 1064. Firedancer і Frankendancer не підтримуються під час міграції, згідно з тими самими вказівками.
Оператори повинні тримати щонайменше 0.8 SOL понад мінімум, що звільняє від оренди, у своїх акаунтах для голосування, щоб покрити Validator Admission Ticket. Перший платіж оплачує участь в епосі 1065, і несплачений збір перешкоджає валідатору голосувати або виробляти блоки в наступній епосі.
Схвалення управління передує цим операційним вимогам. Пропозиція була прийнята у вересні 2025 року з 98.27% голосів на підтримку, згідно з висвітленням завершеного голосування. Участь становила 52% стейку, тому відсоток схвалення описує подані голоси, а не всю популяцію валідаторів.
Те попереднє голосування схвалило SIMD-0326, пропозицію, що стоїть за переглядом консенсусу. Тодішній звіт зафіксував 1.05% проти та 0.69% утрималися, з невеликою різницею округлення, збереженою в опублікованих цифрах.
Доставка RPC може відставати від цільових 150 мс
Документація оператора Anza пояснює, що повідомлення консенсусу зазвичай циркулюють серед допущених валідаторів. Вузол без стейку, який використовує шлях доставки за замовчуванням, дізнається про фінальність із сертифікатів, що переносяться в пізніших блоках, зазвичай додаючи до одного інтервалу виробленого блоку.
Пропущені або затримані блоки можуть подовжити це очікування. Вузол, що співпрацює з допущеним валідатором, може отримувати повідомлення безпосередньо, хоча мережева затримка між ними залишається частиною часу доставки.
Висвітлення devnet у вересні задокументувало окремі зміни для індексаторів і дослідників. Кандидатні блоки повинні залишатися окремими до підтвердження, а дані про участь валідаторів переходять від звичайних транзакцій голосування до сертифікатів, прикріплених до даних блоку.
Згідно з тим звітом, видалення транзакцій голосування змінює підсумки панелі моніторингу, навіть коли кількість користувацьких платежів і торгів залишається незмінною. Сервіси, що підраховують обидві категорії, повинні скинути свої порівняння, тоді як системи, що відстежують голоси валідаторів, повинні читати дані сертифікатів заміни.
