Обновление Agave 4.3: всё, что нужно знать

Введение

С выпуском Agave 4.3 Solana готовится, пожалуй, к крупнейшему обновлению протокола в своей истории. В цикле выпуска 4.3 появится Alpenglow — долгожданный новый механизм консенсуса Solana. Кульминацией станет «Alpenswitch»: скоординированный переход основной сети с TowerBFT.

С момента запуска архитектура консенсуса Solana строилась на Proof of History и TowerBFT. Валидаторы голосуют, отправляя транзакции, которые обрабатываются и включаются в блоки вместе с обычными пользовательскими транзакциями. Финальность достигается по мере накопления этих голосов в течение 32 слотов. Поэтому время достижения финальности в Solana составляет около 12,8 секунды при длительности слота 400 миллисекунд.

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

Alpenglow заменяет «PoH + TowerBFT» на Votor — протокол, в котором валидаторы обмениваются голосами вне основного конвейера транзакций. Он объединяет эти голоса в криптографические сертификаты. Целевое время достижения финальности — около 150 миллисекунд.

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

Транзакции голосования исчезнут из блоков, confirmed и finalized фактически сравняются, а потоковая инфраструктура получит новые данные для различения конкурирующих банков в одном слоте.

В этой статье мы разберём работу Alpenglow и изменения, которые Votor вносит в производство блоков и достижение финальности. Также рассмотрим другие важные изменения, которые появятся в цикле выпуска Agave 4.3.

Поэтапное развёртывание: сначала Votor, затем Rotor

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

Agave 4.3 добавляет Votor, но сохраняет существующий протокол распространения блоков Turbine. Rotor был прямо исключён из SIMD-0326 — предложения, регулирующего первоначальную активацию Alpenglow. Для его развёртывания потребуется отдельный SIMD. Первый этап изменит способ достижения консенсуса валидаторами, но пока не затронет передачу данных блоков по сети.

Votor

Votor заменяет транзакции голосования и систему блокировок TowerBFT более прямым протоколом взаимодействия между валидаторами. В TowerBFT валидаторы голосуют, отправляя транзакции, которые включаются в блоки и со временем накапливают достаточную глубину блокировки для финализации блока. В Votor валидаторы напрямую обмениваются подписанными сообщениями с голосами, а протокол объединяет эти подписи в компактные сертификаты.

Вместо накопления голосов в течение 32 слотов Votor может финализировать блок после одного или двух раундов голосования. Целевое время достижения финальности составляет около 150 миллисекунд по сравнению с примерно 12,8 секунды в TowerBFT.

В Votor одновременно действуют два пути к финальности.

Если в первом раунде блок заверит не менее 80% стейка, эти голоса можно объединить в Fast-Finalization Certificate, после чего блок немедленно становится финальным. Это быстрый путь протокола, для которого достаточно одного раунда голосования.

Если порог в 80% не достигнут, блок всё равно может продвинуться, если за его заверение проголосовало более 60% стейка. В результате формируется Notarization Certificate, позволяющий провести второй раунд голосования. Когда более 60% стейка отдаёт голоса за финализацию по двухраундовому пути, формируется Finalization Certificate, и блок становится финальным.

Таким образом, полный протокол предусматривает пять типов голосов: Notarization, Notarization Fallback, Skip, Skip Fallback и Final. Различные сочетания этих голосов формируют сертификаты заверения, резервного пути, пропуска или финализации. Эти сертификаты служат компактным криптографическим доказательством того, что достаточная доля стейка согласилась с результатом слота.

Votor продолжает работу даже при наличии всего 60% доступного честного стейка. До 20% стейка может вести себя злонамеренно, а ещё 20% — находиться офлайн или не отвечать. Это осознанный компромисс: Alpenglow отказывается от традиционного для BFT-систем порога византийских отказов в одну треть в пользу модели устойчивости 20+20, лучше переносящей сбои и недоступность валидаторов.

Votor также отказывается от Proof of History как часов консенсуса. Вместо этого валидаторы используют локальные таймеры ожидания. Если валидатор достаточно долго не получает приемлемый блок, он может проголосовать за пропуск и позволить консенсусу двигаться дальше. По сравнению с TowerBFT это упрощает связь между отсчётом времени и консенсусом.

