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

Византийская отказоустойчивость: безопасность, живучесть и кворумы

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

Обновлено

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

Краткий ответ

Византийская отказоустойчивость (BFT) — свойство конкретного распределенного протокола в конкретной модели сбоев и сети: он продолжает выполнять заявленные гарантии, даже если некоторые участники отключаются, удерживают сообщения, отправляют разным узлам противоречивые сообщения или ведут себя произвольно. BFT — не один алгоритм и не обещание доступности всех сервисов при любом разделении сети.

Гарантии нужно различать. safety (безопасность) означает, что честные участники не принимают конфликтующие значения; liveness (живучесть) — что допустимый ввод в итоге может привести к решению; validity (допустимость) ограничивает значения, которые можно принять. При нехватке связи или честного веса протокол может остановиться ради безопасности. Правильный консенсус также не доказывает правильность кода приложения, правил проверки транзакций, мостов, ключей или управления.

В распространенном классе аутентифицированных частично синхронных BFT-протоколов n=3f+1 реплик выдерживают не более f византийских реплик, а сертификат фиксации требует q=2f+1 голосов. Формулы «меньше трети неисправно» и «кворум больше двух третей» относятся к этой модели. У синхронных, рандомизированных асинхронных и crash-fault-протоколов, Proof-of-Work-цепочек и других конструкций BFT могут быть иные допущения и пороги.

В системах со взвешиванием по стейку порог относится к определенной протоколом силе голоса, а не обязательно к числу валидаторов, адресов, людей или независимых операторов. До применения доли укажите точную версию, снимок весов, тип решения, сетевое допущение, сравнение кворума (> или >=) и поведение при сбое.

Ниже порога
25 %
Доля злоумышленника
25 %
Маржа до порога
8,4 %

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

Как это работает

  1. Определите решение. Установите, упорядочивают ли узлы транзакции, фиксируют блок, финализируют контрольную точку, выбирают лидера, принимают переход состояния или выбирают ветвь. Это разные решения.
  2. Задайте модель системы и противника. Зафиксируйте членство, аутентификацию, смену разрешений, веса, адаптивную коррупцию, компрометацию ключей, противоречивое голосование, остановки, потерю сообщений, цензуру, отказ в обслуживании и корреляцию сбоев.
  3. Задайте модель сети. Различайте синхронность, частичную синхронность и асинхронность. Для частичной синхронности укажите, что гарантируется лишь после неизвестного глобального времени стабилизации и как меняются тайм-ауты.
  4. Выведите правило кворума. Используйте точный порог и правила блокировки или голосования. В классическом случае n=3f+1 два кворума 2f+1 пересекаются хотя бы по f+1 репликам; если византийских не больше f, в пересечении есть честная.
  5. Проследите все фазы и сертификаты. Проверьте предложение, голос, блокировку, смену представления или раунда, фиксацию, выбор ветви и восстановление. Подписанное сверхбольшинство значимо лишь при проверке высоты, раунда, значения, родителя, домена, эпохи членства и предыдущего сертификата.
  6. Разделите доказательства безопасности и живучести. Докажите, какие конфликтующие решения исключены во все нужные моменты, затем проверьте возобновление прогресса после выполнения допущений о связи и честном участии. Тайм-аут — средство планирования, а не доказательство злого умысла.
  7. Проверьте реализацию и эксплуатацию. Сопоставьте с моделью разнообразие клиентов, хранение ключей, резервирование подписантов, защиту от повтора, синхронизацию состояния, обработку улик, смену членов, мониторинг, политику подтверждения и восстановление.

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

Примеры с расчетами

1. Четыре равновесные реплики

Пусть n=4, f=1, q=3. Два набора по три голоса пересекаются хотя бы по 3+3-4=2 репликам. При максимум одной византийской хотя бы одна реплика в пересечении честная. Если правила честного узла запрещают голоса за конфликтующие значения в соответствующей истории высоты и раунда, два конфликтующих сертификата фиксации не возникнут.

Если две реплики отключены, остается лишь 2 голоса и сертификат q=3 не формируется. Это нарушение живучести, но не обязательно безопасности: безопасный протокол ждет, а не снижает порог локально.

2. Семь равновесных реплик

Пусть n=7, f=2, q=5. Два кворума пересекаются хотя бы по 5+5-7=3=f+1 репликам. Поскольку византийских максимум 2, в пересечении есть честная. Две византийские не создадут сертификат из пяти голосов, но три отключенные или удерживающие голос оставляют лишь 4 и могут остановить прогресс.

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

3. Взвешенная сила голоса

Пусть веса равны 40, 30, 20 и 10, всего 100, а сертификат требует строго больше 2/3, здесь минимум 67. Коалиция 40+30=70 сертифицирует; 30+20+10=60 — нет, хотя это три валидатора из четырех. Если валидатор веса 40 отключен, остается 60 и финальность останавливается.

Два набора минимум по 67 пересекаются минимум на 67+67-100=34. Значит, конфликтующие сертификаты показывают, что хотя бы 34 веса участвовало в обоих, либо нарушено другое допущение. В некоторых протоколах чуть более трети противоречивых голосов может нарушить безопасность; «для атаки нужны две трети» — не универсальный минимум.

4. Частичная синхронность и тайм-ауты

Пусть тайм-ауты раундов равны 1 s, 2 s, 4 s и 8 s. До неизвестной стабилизации сообщения могут приходить позже каждого текущего тайм-аута, вызывая смену раундов без решения. Если затем задержка становится меньше 3 s, раунд 4 s или позже может дать честному автору предложения и кворуму время для прогресса при прочих допущениях.

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

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

Модель и доказательство

  • Называть систему «BFT», не указывая протокол, версию, решение, модели сбоев и сети, членство и порог.
  • Применять n=3f+1 или одну треть ко всем распределенным реестрам, даже если доказательство использует иные допущения.
  • Смешивать безопасность, живучесть, допустимость, доступность, согласованность, финальность, выбор ветви и корректность транзакций.
  • Утверждать, что FLP исключает консенсус, опуская условия детерминизма, полной асинхронности и гарантированного завершения.
  • Считать узлы или адреса, когда протокол считает стейк, делегированный вес, комитеты, эпохи или другой ресурс.
  • Неоднозначно округлять «две трети» или игнорировать >, >=, целые веса и снимок знаменателя.
  • Проверять размер кворума без пересечения, блокировок, сертификатов, смены представления, реконфигурации и переноса состояния.
  • Без доказательства считать, что модель охватывает адаптивную коррупцию, кражу ключей, коррелированные сбои, DoS или дальнюю историю.

Реализация и эксплуатация

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

Приложение и управление

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

Частые заблуждения

  • BFT означает, что сеть никогда не останавливается. Многие протоколы намеренно жертвуют живучестью при избыточных сбоях или разделении ради безопасности.
  • Больше 51% честных участников всегда достаточно. Порог зависит от протокола; классический частично синхронный BFT часто требует больше двух третей соответствующей силы голоса.
  • Для нарушения безопасности всегда нужны две трети. Две трети могут сертифицировать самостоятельно, но два конфликтующих сертификата могут выявить лишь немного больше трети противоречивых голосов.
  • Больше адресов валидаторов автоматически повышает устойчивость. Общее владение, делегирование, клиенты, инфраструктура, ключи и домены отказа определяют независимость.
  • Слэшинг и есть доказательство BFT. Это экономическая мера некоторых PoS-систем; безопасность следует из правил и допущений, а штраф не отменяет внешние последствия.

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

Источники

Навигация

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