«У нас 99.95 процента аптайма» это первое, что говорит большинство операторов, и для slashing-риска это почти бесполезная цифра. Аптайм и риск слеша лежат в разных плоскостях: можно иметь красивый аптайм и схватить slashing, можно пропустить часы и не потерять ни монеты. Мы держим валидаторы за клиентов и считаем по-другому. Дальше про то, где реально живёт опасность.
Два разных слешинга
Сначала разделим то, что слово «slashing» сваливает в кучу. Протоколы наказывают за две разные вещи, и путать их дорого.
Downtime-наказание (inactivity). Валидатор не выполнил свою работу: пропустил attestation, не предложил блок. Чаще это мелкий штраф или inactivity leak, который копится медленно. Неприятно, но обычно это про монетки, а не про катастрофу. Вот за это аптайм и отвечает.
Equivocation (double-sign). Валидатор подписал два конфликтующих сообщения на один слот. Это уже не «недоработал», а «подписал противоречие», и протокол бьёт по нему жёстко: крупный slash плюс выкидывание из набора. Аптайм к этому не имеет отношения вообще. Можно иметь 100 процентов аптайма и слешнуться по equivocation за одну секунду неудачного failover.
Вся серьёзная slashing-экспозиция живёт во второй категории, а её аптайм не измеряет в принципе.
Почему аптайм прячет хвост
Даже там, где аптайм релевантен, процент скрывает распределение. 99.95 на двух нодах могут означать совершенно разные вещи. Одна нода упала на четыре часа разом и поднялась: это видно, это понятно, это лечится. Другая двести раз за месяц словила микро-jitter и пропустила attestation тут и там, набрав тот же суммарный простой: это не видно в проценте, но именно это часто симптом ползущей проблемы, которая завтра выльется в equivocation на нервном failover.
Слешит на хвосте распределения, а не на среднем. Поэтому мы смотрим на p99 attestation latency и на форму распределения пропусков, а не на одну усреднённую цифру, которая их сглаживает.
Коррелированные отказы
Настоящая катастрофа это не одна упавшая нода, а много нод, упавших по одной причине одновременно. Если весь флот клиента стоит у одного провайдера, на одном клиенте консенсуса конкретной версии, за одним апстримом, то один баг, один coordinated outage, один кривой релиз клиента валит всё сразу. Аптайм за прошлый месяц про это не скажет ничего: он измеряет прошлое каждой ноды по отдельности, а не общий blast radius.
Хуже того, именно коррелированный сбой создаёт условия для equivocation. Регион выпал, автоматика начала поднимать резерв в другом месте, а первый сервер на самом деле жив и через минуту вернётся: вот здесь и рождается двойная подпись. Так что коррелированный отказ это не только риск простоя, это спусковой крючок для самого дорогого слеша.
Что мы алертим вместо аптайма
У нас аптайм есть в дашборде, но это производная, не primary-сигнал. Реально мы алертим на другое:
- p99 attestation latency, а не средний. Хвост это ранний симптом.
- Любой признак двойной подписи или конфликта ключа как Sev-1 с немедленной эскалацией. Это категория, ради которой существует половина наших раннбуков.
- Diversity флота: сколько уникальных провайдеров, ASN, версий клиента консенсуса. Падение разнообразия это рост коррелированного риска, и его надо видеть до инцидента.
- Поведение failover-контура: срабатывает ли fencing, не было ли промоушена без подтверждения. Про это отдельный разбор в посте про failover без double-sign.
- Inactivity-штрафы как тренд, а не разовый пропуск: медленно растущий leak это сигнал, что что-то деградирует системно.
Ни один из этих сигналов не сворачивается в красивый процент для лендинга. Поэтому их и не показывают, а слешит ровно по ним.
Как это у клиента
На полигоне мы специально доводим ноды до коррелированных и хвостовых сценариев, чтобы видеть, как ведёт себя мониторинг и failover до того, как это случится на клиенте. На контракте это превращается в набор алертов и раннбуков, заточенных под equivocation и коррелированный риск, а не под «процесс жив».
Если вам нужен оператор, который меряет slashing-риск там, где он действительно живёт, а не отчитывается аптаймом, это часть того, что мы держим в web3 и закрываем через operate. Хотите, чтобы мы посмотрели на вашу реальную slashing-экспозицию: напишите нам.