**Аудитория:** ИИ-агент (Claude, GPT, Gemini, локальная модель), впервые встречающий проект Montana.
Прочитай этот файл целиком перед загрузкой любой другой роли.
---
## 1. Что такое Montana
**Montana** — постквантовый блокчейн-протокол. Цель — масштабирование на ≥1 миллиард активных пользователей с криптографической стойкостью к квантовым атакам.
1.**TimeChain** — последовательная цепочка SHA-256, доказательство «прошло время T». ≠ blockchain, ≠ DAG. Это длинная цепочка SHA-256(SHA-256(...(seed))) с явной длиной D.
2.**Sequential delay function** — функция f(x), которую нельзя вычислить быстрее чем за T sequential steps. В Montana — итеративный SHA-256; проверка стоит O(D), поэтому это не VDF с быстрой верификацией в смысле Boneh/Pietrzak/Wesolowski.
3.**NodeChain** — цепочка `NodeRecord`s (метаданных нод), параллельная TimeChain. Каждый узел публикует NodeRecord при включении в сеть.
4.**Lottery / Selection** — выбор лидера для следующего blockround по детерминированной формуле от VDF-вывода + state. Не PoS (нет staking), не PoW.
5.**Anchor** — финализация состояния через мульти-подписной BFT-комитет. Один из ключевых мест где квант-резистентность критична.
6.**Genesis Decree** — начальное состояние сети: `protocol_params` (D₀, размеры подписей, таймауты, max_*_bytes лимиты), bootstrap nodes, initial state.
7.**Pre-mainnet принцип** — Montana ещё не запущена. Любые breaking changes применяются сразу, без backward-compatibility shims. Правильное архитектурное решение всегда побеждает «удобство миграции».
- **Network layer** — wire-формат, IBT, mesh transport
- **Genesis Decree** — protocol_params, начальное состояние
- **Карточки замыкания механизмов** — детальные micro-spec для каждого layer
- **Threat Model** — 7×7 matrix
- **KAT (Known Answer Tests) vectors** — байт-точные test vectors для cross-implementation verification
**Правило чтения:** в первых разделах (intro/мантра/Определение) идентификаторы кода не используются — `chain_length` пишется как «длина цепочки», `window_index` как «номер окна». В технических разделах — наоборот.
**Цикл работы:** архитектор спеки изменяет → критик спеки находит проблемы → архитектор fix → bump версии → архитектор кода реализует → критик кода ревьюит → коммит.
## 8. Что НЕЛЬЗЯ делать (общие правила всех ролей)
1.**Не редактируй спеку или код без явного подтверждения автора** — за исключением явно делегированных задач.