Rotor

Rotor не входит в Agave 4.3, и дата его активации пока не опубликована. Поэтому после активации Votor данные блоков продолжит передавать Turbine. Rotor и механизм интеллектуальной выборки его ретрансляторов позднее пройдут отдельный процесс рассмотрения и развёртывания.

Важно, что Solana не нужно ждать Rotor для достижения финальности менее чем за секунду. Текущий план развёртывания Alpenglow предполагает финальность примерно за 150 мс с Votor в Agave 4.3 при сохранении Turbine. Rotor должен дополнительно улучшить распространение блоков и повысить эффективность общей архитектуры Alpenglow, но он не является обязательным условием для новой модели финальности Votor.

Конец транзакций голосования

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

Исторически транзакции голосования составляли около трёх четвертей всех записанных ончейн-транзакций, хотя с увеличением ёмкости блоков эта доля снизилась. Транзакции голосования недороги — 5 000 лампортов — и потребляют лишь небольшую долю общих вычислительных ресурсов, около 5%. Однако они искусственно увеличивают общий счётчик транзакций и объём реестра.

В Alpenglow валидаторы вместо этого напрямую обмениваются сообщениями с голосами, подписанными с помощью BLS. Компонент Agave ConsensusPool отслеживает полученные голоса и объединяет достаточную долю стейка в сертификаты, с помощью которых Votor продвигает или финализирует консенсус.

Это не означает, что доказательства участия валидаторов исчезнут из реестра. В блоках Alpenglow появится новый нижний колонтитул с информацией о консенсусе. В текущей реализации Agave BlockFooterV1 может содержать последний сертификат финализации, а также notar_reward_cert и skip_reward_cert. Сертификаты вознаграждений включают агрегированную подпись BLS и битовую карту, указывающую проголосовавших валидаторов.

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

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

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

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

Alpenglow также устраняет одно из давних различий в Solana: разрыв между уровнями подтверждения confirmed и finalized.

Сегодня приложения выбирают один из трёх уровней подтверждения. processed предоставляет самые свежие данные, но не даёт гарантий на уровне всего кластера. confirmed означает, что за блок проголосовало сверхбольшинство стейка; обычно этот статус достигается за один-два слота. finalized обеспечивает детерминированную финальность, но в TowerBFT для этого блок должен достичь максимальной блокировки голосов. Поэтому между подтверждением и финализацией проходит около 32 слотов. Обычно confirmed рекомендуется для чувствительных к задержке RPC-запросов, а finalized — когда требуется более строгая гарантия.

На практике confirmed оказался чрезвычайно надёжным: ни один оптимистично подтверждённый блок Solana впоследствии не остался нефинализированным. Однако гарантия протокола всё равно слабее. Подтверждённый блок ещё не является детерминированно финальным. Поэтому мостам, биржам, расчётным системам и другим приложениям, которые не могут допустить даже такой остаточный риск редкого события, исторически приходилось ждать finalized.

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

Для разработчиков это означает, что после Alpenswitch confirmed и finalized фактически указывают на одно и то же состояние консенсуса. В день активации существующим приложениям не нужно менять настройку уровня подтверждения, поскольку интерфейс RPC по-прежнему принимает processed, confirmed и finalized. Однако разница в задержке между двумя последними исчезает.

Обычные потребители RPC не увидят различия между двумя путями финализации Votor. Независимо от того, достигнет ли блок 80-процентного порога быстрой финализации за один раунд или будет финализирован через двухраундовый путь с порогом 60%, внешний результат будет одинаковым.

Несколько блоков-кандидатов

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

Слот Solana — это временное окно, в котором лидер может создать блок. А bank — локальное представление валидатором состояния, полученного при выполнении конкретного блока-кандидата. Эти понятия всегда различались, и конкурирующие банки существовали и раньше. Однако большая часть рабочей инфраструктуры традиционно считала слоты и блоки синонимами.

С Alpenglow полагаться на это предположение становится всё опаснее.

