montana/Formal-Docs/12-Governance-Updates/Governance.md

# Управление и обновления Монтаны

**Версия:** черновик 1.0
**Базовый источник:** [Montana Protocol v35.25.0 §Эволюция протокола](../../Montana-Protocol/Montana%20Protocol%20v35.25.0.md)

## 1. Принцип

Монтана — pre-mainnet протокол. Согласно `feedback_premainnet_principle.md`: breaking changes применяются сразу, не предлагаются «отложить на потом». До запуска mainnet модель управления — single-author + ИИ-критики.

После mainnet модель меняется: вводятся MIP (Montana Improvement Proposal), advisory councils, параметрическая адаптация.

## 2. Жизненный цикл изменения (post-mainnet)

Согласно §"Эволюция протокола":

1. **MIP** (Montana Improvement Proposal) — предложение обсуждается в публичной форме.
2. **Advisory councils** — экспертные группы дают рекомендации.
3. **Параметрическая адаптация** — некоторые параметры (D, τ₂) автоматически адаптируются по правилам протокола, без MIP.
4. **Constitutional limits** — что MIP не может менять (см. §"Constitutional limits на MIP scope").
5. **Активация** — через `protocol_version` поле; узлы автоматически переключаются на новую логику когда большинство сети согласилось.

## 3. Hard fork vs soft fork

| Тип | Когда | Условия |
|-----|-------|---------|
| **Hard fork** | Несовместимое изменение | Все узлы должны обновиться |
| **Soft fork** | Сужение правил | Старые узлы продолжают работать (но не валидируют новые правила) |

Pre-mainnet — все изменения hard fork без backwards-compat shims (см. `feedback_premainnet_principle.md`).

Post-mainnet — soft forks предпочтительны для параметрической адаптации; hard forks — для крупных изменений с предварительным согласованием.

## 4. Поле protocol_version

Каждое окно τ₁ содержит `protocol_version` в своём заголовке. Изменение версии указывает узлам перейти на новую логику с указанной активационной точки.

Формат: `<major>.<minor>.<patch>`. Текущая версия спецификации — v35.25.0 (см. [04 Спецификация](../04-Protocol-Spec/)).

## 5. Constitutional limits

MIP не может менять:

- Базовое определение редкости (время, не стейк/hashrate).
- Постквантовый набор примитивов (без отдельной процедуры с advisory council по крипто).
- Глобальные инварианты протокола (см. §"Глобальные инварианты").
- Эмиссионную модель (поокнная, фиксированная за окно).

Эти constitutional limits защищают от capture (ситуации когда большинство голосов меняет фундаментальные свойства).

## 6. Параметрическая адаптация

Автоматические изменения без MIP:

- **D** (число итераций VDF) — пересчёт каждые τ₂ = 20 160 окон по медианному наблюдаемому времени.
- **Сложность лотереи** — если применимо, по правилам §"Лотерея".

Не автоматические (требуют MIP):
- Размер окна τ₁.
- Параметры эмиссии.
- Криптографические примитивы.

## 7. Текущая модель (pre-mainnet)

Согласно memory:
- **Архитектор:** автор (efir369999).
- **Критики:** Claude Opus 4.7 multiple passes (см. `feedback_architect_persistence.md`, `feedback_security_cards.md`).
- **Спецификация:** `Montana-Protocol/Montana Protocol v<version>.md` — переименовывается при бампе версии (`feedback_spec_rename.md`).

Это temporary, до запуска тестовой сети с открытой регистрацией (M9, см. [11 Тестовая сеть](../11-Testnet/)).

## 8. Открытые вопросы

- [ ] Конкретный формат MIP-документа.
- [ ] Состав первых advisory councils (крипто, экономика, сеть).
- [ ] Процедура экстренного отката (emergency rollback) при обнаружении critical bug на mainnet.
- [ ] Модель координации между языковыми изоляциями (RU/EN/ZH/ES) при общем протоколе.

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

- [04 Спецификация](../04-Protocol-Spec/) — где зафиксированы текущие правила.
- [11 Тестовая сеть](../11-Testnet/) — как обновляется testnet до mainnet.
- [09 Внешний аудит](../09-External-Audit/) — pre-mainnet gate.
- [10 Формальная верификация](../10-Formal-Verification/) — pre-mainnet gate.

## 10. Источники

1. EIP process (Ethereum) — для контекста MIP.
2. BIP process (Bitcoin).
3. Tezos on-chain governance — для альтернативной модели.
4. Cardano CIP — параметрическая адаптация.