montana/Формальная Документация/12 Управление и Обновления/Governance.md

91 lines
6.1 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.

# Управление и обновления Монтаны
**Версия:** черновик 1.0
**Базовый источник:** [Montana Protocol v35.25.0 §Эволюция протокола](../../Монтана-Протокол/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%20Спецификация%20Протокола/)).
## 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 v<version>.md` — переименовывается при бампе версии (`feedback_spec_rename.md`).
Это temporary, до запуска тестовой сети с открытой регистрацией (M9, см. [11 Тестовая сеть](../11%20Тестовая%20Сеть/)).
## 8. Открытые вопросы
- [ ] Конкретный формат MIP-документа.
- [ ] Состав первых advisory councils (крипто, экономика, сеть).
- [ ] Процедура экстренного отката (emergency rollback) при обнаружении critical bug на mainnet.
- [ ] Модель координации между языковыми изоляциями (RU/EN/ZH/ES) при общем протоколе.
## 9. Связанные документы
- [04 Спецификация](../04%20Спецификация%20Протокола/) — где зафиксированы текущие правила.
- [11 Тестовая сеть](../11%20Тестовая%20Сеть/) — как обновляется testnet до mainnet.
- [09 Внешний аудит](../09%20Внешний%20Аудит/) — pre-mainnet gate.
- [10 Формальная верификация](../10%20Формальная%20Верификация/) — pre-mainnet gate.
## 10. Источники
1. EIP process (Ethereum) — для контекста MIP.
2. BIP process (Bitcoin).
3. Tezos on-chain governance — для альтернативной модели.
4. Cardano CIP — параметрическая адаптация.