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

Механизмы консенсуса: валидность, выбор ветви и финальность

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

Обновлено

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

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

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

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

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

Proof of Work и Proof of Stake обычно обеспечивают защиту от дешёвых дубликатов идентичности, влияние на предложение или подотчётный вес голосов, но их названия не определяют полный протокол. Bitcoin сочетает доказательство работы с проверкой и выбором по накопленной работе. Gasper в Ethereum сочетает взвешенные стейком аттестации, выбор LMD-GHOST и финальность контрольных точек Casper FFG. Раундовый BFT вроде CometBFT имеет другие сообщения, пороги, временные предположения и финальность. Их проценты не взаимозаменяемы.

Метод анализа

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

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

Разобранные примеры

1. Валидность не равна каноническому порядку

Неизрасходованный выход U стоит 1 BTC. Транзакция T_B расходует его в пользу Bob, а T_C — тот же выход в пользу Carol. Относительно одного родительского состояния каждая может иметь корректные подпись и формат, но допустимая история не может потребить U дважды.

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

2. Накопленная работа, а не число узлов

Пусть две допустимые ветви в стиле Bitcoin имеют накопленную работу W_A=240 и W_B=235 в одной условной единице. Проверяющий узел выбирает A по накопленной работе, даже если первым услышал B от большего числа пиров. Число пиров не является весом консенсуса.

Если затем B получает 10 единиц, а A ни одной, выходит W_B=245 против W_A=240; после проверки ветви узел может реорганизоваться на B. Упрощённый расчёт показывает вероятностность PoW-подтверждения: глубокую историю всё дороже заменить, но она не становится логически необратимой после фиксированного числа блоков.

3. Взвешенный кворум BFT и остановка живучести

Пусть общий вес валидаторов равен 100, а фиксация в стиле CometBFT требует предварительных фиксаций >2/3 для одного блока на одной высоте и в одном раунде. Целый вес 67 проходит. Два кворума по 67 пересекаются минимум на 34, поскольку 67 + 67 - 100 = 34. Если византийский вес меньше трети, пересечение содержит честный вес, который не должен подписывать конфликтующие фиксации.

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

4. Выбор ветви и финальность контрольных точек различны

В упрощённой трассе Gasper обозначим контрольные точки C_0, C_1 и её прямого потомка C_2. Голоса с 67/100 активного эффективного баланса могут создать сверхмажоритарную связь от C_0 к C_1, обосновав C_1. Следующая подходящая связь от C_1 к C_2 может финализировать более раннюю точку по соответствующему правилу FFG.

Между точками LMD-GHOST использует последние аттестации для выбора вершины среди допустимых потомков обоснованной точки, а ограничения финальной точки отбрасывают конфликтующие ветви. Выбор вершины, обоснование и финализация — связанные, но разные переходы; фраза «67% проголосовали за этот блок» полностью не описывает ни один.

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

Модель и гарантии

  • Говорить «сеть достигла консенсуса», не определив решение, безопасность, живучесть, валидность и завершение.
  • Считать Proof of Work, Proof of Stake, майнинг, стейкинг или процент голосов полной спецификацией.
  • Универсально применять 51%, 2/3 или n=3f+1 к разным моделям сбоев, времени, веса и финальности.
  • Смешивать остановку, византийское поведение, кражу ключа, неисправные каналы, коррелированное ПО и захват управления.
  • Называть FLP запретом практического консенсуса, а не результатом для детерминизма, полной асинхронности и гарантированного завершения.
  • Считать узлы или ключи без измерения независимых операторов, веса, клиентов, облаков и хранения.
  • Считать канонический, safe, обоснованный, зафиксированный и финальный статусы взаимозаменяемыми.
  • Выводить внешнюю истину, справедливый порядок, конфиденциальность, децентрализацию или стоимость из согласия реплик.

Протокол и реализация

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

Эксплуатация и приложение

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

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

  • Консенсус и проверка одинаковы. Проверка отвергает данные против правил; консенсус выбирает совместимые решения среди кандидатов, возможно допустимых локально.
  • Больше узлов автоматически означает больше безопасности. Влияние, независимость, топология, разнообразие ПО и модель сбоев важнее сырого числа процессов.
  • Атакующий с 51% может подделать любую подпись. Большинство ресурса может дать цензуру или реорганизацию в конкретном протоколе, но не раскрывает ключи и не разрешает недопустимую трату.
  • Две трети всегда означают финальность. Неравенство, сообщение, раунд, снимок весов, правило блокировки и условие финальности зависят от протокола.
  • Быстрые блоки доказывают сильный консенсус. Короткие интервалы могут усилить гонки распространения и давление ресурсов; задержку оценивают с безопасностью, живучестью и финальностью.

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

Источники

Навигация

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