efir369999/montana
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
5c74024e8a
montana/Формальная Документация/05 Сетевой Слой/Сеть.md

4.8 KiB
Raw Blame History

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

Версия: черновик 1.0 Базовый источник: Montana Network v1.0.0, Montana Protocol v35.25.0 §Сетевой уровень

1. Цель

Слой p2p передачи данных между узлами Монтаны. Должен:

  • Передавать VDF-выходы окон между операторами
  • Распространять AccountChain-операции
  • Поддерживать обнаружение узлов (discovery)
  • Защищать от Sybil и DDoS

2. Транспорт

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

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.