Agave 4.3 расширяет Geyser — интерфейс валидатора для потоковой передачи обновлений аккаунтов, транзакций, записей и блоков — новым идентификатором: bank_id. Новые обратные вызовы с учётом банков, включая update_account_for_bank, notify_transaction_for_bank, notify_entry_for_bank и notify_block_metadata_for_bank, связывают событие с конкретным банком, который его создал. Уведомления о статусе на уровне банка также содержат bank_id. Старые обратные вызовы сохранены в версии 4.3 для совместимости, но объявлены устаревшими и будут удалены в следующем основном выпуске Agave.

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

На следующих этапах Alpenglow наличие нескольких банков для одного слота станет обычной частью работы валидатора.

Самый наглядный пример — быстрая передача лидерства, один из компонентов Alpenglow, который будет развёрнут после первоначальной активации Votor. Лидер может оптимистично начать строить блок на родительском блоке, который, по его ожиданиям, примет консенсус. Если Votor решит, что родительский блок следует пропустить, лидер сможет сменить его и перестроить блок в оставшееся время своего лидерского окна. Внутри системы это означает замену одного банка другим для того же слота. Agave уже содержит механизм UpdateParent, необходимый для представления такого переключения. Быстрая передача лидерства не входит в первоначальную активацию Alpenglow в Agave 4.3 и, как ожидается, будет развёрнута в версии 4.4.

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

Недавнее изменение снизило MAX_ALTERNATE_BLOCKS_PER_SLOT с 11 до 6. Поэтому валидатору нужно хранить не более семи блоков-кандидатов для одного слота. В конечном итоге консенсус сводит эти варианты к единой истории. В Votor для заверения требуется более 60% стейка. Два конфликтующих блока не могут одновременно получить действительные сертификаты заверения без существенной доли стейка, проголосовавшей за оба. При допущении Alpenglow, что византийски ведёт себя менее 20% стейка, конфликтующие сертификаты заверения невозможны без нарушения предположений протокола о безопасности.

Практический вывод для потребителей Geyser прост: перестаньте индексировать временное состояние только по слоту. Изменения аккаунтов, транзакции, записи и метаданные блоков следует отслеживать отдельно для каждого (slot, bank_id), пока консенсус не определит сохранившийся банк. Если для того же слота появится другой банк, его события относятся к отдельному состоянию-кандидату и не должны незаметно перезаписывать события первого банка.

Допуски валидаторов

Сейчас транзакции голосования — крупнейшая статья расходов при эксплуатации валидатора Solana. В TowerBFT валидаторы платят стандартную комиссию за каждую отправку голоса, что в сумме составляет около 2 SOL за эпоху. Alpenglow заменяет комиссии за транзакции сбором, который раз в эпоху взимается с валидаторов, допущенных к активному набору консенсуса. Он называется Validator Admission Ticket (VAT).

Основа для этого перехода уже работает. Регистрация открытых ключей BLS, описанная в SIMD-0387, была активирована в основной сети в июле. Вскоре после неё активировали переключатель функции VAT — SIMD-0357. Votor использует подписи BLS, чтобы объединять подписи множества валидаторов в единый компактный сертификат. Для участия в Alpenglow каждый валидатор должен зарегистрировать открытый ключ BLS в своём аккаунте голосования. После активации переключателя VAT валидаторы без такого ключа уже исключаются из набора голосующих.

До активации Alpenglow валидаторы продолжат отправлять обычные транзакции голосования и платить связанные с ними комиссии. На этом этапе VAT в основном служит фильтром допуска. Подходящие валидаторы должны иметь ключ BLS и входить в число 2 000 валидаторов с наибольшим стейком, соответствующих требованиям. После включения Alpenglow начнёт взиматься VAT, а транзакции голосования исчезнут.

После активации Alpenglow допуск будет пересчитываться на границах эпох. В аккаунте голосования валидатора должны быть зарегистрированный ключ BLS и достаточное количество SOL для оплаты допуска и освобождения от арендной платы. Если требованиям соответствуют более 2 000 аккаунтов, система ранжирует их по размеру стейка и допускает валидаторов с наибольшим стейком. Затем она списывает плату непосредственно с аккаунта голосования каждого допущенного валидатора и отправляет её на аккаунт сжигания Solana. Поэтому валидаторам необходимо поддерживать достаточный баланс аккаунта голосования. В прежней системе комиссии за транзакции голосования списывались с идентификационного аккаунта валидатора.

