Alpenglow: масштабная переработка консенсуса Solana

Практические выводы 

• Главное преимущество Alpenglow для Solana — сокращение времени до финализации транзакции в 100 раз. В зависимости от географического расположения валидатора оно уменьшится с 12,8 секунды до 100–150 мс. Благодаря этому Solana сможет конкурировать с более централизованной инфраструктурой Web2 и поддерживать приложения реального времени.
• Alpenglow упрощает консенсус, исключая несколько устаревших компонентов Solana, включая Proof of History, Tower BFT и распространение голосов через gossip. Вместо Proof of History в Alpenglow вводится фиксированное время блока в 400 мс для координации времени в сети. Это не то же самое, что глобально синхронизированные часы.
• Протокол основан на двух ключевых компонентах: Rotor — улучшенном протоколе распространения блоков, который расширяет и совершенствует существующую архитектуру Turbine в Solana; и Votor — новом механизме голосования, который заменяет Tower BFT, Proof of History и использование gossip для распространения голосов.
• Вся активность консенсуса переносится офчейн — сертификаты голосования по-прежнему будут закрепляться ончейн, а транзакции голосования для каждого слота заменит легковесная система BLS-сертификатов. Это изменение устраняет комиссии за голосование в их нынешнем виде. Исторически они были основной статьёй операционных расходов валидаторов. В результате экономика валидаторов значительно улучшится для небольших операторов. Точная экономическая модель ещё разрабатывается.
• Alpenglow предлагает модель устойчивости «20+20»: протокол сохраняет безопасность, если злоумышленники контролируют до 20% стейка, и работоспособность, если ещё 20% стейка, не связанные с первыми, находятся офлайн или не отвечают. Благодаря этому протокол выдерживает как враждебные, так и нестабильные условия в сети.
• Votor использует двухуровневую параллельную систему голосования для достижения консенсуса. В сценарии Fast-Finalization, если блок получает одобрение ≥80% стейка в первом раунде, он немедленно финализируется с помощью Fast-Finalization Certificate. В сценарии Slow-Finalization второй раунд начинается, как только блок получает одобрение ≥60% стейка. Если в этом раунде уровень одобрения достигает ≥60%, блок финализируется с помощью Finalized Certificate.
• В отличие от Turbine, который использует многоуровневую древовидную структуру с ветвлением 200, Rotor применяет одношаговую модель, где распространением шредов занимаются ретрансляционные ноды. Каждый шред передаётся как один пакет с кодированием для исправления стираний. Архитектура Rotor изначально совместима с системами многоадресной рассылки, такими как DoubleZero. Обратите внимание: Rotor, скорее всего, будет оформлен как отдельный SIMD от Votor.
• Сейчас ожидается, что Alpenglow будет развёрнут в основной сети Solana к началу следующего года. Эталонную реализацию протокола можно найти на Github.

Введение

Алгоритм консенсуса Alpenglow представляет собой самую значительную на сегодняшний день переработку основного протокола Solana. Он опирается на новейшие достижения в исследованиях блокчейнов и фундаментально меняет архитектуру достижения консенсуса в сети.

Alpenglow разработан новым исследовательским подразделением Anza, которым руководит профессор Roger Wattenhofer из ETH Zurich — одного из ведущих мировых учебных заведений в области компьютерных наук. Профессор Wattenhofer — ведущий специалист по распределённым системам. Ранее он выступил соавтором статьи 2024 года Halting the Solana Blockchain with Epsilon Stake, в которой были выявлены возможные уязвимости работоспособности текущего протокола консенсуса Solana. Вместе с профессором Wattenhofer в Anza работают его бывшие аспиранты Kobi Sliwinski и Quentin Kniep.

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

Название Alpenglow происходит от немецкого слова Alpenglühen, означающего «свечение Альп». Так называют эффектный свет на горных вершинах на рассвете или закате. Название также отсылает к швейцарскому происхождению протокола.

Каковы преимущества Alpenglow?

Ниже представлен общий обзор ключевых преимуществ, которые должен обеспечить Alpenglow. Каждое из них подробнее рассматривается далее в статье.

Более быстрая финализация

Главное преимущество Alpenglow для Solana — сокращение времени до финализации транзакции в 100 раз, то есть времени, за которое пользовательские транзакции окончательно закрепляются в блокчейн-сети. В зависимости от географического расположения валидатора оно уменьшится с 12,8 секунды до 100–150 мс. Благодаря этому Solana сможет конкурировать с более централизованной инфраструктурой Web2 и поддерживать приложения реального времени.

• Текущая финализация Solana: 12,8 секунды 
• Текущее оптимистичное подтверждение Solana: 500–600 миллисекунд
• Финализация Alpenglow: 150 миллисекунд (медианное значение)*
• Самая быстрая финализация среди конкурентов: 400 миллисекунд (по собственным данным)

*зависит от географии и распределения кластера.

Больше никаких транзакций голосования

С Alpenglow вся активность консенсуса происходит офчейн. Это снизит нагрузку на модуль обработки транзакций (TPU) и механизм воспроизведения, которым больше не придётся обрабатывать транзакции голосования.

