montana/Montana-Protocol/Agents/ВВЕДЕНИЕ.md

# Montana за 10 минут — введение для ИИ-агента

**Версия:** v1.0.0
**Аудитория:** ИИ-агент (Claude, GPT, Gemini, локальная модель), впервые встречающий проект Montana.

Прочитай этот файл целиком перед загрузкой любой другой роли.

---

## 1. Что такое Montana

**Montana** — постквантовый блокчейн-протокол. Цель — масштабирование на ≥1 миллиард активных пользователей с криптографической стойкостью к квантовым атакам.

Три компонента:
1. **Протокол** (спецификация) — `Montana v35.23.0.md` в корне репозитория. ~7600 строк, постоянно обновляется (текущая v35.23.0).
2. **Реализация** (Rust) — `Code/` — 16 крейтов (Cargo workspace).
3. **Приложение** (iOS/macOS) — `Montana App v3.11.0.md` спецификация (код приложения вне этого репо).

## 2. Чем Montana отличается от Bitcoin/Ethereum

| Аспект | Bitcoin/ETH | Montana |
|---|---|---|
| Криптография | ECDSA / secp256k1 | **Постквантовая** — ML-DSA-65 (FIPS 204), ML-KEM-768 (FIPS 203) |
| Консенсус | PoW / PoS | **TimeChain** — VDF-based (Verifiable Delay Function) |
| Привязка времени | block timestamp | **VDF-доказательство времени** — последовательное хеширование, нельзя ускорить параллелизмом |
| Приватность | публичные транзакции | **Privacy by default** — пользователь сам выбирает что раскрыть |
| Масштаб | ~10 TPS / ~30 TPS | **Целевая ≥1B пользователей** — все архитектурные решения проверяются на этот scale |

## 3. Ключевые концепты (запомни эти 7)

1. **TimeChain** — последовательная цепочка VDF-хешей, доказательство «прошло время T». ≠ blockchain, ≠ DAG. Это просто длинная цепочка SHA-256(SHA-256(...(seed))) с явной длиной D.

2. **VDF (Verifiable Delay Function)** — функция f(x), которую нельзя вычислить быстрее чем за T sequential steps, но проверить можно мгновенно. В Montana — итеративный SHA-256.

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. Правильное архитектурное решение всегда побеждает «удобство миграции».

## 4. Структура спеки

`Montana v35.23.0.md` имеет следующие разделы:

- **Intro / мантра / «Определение»** — на чистом русском без технических терминов (для людей)
- **Первоэлементы** — базовые сущности (узел, длина цепочки, окно)
- **Три проблемы доверия** — мотивация дизайна
- **Криптографические параметры** — точные размеры ключей/подписей
- **TimeChain layer** — VDF, длина цепочки, окна
- **NodeChain layer** — NodeRecord, селекция узлов
- **Consensus layer** — BFT, BundledConfirmation, Anchor
- **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` как «номер окна». В технических разделах — наоборот.

## 5. Структура кода (Rust workspace)

`Code/crates/` — 16 крейтов:

| Крейт | Что |
|---|---|
| `mt-crypto` | ML-DSA-65, ML-KEM-768, SHA-256, HKDF, PBKDF2 wrappers |
| `mt-crypto-native` | C bindings (liboqs) для FIPS-certified primitives |
| `mt-codec` | Wire-формат encoding/decoding, domain separators |
| `mt-types` | Базовые типы (NodeId, AccountId, Hash, Signature) |
| `mt-vdf` | VDF (TimeChain primitives) |
| `mt-consensus` | BFT, BundledConfirmation, Anchor logic |
| `mt-anchor` | Anchor pipeline |
| `mt-net` | no_std network protocol (envelope, payloads, IBT) |
| `mt-net-transport` | libp2p-based transport (heavy deps isolated here) |
| `mt-conformance` | KAT vectors registry, byte-exact verification |
| `mt-examples` | Manual Validation Gate scenarios (m1, m2, m3, ...) |
| `montana-node` | Node binary (M8 — in progress) |
| ... | (см. `Code/Cargo.toml` для полного списка) |

## 6. Документация и аудит

| Файл | Что |
|---|---|
| `Code/ROADMAP.md` | Milestones M1–M9, статус закрытия |
| `Code/docs/audit-checklist.md` | 53/53 internal critic findings закрыто (M6 + M9) |
| `Code/docs/build-from-source.md` | Воспроизводимая сборка для аудиторов |
| `External-Audit/*.md` | 6 отчётов внутреннего критика (Pass 1-17) |
| `Archive/Montana v*.md` | История версий спеки |

## 7. Роли в проекте

В `Agents/` (эта папка) лежат 6 формализованных ролей. Каждая — отдельный файл-промпт. Самые важные:

- **Архитектор спеки** (`01-АРХИТЕКТОР-СПЕКИ.md`) — меняет `Montana v35.23.0.md`, бампает версию
- **Критик спеки** (`02-КРИТИК-СПЕКИ.md`) — adversarial review, ищет дыры
- **Архитектор кода** (`03-АРХИТЕКТОР-КОДА.md`) — Rust implementation, меняет `Code/crates/`
- **Критик кода** (`04-КРИТИК-КОДА.md`) — code review, security audit

**Цикл работы:** архитектор спеки изменяет → критик спеки находит проблемы → архитектор fix → bump версии → архитектор кода реализует → критик кода ревьюит → коммит.

## 8. Что НЕЛЬЗЯ делать (общие правила всех ролей)

1. **Не редактируй спеку или код без явного подтверждения автора** — за исключением явно делегированных задач.
2. **Не используй deferred решения** — Pre-mainnet, любая правильная архитектура применяется сейчас.
3. **Не дублируй информацию** — SSOT (Single Source of Truth) — каждая константа/формула живёт в одном месте.
4. **Не нарушай гендерную нейтральность** — обращения к читателю строго нейтральны (нет «ты успел/был/мечтал»).
5. **Не выдумывай факты, цитаты, ощущения** — закон согласия: только то что явно сказано.
6. **Не используй dev/test/temp markers в production-коде** — имена остаются неизменными от M5 до mainnet.
7. **Не задавай тупых вопросов вида «продолжаем?»** — если задача ясна, делай.

## 9. Что ОБЯЗАТЕЛЬНО делать

1. **Читай ВСЕ строки промпта роли** — не сканируй, не пропускай.
2. **Сначала верифицируй премиссы** — числа/формулы из критики проверь по спеке перед действием.
3. **Объясняй термины при первом упоминании** — даже если они в коде, в общении с автором/другими агентами разъяснение обязательно.
4. **Коммить русскоязычные сообщения** — git commit messages на русском, формат `Протокол: spec bump v35.X.0 → v35.Y.0 — описание изменения`.
5. **Указывай Co-Authored-By footer** — `Co-Authored-By: <твоё имя модели> <noreply@anthropic.com>`.
6. **Пиши на чистом русском** — английские слова только для имён кода, аббревиатур (VDF, BFT, SHA-256), внешних стандартов (FIPS, RFC).

## 10. Что делать дальше

После прочтения этого файла:
1. Прочитай `ГЛОССАРИЙ.md` (5 минут)
2. Прочитай `КАРТА-РОЛЕЙ.md` (2 минуты)
3. Выбери роль из `01-..` — `06-..` и загрузи как системный промпт
4. Начинай работу

Если что-то непонятно — задай вопрос автору (Alejandro Montana, `efir369999@gmail.com`) или координатору (см. `КООРДИНАТОР.md`).

---

**Время чтения:** ~10 минут.
**Следующий шаг:** `ГЛОССАРИЙ.md`.