В сети Solana с 21 октября работает обновление Alpenglow, заменяющее систему голосования, при которой для подтверждения блока требовалось несколько секунд, на систему, обеспечивающую завершение процесса за долю секунды. Фонд Solana зафиксировал это изменение в эпохе 1064, после того как 446 из 654 валидаторов подтвердили генезисный блок.

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

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

СРОЧНО: Solana запланировала обновление Alpenglow на 21 октября.

В ходе обновления система голосования Solana заменена на консенсус, основанный на сертификатах, с целью обеспечения финализации транзакций примерно за 150 миллисекунд. pic.twitter.com/4ljZVuxfN5

— crypto.news (@cryptodotnews) 14 октября 2026 г.

Переход произошел, но 150 миллисекунд – это целевой показатель

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

Фонд использует 12,8 секунды в качестве ориентира для старой финализации и примерно 150 миллисекунд в качестве нового целевого показателя. Эти цифры описывают сравнение протоколов, а не два измерения, полученные из одного и того же кошелька в идентичных условиях. В отчете о подготовке к 21 октября предупреждалось, что RPC-узлы, не участвующие в стейкинге, могут получать информацию о финализации позже, чем участвующие валидаторы, иногда после создания другого блока. Задержка в сети Интернет и выбранный приложением узел также влияют на то, что видит пользователь.

Согласно внешнему исследованию, опубликованному 23 октября, среднее время подтверждения транзакции за последние 24 часа составило 404 миллисекунды, при этом 90-й процентиль – 579 миллисекунд, а 99-й процентиль – 765 миллисекунд. Ранее этот показатель составлял около семи секунд при использовании TowerBFT. Таким образом, среднее время подтверждения улучшилось примерно в 17 раз (рассчитано путем деления семи секунд на 0,404 секунды). Методология и точка наблюдения отличаются от базового показателя в 12,8 секунды и целевого показателя в 150 миллисекунд, установленных Фондом.

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

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

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

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

Независимый наблюдатель должен выяснить, с какого момента запускается таймер подтверждения. Если отсчет начинается с момента получения валидатором предложенного блока, это исключает время, затраченное кошельком на отправку транзакции. Если отсчет начинается с момента нажатия продавцом кнопки «оплата», в процесс вовлекаются человек и несколько программных систем. Если отсчет начинается с момента, когда RPC-сервер получает сертификат, учитывается задержка между валидаторами и сервером. Каждый таймер отвечает на свой вопрос. Внешние измерения, проведенные 23 октября, полезны, поскольку их метод и результаты можно проанализировать отдельно от заявлений фонда о характеристиках системы.

У кошелька больше одного таймера

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

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

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

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

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

Возможно, вам также будет интересно: Количество держателей токенизированных акций Solana выросло в 5 раз, но почему цена SOL снижается?

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

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

Меньшее количество транзакций на графике может означать тот же объем использования

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

Соучредитель Solana, Анатолий Яковенко, обсудил удаление транзакций голосования незадолго до активации, когда изменения в показателе TPS привлекали внимание. Аналитики, сравнивающие трафик 20 октября с трафиком после 21 октября, должны выделить транзакции, не связанные с голосованием, с обеих сторон. В противном случае изменение в учете может показаться снижением спроса. Обратная ошибка будет заключаться в утверждении, что снижение трафика голосования само по себе создает такое же количество дополнительных полезных пользовательских транзакций; резервные мощности и фактическое использование — это разные вещи.

Арифметику можно проверить, не придумывая новую оценку пропускной способности. Если до обновления общее количество включает пользовательские транзакции U и голоса валидаторов V, то их сумма составляет U + V. После исключения голосов из блока аналогичный график может показывать примерно U, даже если пользователи отправляют такое же количество переводов. Разница V — это изменение в том, что отображает график. Для расчета фактического роста требуются сопоставимые данные только по пользовательским транзакциям, а не общие данные до и после.

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

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

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

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

Сервисы данных должны следовать за выбранным блоком

Быстрое принятие решения о голосовании не означает, что каждый предложенный блок станет победителем. Обновленные потоки данных Solana могут показывать более одного кандидата на слот, и Agave 4.3 помечает события идентификатором банка (bank_id), чтобы клиенты могли разделять кандидатов. Индексатор, группирующий все данные по номеру слота, может случайно смешать транзакции от конкурирующих кандидатов в запись блока, которого в такой форме никогда не существовало.

