montana/Монтана-Протокол/Агенты/ВВЕДЕНИЕ.md

138 lines
11 KiB
Markdown
Raw Permalink Normal View History

# 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) — `Код/` — 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)
`Код/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) |
| ... | (см. `Код/Cargo.toml` для полного списка) |
## 6. Документация и аудит
| Файл | Что |
|---|---|
| `Код/ROADMAP.md` | Milestones M1M9, статус закрытия |
| `Код/docs/audit-checklist.md` | 53/53 internal critic findings закрыто (M6 + M9) |
| `Код/docs/build-from-source.md` | Воспроизводимая сборка для аудиторов |
| `Внешний аудит/*.md` | 6 отчётов внутреннего критика (Pass 1-17) |
| `Архив/Montana v*.md` | История версий спеки |
## 7. Роли в проекте
В `Агенты/` (эта папка) лежат 6 формализованных ролей. Каждая — отдельный файл-промпт. Самые важные:
- **Архитектор спеки** (`01-АРХИТЕКТОР-СПЕКИ.md`) — меняет `Montana v35.23.0.md`, бампает версию
- **Критик спеки** (`02-КРИТИК-СПЕКИ.md`) — adversarial review, ищет дыры
- **Архитектор кода** (`03-АРХИТЕКТОР-КОДА.md`) — Rust implementation, меняет `Код/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`.