Alpenglow также значительно улучшит экономику небольших валидаторов. Комиссии за транзакции голосования — крупнейшая статья операционных расходов валидаторов. Благодаря офчейн-голосованию эти комиссии исчезнут, а стоимость участия существенно снизится. Небольшим валидаторам станет проще работать, а порог входа для участия в обеспечении безопасности сети уменьшится.

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

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

Более оптимизированный протокол

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

Votor и Rotor в Alpenglow закладывают основу для будущих улучшений, таких как асинхронное исполнение и несколько параллельных лидеров (MCL). Это открывает для Solana возможности дальнейшего повышения производительности и развития протокола.

Как работает текущий механизм консенсуса Solana?

Proof of History

Proof of History (PoH) — не алгоритм консенсуса, а инструмент, который помогает достичь консенсуса. Путаница, вероятно, связана с названием — «Proof of X». Для тех, кто знаком с Proof of Work и Proof of Stake, оно подразумевает, что речь идёт об алгоритме консенсуса. Полезнее рассматривать PoH как алгоритм «предварительного консенсуса», который оптимизирует достижение консенсуса за счёт эффективной обработки транзакций.

На высоком уровне PoH — это децентрализованные часы, используемые для доказательства времени во враждебной сети. Формально PoH представляет собой криптографическую функцию временных меток, которая позволяет нодам согласовать порядок событий без обмена данными друг с другом. Она использует последовательную устойчивую к нахождению прообраза хеш-функцию для создания цепочки хешей. Лидеры присваивают блокам временные метки с помощью этих хешей, чтобы доказать, что прошёл определённый период времени. Поскольку все хеши связаны в цепочку, PoH формирует историческую запись, доказывающую, что данные существовали в конкретный момент времени. 

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

Tower BFT

Tower BFT начинает работать после того, как шреды (то есть части блоков) распространены среди других валидаторов и сеть воспроизвела их, чтобы определить, станет ли блок частью реестра. Концептуально это алгоритм консенсуса, похожий на pBFT и использующий общесетевые часы Proof of History. Вместо синхронного раунда консенсуса для каждого слота валидаторы заранее принимают обязательства по будущим слотам на основе уже наблюдаемой последовательности Proof of History. Это обеспечивает непрерывное производство блоков.

Валидаторы отправляют по одной транзакции голосования на слот, подписанной их аккаунтом голосования. Голоса за определённый форк приводят к блокировке (то есть периоду ожидания) для этого форка. Блокировка — это заданный период в слотах, в течение которого валидатор не может голосовать за другой форк. Это вынуждает валидаторов придерживаться одного форка и экспоненциально увеличивает блокировку при попытке переключиться на другой. Каждый голос содержит счётчик блокировки, который удваивается всякий раз, когда валидатор голосует за слот-потомок, формируя «башню голосов» из обязательств. Поэтому, если валидатор голосует за блок X, он не может голосовать за конфликтующий форк в течение экспоненциально растущего числа будущих слотов (например, 1, 2, 4, 8…). Нарушение блокировки можно доказать и наказать, хотя слешинг ещё не был внедрён в основной сети.

В рамках Tower BFT Solana достигает двух уровней финализации: оптимистичного подтверждения и детерминированной финализации. 

Когда создаётся новый блок и за него голосует ≥66% стейка, блок признаётся частью ведущего, или канонического, форка. Это называется оптимистичным подтверждением: блок получает уровень подтверждения «confirmed», как только за него проголосовало квалифицированное большинство. Оптимистичное подтверждение появилось в версии v1.3 клиента Solana Labs (ныне Agave), чтобы улучшить UX: блок считается финализированным до его формальной финализации.

С момента создания генезис-блока Solana ни один оптимистично подтверждённый блок не был отменён. Для этого потребовалось бы, чтобы не менее трети общего стейка раскрыли конфликтующий форк после того, как 66% уже проголосовали честно. Аналогично, когда уровень оптимистичного подтверждения блока достигает ~87% стейка, злоумышленнику потребуется ≥20% того же стейка для двойной подписи — действия, за которое доказуемо применяется слешинг. Хотя в строгом теоретическом смысле это не абсолютная финализация, на практике оптимистичное подтверждение предоставляет сильные гарантии. Такие блоки можно считать финализированными почти во всех сценариях использования — поэтому на практике временем финализации Solana обычно называют 500–600 миллисекунд.

Для настоящей детерминированной финализации блок должен достичь максимальной блокировки в башне голосов, то есть получить подтверждение 32 последовательными голосами. Иными словами, поверх блока должны быть созданы ещё 32 блока, чтобы он считался «финализированным» или окончательно закреплённым в сети. С учётом требования в 32 слота и длительности слота ~0,4 секунды детерминированная финализация блока занимает ~12,8 секунды. Она достигается, когда глубина блокировки голосов делает откат невозможным.

Каковы ограничения текущего механизма консенсуса Solana?

Proof of History и Tower BFT помогли Solana добиться высокой пропускной способности и быстрых оптимистичных подтверждений. Однако эта архитектура имеет ряд ограничений, связанных со стоимостью, задержкой, работоспособностью и эксплуатацией валидаторов.

