Что происходит с валидаторами Solana, пропустившими обновление Agave 4.4.1?

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

Anza предупредила валидаторов перед эпохой 1079, что операторы, работающие на старом программном обеспечении, рискуют остаться позади, когда сеть включит новое правило. Указанными совместимыми версиями были Agave 4.4.1 и Firedancer v26.10.6.

Трекер feature gate Agave определяет соответствующее изменение как минимальный размер загружаемых данных для учётных записей ProgramData loader-v3. Его таблица минимальных версий разделяет выпуски, используемые тестовыми сетями, и те, что запланированы для мейннета. Для чтения расписания необходимо проверять кластер, функцию и эпоху вместе.

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

Что делает изменение

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

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

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

Почему важен стейк за узлами

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

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

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

Что заметили бы пользователи и биржи

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

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

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

Почему крайний срок обновления касался и инфраструктуры

В примечаниях к выпуску Agave от Anza изменение учёта ProgramData указано как бэкпорт. Выпуск Firedancer включает поддержку той же функции. Когда два клиента обрабатывают одну и ту же транзакцию после активации, они должны согласовать, какой объём данных аккаунта она загружает. Именно общее правило имеет значение на границе.

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

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

Чем крайний срок отличался от даты выпуска

Anza опубликовала Agave 4.4.1 5 ноября. В последовавшем предупреждении операторам говорилось, что изменение запланировано на эпоху 1079, начало которой оценивалось примерно в 13:30 UTC 6 ноября. Версия определяла программное обеспечение, необходимое операторам, а эпоха определяла, когда сеть планирует начать применять правило.

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

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

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

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

Различие между программным обеспечением и активацией уже появлялось в материалах crypto.news о развёртывании Alpenglow в тестовой сети. Alpenglow изменил консенсус, тогда как ноябрьский патч касался обработки транзакций. В обоих случаях доступность сборки была отдельной вехой от момента, когда сеть требует её поведения.

Где ProgramData вступает в транзакцию

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

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

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

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

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

Правило также оставляет развёрнутые инструкции приложения на месте. Программа может оставаться по тому же адресу и иметь тот же код, пока валидатор взимает плату за её счёт ProgramData иначе. У команд приложений есть причина перепроверить транзакции вблизи лимита, даже если они сами не выполняли развёртывания.

Как два узла могут разойтись во мнении об одном и том же блоке

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

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

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

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

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

Почему подсчёт валидаторов рассказывает лишь часть истории

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

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

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

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

Что делегаторы могут установить по записям голосования и вознаграждений

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

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

Более низкое вознаграждение само по себе не указывает на обновление как на причину. Комиссия, предыдущая производительность валидатора и статус стейк-аккаунта — всё это может влиять на записанную сумму. Доказательство того, что голоса остановились на границе и возобновились после смены клиента, дало бы более сильное объяснение, чем одно более низкое вознаграждение.

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

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

Что устаревшая конечная точка RPC может сделать с кошельком

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

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

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

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

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

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

Почему биржевое начисление может отставать от цепочки

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

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

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

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

Что показало бы, пропустили ли операторы патч

Трекер feature gate от Anza отделяет минимальный порог релиза от отдельных активаций. Предыдущие материалы crypto.news о развёртывании Alpenglow и минимальном пороге основной сети описывали то же различие. Сборка может соответствовать порогу в один момент времени и не содержать изменения, запланированного на более позднюю эпоху.

Наиболее полезная запись после активации сравнила бы активную функцию, распространение программного обеспечения и участие операторов за одно и то же окно. Запись о функции указывает, когда правило начало применяться. Запись о программном обеспечении указывает, какие сборки находились в эксплуатации. Голоса и блоки показывают, вела ли себя сеть и отдельные операторы иначе.

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

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

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

Почему поэтапное развёртывание всё равно требует проверки активации

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

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

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

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

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

Почему цена SOL не может измерить эффект обновления

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

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

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

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

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

Что происходит, когда оператор снова выходит в сеть

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

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

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

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

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

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

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

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

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

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

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

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