# M9 — Расширение сети до n≥9

**Статус:** 🟡 План готов, исполнение требует решения автора по типу узлов.

## Контекст

Текущая сеть: 3 genesis-узла (мос/фра/зел) — все одного автора. По BFT-теореме f<n/3 при n=3 даёт f<1 — нет ни одного запасного узла на отказ.

Цель M9: поднять до n≥9 с f<n/3≥3 = реальный 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)