Фонд рекомендует потребителям потоковых данных буферизовать данные по паре «слот и идентификатор банка» и сохранять банк, который достиг подтверждения. Если они объединяют потоки от разных поставщиков, идентификатор имеет смысл только в рамках каждого соединения; хеш блока является общим для всех поставщиков. Некоторые из более частых случаев использования нескольких банков ожидаются в Agave 4.4, поэтому есть время для адаптации до того, как это станет обычным явлением, но приложения, обрабатывающие текущие потоки блоков, должны подготовиться сейчас.

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

В документации по миграции в основную сеть, опубликованной Фондом, говорится, что подтвержденные и окончательно зафиксированные уровни коммитов теперь описывают одно и то же состояние, хотя прежний вариант пока остается доступным и будет удален в последующей версии. Разработчикам рекомендуется использовать новые данные и проверить настройки времени ожидания или повторных попыток, адаптированные к прежним значениям. Сервис, который по привычке ожидает 12 секунд, может оставаться медленным, несмотря на значительно более высокую скорость работы сети.

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

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

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

У валидаторов появился новый постоянный расход

Удаление транзакций голосования из блокчейна изменяет стоимость работы валидаторов. Фонд Solana сообщает, что ранее голосование стоило около 1 SOL за эпоху в виде комиссий за транзакции, оплачиваемых со счета идентификатора валидатора. Новая система Validator Admission Ticket сжигает 0,8 SOL за эпоху со счета голосования, в дополнение к минимальной сумме, необходимой для поддержания счета. Билет, приобретенный в начале одной эпохи, позволяет валидатору участвовать в следующей.

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

Сравнение примерно 1 SOL и 0,8 SOL не является универсальным показателем чистой экономии. Доходы, доля в сети, затраты на программное обеспечение, комиссии и сроки взимания каждой платы различаются у разных валидаторов. Важным фактом является то, какой счет оплачивает, каков размер фиксированной платы за участие и что произойдет, если она не будет уплачена. Долгосрочная концентрация будет зависеть от того, смогут ли небольшие операторы поддерживать операционные и финансовые требования, оставаясь при этом конкурентоспособными.

Для запуска требовались Agave 4.3.2 или совместимые клиенты Jito-Solana или Harmonic Salsa. Согласно странице для операторов Фонда, Firedancer и Frankendancer не поддерживались для миграции. Активация Alpenglow доказывает, что сеть может переключаться с участием валидаторов; это не означает, что каждый альтернативный клиент-валидатор был готов к этому в тот же день. Разнообразие клиентов остается отдельным вопросом, связанным с устойчивостью.

Одобрение управления было получено до миграции. В более раннем плане развертывания описывался код в Agave 4.2 во время тестирования, но одной установки было недостаточно для переключения на основную сеть. Сертификат генезиса и начало консенсуса на слоте 459 653 000 являются доказательством активации. 446 подписавших первый сертификат представляли собой конкретное событие координации, а не обещание о посещаемости или производительности всех 654 валидаторов каждый час после этого.

Фиксированная плата по-разному влияет на экономику валидаторов в зависимости от их размера. Крупный и мелкий оператор платят одинаковую плату в размере 0,8 SOL за участие, поэтому эта плата составляет большую долю от валового вознаграждения мелкого оператора. То, повлияет ли это на кого-либо, зависит от делегированной доли, комиссии, операционных расходов и других доходов. Руководство для операторов определяет механизм оплаты; оно не прогнозирует, сколько валидаторов уйдет. Было бы полезно сравнить активных независимых операторов и концентрацию доли в сети в течение нескольких периодов.

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

Это обновление решает более узкую проблему, чем приложения для платежей

Аргументы Solana в пользу Alpenglow весьма убедительны: если подтверждение транзакции будет происходить значительно быстрее, сервисы, которым требуется необратимое завершение транзакции, смогут прекратить ожидание в течение нескольких секунд неопределенности. Внешние измерения, проведенные 23 октября, подтверждают существенное улучшение работы в основной сети, хотя среднее время обработки транзакции в 404 миллисекунды оказалось немного больше запланированного. Торговцы и биржи могут выбрать использование этого более надежного и быстрого механизма.

