efir369999/montana
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
main
montana/Формальная Документация/11 Тестовая Сеть/M9-Расширение-Сети.md

7.4 KiB
Raw Permalink Blame History

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

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

Контекст

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

Цель M9: поднять до n≥9 с f<n/3≥3 = реальный BFT-запас на 3 одновременных отказа.

Два пути расширения

Путь A — Независимые третьи операторы (закрывает G3 правильно)

Что: разные люди в разных юрисдикциях запускают свои узлы по гайду оператора.

Плюсы:

  • Реальная BFT-независимость.
  • Закрывает G3 формально.
  • Готовит сеть к mainnet-launched.

Минусы:

  • Требует найти 6+ людей готовых запустить узел.
  • Без bug bounty (по решению автора — это не коммерческий проект) мотивация только идейная или ранний-оператор-эмиссия.
  • Гарантированно занимает недели-месяцы.

Что нужно сделать:

  1. ✅ Опубликовать гайд оператора — готов.
  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 в внутреннем аудите).
  • Нагрузка на сервер: 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 остаётся 🟡 до прихода настоящих третьих операторов через Путь 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).

Связанные документы