Solana обещала ускоренное подтверждение. Теперь валидаторам придётся доказать, что это работает

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

Самое значимое изменение консенсуса Solana проходит через серию тестов валидаторов. Трекер функциональных шлюзов Anza перечисляет SIMD-0326, Alpenglow, среди ожидающих активации в основной сети. Он фиксирует позиции активации в тестовой сети и devnet и определяет Agave 4.3.0 как версию программного обеспечения, связанную с этой функцией. Минимальный порог версии основной сети, показанный в том же снимке, был 4.2.2, при этом 4.3.0 указан как следующий ожидаемый порог. Запланированный минимальный порог версии и работающая функция консенсуса — это разные этапы.

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

28 сентября было календарной ловушкой

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

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

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

Votor меняет голосование, а Rotor ждёт

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

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

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

Предложение заменяет схему голосования другим компромиссом между безопасностью и живучестью. Оно описывает модель «20 плюс 20», которая может выдержать враждебную долю и отдельную неотвечающую долю при заявленных допущениях. Авторы явно отмечают, что однораундовое голосование не обеспечивает тот же порог византийской устойчивости в 33%, достижимый при двухраундовых схемах. Это признание должно стоять рядом с заявлением о скорости, а не в сноске.

Тест из двух колонок предотвращает вводящий в заблуждение бенчмарк

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

Предположим, тест сообщает о 150 миллисекундах для финализации после предложения, но включение транзакции ожидает один слот в 350 миллисекунд, а доставка через RPC занимает ещё 100 миллисекунд. Клиент видит как минимум 600 миллисекунд при этих иллюстративных допущениях, ещё до добавления подписи или повторных попыток. Расчёт таков: 350 плюс 150 плюс 100. Это гипотетические тайминги, а не измерения Alpenglow в продакшене. Они показывают, почему субсекундная цифра консенсуса не обязательно совпадает с субсекундным опытом платежа.

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

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

Валидаторы должны тестировать случаи отказа

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

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

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

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

Быстрый сертификат и медленный сертификат обслуживают разные условия

Протокол не зависит от того, что один маршрут всегда завершается за 150 миллисекунд. SIMD-0326 определяет быструю финализацию, когда валидаторы, представляющие 80% стейка, нотаризуют блок за один раунд. Его более медленный маршрут полагается на два раунда с участием 60% стейка и как сертификатов нотаризации, так и сертификатов финализации. Лидер может не успеть предоставить действительный блок вовремя, и в этом случае валидаторы могут проголосовать за пропуск этого слота. Дизайн включает сертификаты для пропущенных слотов и запасной путь. Эталонный тест, измеряющий только быстрый маршрут с 80%, упустил бы именно те ситуации, которые делают финализацию ценной.

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

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

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

Авторы протокола не заявляют тот же порог противодействия, что и любой конкурирующий дизайн. Их формулировка «20 плюс 20» принимает иной баланс между византийскими отказами и неотвечающим стейком в обмен на более короткий нормальный путь. Приемлем ли этот компромисс — это управленческое решение, основанное на моделировании угроз и доказательствах производительности, а не вопрос, решаемый единственной демонстрацией самого быстрого случая. Необычно откровенный раздел о безопасности в SIMD-0326 позволяет сообщить о компромиссе, не приписывая мотивы ни одной из сторон.

Переключение консенсуса требует общего начального блока

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

Предлагаемая передача начинается после слота активации функции, но граница, используемая для миграции, находится на 5000 слотов позже. Дополнительный интервал предназначен для того, чтобы избежать начала эпохи. Затем процесс ожидает блок, удовлетворяющий условию сильного оптимистичного подтверждения, с голосами, представляющими не менее 82% стейка в указанном в предложении шаблоне. Валидаторы подписывают генезис-голос за блок общего предка. Сертификат генезиса с 82% даёт им доказательство для переключения. Арифметика этих порогов является частью дизайна миграции, отдельной от быстрого маршрута финализации Votor с 80% после переключения.

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

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

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

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

Затраты валидаторов могут изменить состав участников

Обновление имеет как экономический дизайн, так и цель по задержке. При текущем голосовании операторы отправляют транзакции голосования и платят связанные с ними комиссии. SIMD-0326 предлагает ввести входной билет валидатора, или VAT, взимаемый вместо такой схемы комиссий. В документе приводится первоначальная оценка около 0,8 SOL в день, или 1,6 SOL за эпоху, и говорится, что весь платеж будет сожжен. Эта цифра является первоначальным параметром в предложении, а не действующим счетом для каждого валидатора.

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

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

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

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

Транзакция может быть финальной, пока сервис все еще отстает

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

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

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

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

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

Самый сильный аргумент — реальное улучшение расчётов

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

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

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

Готовность основной сети имеет несколько отдельных этапов

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

Трекер Anza указывает, что минимальная версия для основной сети может повыситься после того, как 95% стейка примут новую минорную версию и пройдут две полные эпохи. Это правило регулирует минимальную поддерживаемую версию; его не следует перефразировать как автоматическую активацию Alpenglow при 95%. Независимая строка функций остаётся местом для проверки фактического ожидающего изменения.

Ни один из reported тестов не устанавливает, что цена SOL должна реагировать определённым образом. Цены токенов учитывают макроэкономические условия, финансирование, предложение, спрос на приложения и ожидания относительно обновлений до их развёртывания. Более ранний обзор активации объясняет, почему веха консенсуса имеет значение, не делая её катализатором цены по определению.

Чего по-прежнему не хватает публичным доказательствам

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

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

За чем следить

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

FAQ