Высокие накладные расходы и стоимость голосования

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

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

Задержка финализации

Оптимистичное подтверждение выполняется быстро, но детерминированная финализация — нет. ~12,8 секунды — это медленно по сравнению с более новыми протоколами консенсуса, такими как Mysticeti от Sui, где заявлен срок финализации ~500 мс. Это создаёт проблемы для приложений, которым необходима абсолютная определённость при выполнении операций, например для бирж. На практике пользователи доверяют подтверждённым блокам. Однако сети всё равно приходится хранить длинную историю форков на случай небольших потенциальных реорганизаций до финализации. 

Разрыв между оптимистичным подтверждением и детерминированной финализацией — это компромисс: Tower BFT отдаёт приоритет работоспособности и сохраняет короткое окно для потенциального форка ценой более медленной финализации. Даже без атак или ошибок консенсуса финализация за ~12,8 секунды значительно уступает блокчейнам с быстрой финализацией и существующей инфраструктуре Web2.

Работоспособность и устойчивость к разделению сети

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

Это классическое ограничение BFT-консенсуса. В Solana нет встроенного механизма, допускающего временную недоступность значительной части валидаторов. Поэтому в экстремальных условиях работоспособность Solana страдала: протокол не мог корректно работать после падения доли участников ниже порога квалифицированного большинства, необходимого для консенсуса. Tower BFT приходилось продолжать создавать блоки, когда онлайн находилось менее 60% стейка. Такие блоки не могли получить оптимистичное подтверждение и могли быть отменены.

Эксплуатационная сложность для валидаторов

Tower BFT предъявляет к валидаторам множество требований: постоянная отправка транзакций голосования, надёжная сеть, обновления клиента, предотвращение сбоев и сохранение «состояния башни». Если валидатор перезапустится или потеряет последнее состояние башни, он рискует отдать голос, нарушающий предыдущее обязательство блокировки, и потерять баллы за голосование.

Зависимость протокола от непрерывного хеширования в Proof of History и распространения голосов через gossip означает, что валидаторам приходится прилагать значительные усилия, чтобы успевать за временем слота Solana в ~400 мс. Высокие требования Solana к оборудованию также существенны, хотя со временем снижаются. Кроме того, независимо от стейка все валидаторы должны голосовать в каждом слоте, чтобы максимизировать вознаграждения. Поэтому небольшие валидаторы в основном платят те же комиссии и выполняют ту же работу, что и крупные. Поскольку слоты лидера распределяются пропорционально стейку, валидаторы с большим стейком создают больше блоков и, следовательно, получают больше комиссий за голоса от других валидаторов. Возникает круговой поток стоимости, при котором комиссии за голосование фактически перераспределяют капитал в пользу валидаторов с более крупным стейком.

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

Таким образом, становится очевидно, что архитектура Tower BFT, несмотря на свою инновационность, создаёт значительную эксплуатационную сложность для валидаторов.

Как работает Alpenglow?

Alpenglow построен вокруг двух основных компонентов:

• Rotor: обновлённый протокол распространения блоков, основанный на существующей архитектуре Turbine и улучшающий её.
• Votor: новый протокол голосования, который заменяет Tower BFT, распространение голосов через gossip и Proof of History для участия в консенсусе.

В следующих разделах мы подробно рассмотрим эти компоненты.

Rotor: новый уровень распространения данных

Rotor — улучшенный протокол распространения блоков, основанный на существующей архитектуре Turbine в Solana. Ключевые улучшения касаются эффективности и простоты. В отличие от Turbine, который использует многоуровневую древовидную структуру с ветвлением 200, Rotor применяет одношаговую модель (2δ). 

Блоки разделяются на сегменты, после чего каждый сегмент кодируется в несколько шредов с помощью кодов Рида — Соломона для исправления стираний. Чтобы гарантировать подлинность шредов, лидер создаёт дерево Меркла из их хешей и подписывает корень. Каждый шред содержит свой путь в этом дереве и подпись лидера.

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

И лидер, и ретрансляторы шредов выбираются методом взвешенной по стейку выборки. Это означает, что каждая нода отвечает за передачу объёма данных, пропорционального её стейку. Благодаря кодированию для исправления стираний нодам достаточно получить часть шредов, чтобы восстановить исходный сегмент блока.

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

Архитектура Rotor также совместима с системами многоадресной рассылки, такими как DoubleZero, что обеспечивает гибкость при доставке блоков. Распространение блоков потребляет значительную пропускную способность: сейчас крупные валидаторы отправляют около 150 000 пакетов в секунду. Поэтому Rotor вводит модель, в которой ретрансляторы получают вознаграждение за распространение данных. Это согласует стимулы для поддержания производительности сети.

В техническом документе Alpenglow не определяется конкретный механизм расчёта или распределения вознаграждений. Однако там отмечается, что вознаграждения Rotor должны учитывать потреблённую пропускную способность: ноды, ретранслирующие больше данных, должны получать большую долю вознаграждений.

Что такое Blokstor?