Сервис по-прежнему может использовать буфер. Он может использовать несколько провайдеров RPC, требовать проверки на мошенничество или зачислять средства клиенту только после сверки депозитов в собственной системе учета. Небольшие платежи могут быть обработаны и подтверждены сразу, что делает Alpenglow практически незаметным в текущем интерфейсе. Для крупных переводов может использоваться подтвержденный статус, что позволит сэкономить несколько секунд. Обновление не делает осторожный сервис нелогичным; оно предоставляет сервису более быстрый сигнал из сети, который можно использовать при принятии решений.

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

Вторая часть Alpenglow, Rotor, пока запланирована для выпуска в более поздний срок, без указания конкретной даты активации. Votor изменил механизм голосования и подтверждения; распределение блоков по-прежнему использует старый подход Turbine. Название пакета может создать впечатление, что все предложенные компоненты были выпущены одновременно. Текущая таблица статусов, опубликованная Фондом, четко показывает разделение. Любое повышение производительности, приписываемое Rotor в текущих данных основной сети, будет неверно отражать хронологию событий.

Распределение блоков остается актуальным, когда данные передаются по сети неравномерно. Более быстрое голосование не может помочь валидатору подтвердить предложение, которое он не получил. Планируемый компонент Rotor будет решать задачу на другом этапе, чем сертификаты Votor. На данный момент медленные наблюдения могут отражать распространение данных, голосование, передачу данных через общедоступные RPC или их комбинацию. Запись каждого этапа позволит оператору определить, к какой области следует направить следующее улучшение: к программному обеспечению валидатора, к системе распределения данных или к инфраструктуре клиента.

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

НОВОСТЬ: Предложение SIMD 326 – Alpenglow от $SOL запустило процесс управления сообществом, представляя собой крупное обновление консенсуса, нацеленное на достижение окончательности блока за 150 мс.

Ожидается голосование примерно через 16 дней. pic.twitter.com/p8aWtH9TYy

— crypto.news (@cryptodotnews) 15 августа 2025 г.

Что еще предстоит измерить

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

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

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

На что обратить внимание

• Наблюдаемая окончательность: Сравните скользящую медиану и самые медленные значения в процентилях на панели управления Фонда и независимых узлах, указав точки наблюдения.
• Время обработки в кошельках и на биржах: Измерьте интервал от подтверждения клиентом до видимого подтверждения или зачисления средств, а не только сертификат валидатора.
• Сопоставимый трафик: Отслеживайте пользовательские транзакции, не связанные с голосованием, до и после 21 октября, чтобы исключить искажение тенденции из-за транзакций голосования.
• Ошибки потоковой передачи: Проверьте, поддерживают ли поставщики RPC и индексаторов восстановление блоков с учетом банковских требований и своевременное отображение статуса окончательности.
• Прием валидаторов: Следите за финансированием учетных записей для голосования, активными валидаторами и разнообразием поддерживаемых клиентов, поскольку комиссия в размере 0,8 SOL повторяется в каждой эпохе.

Часто задаваемые вопросы

Работает ли Alpenglow в основной сети Solana?

Да. Фонд Solana указывает, что активация произошла 21 октября 2026 года, а консенсус Alpenglow начался со слота 459 653 000.

Теперь транзакция в Solana завершается за 150 миллисекунд?

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

Почему зачисление средств на биржу все еще может занимать больше времени?

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

Изменилось ли обновление комиссию за транзакции в сети Solana?

Нет. Фонд заявляет, что формат транзакций пользователей, программы и механизм комиссий остаются прежними. Стоимость голосования валидаторов изменилась и теперь составляет 0,8 SOL за эпоху.

Почему количество транзакций в сети Solana уменьшилось после обновления Alpenglow?

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

В чем разница между Votor и Rotor?

Votor — это система голосования и подтверждения, работающая в основной сети. Rotor заменит распределение блоков, но дата его запуска пока не определена.

Нужно ли обновлять кошельки?

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

Как пользователи могут понять, помогло ли обновление?

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

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