Разработчики Solana запланировали обновление консенсуса Alpenglow на 21 октября, нацеливаясь на финальность примерно в 150 миллисекунд и прося валидаторов и операторов приложений подготовиться к изменениям во время перехода основной сети.
Краткое содержание
- Обновление Solana Alpenglow запланировано на 21 октября с целью достижения финальности транзакций примерно за 150 миллисекунд.
- Quicknode предупреждает о кратковременной паузе в обработке транзакций и возможных перерывах в потоках данных во время перехода.
- Валидаторы должны использовать совместимое программное обеспечение и пополнить счета для голосования для оплаты вступительного взноса в размере 0,8 SOL.
- Некоторые RPC-узлы могут получать информацию о финальности позже, чем валидаторы, непосредственно участвующие в консенсусе.
Уведомление о техническом обслуживании Quicknode указывает среду как запланированный день активации, но его последнее обновление предупреждает, что первоначальная оценка в 14:50 UTC может сместиться на 13:20 UTC по мере продвижения производства блоков. Провайдер просит операторов быть готовыми с 13:00 UTC, при этом передача консенсуса последует за активацией примерно через 20 минут.
Текущая страница обновления Solana Foundation относит изменение к эпохе 1064 и указывает, что основная сеть ещё не активирована. Обновлённая оценка помещает начало эпохи около 13:20 UTC, делая границу эпохи соответствующим триггером вместо фиксированного назначенного времени.
Solana Alpenglow нацелен на финальность, а не на более быстрое исполнение
Согласно дизайну Anza, Votor заменяет логику голосования и финальности TowerBFT. Цель — примерно 150 миллисекунд при нормальных условиях сети, а не гарантия того, что каждый кошелёк, биржа или торговая платформа отобразит завершённую транзакцию в течение этого периода.
Фонд заявляет, что исполнение транзакций, поведение программ и механика комиссий остаются неизменными. Обычным пользователям не нужно менять способ подписания или одобрения транзакций, а отдельное обновление распределения данных Rotor отложено до более позднего релиза. Его документация отделяет развёртывание консенсуса от более ранних сокращений длительности слота, которые определяют, как часто сеть производит блоки.
Технический обзор Quicknode описывает два пути голосования, работающих одновременно. Один может финализировать блок за один раунд, когда участвуют 80% валидаторов, а другой использует второй раунд, когда участие достигает 60%.
Провайдер отличает этот процесс от ранних подтверждений, которые пользователи уже видят. В его обзоре говорится, что приложения обычно отображают подтверждения в течение двух-трёх секунд при оптимистичных настройках, прежде чем старая система достигает полной финальности примерно через 13 секунд.
Октябрьское развёртывание следует более ранней дорожной карте, которая связывала Alpenglow с Agave 4.3. Отчёт от 14 августа документировал, что код Alpenglow присутствовал в Agave 4.2 для тестирования, без разрешения активации в основной сети в том релизе.
К 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 документировало отдельные изменения для индексаторов и обозревателей. Кандидатные блоки должны оставаться отдельными до подтверждения, а данные об участии валидаторов переходят от обычных голосующих транзакций к сертификатам, прикреплённым к данным блока.
Согласно этому отчёту, удаление голосующих транзакций изменяет итоговые показатели панели мониторинга, даже когда количество пользовательских платежей и сделок остаётся неизменным. Сервисы, учитывающие обе категории, должны сбросить свои сравнения, а системам, отслеживающим голоса валидаторов, необходимо читать данные замещающих сертификатов.
