Соучредитель Solana Анатолий Яковенко заявил, что Alpenglow можно было бы выпустить вдвое быстрее с помощью более простого изменения программы голосования, в преддверии миграции консенсуса 21 октября, которая удалит транзакции голосования валидаторов из блоков.
Краткое содержание
- Яковенко заявил, что более простое изменение программы голосования могло бы вдвое сократить время разработки Alpenglow.
- Удаление транзакций голосования валидаторов снизит общие показатели TPS без обязательного изменения активности пользователей.
- Сжигаемый вступительный взнос в размере 0,8 SOL за эпоху заменит индивидуальные комиссии за голосование.
- Некоторые RPC-узлы могут получать обновления финальности позже целевого показателя Alpenglow в 150 миллисекунд.
Яковенко в публикации в X от 21 октября сделал это замечание, цитируя комментарий, восхваляющий планируемое удаление ончейн-голосований и высмеивающий повторяющуюся критику о том, что большинство транзакций Solana в секунду состоят из голосований валидаторов.
«Alpenglow был бы выпущен вдвое быстрее, если бы они просто изменили программу голосования на конечный автомат ag»
Опубликованный дизайн Anza описывает замену TowerBFT — системы, которую валидаторы использовали для согласования блоков, — на прямое голосование и компактные сертификаты.
Миграция основной сети была запланирована на 21 октября, как ранее сообщал crypto.news, освещая планируемую передачу консенсуса. Обновлённое руководство Solana Foundation определяет эпоху 1064 как триггер и оценивает её начало примерно в 13:20 UTC.
Страница миграции Anza отделяет активацию функции от передачи консенсуса. Граница миграции наступает на 5 000 слотов позже, когда блоки временно содержат только голосования, пока валидаторы завершают переход.
Alpenglow удаляет голосования из общих подсчётов транзакций
Руководство по миграции Solana Foundation предписывает обозревателям и аналитическим сервисам сбросить базовые показатели подсчёта транзакций и TPS, поскольку транзакции голосования исчезнут из блоков. Общий показатель, включающий голосования, упадёт, даже если платежи, сделки и другие неголосовательные транзакции останутся неизменными.
Фонд заявляет, что сервисы, отслеживающие участие валидаторов, должны заменить своё чтение инструкций программы Vote данными сертификатов в футерах блоков. В его руководстве отмечается, что сообщение футера gRPC Yellowstone пока не передаёт эти сертификаты.
Разработчики получили доступ к изменённому поведению, когда Alpenglow достиг devnet в сентябре, после перехода в тестовой сети. Материал от 26 сентября описывал, как обозреватели должны держать конкурирующие блоки-кандидаты отдельно до подтверждения, сохраняя выбранный блок вместо объединения их транзакций.
Документация Anza для операторов объясняет, как плагины получают замещающие метаданные. Agave 4.3 предоставляет опциональное уведомление о футере блока, которое сервисы должны включить и реализовать, если им нужны данные футера. Эти уведомления сохраняют свой порядок относительно уведомлений о записях.
Согласно той же документации, часы сети сохраняют существующий формат и точность до целых секунд. Во время выполнения транзакции их временная метка оценивает, когда закончился родительский блок, и операторам предписано продолжать рассматривать это значение как приблизительное.
Комиссии валидаторов переходят в отдельный эпохальный платёж
Документация Solana Foundation о комиссиях гласит, что удаление ончейн-голосований прекращает комиссии, уплачиваемые за отдельные транзакции голосования. Валидаторы вместо этого платят фиксированный вступительный взнос в размере 0,8 SOL за эпоху, причём вся сумма сжигается.
Деньги поступают со счёта голосования, заменяя счёт идентификации в качестве источника платежей, связанных с голосованием. Согласно тому же руководству, операторы должны держать платёж выше минимального порога освобождения от арендной платы для счёта.
Оплата производится на одну эпоху вперёд. Первый платёж в начале эпохи 1064 покрывает участие в эпохе 1065, и валидатор, который не может заплатить, теряет право голосовать или производить блоки в следующей эпохе.
Фонд сообщает, что регистрация открытых ключей BLS стала доступна в основной сети 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 сообщает, что это может добавить до одного интервала произведённого блока, с более длительными ожиданиями при пропуске или задержке блоков.
Допущенный валидатор может отправлять сообщения консенсуса напрямую партнёрскому узлу, оставляя сетевую задержку между партнёрами в качестве основной дополнительной задержки. Если каждый настроенный партнёр становится недоступным, получатель возвращается к получению информации о финальности из более поздних футеров блоков.
