Solana назначает обновление Alpenglow на 21 октября с целью финализации за 150 мс

Разработчики Solana запланировали обновление консенсуса Alpenglow на 21 октября, нацеливаясь на финализацию примерно за 150 миллисекунд, при этом просят валидаторов и операторов приложений подготовиться к изменениям во время передачи основной сети.

Резюме

• Обновление Alpenglow от Solana запланировано на 21 октября с целью финализации транзакций примерно за 150 миллисекунд.
• Quicknode предупреждает о кратковременной паузе в транзакциях и возможных перерывах в потоках данных во время передачи.
• Валидаторы должны использовать совместимое программное обеспечение и пополнить счета для голосования на сумму 0.8 SOL.
• Некоторые RPC-узлы могут получать информацию о финализации позже, чем валидаторы, участвующие непосредственно в консенсусе.

Уведомление о техническом обслуживании от Quicknode указывает на среду как на запланированный день активации, но его последнее обновление предупреждает, что первоначальная оценка в 14:50 UTC может быть перенесена на 13:20 UTC по мере увеличения производства блоков. Провайдер просит операторов быть готовыми с 13:00 UTC, а передача консенсуса произойдет примерно через 20 минут после активации.

Текущая страница обновлений Фонда Solana указывает на изменение в эпохе 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 после перехода тестовой сети накануне, как ранее освещалось crypto.news. Команды приложений могли затем проверить новое поведение консенсуса перед развертыванием против сети, обрабатывающей средства пользователей.

Трейдеры сталкиваются с кратковременной паузой во время передачи

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

Отправка транзакций может временно возвращать ошибку "узел неработоспособен" при предварительной проверке, сообщает провайдер. Потоки данных Yellowstone могут отключиться один раз, в то время как подписки, использующие ранее обработанное обязательство, могут отображать слоты, которые никогда не достигают подтверждения.

Уведомление о техническом обслуживании рекомендует подтвержденное или финализированное обязательство для данных, которые не должны быть отменены. Quicknode сообщает, что его существующие конечные точки Solana останутся на месте и что его команда будет следить за сетью на протяжении всего изменения.

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

Готовность валидаторов включает программное обеспечение и финансирование аккаунтов

Текущий контрольный список Фонда Солана инструктирует валидаторов запускать версию 4.3.2 Agave, Jito-Solana или Harmonic Salsa до эпохи 1064. Firedancer и Frankendancer не поддерживаются во время миграции, согласно тем же указаниям.

Операторы должны поддерживать как минимум 0.8 SOL выше минимального уровня, освобождающего от аренды, на своих голосовых аккаунтах, чтобы покрыть стоимость Билета на Приём Валидатора. Первый сбор оплачивает участие в эпохе 1065, а неоплаченная плата предотвращает голосование или создание блоков валидатором в следующей эпохе.

Одобрение управления предшествует этим операционным требованиям. Предложение прошло в сентябре 2025 года с 98.27% голосов, поддерживающих его, согласно освещению завершённого голосования. Участие составило 52% от доли, поэтому процент одобрения описывает поданные голоса, а не всё население валидаторов.

Это предыдущее голосование одобрило SIMD-0326, предложение, стоящее за переработкой консенсуса. Современный отчёт зафиксировал 1.05% против и 0.69% воздержавшихся, с небольшой округлённой разницей, сохранённой в опубликованных цифрах.

Доставка RPC может отставать от целевого времени в 150 мс

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

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

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

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