Blokstor — это место, где ноды хранят полученные от Rotor данные блоков и управляют ими. Формально Blokstor представляет собой структуру данных для управления хранением сегментов. При получении шреда его содержимое добавляется в Blokstor, если выполнены определённые условия, включая следующие:

• Blokstor ещё не содержит шреда для этих индексов
• Действительная подпись лидера
• Действительный путь в дереве Меркла

Blokstor генерирует событие "Block(slot(b), hash(b) hash(parent(b)))" при получении первого полного блока b для slot(b). Blokstor также может выполнять процедуры восстановления для сбора и хранения альтернативных блоков для того же слота. Когда блок финализирован, Blokstor должен хранить в соответствующем слоте только этот блок.

Votor: новый механизм голосования и финализации

Votor — новый механизм голосования и финализации Alpenglow, который заменяет Tower BFT при нотаризации и финализации блоков. Для повышения эффективности и простоты он опирается на идеи из серии исследований Simplex и применяет их в контексте Proof of Stake. 

Simplex демонстрирует, что в системе Proof of Stake с чередующимися лидерами можно эффективно достичь византийского соглашения с помощью сообщений крайне малого размера при наличии строгой верхней границы сетевой задержки. На основе этих идей Votor достигает консенсуса за один или два раунда.

На высоком уровне Votor гарантирует, что для каждого слота существует либо сертификат пропуска, указывающий на пропуск слота, либо нотаризованный блок, продолжающий каноническую цепочку нотаризованных блоков. Для нотаризации блок должен иметь действительный сертификат. Вместо массового распространения голосов через gossip валидаторы передают легковесные сообщения голосования набору пиров, взвешенному по стейку. Это своего рода mesh-сеть с прямой отправкой, а не традиционный gossip Solana. После достижения кворума любая нода может агрегировать подписи в сертификат с помощью схемы подписей Boneh–Lynn–Shacham (BLS). Это устраняет необходимость в транзакциях голосования для каждого слота: ончейн закрепляется заголовок агрегированного сертификата.

Как работает механизм голосования Votor?

Votor использует многоуровневый параллельный механизм с двумя сценариями голосования:

• Fast-Finalization: если предложенный блок получает одобрение ≥80% стейка в первом раунде голосования, блок немедленно финализируется и создаётся Fast-Finalization Certificate. Финализация за один раунд возможна, поскольку 80% стейка значительно превышают порог квалифицированного большинства, поэтому второй раунд голосования не требуется.
• Slow-Finalization: если в первом раунде голосования блок получает одобрение <80%, но ≥60% стейка, Votor немедленно начинает второй раунд. Как только во втором раунде уровень одобрения достигает ≥60% стейка, создаётся Finalized Certificate.

Оба сценария выполняются параллельно, и блок финализирует тот, который первым достигает своего порога. Как только лидер завершает получение родительского блока, он может начать передачу следующего, пока голоса ещё собираются. Поэтому новый блок создаётся каждые ~400 мс, как и в прежнем консенсусе Solana. Если первый раунд не получает одобрения ≥80% стейка, Votor переходит ко второму раунду голосования. Пересечение стейка также гарантирует, что два конфликтующих блока не смогут одновременно достичь финализации.

Что представляет собой структура данных Pool в Votor?

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

Несколько валидаторов могут создать сертификаты почти одновременно. Однако любой сертификат, соответствующий порогу кворума, функционально эквивалентен для консенсуса независимо от того, какие именно валидаторы входят в набор подписей. Единственное исключение — Finalized Certificate, поскольку может потребоваться распространение до трёх различных подтверждений. Для одного слота никогда не существует более четырёх уникальных сертификатов всех типов, и каждый уникальный сертификат передаётся только один раз. Такой подход предотвращает спам голосами, но позволяет любой честной ноде создать и распространить сертификат, как только Pool зафиксирует кворум.

Основные выводы

Голоса передаются всем валидаторам в виде отдельных UDP-пакетов, а валидаторы запоминают полученные голоса для каждого слота и каждой ноды. Нотаризация и финализация конкретного блока в Votor определяются следующими тремя условиями:

• Одобрение ≥80% стейка в первом раунде голосования.
• Одобрение ≥60% стейка в первом и втором раундах голосования.
• Валидатор получает от другого валидатора действительный сертификат, указывающий, что блок финализирован.

Больше никакого Proof of History

Поскольку Rotor распространяет данные блока за один шаг, а целевая верхняя граница задержки Votor составляет ~150 мс (подробнее об этом в следующем разделе), децентрализованные часы в Solana больше не нужны. Достаточно простых локальных часов. Alpenglow заменяет Proof of History локальными таймерами ожидания.

Как работает механизм тайм-аутов Votor?

На практике система тайм-аутов работает следующим образом:

• Окно лидера: лидер отвечает за окно из четырёх слотов с длительностью Δblock ≈ 400 мс на слот.
• Получение данных или тайм-аут: как только родительский блок лидера нотаризуется, каждый валидатор запускает таймеры и заранее устанавливает четыре крайних срока — по одному на слот — по формуле t = now + Δtimeout + slotIndex * Δblock, где Δblock ≈ 400 мс. Обратите внимание: эти таймеры никогда не сбрасываются и служат верхними границами. Если шреды блока поступают вовремя, валидатор голосует по этому слоту сообщением NotarVote, а ожидающий тайм-аут не выполняет никаких действий. Если время истекает до поступления шредов, валидатор считает лидера недобросовестным или неработоспособным и отправляет SkipVote.
• Сертификация: для нотаризованных блоков создаётся Fast-Finalization Certificate или Finalized Certificate, как описано выше. Для пропущенных слотов также может быть создан Skip Certificate.

