montana/Formal-Docs/07-Threat-Model/Threat-Model.md

# Модель угроз Монтаны

**Версия:** черновик 1.0
**Базовый источник:** [SECURITY.md](../../Montana-Protocol/SECURITY.md), [Montana Protocol v35.25.0 §Глобальные инварианты](../../Montana-Protocol/Montana%20Protocol%20v35.25.0.md)

## 1. Кто может атаковать

| Актор | Возможности | Защита |
|-------|-------------|--------|
| Рядовой узел | Стандартные сообщения сети | Подписи + правила консенсуса |
| Майнер/оператор | Может крутить много VDF | f<n/3 BFT-граница |
| Оператор сговора | Координированные действия | f<n/3 BFT-граница |
| Государственный актор | Блокировка IP, давление на хостинг | Многосерверная архитектура (3 genesis в разных юрисдикциях) |
| Квантовый противник | Алгоритм Шора на дискретный логарифм | ML-DSA-65, ML-KEM-768 (FIPS 203/204) |
| Сетевой противник | DDoS, eclipse, man-in-the-middle | TLS-A pin, gossip избыточность, fail2ban |
| Имплементационный | Side-channel, ошибки кода | KAT, аудит, формальная верификация (см. [10](../10-Formal-Verification/)) |

## 2. Какие атаки рассматриваются

### 2.1 51% / большинство hashrate

**Не применимо.** В Монтане нет hashrate. VDF не параллелится — больше железа не даёт больше времени.

### 2.2 Long-range attack

**Защита:** канонический порядок основан на VDF-цепи от Genesis. Альтернативная цепь от t=0 потребует пересчитать всё VDF от Genesis до текущего момента — невозможно за разумное время для атакующего, у которого нет времени-форы.

### 2.3 Eclipse attack

**Угроза:** изоляция отдельного узла, заполнение его пирами-атакующими, подача ему альтернативной "канона".

**Защита:**
- Жёсткие bootstrap peers (3 genesis-узла).
- Проверка VDF-цепи независимо: даже изолированный узел может проверить что подаваемая цепь корректна.
- При расхождении со своим VDF — узел знает что ему врут.

**Открытый вопрос:** формальный анализ устойчивости к долгому eclipse (когда атакующий имеет ресурс держать узел в изоляции дни-недели).

### 2.4 Nothing-at-stake

**Не применимо.** Нет стейка. Победа в лотерее не зависит от баланса. Множественное участие в нескольких ветках стоит времени, не балансу.

### 2.5 Time manipulation

**Угроза:** подделка локального времени узла для манипуляции восприятием τ-координаты.

**Защита:**
- Канон не зависит от локального clock узла. Канон = длина VDF-цепи.
- Локальное время используется только для UX (отображение).

### 2.6 Network partition

**Угроза:** сеть разделяется на две части, обе продолжают своё VDF.

**Поведение:** обе подсети имеют валидные VDF-цепи. Когда сеть восстанавливается, протокол выбирает более длинную цепь (стандартное правило fork choice). Часть операций в "проигравшей" ветке откатывается.

**Граница безопасности:** safety сохраняется на каждой из подсетей в отдельности; liveness одной подсети может пострадать.

### 2.7 Quantum attack

**Защита:** все примитивы постквантовые (см. [02 Криптография](../02-Cryptography/)). Шор не работает.

**Граница:** SHA-256 при квантовом противнике даёт 128 бит preimage (Гровер, квадратичное ускорение) — всё ещё вне досягаемости.

### 2.8 Bribery / coercion

**Угроза:** атакующий подкупает оператора крутить альтернативную VDF-цепь.

**Защита:**
- Победа в лотерее не передаётся внешним способом — только через канон.
- Подкупленный оператор крутит свою VDF, но если он отступит от канонического порядка, его блок не примут.
- Протокольно — невозможно подкупить "будущее" поведение, только конкретные шаги.

### 2.9 Replay attack

**Защита:** seq в каждой операции аккаунта + привязка к τ-окну. Replay невозможен.

### 2.10 MEV (Maximal Extractable Value)

**Состояние:** в текущей версии MEV редуцируется к одному фактору — порядок операций внутри окна τ₁.

**Защита:**
- Внутри окна порядок выбирается победителем лотереи, который заранее не известен.
- Front-running через mempool — невозможен потому что нет публичного mempool в EVM-смысле.

**Открытый вопрос:** более глубокий анализ MEV-векторов в условиях когда прикладной слой развивается.

## 3. Что НЕ защищено протоколом (вне scope)

- Утечка пользовательского ключа (на стороне клиента).
- Социальная инженерия.
- Аппаратные атаки на устройство пользователя.
- Юридическое давление на конкретных операторов.

Эти векторы — задача клиентского слоя и operational security оператора, не протокола.

## 4. Допущения безопасности

| Допущение | Доказательство / источник |
|-----------|---------------------------|
| ML-DSA-65 EUF-CMA при f<n/3 | NIST FIPS 204 |
| SHA-256 collision resistance | NIST FIPS 180-4 |
| VDF несжимаемость | Pietrzak 2018 |
| Сеть после GST доставляет ≤ Δ | Стандартная модель Dwork-Lynch-Stockmeyer |
| Honest majority (n/3) | BFT consensus assumption |

## 5. Связанные документы

- [02 Криптография](../02-Cryptography/) — обоснование примитивов.
- [01 Консенсус](../01-Consensus/) — Safety/Liveness теоремы.
- [05 Сетевой слой](../05-Network-Layer/) — DDoS и eclipse детали.
- [08 Стимулы](../08-Incentives-Game-Theory/) — атаки через стимулы.
- [09 Внешний аудит](../09-External-Audit/) — нужен для подтверждения этой модели.

## 6. Источники

1. Lamport, L., Shostak, R., Pease, M. (1982). *The Byzantine Generals Problem*. TOPLAS.
2. Heilman, E., et al. (2015). *Eclipse Attacks on Bitcoin's Peer-to-Peer Network*. USENIX.
3. Daian, P., et al. (2020). *Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges* (для MEV-контекста).
4. NIST FIPS 203, 204, 205 (2024).