efir369999/montana
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
f26e622070
montana/Монтана-Протокол/Агенты/ВВЕДЕНИЕ.md

11 KiB
Raw Blame 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 — цепочка NodeRecords (метаданных нод), параллельная 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 M1–M9, статус закрытия
Код/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.