---
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.
# Задача византийских генералов: согласие при противоречивых сообщениях
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Задача византийских генералов спрашивает, как исправные участники, обменивающиеся сообщениями, могут принять согласованное решение, если некоторые действуют произвольно, в том числе сообщают разным адресатам разные сведения. Военная история — аналогия интерактивной согласованности в распределённых системах, а не историческое событие и не конкретный алгоритм консенсуса блокчейна.
В постановке с командующим генералом условие `IC1` требует, чтобы все верные лейтенанты выполнили один приказ, а `IC2` — чтобы каждый верный лейтенант выполнил приказ командующего, если тот верен. Одного согласия недостаточно: правило всегда выбирать ОТСТУПЛЕНИЕ даёт согласие, но нарушает корректный приказ АТАКОВАТЬ от верного командующего.
В модели «устных сообщений» из статьи при не более чем `m` предателях решение существует только при `n>3m`, что для целого числа участников равносильно `n>=3m+1`. Модель предполагает, что сообщения верных участников доставляются без искажений, получатель знает отправителя, а отсутствие ожидаемого сообщения обнаружимо. «Устные» означает возможность выдать неаутентифицированное содержание за пересказ другого участника, а не возможность курьера навсегда исчезнуть незаметно.
Модель «подписанных сообщений» добавляет неподделываемые и публично проверяемые подписи и меняет результат по устойчивости. Подпись не делает содержание истинным, не гарантирует доставку, не решает задачу завершения в полностью асинхронной системе, не защищает украденные ключи и не доказывает безопасность современного протокола. Задача византийских генералов, задача двух генералов или координированной атаки, FLP, протоколы BFT, Proof of Work и Proof of Stake связаны, но являются разными моделями или конструкциями.
## Как анализировать задачу
1. **Определить задачу согласования.** Указать участников, входы, выходы и точные свойства согласия, валидности и завершения. Для постановки с командующим явно записать `IC1` и `IC2`, а не ограничиваться словами «достичь консенсуса».
2. **Определить идентичности и каналы.** Указать, аутентифицируются ли сообщения точка-точка, надёжно ли доставляются, упорядочиваются, защищаются от повторного воспроизведения и связываются с отправителем; обнаружимы ли пропуски; является ли широковещание примитивом или серией отправок.
3. **Определить временную модель.** Разделять синхронность с ограниченной задержкой, частичную синхронность после неизвестного момента стабилизации и полную асинхронность. Нельзя добавлять исчезающих посланников в одну модель и сохранять теорему, доказанную для другой.
4. **Определить бюджет сбоев.** Зафиксировать общее число участников `n`, максимум византийских участников `m`, статичность или адаптивность компрометации и то, включают ли сбои пропуски, противоречивые сообщения, сговор, кражу ключей либо неисправные каналы.
5. **Рекурсивно проследить информацию.** Для каждого верного участника перечислить прямые и переданные утверждения, включая пути отправителей, значения по умолчанию для отсутствующих сообщений и детерминированные правила разрешения ничьей. Сравнить, что два верных участника различают по своим локальным представлениям.
6. **Проверить теорему вместе с алгоритмом.** Сопоставить нижнюю границу и достаточность с точной устной или подписанной моделью, связностью и бюджетом сбоев. Одно пороговое неравенство не является ни реализацией, ни доказательством.
7. **Сопоставить модель с эксплуатацией.** Проверить применяемый механизм `OM(m)`, `SM(m)` или иной, домены сообщений, раунды, блокировки, сертификаты, смену состава, тайм-ауты, поведение клиента, правило финальности и политику подтверждений приложения.
Ключевой приём доказательства — неразличимость. Верный участник видит только свои локальные сообщения; если два исполнения выглядят для него одинаково, но валидность требует разных решений, никакое детерминированное правило не всегда выберет верно. Протоколы добавляют достаточно независимых участников, аутентифицированных свидетельств, временных предположений, случайности или иной структуры, чтобы нужные исполнения стали различимыми либо гарантия изменилась.
## Разобранные примеры
### 1. Почему три генерала с устными сообщениями не выдерживают одного предателя
Пусть `n=3` и `m=1`. Требование `n>3m` превращается в ложное `3>3`. Допустим, командующий A говорит лейтенанту B `ATTACK`, а лейтенанту C — `RETREAT`. B не может понять, предатель ли A, рассылающий разные приказы, или предатель C ложно пересказывает слова A; у C симметричная неопределённость.
Любой детерминированный выбор, сохраняющий приказ верного командующего в соответствующих исполнениях с верным A, может заставить B и C выбрать разное при предателе A. Пересылка не создаёт четвёртый независимый источник, поэтому одновременно гарантировать `IC1` и `IC2` невозможно.
### 2. Четыре генерала с устными сообщениями и один предатель
При `OM(1)`, `n=4` и `m=1` командующий отправляет приказ трём лейтенантам; каждый пересылает полученное значение двум другим; каждый верный лейтенант применяет одинаковое правило большинства и значение по умолчанию. Если командующий верен и отправляет `v`, верный лейтенант видит, например, `v`, `v` и возможное `x` предателя, поэтому выбирает `v`.
Если командующий — единственный предатель, все три лейтенанта верны и точно пересылают полученное. Они восстанавливают один и тот же набор заявлений командующего каждому лейтенанту и применяют одно детерминированное правило. Они могут не узнать «истинное намерение» командующего, но достигают согласия.
### 3. Общая нижняя граница для устных сообщений
При `n=7` и `m=2` условие `7>6` выполняется, поэтому предпосылка по числу участников соблюдена и рекурсивная конструкция устных сообщений может при своих предположениях выдержать до двух предателей. При `n=6` утверждение `6>6` ложно. При `n=10` и `m=3` условие `10>9` выполняется. Неравенство необходимо, но также нужны правильные раунды, пересылка, большинство, значения по умолчанию и каналы.
### 4. Что меняют подписи
В примере с тремя генералами и `SM(1)` командующий-предатель подписывает `ATTACK` для B и `RETREAT` для C. Верные лейтенанты пересылают оба подписанных приказа, поэтому каждый получает один набор `{ATTACK, RETREAT}` и применяет заданное значение по умолчанию, например `RETREAT`. Авторство противоречия установлено.
В рамках модели подписи не дают незаметно подделать или изменить приказ верного участника. Они не показывают, какой приказ отражает реальное намерение предателя, не гарантируют своевременную доставку и не мешают атакующему с легитимным закрытым ключом подписать оба.
## Риски и ошибки проверки
### Задача и модель
- Пересказывать аллегорию без точных условий согласия, валидности и завершения.
- Считать задачу исторической осадой, единственным алгоритмом или синонимом блокчейна.
- Смешивать её с задачей двух генералов о всеобщем знании при ненадёжном канале.
- Добавлять необнаружимую постоянную потерю сообщений, цитируя теорему, чьи предположения устной модели её исключают.
- Применять `n>3m` к любому аутентифицированному, асинхронному, взвешенному, открытому или ресурсному протоколу.
- Считать отказ, пропуск, противоречивые сообщения, произвольные вычисления, неисправные каналы и компрометацию ключа одним сбоем.
- Приравнивать число участников к независимым организациям, стейку, хеш-мощности или весу комитета.
- Не различать верного и предавшего командующего в условии валидности.
### Алгоритм и реализация
- Проверять только итоговое большинство, не прослеживая рекурсивные пути отправителей и локальный вид каждого верного участника.
- Использовать разные значения по умолчанию, правила ничьей, снимки состава или порядок сообщений в разных реализациях.
- Принимать сообщения без привязки к протоколу, цепочке, задаче, высоте, раунду, значению, отправителю и эпохе состава.
- Повторно применять или склеивать сообщения между исполнениями, раундами, ветками, сетями или изменениями состава.
- Считать подпись доказательством истинности, свежести, контекста полномочий, доставки, доступности или честного хранения ключа.
- Ссылаться на `OM(m)` или `SM(m)`, не реализовав нужные раунды, пересылку, проверку и связность.
- Тестировать только одно положение предателя вместо случаев командующего, лейтенанта, сговора, пропуска и противоречивых сообщений.
### Эксплуатация и интерпретация
- Заявлять, что протокол консенсуса «решает Византию», без точных предположений о безопасности, живучести и сети.
- Считать согласие о байтах доказательством корректности исполнения приложения или внешнего факта.
- Игнорировать общие клиенты, операторов, облака, системы ключей и управление, связывающие номинально разных участников.
- Зачислять депозиты, выпускать мостовые активы или необратимо рассчитываться до выполнения условия финальности.
- Выводить децентрализацию, безопасность активов, юридическую истину или стоимость токена из ярлыка отказоустойчивости.
## Распространённые заблуждения
- **Это просто атака 51 %.** Задача рассматривает произвольное и противоречивое поведение в определённой модели согласования; атаки ресурсного большинства относятся к конкретным протоколам.
- **Большинство всегда решает задачу.** В классической модели устных сообщений для устойчивости к `m` предателям нужно более чем втрое больше участников, а не просто на одного честного больше.
- **Цифровая подпись доказывает истинность сообщения.** Она аутентифицирует ключ и защищает целостность; вредоносный или скомпрометированный ключ всё равно подпишет ложное либо противоречивое содержание.
- **Ненадёжная доставка уже учтена исходным результатом для устных сообщений.** В нём явно предполагаются доставка, известность отправителя и обнаружимость пропуска; для иных моделей времени и каналов нужны другие результаты.
- **Согласие означает, что система узнала реальность.** Без отдельных правил валидации верные узлы могут согласовать некорректный результат приложения или ошибочные внешние данные.
## Связанные темы
- [Византийская отказоустойчивость](/ru/crypto/byzantine-fault-tolerance/)
- [Механизм консенсуса](/ru/crypto/consensus-mechanism/)
- [Финальность](/ru/crypto/finality/)
## Источники
- [The Byzantine Generals Problem](https://lamport.azurewebsites.net/pubs/byz.pdf) - ACM Transactions on Programming Languages and Systems (дата обращения: 2026-08-19)
- [Reaching Agreement in the Presence of Faults](https://lamport.azurewebsites.net/pubs/reaching.pdf) - Journal of the ACM (дата обращения: 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)
- [Practical Byzantine Fault Tolerance](https://pmg.csail.mit.edu/papers/osdi99.pdf) - USENIX OSDI (дата обращения: 2026-08-19)
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (дата обращения: 2026-08-19)
- [HotStuff: BFT Consensus with Linearity and Responsiveness](https://arxiv.org/abs/1803.05069) - arXiv (дата обращения: 2026-08-19)
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (дата обращения: 2026-08-19)
Source: https://wiki.fcontext.com/ru/crypto/byzantine-generals-problem/index.mdx