Alpenglow вводит систему, в которой каждый валидатор измеряет тайм-ауты локально и независимо. Поэтому Solana не нужны единые часы на основе хеширования, подобные Proof of History. Поскольку сообщение помещается в один UDP-пакет, а Rotor выполняет передачу за один шаг, граница в 400 мс реалистична и без хеширования. Валидаторам больше не придётся непрерывно вычислять хеши. Они смогут голосовать против блоков без блокировок, а альтернативным клиентам, таким как Firedancer, не потребуется воспроизводить реализацию Proof of History из клиента Agave.

Пропуск слотов

Валидаторы также могут пропустить слот, отправив сообщение SkipVote. Если SkipVote отправляет ≥60% стейка, создаётся Skip Certificate, а слот официально пропускается. Голоса за пропуск имеют тот же вес при расчёте вознаграждений, что и голоса за нотаризацию. Поэтому у валидатора нет стимула молчать, когда лидер действует неправильно. Обратите внимание: это может измениться после окончательного утверждения экономической модели Alpenglow.

Валидаторы отправляют SkipVote для слота, когда определяют, что не могут финализировать блок в этом слоте. Причиной может быть тайм-аут, отсутствие блока либо создание недействительного или некорректно сформированного блока. Если в первом слоте четырёхслотового окна лидера возникает любое из этих условий, валидаторы помечают всё окно как некорректное. Затем они перебирают оставшиеся слоты окна и отправляют SkipVote для каждого слота, по которому ещё не голосовали. Таким образом, всё окно из четырёх слотов можно обработать за один раунд пропуска. Каждый голос по-прежнему относится к одному слоту, но поскольку большинство валидаторов одновременно отправляет одинаковый пакет голосов, все три оставшихся слота достигают порога 60% примерно в одно время. Это не позволяет кластеру бездействовать ещё три пустых слота, ожидая тайм-аута офлайн-лидера.

Разумеется, это оставляет пробелы в производстве блоков. Однако благодаря быстрым сертификатам пропуска последовательность слотов не прерывается. Это упрощает выбор форка и повышает согласованность, поскольку сертификат пропуска служит каноническим «нулевым блоком» для этого слота, и все честные ноды принимают пропуск как результат. Конкурирующий форк не возникает, а пропуски не приводят к устойчивым форкам, что позволяет сохранить регулярный ритм производства блоков.

Вознаграждения валидаторов

Вознаграждения валидаторов в Votor зависят от участия в голосовании и создании сертификатов. Ноды, которые участвуют в консенсусе, голосуя за блок (NotarVote) или против него (SkipVote), получают одинаковое вознаграждение. Это стимулирует честное участие: ноды голосуют на основе собственного состояния, а не пытаются предсказать решение большинства или подстроиться под него.

Точная реализация механизма вознаграждений пока не определена.

Тесты производительности и результаты моделирования Alpenglow

Моделирование Anza показывает, что Alpenglow финализирует блок примерно за 100–150 мс — в зависимости от того, какой путь нотаризует блок: Fast-Finalization или Fallback (то есть медленная финализация). Целевая задержка пути Fast-Finalization составляет ~100 мс, а пути Slow-Finalization — ~150 мс.

Гистограмма задержки

Сетевая задержка задает фундаментальную нижнюю границу времени обмена данными в любой распределенной системе. Например, если лидер находится в Нью-Йорке, а большая часть стейка — в Европе, медианная односторонняя задержка при отправке данных нодой другим нодам сети может достигать примерно 200 миллисекунд. Для географически близких нод, например в одном дата-центре или регионе, задержка ниже. Для нод в странах Глобального Юга и других удаленных регионах она значительно выше.

• Сеть: сетевая задержка при отправке 1 бита другим нодам через интернет
• Rotor: насколько Rotor медленнее этой нижней границы
• Нотаризация: время получения нотаризованных голосов от 60% стейка (также можно провести еще один раунд голосования; после получения голосов может начаться финализация)
• Финальность: время финализации

Общая задержка до финальности в Alpenglow вдвое превышает нижнюю границу. Иными словами, накладные расходы консенсуса удваивают минимальную сетевую задержку. Поэтому, если самый длинный односторонний маршрут между лидером и квалифицированным большинством стейка занимает, например, ~70 мс (то есть RTT составляет ~140 мс), финальность по быстрому пути должна достигаться за 120–150 мс.

Гистограмма задержки из моделирования Anza показывает, что 65% стейка достигает финальности в пределах 50 мс сверх исходной сетевой задержки. Это означает, что большинство валидаторов голосуют практически сразу после получения данных.

