montana/Формальная Документация/11 Тестовая Сеть/M9-Расширение-Сети.md

119 lines
7.4 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.

# M9 — Расширение сети до n≥9
**Статус:** 🟡 План готов, исполнение требует решения автора по типу узлов.
## Контекст
Текущая сеть: 3 genesis-узла (мос/фра/зел) — все одного автора. По BFT-теореме f<n/3 при n=3 даёт f<1 нет ни одного запасного узла на отказ.
Цель M9: поднять до n9 с f<n/33 = реальный BFT-запас на 3 одновременных отказа.
## Два пути расширения
### Путь A — Независимые третьи операторы (закрывает G3 правильно)
**Что:** разные люди в разных юрисдикциях запускают свои узлы по [гайду оператора](Запуск-узла-для-всех.md).
**Плюсы:**
- Реальная BFT-независимость.
- Закрывает G3 формально.
- Готовит сеть к mainnet-launched.
**Минусы:**
- Требует найти 6+ людей готовых запустить узел.
- Без bug bounty (по решению автора это не коммерческий проект) мотивация только идейная или ранний-оператор-эмиссия.
- Гарантированно занимает недели-месяцы.
**Что нужно сделать:**
1. Опубликовать [гайд оператора](Запуск-узла-для-всех.md) готов.
2. Опубликовать спецификацию готова на хабе.
3. [ ] Зарелизить готовый бинарь `montana-node` (Linux/macOS, статический).
4. [ ] Опубликовать genesis-manifest.json в репо в открытом доступе.
5. [ ] Сделать публичное приглашение через каналы автора.
### Путь B — Author redundancy (увеличивает n но НЕ закрывает G3)
**Что:** на существующих 3 серверах (мос/фра/зел) поднимаем по 2 дополнительных не-bootstrap узла = всего 9.
**Плюсы:**
- Делается за час, контролируемо.
- Тестирует scaling-поведение Node Table.
- Защита от отказа одного из трёх существующих процессов (но не от компрометации автора).
**Минусы:**
- **G3 НЕ закрывается** все узлы под одним SSH-ключом автора, single point of compromise.
- Single-implementation risk сохраняется (см. F-01 в [внутреннем аудите](../09%20Внешний%20Аудит/Internal-Audit-2026-05-04.md)).
- Нагрузка на сервер: 3 узла × 1 ядро = 3 ядра под 100% непрерывно. Москва VM это потянет, остальные нужно проверить.
**Что нужно сделать (если автор выбирает этот путь):**
```
# На каждом сервере: создать 2 дополнительных узла-инстанса
ssh montana-moscow
sudo mkdir -p /var/lib/montana-2 /var/lib/montana-3
sudo chown root:root /var/lib/montana-2 /var/lib/montana-3
/usr/local/bin/montana-node init --data-dir /var/lib/montana-2
/usr/local/bin/montana-node init --data-dir /var/lib/montana-3
# Создать systemd unit для каждого
sudo tee /etc/systemd/system/montana-node-2.service > /dev/null <<'UNIT'
[Unit]
Description=Montana Node #2
After=network.target
[Service]
ExecStart=/usr/local/bin/montana-node start --data-dir /var/lib/montana-2 --listen /ip4/0.0.0.0/tcp/8445 --genesis-manifest /etc/montana/genesis-manifest.json
Restart=on-failure
[Install]
WantedBy=multi-user.target
UNIT
sudo systemctl daemon-reload
sudo systemctl enable --now montana-node-2
# То же для montana-node-3 на порту 8446 с data-dir /var/lib/montana-3
```
После ~10 часов registration_window каждый дополнительный узел станет CandidateVdf, потом Active при следующем selection event (каждые 336 окон).
## Архитекторское решение
**Путь A — единственный честный.** Path B увеличивает цифру n на бумаге, но G3 не закрывает: BFT теорема о f<n/3 предполагает что f отказов **независимы**. Если все узлы под одним SSH-ключом компрометация ключа = отказ всех = f=n. Это известная patten "monoculture risk" критиковалась в bitcoin-mining context (в Bitcoin есть три независимых имплементации специально по этой причине).
Поэтому **G3 в [Mainnet Readiness](../Mainnet-Readiness.md) остаётся 🟡** до прихода настоящих третьих операторов через Путь A.
Путь B полезен как:
- Stress-тест Node Table (как ведёт себя протокол при n=9).
- Защита liveness против отказа одного процесса (не оператора).
- Не используется как обоснование «G3 закрыт».
## Параллельные действия
Пока ждём третьих операторов:
1. **Релиз-теги.** Зафиксировать commit SHA текущего узла как v0.1.0-m8 в [Коде/](../../Монтана-Протокол/Код/). Закрывает часть F-04 в внутреннем аудите.
2. **Публикация бинарника.** Собрать статический бинарь, разместить в releases на хабе.
3. **Публикация genesis-manifest.** Сделать `https://montana.quest/efir369999/montana/raw/branch/main/Монтана-Протокол/genesis-manifest.json` доступным.
4. **Cross-region мониторинг.** Развернуть простой watchdog который собирает status с 3 узлов раз в минуту и публикует на montana.quest/explorer/.
5. **Документация подключения.** Видео-инструкция запуска узла.
## Когда G3 закроется
Формальный критерий: **n≥9 операторов, минимум 6 из которых принадлежат разным авторам в разных юрисдикциях**.
Стартовый таргет:
- 3 текущих genesis (один автор) +
- 6 независимых операторов (минимум) =
- 9 узлов с f<n/3=3 при f=3 одновременных компрометаций.
Достижение этого числа milestone M9 переход к M10 (pre-mainnet hardening).
## Связанные документы
- [Гайд оператора для всех](Запуск-узла-для-всех.md)
- [Внутренний аудит F-01, F-05](../09%20Внешний%20Аудит/Internal-Audit-2026-05-04.md)
- [Mainnet Readiness](../Mainnet-Readiness.md)
- [01 Консенсус — Safety/Liveness](../01%20Консенсус/Proof-of-Time.md)