Solana ускорила финализацию: что это меняет для пользователей?

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

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

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

Переключение произошло, но 150 миллисекунд — это цель

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

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

Внешнее измерение, опубликованное 23 октября, показало медианную финальность на уровне 404 миллисекунд за предшествующие 24 часа, с 90-м процентилем 579 миллисекунд и 99-м процентилем 765 миллисекунд. Его более ранний ориентир составлял около семи секунд при TowerBFT. По этим цифрам медиана улучшилась примерно в 17 раз, рассчитано делением семи секунд на 0,404 секунды. Методология и точка наблюдения отличаются от базовой линии Фонда в 12,8 секунды и проектной цели в 150 миллисекунд.

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

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

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

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

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

У кошелька больше одних часов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У валидаторов появился новый регулярный счёт

Удаление ончейн-транзакций голосования меняет расходы валидаторов. Solana Foundation сообщает, что голосование ранее стоило около 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, включая пиковые периоды, была бы для торговца ценнее, чем одна быстрая демонстрация.

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

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

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

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

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

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

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