---
title: "Механизмы консенсуса: валидность, выбор ветви и финальность"
description: "Механизм консенсуса согласует реплики на совместимой истории при явных предположениях о сбоях и сети. Отдельно анализируйте решение, участников и веса, валидность, предложение, выбор ветви, финальность, безопасность, живучесть и эксплуатацию."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Механизмы консенсуса: валидность, выбор ветви и финальность
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Механизм консенсуса — это протокол, по которому исправные реплики сходятся к совместимым решениям об упорядоченном журнале или состоянии, несмотря на задержки, параллельность и сбои, охваченные моделью. В блокчейне полный механизм может включать выбор предлагающего, проверку блоков и переходов состояния, голоса или доказательства, выбор ветви, фиксацию или финальность, восстановление и правила состава. Это не просто «много компьютеров хранят один файл», порог голосов, майнинг, стейкинг или расписание стимулов.
Три свойства следует задавать отдельно. `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% может подделать любую подпись.** Большинство ресурса может дать цензуру или реорганизацию в конкретном протоколе, но не раскрывает ключи и не разрешает недопустимую трату.
- **Две трети всегда означают финальность.** Неравенство, сообщение, раунд, снимок весов, правило блокировки и условие финальности зависят от протокола.
- **Быстрые блоки доказывают сильный консенсус.** Короткие интервалы могут усилить гонки распространения и давление ресурсов; задержку оценивают с безопасностью, живучестью и финальностью.
## Связанные темы
- [Византийская отказоустойчивость](/ru/crypto/byzantine-fault-tolerance/)
- [Задача византийских генералов](/ru/crypto/byzantine-generals-problem/)
- [Финальность](/ru/crypto/finality/)
- [Правило выбора ветви](/ru/crypto/fork-choice-rule/)
- [Proof of Stake](/ru/crypto/proof-of-stake/)
## Источники
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (дата обращения: 2026-08-19)
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (дата обращения: 2026-08-19)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (дата обращения: 2026-08-19)
- [Ethereum Consensus Specifications: Fork Choice](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/fork-choice.md) - Ethereum Foundation (дата обращения: 2026-08-19)
- [Impossibility of Distributed Consensus with One Faulty Process](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf) - Journal of the ACM (дата обращения: 2026-08-19)
- [Consensus in the Presence of Partial Synchrony](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) - Journal of the ACM (дата обращения: 2026-08-19)
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (дата обращения: 2026-08-19)
- [HotStuff: BFT Consensus in the Lens of Blockchain](https://arxiv.org/abs/1803.05069) - arXiv (дата обращения: 2026-08-19)
Source: https://wiki.fcontext.com/ru/crypto/consensus-mechanism/index.mdx