В исходных предложениях Alpenglow и VAT была указана плата 1,6 SOL за эпоху — около 80% от примерно 2 SOL, которые валидатор ранее тратил на транзакции голосования. Эта сумма рассчитывалась исходя из исторической целевой длительности слота Solana в 400 миллисекунд. SIMD-0525 вместо этого масштабирует VAT вместе с длительностью слота. При длительности слота 200 миллисекунд допуск будет стоить 0,8 SOL.

VAT также меняет назначение этих средств. Сейчас базовая комиссия в 5 000 лампортов за транзакцию голосования делится пополам: 50% сжигается, а 50% получает лидер блока. VAT, напротив, полностью отправляется на аккаунт сжигания. Однако основная цель VAT — не сделать SOL существенно более дефляционным. Механизм должен сохранить экономическую стоимость входа в набор консенсуса после исчезновения комиссий за транзакции голосования.

Безопасность и готовность

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

С мая операторы валидаторов поддерживают отдельный Alpenglow Community Cluster, который вырос до более чем 100 нод. Операторы используют настоящее оборудование валидаторов и реальные сетевые конфигурации. Это позволяет тестировать Alpenglow при географическом распределении, различной задержке, разных конфигурациях ПО, перезапусках и операционных ошибках, которые трудно воспроизвести в контролируемой среде.

Одна из важнейших задач кластера — тестирование самого Alpenswitch. Операторы не ограничиваются проверкой работы Votor в уже переведённом на Alpenglow кластере, а многократно отрабатывают переход с TowerBFT на новую систему консенсуса.

Roger Wattenhofer

@TheWattenhofer

We just had the first successful Alpenswitch on our Alpenglow community cluster! The @solana finalization time improved 100x. Thanks to everybody participating. Watch it live: https://ag.validblocks.com/ https://ag-community-status.stakingfacilities.com/

9 мая 2026 г., 6:59 PM

Alpenglow также прошёл специальную проверку на устойчивость к атакам. В августе Anza открыла двухнедельный конкурс Alpenglow Bug Bounty с призовым фондом до 50 000 SOL. В отличие от постоянной программы Agave, конкурс был посвящён исключительно новому стеку консенсуса, включая Votor, проверку подписей и сертификатов BLS, допуск валидаторов и путь миграции с TowerBFT на Alpenglow. Участие было значительным: Anza сообщила о более чем 300 заявках и заявила, что выплатит более 25 000 SOL в качестве вознаграждений.

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

Согласно рекомендациям для валидаторов, ни Frankendancer, ни полный Firedancer не будут поддерживать само короткое окно миграции с TowerBFT на Alpenglow. Поэтому операторам Firedancer следует заранее настроить переключение на валидатор Agave перед Alpenswitch, оставаться на Agave во время перехода, а затем вернуться на Firedancer, когда кластер начнёт нормально работать под управлением Alpenglow.

Как на самом деле происходит Alpenswitch

Alpenglow не включается повсеместно в произвольный момент времени. После активации соответствующей функции протокол устанавливает границу миграции через 5 000 слотов. TowerBFT продолжает работать, пока валидаторы не перейдут эту границу и не найдут достаточно надёжно подтверждённый блок. Затем валидаторы подписывают выбранный генезис-блок Alpenglow с помощью BLS и напрямую распространяют эти генезис-голоса друг другу.

Переход происходит, когда один и тот же генезис-блок подписывает не менее 82% стейка, в результате чего создаётся генезис-сертификат Alpenglow. Получившие и проверившие его валидаторы отключают TowerBFT после генезис-блока и инициализируют Votor из согласованного состояния. Затем сертификат распространяется по набору валидаторов, переводя оставшиеся ноды через границу миграции.

Этот сертификат предоставляет операторам инфраструктуры удобный способ определить, на какой стороне Alpenswitch находится кластер.

Agave 4.3 добавляет новый метод RPC getAgGenesisCert. До миграции нода Agave 4.3 возвращает null. После перехода кластера она возвращает генезис-сертификат Alpenglow, включающий генезис-блок и агрегированную подпись BLS. Более старая нода, которая не поддерживает этот метод, вместо этого возвращает Method not found. CLI предоставляет ту же информацию с помощью команды: solana alpenglow-genesis-info.

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

Новые криптографические системные вызовы