Благодаря Alpenglow детерминированное подтверждение происходит значительно быстрее, чем в любой конкурирующей L1. Это приближает пользовательский опыт ончейн-приложений Solana к традиционным сервисам Web2.

Анализ безопасности и отказоустойчивости Alpenglow

Консенсус Alpenglow улучшает традиционный консенсус BFT, который сохраняет устойчивость к злоумышленникам, контролирующим до 33% стейка сети. Это обозначается как «3f + 1». Alpenglow снижает этот предел до 20% стейка сети на основе границы 5f + 1, представленной Мартином и Алвизи в работе Быстрый византийский консенсус. В нем используется модель устойчивости «20+20», где безопасность разделена на две составляющие:

• Византийские сбои ≤ 20%: безопасность сохраняется, если злоумышленники контролируют менее 20% совокупного стейка. Это значительная сумма в миллиарды долларов, а такую атаку было бы легко выявить и наказать. Таким образом, атакующий рискует потерять весь свой стейк, что делает подобные атаки экономически нецелесообразными.
• Незлонамеренные сбои ≤ 20%: живучесть сохраняется, если не более 20% совокупного стейка, помимо стейка злоумышленников, отключено, вышло из строя или иным образом не участвует в консенсусе. Сюда относятся сетевые сбои, ошибки конфигурации и программные ошибки. Таким образом, сеть может продолжать финализировать блоки, даже если значительное меньшинство валидаторов не отвечает.

Безопасность

Безопасность гарантируется при условии, что совокупный стейк злоумышленников составляет ≤20% и они не могут помешать участию как минимум 60% честного стейка в одной ветви. При этих условиях любой порог голосов, который протокол считает финальным — быстрый за один раунд или медленный за два, — достаточно высок, чтобы нельзя было достичь конфликтующего порога в другой ветви. Если злонамеренные валидаторы попытаются голосовать неоднозначно, то есть проголосуют за две разные ветви или создадут два разных блока в одном слоте, честные ноды в итоге получат их конфликтующие подписи. Это легко обнаружить. В идеале в будущем такие нарушения будут наказываться, например через слешинг. 

Кроме того, если лидер попытается создать недействительный блок, честные валидаторы просто откажутся за него голосовать. Модель прямого обмена данными для голосования в Alpenglow затрудняет изоляцию честной ноды или проведение eclipse-атаки на ее стейк: в конечном итоге злоумышленника разоблачат голоса честного большинства. В лучшем случае злонамеренный лидер сможет перевести консенсус на более медленный путь или вызвать задержку на один слот, но не сможет навсегда остановить или разделить цепочку.

Живучесть

Живучесть гарантируется в условиях частичной синхронности, пока соблюдаются пороги отказов. Это означает, что после некоторой сетевой задержки честные валидаторы смогут обменяться данными и собрать ≥60% стейка за определенный блок. Если отключено ровно 20% совокупного стейка, быстрый путь все еще может завершиться успешно, если проголосуют все оставшиеся честные ноды. Если отключено чуть больше 20% совокупного стейка, сеть будет стабильно использовать путь медленной финализации со вторым раундом голосования. Финальность по-прежнему гарантируется, хотя и достигается медленнее. Таким образом, незлонамеренные сбои в основном влияют на производительность, а не на безопасность.

Высокая устойчивость к сбоям

Alpenglow изначально спроектирован с высокой устойчивостью к сбоям для работы в сложных сетевых условиях. Иными словами, Alpenglow продолжит безопасно работать, даже если 20% стейка действует злонамеренно, а еще 20% не отвечает. 

Однако это не универсальное средство от всех возможных сбоев. Alpenglow значительно улучшает Solana, но не устраняет полностью риск остановок или сбоев сети при нарушении исходных допущений. Для создания новых блоков требуется ≥60% стейка, а злонамеренные действия ≥20% стейка могут помешать достижению консенсуса или вызвать сбой. Тем не менее в установленных пределах Alpenglow гарантирует безопасность и живучесть за один или два раунда голосования.

Ослабляет ли безопасность отказ от Proof of History?

Несмотря на фундаментальную роль в текущей работе Solana, отказ от Proof of History не ослабляет безопасность сколько-нибудь существенным образом. Как упоминалось выше, универсальная граница в 400 мс заменяет хеш-часы Proof of History. Даже при значительных задержках в сети пересечение стейка в Votor — то есть ≥80% за один раунд и ≥60% + ≥60% за два раунда — не позволяет честным валидаторам одобрить две разные ветви.

Однако это меняет гарантии живучести, поскольку живучесть зависит от синхронной доставки сообщений: она сохраняется, пока сообщения честных участников приходят в пределах этой задержки. Распространение данных за один переход в Rotor и голоса в одном пакете удерживают задержку в пределах 400 мс даже при высокой нагрузке.

В целом отказ от Proof of History устранит зависимость от непрерывного перебора хешей, а вместе с ней и векторы атак через задержку хеширования. Как сказано выше, он также изменит гарантии живучести. Но отказ от Proof of History не ослабляет безопасность сколько-нибудь существенным образом.

Основные выводы

