# P32. Alea-BFT: асинхронная репликация с византийскими отказами

- **Версия и дата проверки:** 1.0, 05.09.2026.
- **Статус:** готово к назначению.

## Статья и исходные материалы

- **Основная статья:** Diogo S. Antunes и соавт. — [Alea-BFT: Practical Asynchronous Byzantine Fault Tolerance](https://www.usenix.org/conference/nsdi24/presentation/antunes). NSDI 2024.
- **Кратко о статье:** Классические BFT-протоколы обычно полагаются на частичную синхронность, лидера и тайм-ауты, которые плохо работают при непредсказуемых задержках. Alea-BFT использует рандомизированную асинхронную модель и простой двухступенчатый конвейер: рассылку от назначенной реплики и последующее бинарное согласование. В проекте протокол сравнивается с опубликованным baseline на локальных процессах при задержках, потерях и crash-отказах.
- **Почему результат актуален:** прототип — снимок состояния на момент публикации, но асинхронная BFT-репликация остаётся самостоятельной базовой темой распределённых систем; две интеграции в системы распределённых валидаторов дают более сильный сигнал практической применимости, чем один экспериментальный стенд.
- **Артефакты и данные:** [diogoantunes25/AleaBFT](https://github.com/diogoantunes25/AleaBFT) — Java-прототип с Alea-BFT, HoneyBadger и Dumbo, режимами штатной работы, crash- и Byzantine-отказов и возможностью запускать несколько реплик на одной машине. [Официальная страница проекта](https://alea-bft.org/) указывает для прототипа лицензию MIT и приводит две интеграции протокола. Зафиксированная ревизия: `diogoantunes25/AleaBFT@543786ef199a` (MIT по официальной странице проекта; файл лицензии в репозитории отсутствует).

## Обязательный результат

- **Проверяемый вопрос или утверждение:** двухступенчатый конвейер сохраняет прогресс при непредсказуемых задержках и отказах без настройки таймаутов и даёт меньшую задержку, чем сравниваемые асинхронные протоколы в части режимов.
- **Технический результат:** Развернуть 4–7 локальных процессов Alea-BFT и хотя бы одного опубликованного baseline, подготовить общий клиент и управляемую инъекцию задержек, потерь и crash-отказов. Стенд должен автоматически проверять единый порядок доставки, отсутствие потерь подтверждённых запросов и прогресс допустимого числа реплик.
- **Эксперимент:** на подготовленном стенде сравнить Alea-BFT хотя бы с одним опубликованным baseline при контролируемых задержках, потерях и crash-отказах по порядку доставки, прогрессу, задержке и пропускной способности.
- **Границы выводов:** безопасность и прогресс проверяются для 4–7 локальных процессов, выбранного baseline и управляемых задержек, потерь и crash-отказов; эксперимент не подтверждает устойчивость ко всем византийским стратегиям и производительность геораспределённого развёртывания.
- **Ресурсный профиль:** расширенно локально, Linux или Docker, CPU, желательно 16 ГБ памяти. Если полный benchmark service нестабилен, оставить реальные локальные реплики Alea-BFT и один простой baseline, а сетевые режимы задавать через управляемый прокси или `tc netem`.

## Содержательные направления

- сборка реплик и автоматическая проверка согласованности порядка.
- базовый протокол и инъекция отказов.
- нагрузка, статистический анализ и новый режим.

## Возможное продолжение

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

## Известное ограничение

На зафиксированной ревизии нет файла лицензии, хотя официальная страница проекта указывает MIT. До появления однозначного файла лицензии исходный код прототипа не копируется в репозиторий команды. Его можно запускать как внешнюю зависимость; изменения реализуются независимо либо после разрешения правообладателя.