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

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

Версия: черновик 1.0 Базовый источник: Montana Protocol v35.25.0 §Эволюция протокола

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 Спецификация).

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 Тестовая сеть).

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

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

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

• 04 Спецификация — где зафиксированы текущие правила.
• 11 Тестовая сеть — как обновляется testnet до mainnet.
• 09 Внешний аудит — pre-mainnet gate.
• 10 Формальная верификация — pre-mainnet gate.

10. Источники

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