Конкурс безопасности Solana на 50 000 SOL не охватил атаку на часы, раскрытую несколькими месяцами ранее

На конференции USENIX Security — одной из ведущих рецензируемых конференций в этой области — 12 августа исследователи представили атаку на Proof-of-History (механизм логических часов Solana), о которой они конфиденциально уведомили разработчиков Solana в декабре 2025 года. Спустя семь дней компания Anza — разработчик клиента валидатора Agave — закрыла приём заявок на конкурс Alpenglow с призовым фондом 50 000 $SOL, и, судя по правилам, атака оказалась вне его области охвата.

В статье описан протокольно-корректный метод, позволяющий назначенному лидеру растягивать эффективное окно создания блока и подавлять предложения честных лидеров в форк-ассистированном варианте. Метод опирается на Proof-of-History и TowerBFT — логические часы Solana и построенный поверх них механизм консенсуса, — то есть на компоненты, которые Alpenglow призван заменить, но которые в Agave 4.2 ещё не были вытеснены из основной сети.

Этот результат поднимает два отдельных вопроса: входила ли атака в область охвата конкурса и оставляет ли сам переход протокола пространство для риска.

Правила конкурса исключали поведение, достижимое только при неактивном Alpenglow. Публичные проектные документы указывают, что точный устаревший путь из статьи должен стать недостижимым после активации, однако ни Anza, ни Solana Foundation не опубликовали отдельного решения по этой статье или анализа реализации.

Как лидер может растянуть часы Solana

Proof-of-History, или PoH, использует последовательную хеш-цепочку, чтобы задать Solana логические часы. Валидаторы продолжают продвигать своё локальное представление этих часов, когда назначенный лидер не публикует блок немедленно.

По словам исследователей, вредоносный назначенный лидер может придержать протокольно-корректный блок, пока честные валидаторы уходят вперёд, а затем выпустить блок, привязанный к более ранней точке логического времени. Если валидаторы принимают эту ветку, они выравнивают своё состояние PoH по более ранней точке блока. Исследователи называют такой сброс «повторной привязкой» (re-anchoring).

Time Inflation, или TI, повторяет этот приём, чтобы дать атакующему больше физического времени на выбор транзакций, пока логическое время движется медленнее. Fork-Assisted Time Inflation, или FTI, объединяет этот сброс с правилом выбора форка в TowerBFT.

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

Модель угроз предполагает, что противник владеет менее чем 33% стейка — в пределах границы отказов в одну треть, которую обычно рассчитаны выдерживать византийско-устойчивые протоколы, — и не контролирует сетевой планировщик. Она также предполагает известное расписание лидеров, взвешенное по стейку, частичную синхронность и доставку честного блока честным валидаторам в течение одного номинального слота после стабилизации сети.

Для атакующего, контролирующего ℓ последовательных четырёхслотовых раундов лидера, эксперименты используют консервативную, не зависящую от стейка максимальную задержку в 4ℓ + 1 единиц слотов. Один раунд соответствует параметру задержки в пять единиц слотов.

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

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

Что показывают публичные данные

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

Такая картина согласуется с мотивационным каналом TI: более длинное физическое окно создаёт больше возможностей для отбора транзакций с комиссиями — преимущество в упорядочивании транзакций того типа, которое в отрасли обсуждают под названием maximal extractable value, или MEV.

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

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

Почему конкурс Solana Alpenglow, вероятно, исключил эту атаку

Приём заявок на конкурс Alpenglow закрылся 19 августа в 16:00 UTC. Правила охватывали консенсусную поверхность с активной функциональностью Alpenglow, интеграционный код, поведение которого изменилось из-за активации Alpenglow, и путь миграции с TowerBFT на Alpenglow.

Поведение, достижимое только при неактивном Alpenglow, относилось к домену TowerBFT и находилось вне конкурса. Ранее публично известные проблемы также не допускались.

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

Что меняет Alpenglow

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

Эти решения устраняют предпосылки, используемые TI и FTI: повторную привязку PoH и выбор форка TowerBFT. В публичных материалах отсутствует анализ Anza или Solana Foundation, который сопоставлял бы каждый шаг атаки с поставляемым кодом Alpenglow или исключал бы аналогичную проблему в логике миграции.

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

Авторы также сообщили, что к моменту публикации меры по снижению риска не были полностью развёрнуты.

В обзоре Solana Foundation, посвящённом Agave 4.2, говорилось, что клиент содержал код Alpenglow для общественных тестовых кластеров, но не активировал новый консенсус в основной сети; активация ожидалась в Agave 4.3.

Похоже, что описанная в статье атака на устаревший PoH не попала в конкурс на 50 000 $SOL, а Alpenglow спроектирован так, чтобы устранить её точные предпосылки. До активации — ожидаемой в Agave 4.3 — и публичного ответа на уровне реализации переход остаётся нерешённой частью этой истории.