Alpenglow немного снижает устойчивость к византийским сбоям, но взамен обеспечивает детерминированную финальность менее чем за секунду, стабильную работу при масштабных незлонамеренных сбоях и более простое выявление злонамеренных валидаторов. Основные выводы можно сформулировать так:

• Два конфликтующих блока не могут быть финализированы, если только ≥20% стейка не подпишет оба блока. Такое действие легко доказать и наказать.
• Solana продолжит финализировать блоки, пока ≥60% стейка может обмениваться данными, даже если весь остальной стейк отключен.
• В худшем случае финализация переходит ко второму раунду голосования с целевой задержкой ~150 мс. Поэтому атаки сначала снижают скорость цепочки и лишь затем начинают угрожать безопасности.
• Нарушение 20%-го предела византийских сбоев требует запретительных затрат. Менее серьезные нарушения можно выявлять и наказывать социально и экономически после запуска слешинга в основной сети.

Как Alpenglow повлияет на валидаторов?

Расходы на голосование — главный барьер для запуска валидатора Solana. Строгого минимального количества SOL для работы валидатора нет. Однако отправка транзакций голосования в каждом слоте, необходимая для участия в консенсусе, может обходиться в ~1 SOL в день.

Alpenglow призван заменить транзакции голосования в каждом слоте компактной системой сертификатов, которая фактически устраняет комиссии за голосование в их нынешнем виде. Каждый валидатор будет рассылать легковесные сообщения с голосами всем остальным нодам. После достижения кворума любая нода сможет объединить эти подписи в сертификат с помощью схемы подписей BLS. Поскольку голоса агрегируются с помощью BLS, ончейн закрепляется только заголовок сертификата. На практике это устранит ежедневные расходы в размере ~1 SOL на валидатора. 

Как упоминалось выше, в Alpenglow каждое предложение блока оценивается одновременно по двум путям голосования:

• Fast-Finalization (один раунд)
  • Запускается, когда количество нотаризованных голосов за определенный блок в первом раунде достигает ≥80% стейка
  • Создает сертификат Fast-Finalization
  • Целевая задержка составляет ~100 мс
• Slow-Finalization (два раунда)
  • Запускается, когда количество нотаризованных голосов за определенный блок в первом раунде достигает ≥60% стейка
  • Создает сертификат финализации после того, как количество нотаризованных голосов во втором раунде достигает ≥60% стейка
  • Целевая задержка составляет ~150 мс

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

Новая архитектура положительно влияет на работу валидаторов:

Снижение операционных расходов 

Отмена комиссий за голосование значительно снижает барьер для новых валидаторов. Кроме того, из-за комиссий за голосование небольшие валидаторы сильнее зависели от инфляционных вознаграждений во время медвежьих рынков. Их отмена может потребовать дальнейшего обсуждения инфляции Solana, учитывая неоднозначное голосование по SIMD-228. В рамках обсуждаемой сейчас реализации Alpenglow такое снижение уменьшит минимальное количество SOL для прибыльной работы с ~4850 SOL (~800 тыс. USD) до ~450 SOL (~75 тыс. USD) согласно расчетам в калькуляторе прибыли валидатора Cogent Crypto.

Упрощенное управление ключами 

Валидаторам Solana больше не потребуется подписывать голоса в каждом слоте. Поэтому ключ идентификации валидатора можно будет хранить в аппаратном модуле безопасности (HSM) без рисков для производительности, что существенно снизит риски горячих кошельков.

Снижение сетевой нагрузки в лидерском слоте

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

Отсутствие расчетов блокировки

Экспоненциальная таблица блокировок Solana в стиле Tower удаляется. Теперь валидаторам нужно хранить в памяти только последнюю цепочку сертификатов, что сокращает время перезапуска.

Как Alpenglow повлияет на провайдеров RPC?

Новая архитектура в основном положительно влияет на работу провайдеров RPC, хотя некоторые аспекты могут вызвать проблемы с масштабированием:

Упрощенные уровни подтверждения 

Новый уровень финальности устранит исторический разрыв между уровнями confirmed (то есть оптимистическим) и finalized (то есть укорененным) среди уровней подтверждения. Например, любую UX-логику, которая ожидает два уровня подтверждения — скажем, показывает индикатор загрузки до финализации, — можно будет свести к одной проверке сертификата.

Уменьшение размера реестра

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

Узкое место при распределении через WebSocket

С Alpenglow опрашивать транзакции больше не имеет смысла: финальность наступает за ~100–150 мс и кодируется в одном сертификате. Логичнее получать сведения о финальности через push-канал, который остается открытым на протяжении всей работы приложения, браузера или бота и передает каждый новый сертификат всем подписанным клиентам. Вместо миллионов небольших опросов HTTP узким местом станут сотни тысяч сокетов реального времени.

Актуальность кеша в реальном времени

Любой кеш, который хранит данные аккаунта дольше четверти секунды, может отдавать устаревшие данные, поскольку сертификаты подтверждают блок за 100–150 мс. Пограничным кешам, CDN и прокси уровня 7 потребуются чрезвычайно короткие TTL или механизмы очистки, учитывающие сертификаты.

Каковы сроки разработки Alpenglow?

