# Сетевой слой Монтаны

**Версия:** черновик 1.0
**Базовый источник:** [Montana Network v1.0.0](../../Монтана-Протокол/Montana%20Network%20v1.0.0.md), [Montana Protocol v35.25.0 §Сетевой уровень](../../Монтана-Протокол/Montana%20Protocol%20v35.25.0.md)

## 1. Цель

Слой p2p передачи данных между узлами Монтаны. Должен:
- Передавать VDF-выходы окон между операторами
- Распространять AccountChain-операции
- Поддерживать обнаружение узлов (discovery)
- Защищать от Sybil и DDoS

## 2. Транспорт

- **Протокол транспорта:** TCP с TLS-A (self-signed + certificate pinning), порт 8444 на M8.
- **PQ KEM:** ML-KEM-768 для обмена сессионными ключами (см. [02 Криптография](../02%20Криптография/)).
- **Сериализация:** канонический бинарный формат (см. §"Слой кодирования консенсуса").

## 3. Discovery (обнаружение узлов)

### 3.1 Bootstrap

3-узловой genesis-набор (см. memory `project_montana_3node_genesis_deploy.md`):
- mos (Moscow) — `176.124.208.93`
- fra (Frankfurt) — `89.19.208.158`
- зел (Helsinki) — `91.132.142.42`

Из любого genesis-узла новый оператор получает peer-list для дальнейшего расширения.

### 3.2 Защита от Sybil

Sybil-атака классически решается ценой. Монтана использует время:

- Регистрация нового узла требует выработки кандидатной VDF-цепи длиной ≥ 20 160 окон ≈ 10 часов настенного времени на обычном x86_64.
- Породить N подложных узлов = породить N таких цепей = N × 10 часов.
- Шорткатов нет: VDF не параллелится.

## 4. Распространение операций

- **Gossip protocol:** новые AccountChain-операции рассылаются всем известным peer-ам с экспоненциальным backoff'ом для уже-видевших.
- **Valid-only forwarding:** узел не пересылает операцию, не проверив подпись и канонический порядок локально.
- **Anti-spam:** одно-окно-один-шаг на личность; узел отбрасывает операции с нарушением.

## 5. Bandwidth model

При размере подписи ML-DSA-65 ≈ 3.3 КБ и операциях ~5 КБ:
- Один аккаунт даёт максимум 5 КБ за окно τ₁ ≈ 60 с → ≤ 0.7 Кбит/с на аккаунт.
- При N = 10⁹ активных аккаунтов теоретический пик = 700 Гбит/с глобально.
- Реальная нагрузка распределена через AccountChain-локальность: узел держит только подписку на аккаунты, которые его клиенты используют (не весь глобальный поток).

## 6. DDoS защита

| Уровень | Механизм |
|---------|----------|
| Сетевой | TCP rate-limiting на узле; nginx/iptables на genesis-узлах |
| Транспортный | TLS-A handshake требует валидной подписи peer'а |
| Протокольный | Один шаг на личность за окно (естественный rate-limit) |
| Приложный | Anchor-операции требуют времени на цепь — спамить дорого |

## 7. Реализация

`mt-net-tcp` crate в [Коде](../../Монтана-Протокол/Код/). M8 milestone завершает cross-machine peer-to-peer (см. memory `project_montana_cross_machine_m8.md`).

## 8. Открытые вопросы

- [ ] Анализ устойчивости gossip-распространения при разделении сети (network partition).
- [ ] Формальный анализ eclipse-атаки на отдельный узел.
- [ ] Тест против DDoS на genesis-узлах (см. memory: fail2ban установлен на Frankfurt + Moscow).
- [ ] Спецификация cross-region behaviour когда один из 3 genesis недоступен.

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

1. Heilman, E., Kendler, A., Zohar, A., Goldberg, S. (2015). *Eclipse Attacks on Bitcoin's Peer-to-Peer Network*. USENIX Security.
2. Decker, C., Wattenhofer, R. (2013). *Information propagation in the Bitcoin network*. P2P.
3. Montana Network v1.0.0.