montana/Формальная Документация/05 Сетевой Слой/Сеть.md

77 lines
4.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Сетевой слой Монтаны
**Версия:** черновик 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.