91 lines
6.1 KiB
Markdown
91 lines
6.1 KiB
Markdown
|
# Управление и обновления Монтаны
|
|||
|
|
|
|||
|
|
**Версия:** черновик 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 — параметрическая адаптация.
|