Alpenglow официально представили на конференции Accelerate в Нью-Йорке в конце мая. Следующий этап — публикация формального документа Solana Improvement Document (SIMD), после которой сообщество сможет обсудить предложение через GitHub, форумы управления Solana и Discord-сервер Solana Tech.

После периода общественного обсуждения сообщество валидаторов проведет ончейн-голосование по управлению. Параллельно новая архитектура пройдет всестороннее тестирование производительности и безопасности.

Если все этапы пройдут по плану, развертывание в основной сети Solana ожидается к началу следующего года.

Риски и открытые вопросы Alpenglow

Новый алгоритм консенсуса

Переход на новый протокол консенсуса — масштабная задача, но для него уже есть значимый прецедент. Слияние Ethereum в 2022 году показало, что крупная действующая сеть может успешно изменить основной механизм консенсуса, перейдя с Proof-of-Work на Proof-of-Stake без нарушения работы. Иными словами, рисков по-прежнему много, но это не совсем неизведанная территория.

Для такого перехода также потребуются руководства по миграции, чтобы приложения, SDK, кошельки и боты незаметно не перестали работать, когда Alpenglow объединит уровни подтверждения confirmed и finalized в одну проверку сертификата. Любой код, который явно опрашивает два уровня подтверждения или по умолчанию использует уровень confirmed, перестанет работать. До запуска Alpenglow экосистеме потребуются согласованные усилия по обновлению документации, предупреждений линтера, методов RPC и общей архитектуры кода. 

Управление

Риск, связанный с управлением, — еще один фактор, который необходимо учитывать. Недавнее голосование по SIMD-228 показывает, что Solana работает как действительно децентрализованная сеть, где принятие предложений не гарантировано, даже если их поддерживают ключевые разработчики и известные участники сообщества. Однако предстоящие изменения Alpenglow, особенно снижение расходов на голосование, в целом выгодны валидаторам, прежде всего небольшим операторам. Поэтому мы считаем вероятность сопротивления со стороны системы управления сравнительно низкой.

Вознаграждения

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

MEV

Alpenglow также фундаментально изменит нынешнюю структуру MEV в Solana. Задержка по-прежнему играет ключевую роль для MEV, поскольку некоторые прибыльные стратегии зависят от зеркалирования трафика TPU или массовой отмены и замены транзакций в определенном порядке до их оптимистического подтверждения. Сейчас все это происходит в окне ~500–600 мс, которое Alpenglow стремится сократить до ~150 мс. На первый взгляд лидеры, особенно валидаторы, уже использующие специализированную инфраструктуру создания блоков, смогут получать большую долю MEV. При этом независимые участники арбитража задержек могут лишиться преимущества, если не продолжат создавать еще более быстрые и детализированные торговые системы.

Несколько одновременных лидеров

По сравнению с текущей архитектурой консенсуса Solana архитектура Alpenglow гораздо лучше подходит для внедрения модели с несколькими лидерами, известной как Multiple Concurrent Leaders (MCL). Как отметил Анатолий Яковенко, первый прототип MCL может включать запуск двух экземпляров Alpenglow, которые используют один набор Rotor и одновременно выпускают все шреды. Rotor будет распределять параллельные потоки, а Votor — нотаризовать каждый канал. Однако при этом возникает несколько вопросов на уровне исполнения. В частности:

• Как разделить наборы операций записи, чтобы блоки двух лидеров никогда не блокировали один и тот же аккаунт, а если это все же произойдет, разрешение конфликта было детерминированным и недорогим?
• Как объединить сертификаты отдельных каналов в один канонический корень состояния без удвоения затрат на воспроизведение?
• Какая логика рынка комиссий должна применяться, когда каналы конкурируют за активы?
• Какие межканальные стратегии MEV станут возможны?
• Сможет ли один валидатор с крупным стейком доминировать в одновременных слотах без ограничений для каналов? 

Архитектура Alpenglow устраняет препятствия на уровне консенсуса и делает MCL реалистичным пунктом дорожной карты. Однако пока эти открытые вопросы не решены, это остается перспективной задачей на будущее.

Заключение

В этом отчете мы рассмотрели основные компоненты Alpenglow и то, как они меняют модель консенсуса Solana. Мы также проанализировали технические улучшения, изменения в экономике валидаторов, влияние на уровне сети и преимущества для производительности, простоты и масштабируемости.

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

Отказ от Proof-of-History (PoH) столь же символично меняет идентичность сети. Практическое значение PoH часто преувеличивали, но эта технология долгое время считалась ключевой инновацией Solana, занимала заметное место в технических обзорах и стала неотделима от бренда. Ее удаление знаменует конец одной эпохи и начало другой. Solana взрослеет.

Дополнительные ресурсы

• Слайды презентации Alpenglow на Accelerate — Roger Wattenhofer
• Alpenglow: новый консенсус для Solana — блог Anza
• Эталонная реализация Alpenglow — GitHub
• Технический документ Alpenglow — Quentin Kniep, Jakub Sliwinski, Roger Wattenhofer
• Консенсус в Solana — блог Helius
• Масштабируйся или умри на Accelerate 2025: представляем Alpenglow — новый консенсус Solana — видео на YouTube