Solana Alpenglow: как Votor и Rotor меняют консенсус и финальность сети

Alpenglow лучше понимать не как очередное «ускорение Solana», а как замену ключевой части ее консенсусного механизма. Формальное предложение SIMD-0326 описывает переход от существующей связки Proof of History и Tower BFT к новой архитектуре, где Votor отвечает за голосование и финальность, а Rotor — за распространение данных блоков. Цель — сократить финальность с 12,8 секунды в Tower BFT до примерно 100–150 миллисекунд .

Предложение уже прошло голосование в governance Solana, но это не означает, что обновление немедленно работает в основной сети. Активация mainnet — то есть основной рабочей сети с реальными транзакциями — все еще зависит от тестирования, готовности клиентов и того, как реализация покажет себя за пределами закрытых и разработческих кластеров .

Почему Solana вообще меняет консенсус

Сегодня Solana использует Proof of History как криптографический механизм упорядочивания времени: лидерские узлы «штампуют» блоки доказательствами того, что прошел некоторый промежуток времени, а валидаторы могут эти доказательства проверить . Поверх этого работает Tower BFT — алгоритм, где валидаторы складывают голоса в так называемую башню голосов, а каждый новый голос подтверждает выбранную ветку и увеличивает lockout для предыдущих голосов .

Эта архитектура дала Solana быстрые оптимистические подтверждения, но Alpenglow целится в более сильную метрику — финальность. Anza описывала текущую optimistic finality Solana примерно как уровень одной секунды, тогда как SIMD-0326 сравнивает 12,8 секунды финальности в Tower BFT с целевым диапазоном Alpenglow в 100–150 мс .

Разница важна. Оптимистическое подтверждение может выглядеть быстрым для пользователя кошелька или приложения. Финальность — это более строгая точка, где транзакция считается окончательно закрепленной консенсусом. Именно этот второй показатель Alpenglow пытается радикально сократить.

Votor: новый путь к голосованию и финальности

Votor — часть Alpenglow, которая должна заменить текущую логику голосования и финализации блоков . В SIMD-0326 он описан как легковесный протокол прямого голосования, способный финализировать блоки либо за один раунд, либо за два раунда — в зависимости от сетевых условий .

Это серьезный отход от модели Tower BFT с накоплением голосов и lockout-ограничениями. Если упрощать, Votor пытается не строить длинную «башню» подтверждений, а быстрее собрать достаточное участие stake и довести блок до финальности за один или два прохода .

Некоторые сторонние технические разборы описывают это через пороги участия stake в диапазоне 60–80%, но более надежный вывод из первичного предложения — именно модель одно- или двухраундовой финализации, а не конкретная интерпретация отдельных обзоров . Anza также указывала, что Alpenglow использует криптографические примитивы BLS для снижения задержки финализации при сохранении безопасности .

Иными словами, Votor нужен не просто для того, чтобы быстрее показать пользователю статус «подтверждено». Его задача — укоротить путь к более жесткой, консенсусной финальности.

Rotor: почему одной быстрой голосовалки недостаточно

Rotor — это протокол распространения данных в Alpenglow. Anza описывает его как развитие подхода Turbine, нынешней системы доставки блоков в Solana . Его роль практическая: даже самый быстрый механизм голосования не поможет, если валидаторы не получат данные блока достаточно быстро, чтобы проверить их и проголосовать.

Сторонние разборы описывают Rotor как более структурированную схему передачи блоков по relay-путям, взвешенным по stake. В них встречаются оценки распространения блока менее чем за 100 мс, а один обзор приводит показатель 18 мс при типичных условиях сети . Эти цифры стоит читать как целевые оценки, а не как доказанные результаты mainnet: по данным Alchemy, Alpenglow находился на стадии private cluster testing, а запуск в основной сети ожидался позднее .

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

Что может улучшиться — и где нужны оговорки

Область	Ожидаемое изменение	Важная оговорка
Финальность	Главная заявленная цель — переход от 12,8 секунды в Tower BFT к примерно 100–150 мс в Alpenglow .	Solana уже имеет более быстрые оптимистические подтверждения, которые Anza описывала как примерно одну секунду; главный сдвиг — именно в более строгой финальности .
Распространение блоков	Rotor должен сделать доставку блоков быстрее и предсказуемее; сторонние оценки говорят о цели ниже 100 мс, включая оценку 18 мс при типичных условиях .	Это пока не устоявшиеся измерения основной сети.
Blockspace и пропускная способность	Alchemy утверждает, что голоса валидаторов сейчас занимают около 75% blockspace Solana, а перенос голосования off-chain может освободить значительную часть места для пользовательских транзакций .	Alpenglow прежде всего меняет консенсус и финальность, поэтому рост throughput здесь скорее косвенный, а не гарантированное механическое увеличение TPS .

Коротко: прямое обещание Alpenglow — не «магический TPS», а низколатентная финальность. Возможные плюсы для throughput, blockspace и расходов валидаторов вытекают из уменьшения consensus-трафика, особенно vote-транзакций, а не из полной переделки исполнения транзакций в Solana.

Как выглядит дорожная карта до mainnet

Anza представила Alpenglow как новый протокол консенсуса и назвала его крупнейшим изменением ядра Solana за всю историю проекта . Формальное предложение SIMD-0326 было опубликовано в августе 2025 года и описывало Alpenglow как крупную переработку core consensus protocol Solana .

Голосование началось 27 августа 2025 года, с эпохи 840, и должно было идти до эпохи 842 — примерно одну неделю . В начале сентября 2025 года governance-голосование завершилось одобрением. В опубликованных отчетах есть небольшое расхождение по доле голосов «за»: Alchemy указывает 98,27%, а Blockworks — 98,94% участников; оба описывают участие примерно 52% stake . Суть от этого не меняется: предложение прошло с очень сильной поддержкой валидаторов.

С датой запуска в основной сети все менее однозначно. В дорожной карте Anza упоминался ориентир early 2026 для выхода Alpenglow на mainnet, а более поздний обзор Alchemy от апреля 2026 года говорил, что Alpenglow проходит private cluster testing и ожидается в mainnet в late 2026 . Anza также писала, что фокус 2026 года — вывести Alpenglow из development clusters к более широкому развертыванию .

Самая осторожная версия таймлайна по доступным источникам выглядит так: предложение и governance — III квартал 2025 года; разработка и закрытое тестирование — в течение 2026 года; возможный запуск mainnet — в 2026 году, причем late 2026 выглядит более консервативным ориентиром, если главным фильтром остаются тесты и готовность реализации .

Главное для читателя

Если Alpenglow будет развернут так, как задумано, это станет одним из самых важных изменений Solana на уровне протокола. Votor должен сжать голосование и финальность до одного-двух быстрых раундов, а Rotor — достаточно быстро доставлять данные блоков по сети валидаторов, чтобы эта схема действительно работала .

Цифра 100–150 мс звучит эффектно, особенно на фоне 12,8 секунды в Tower BFT. Но пока ее разумнее воспринимать как инженерную цель, а не как уже доказанный результат mainnet. Governance-поддержка у Alpenglow есть; теперь ключевые вопросы — тестирование, готовность клиентов и то, подтвердятся ли заявленные преимущества по vote-overhead, blockspace и расходам валидаторов в реальных сетевых условиях .