Перейти к содержанию
Financial Context Wiki

Nothing at Stake: эквивокация, слэшинг, финальность и риск старых ключей

Nothing at Stake — проблема стимулов в proof of stake, при которой поддержка конкурирующих историй может иметь низкие предельные издержки. Отдельно анализируйте наказуемые сообщения, ожидаемый результат, пересечение кворумов, исполнение доказательств, выбор форка и слабую субъективность.

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Прямой ответ

Nothing at Stake — проблема стимулов в proof of stake: если дополнительная подпись стоит дёшево, а протокол не создаёт действенных издержек за несовместимую поддержку, валидатор может заработать больше, помогая каждой конкурирующей истории, чем выбирая одну. Если многие валидаторы следуют этому частному стимулу, форки могут сохранять поддержку, сходимость ослабевает, а атакующий получает подписи, воспроизведение которых в proof of work потребовало бы затрат.

Термин не означает, что у каждой системы proof of stake отсутствует бюджет безопасности или что любой голос за проигравший форк является нарушением. Заблокированный капитал, упущенные награды, слэшинг, задержка вывода, правила выбора форка и финальности могут изменить результат. Какие подписанные сообщения и конфликты наказуемы, зависит от протокола и версии; обычное обновление голоса, задержанное сообщение или временный честный форк могут быть допустимы.

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

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

Как анализировать Nothing at Stake

  1. Зафиксируйте контекст протокола. Запишите protocol, version, network, epoch, slot, validator set и время наблюдения. Определите действующие fork choice, finality gadget, reward rule, penalty rule и withdrawal delay; обозначение «PoS» само по себе не задаёт ни одно из них.
  2. Определите подписываемые действия. Перечислите предложения блоков, аттестации, предварительные голоса, предварительные обязательства, сертификаты и иные сообщения с их доменами. Отличайте два сообщения, которые лишь поддерживают разных потомков, от формально наказуемых по указанным правилам double proposal, double vote или surround vote.
  3. Смоделируйте результат без наказания. Оцените вероятности ветвей, награды канонической ветви, дополнительные расходы на подпись и распространение, взятки, упущенные возможности и награды за конфликтующие сообщения. Сравните EV(honest) и EV(equivocate), а не делайте вывод о выгоде отклонения лишь из-за малого потребления электричества.
  4. Смоделируйте исполнимый убыток. Определите связанный баланс, вероятность обнаружения, срок действия доказательства, путь сообщения, риски включения и цензуры, начальный и корреляционный штрафы, исключение, сроки вывода и потерянный будущий доход. Наличие штрафа в документации не равнозначно надёжному исполнению slashing evidence.
  5. Разделите выбор форка и финальность. Восстановите влияние последних голосов, эквивокаций и времени сообщений на голову цепи, затем рассчитайте вес для обоснования или финализации контрольных точек. Анализируйте safety threshold и liveness threshold отдельно: удержание голосов может остановить финальность, не создавая противоречащую финальность.
  6. Проверьте предположения о старых ключах и синхронизации. Определите, когда вышедший залог перестаёт быть наказуемым, какую финализированную историю отвергнет онлайн-узел, как новый или давно отключённый узел получает weak-subjectivity checkpoint и как проверяет его свежесть и происхождение. Это проблема дальней дистанции, а не только недавнего двойного голоса.
  7. Проведите стресс-тест эксплуатации и контроля. Проверьте дублирование ключей, резервные узлы, удалённые подписывающие устройства, откат базы данных, ошибки клиентов, общее размещение, стейкинг-пулы, делегированное хранение, разделение сети, eclipse-атаки и цензуру доказательств. Считайте независимые пути контроля и программного обеспечения, а не только идентификаторы валидаторов.

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

Расчётные примеры

1. Стратегия без наказания может поощрять обе ветви

Предположим, канонической станет ровно одна из двух ветвей: ветвь A с вероятностью 0.55 или ветвь B с вероятностью 0.45. Подпись канонической ветви приносит 1.00 unit, а подпись проигравшей — ноль. Если не учитывать штрафы и дополнительные операционные затраты, подпись только A даёт EV(A only) = 0.55 * 1.00 = 0.55 units. Подпись обеих даёт EV(sign both) = (0.55 + 0.45) * 1.00 = 1.00 unit.

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

2. Исполнимый слэшинг может обратить результат

Сохраним валовую каноническую награду 1.00 unit и добавим взятку 0.02 unit за эквивокацию. Предположим, допустимое доказательство достигает механизма наказания с вероятностью 0.80, а полный относимый убыток равен 5.00 units. Упрощённый результат составляет EV(equivocate) = 1.00 + 0.02 - (0.80 * 5.00) = -2.98 units, что ниже 0.55 units при подписи только A.

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

3. Пересечение кворумов защищает безопасность, но может ослабить живучесть

Рассмотрим 100 stake units и правило, требующее не менее 67 units для голоса финальности. Любые два таких кворума пересекаются как минимум на 67 + 67 - 100 = 34 units. Поэтому две конфликтующие финализации требуют участия не менее 34 единиц в обоих сертификатах кворума; подотчётный протокол может сделать это пересечение доказуемо наказуемым.

Тот же порог иначе влияет на живучесть. Если 34 units удерживают допустимые голоса, остаётся лишь 66 units, то есть меньше 67, и финальность может остановиться. Эти 34 единицы не способны самостоятельно финализировать две ветви. Нарушение безопасности, относимое доказательство и отсутствие продвижения нельзя описывать как одно событие.

4. Старые ключи создают другую проблему синхронизации

Предположим, онлайн-узел финализировал контрольную точку epoch 39,900, а у нового узла нет доверенного состояния. Атакующий получает ключи, которые контролировали достаточный залог около epoch 10,000, после выхода этих валидаторов и утраты возможности взыскать их залог, и создаёт альтернативную историю до epoch 40,000. Дешёвые исторические подписи существенны, но слэшинг современных валидаторов уже может не сдерживать эти старые ключи.

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

Риски и ошибки проверки

Ошибки протокола и доказательств

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

Ошибки стимулов и исполнения

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

Ошибки эксплуатации, концентрации и восстановления

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

Распространённые заблуждения

  • В proof of stake буквально ничем не рискуют. Хорошо спроектированная система может подвергать риску связанный капитал, награды и будущее участие; важно, достаточны и исполнимы ли эти издержки для конкретного отклонения.
  • Каждое сообщение валидатора в двух форках является двойным голосом. Наказуемость зависит от полей сообщений, доменов и правил конфликта протокола; честным обновлениям выбора форка необходимо допустимое пространство.
  • Слэшинг гарантирует консенсус. Он обеспечивает подотчётность и стимулы, но безопасность и живучесть также зависят от порогов, сети, реализаций, безопасности ключей и предположений о честном поведении.
  • Треть залога может самостоятельно финализировать две ветви. В модели финальности с двумя третями около трети обычно может остановить продвижение; конфликтующая финальность требует пересекающихся сверхбольшинств и наказуемого участия в их пересечении.
  • Nothing at Stake и атаки дальней дистанции идентичны. Обе используют дешёвые подписи, но первая касается текущей поддержки конкурирующих ветвей, а вторая может применять исторические ключи против узлов без свежего доверенного состояния.

Связанные темы

Источники

Навигация

Поиск по вики...