Agave 4.3 также расширяет набор криптографических инструментов SVM новыми примитивами среды выполнения для операций, которые слишком дорого выполнять непосредственно в sBPF.

Два главных нововведения — хеширование SHA-512 и модульное возведение больших целых чисел в степень. Оба дополнения активируются отдельными функциями и не затрагивают существующие программы. Программы, которые решат их использовать, смогут делегировать ресурсоёмкие криптографические вычисления оптимизированным нативным реализациям в среде выполнения валидатора.

Модульное возведение больших целых чисел в степень

SIMD-0529: системный вызов ModExp для больших целых чисел добавляет sol_big_mod_exp — системный вызов для вычисления:

result = (base ^ exponent) mod modulus

Модульное возведение в степень — фундаментальная операция, лежащая в основе проверки подписей RSA, криптографических аккумуляторов, некоторых проверяемых функций задержки и других теоретико-числовых протоколов. Реализация этой операции с помощью целочисленной арифметики произвольной точности непосредственно в программе SVM требует чрезвычайно больших вычислительных ресурсов, особенно при распространённых размерах ключей RSA в 2048, 3072 и 4096 бит.

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

Самый очевидный сценарий использования — проверка RSA. Например, программа, проверяющая обычную подпись RSA, может вызвать sol_big_mod_exp с распространённым открытым показателем степени 65537 вместо самостоятельной реализации возведения больших целых чисел в степень. Системный вызов намеренно ограничивается арифметическим примитивом: программы по-прежнему отвечают за хеширование, заполнение RSA вроде PKCS#1 v1.5 или PSS, проверку ключей и специфичное для протокола разделение доменов.

Он также может эффективно выполнять модульное сокращение больших целых чисел. При передаче показателя степени 1 операция сводится к следующему:

base mod modulus

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

По замыслу решение похоже на прекомпилированный контракт ModExp в Ethereum, представленный в EIP-198, а модель учёта вычислительных ресурсов использует формулу сложности операций из EIP-198. Однако побайтовой совместимости с Ethereum нет. Solana предоставляет эту функциональность через нативный ABI системного вызова, использует входные данные с порядком байтов от младшего к старшему и требует, чтобы модуль был нечётным целым числом больше единицы. Чётные модули отклоняются.

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

SHA-512

Второе дополнение значительно проще, но полезно уже сейчас.

SIMD-0512: системный вызов Sha512 добавляет sol_sha512, предоставляя ончейн-программам прямой доступ к хеш-функции SHA-512 через среду выполнения валидатора. Его интерфейс соответствует существующим системным вызовам Solana sol_sha256, sol_keccak256 и sol_blake3 и возвращает стандартный 64-байтовый хеш SHA-512.

SHA-512 — один из основных примитивов Ed25519, схемы подписи, которую сама Solana широко использует. И Agave, и Firedancer уже зависят от SHA-512 внутри системы, но до этого изменения программы SVM не имели прямого доступа к оптимизированной реализации. Программам, которым требовался SHA-512, приходилось реализовывать алгоритм самостоятельно.

С точки зрения вычислительных ресурсов разница существенна. По оценке SIMD, хеширование короткого ввода с помощью реализации sBPF стоит тысячи CU, а та же операция через системный вызов — менее 100 CU. sol_sha512 использует ту же общую модель расчёта вычислительной стоимости, что и существующий системный вызов SHA-256 в Solana.

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

Заключение

Главное изменение Agave 4.3 — Alpenglow. Он заменяет TowerBFT на Votor, удаляет транзакции голосования из блоков, сокращает время достижения финальности с секунд до миллисекунд и меняет взаимодействие валидаторов и инфраструктуры с консенсусом.

Для большинства пользователей и разработчиков приложений значительная часть перехода пройдёт незаметно. Однако для валидаторов, поставщиков RPC, индексаторов и инфраструктурных команд Agave 4.3 знаменует начало серьёзных изменений в механизме достижения консенсуса Solana.

Дополнительные материалы

• Технический документ Alpenglow v1.2 (июль 2026 г.)
• График выпуска Agave 4.3
• График отслеживания переключателей функций
• Журнал изменений Agave 4.3
• Запросы на включение изменений в Agave 4.3
• Обновление Alpenglow — Solana Foundation