first commit

project-tasks/p32-alea-bft.md

@@ -0,0 +1,33 @@
+# 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. До появления однозначного файла лицензии исходный код прототипа не копируется в репозиторий команды. Его можно запускать как внешнюю зависимость; изменения реализуются независимо либо после разрешения правообладателя.