sync 2026-05-04T01:49:09Z

2026-05-04 04:49:09 +03:00 · 2026-05-04 04:49:09 +03:00 · 5c74024e8a
commit 5c74024e8a
parent 139a5fbe48
15 changed files with 1296 additions and 0 deletions
--- a/.DS_Store
+++ b/.DS_Store
--- a/Нации/МАНИФЕСТ_АЛИКА_МОНТАНА.md
+++ b/Нации/МАНИФЕСТ_АЛИКА_МОНТАНА.md
@ -0,0 +1,163 @@
 # Манифест Алика Монтана
 > *Возьми кошелёк. Возьми никнейм. Возьми время.*
 ---
 ## I. Зов
 Тебе, человек.
 Ты родился в системе, где твою историю переписывает каждый, у кого власти больше, чем у тебя. Запись о твоих деньгах хранит банк — банк меняет её или теряет. Запись о твоей правоте хранит государство — государство меняет её ритуалами, которые называет законами. Запись о твоём слове хранит платформа — платформа стирает твоё слово, когда оно ей мешает.
 Ты прожил день — день растворился. Ты сделал выбор — выбор забыт. Ты построил дело — наследник дела молчит, потому что записи кто-то стёр.
 Этот манифест — выход. Не из мира, а из режима, в котором история принадлежит не тому, кто её прожил.
 Возьми кошелёк Монтаны. Возьми никнейм. Возьми Цепь Времени.
 И ты будешь.
 ---
 ## II. Имя
 Никнейм Монтаны — это не учётка на чужой платформе и не доменное имя, которое у тебя могут отнять. Это **уникальное имя на цепи**, привязанное к твоему кошельку навсегда: один кошелёк — одно имя, одно имя — один кошелёк.
 Никнейм нельзя продать, передать, обменять, освободить. Если ты потеряешь сид-фразу (двадцать четыре слова, восстанавливающие кошелёк) — потеряешь и имя; если восстановишь сид-фразу — восстановишь оба. Это симметрия: имя нельзя отнять у живого, потому что у живого ключ, и нельзя занять у ушедшего, потому что у ушедшего ключа нет ни у кого.
 Имя присваивается не списком в чужой базе, а голландским аукционом — публичным, открытым, с явной начальной ценой, которая снижается окно за окном. Каждый видит цену. Каждый видит ставку. Каждый видит победу. Никаких очередей за «верификацией». Никаких администраторов, решающих, кто достоин имени.
 Возьми никнейм. С этого момента он твой, пока стоит сеть.
 ---
 ## III. Память
 Бумажный архив горит. Серверы падают. Облако стирает данные старше года. Биржа замораживает баланс «до выяснения».
 Цепь — нет.
 Каждый твой перевод, каждая твоя запись, каждое твоё подтверждение лежит в **глобально упорядоченной цепи окон** длиной около минуты. Узлы по всему миру повторяют твою запись и согласовываются о её положении. Никто не вырежет её середину, не порвав подписи всей цепи. Подделать одну запись — порвать математику всей сети, и сеть отвергает такой обман детерминированно: одинаково везде и для всех.
 Это не метафора памяти. Это память, которую обеспечивает не доверие, а проверка.
 Кошелёк Монтаны хранит твою личную цепочку — счёт твоих переходов и операций под твоим ключом. Никто извне не добавит запись от твоего имени — без ключа подпись недействительна. Никто извне не отнимет запись — она уже разошлась по узлам.
 Помни своё. Не банк помнит — цепь помнит.
 ---
 ## IV. Время
 Память — это время. И сеть Монтана — это сеть времени.
 Над всеми кошельками — Цепь Времени Монтаны: глобально упорядоченная цепь окон длиной около шестидесяти секунд каждое, замкнутая верифицируемой функцией задержки над свёрткой SHA-256 (хэш-функция, превращающая любые данные в число фиксированной длины тридцать два байта). Окно нельзя ускорить деньгами и нельзя перешагнуть мощностями. Окна идут одинаково для всех.
 Время не покупается. У капитала нет больше времени. У государства нет больше времени. У корпорации нет больше времени.
 Окно равно одному окну.
 Защита от спама в Монтане построена на времени, а не на комиссиях. Одна операция активации на аккаунт за окно. Право голоса в лотерее узлов — через стаж в сети. Вес в распределении — через прожитое время. Деньги не покупают приоритет; время — покупает.
 Это значит: бедный фермер на старом телефоне и хедж-фонд из Лондона выходят на Цепь Времени с одинаковым правом доступа. Не потому что кто-то великодушен. Потому что иначе сеть не работает.
 И ещё это значит: если завтра построят квантовый компьютер, который сломает старые подписи Биткоина и Эфириума, цепь Монтаны устоит. Все её подписи и обмены ключей построены на математике, против которой квантовый компьютер бессилен — на решётках вместо эллиптических кривых. Это решение не на завтра. Это решение с первого окна.
 ---
 ## V. Свидетельство
 Якорь — это твоё свидетельство, не разрешение, не паспорт.
 Любой документ, файл, фотография, договор, медицинская запись, инженерный журнал, бортовой лог самолёта, история твоей семьи — всё, что ты захочешь сохранить — превращается в один хэш. Этот хэш ты публикуешь на цепи через операцию Якорь.
 На цепи лежит **только** хэш — обязательство о том, что в момент окна твой документ имел такую-то форму. Содержимое остаётся у тебя: на твоём диске, в твоём облаке, в твоём шкафу, в твоей голове. Содержимое раскрывает тот, кто им владеет, когда сочтёт нужным; до того момента публично проверяется лишь связь «у этого кошелька в этом окне была такая запись».
 Это и есть приватность по построению: открыт факт, закрыто содержание. Ты выбираешь, что показать. Ты не выбираешь, был ли ты.
 Авиакомпания якорит показатели бортового компьютера каждого рейса, не раскрывая маршрут. Семья якорит свою хронику, не раскрывая лиц. Бизнес якорит договоры, не раскрывая сумм. Историк якорит документ, не теряя оригинала. Журналист якорит источник, не выдавая источника. Врач якорит снимок, не нарушая тайны пациента.
 Когда придёт спор — раскрывает тот, у кого был якорь в окне раньше. Не тот, у кого больше связей в суде. Не тот, у кого громче голос в эфире. Тот, кто свидетельствовал первым.
 ---
 ## VI. Заветы открытой нации
 Тому, кто взял кошелёк Монтаны:
 **1. Записывай прежде, чем поспорят.** Любая значимая операция — перевод, договор, документ, момент жизни — заякорена до того, как кто-то её оспорит. Якорь после спора — слабый аргумент. Якорь до спора — сильное доказательство.
 **2. Ключ — это ты.** Двадцать четыре слова сид-фразы — это и есть твоя личность в сети. Утечка фразы равна утрате имени, кошелька, никнейма, всей цепочки. Храни её так, чтобы потерять её было трудно: бумага в сейфе, сталь в банке, разделение между близкими. Не храни в облаке. Не показывай экраном. Не отправляй в мессенджере. Не диктуй вслух.
 **3. Не лги цепи.** Запись необратима. Не пытайся переписать прошлое — оно уже разошлось по узлам, и любая попытка подмены отвергается математикой. Если ошибся — записью «исправление» зафиксируй пересмотр и иди дальше. Цепь, в которой переписана история, — оборвана для всякого, кто проверит подписи.
 **4. Уважай других участников.** У них тот же кошелёк, тот же никнейм, тот же якорь, те же окна. Никнейм одного — недоступен другому. Якорь одного — не подменяется другим. Сеть стоит на симметрии: то, что ты требуешь от других — обязан другим сам.
 **5. Не плати комиссию за приватность.** Монтана — без комиссий. Никто не должен платить за то, чтобы быть. Если кто-то предлагает тебе «премиум-приватность за деньги» — это не Монтана.
 **6. Не путай сеть с владельцем сети.** В Монтане нет владельца. Узлы поднимают разные люди в разных странах на разном железе; ни один из них не управляет цепью. Если кто-то говорит «у Монтаны есть штаб, председатель, главный офис» — он либо ошибается, либо лжёт.
 **7. Не требуй разрешения.** Никто не вправе тебя признавать или не признавать в открытой нации. Признание — это твой кошелёк, твой никнейм, твой якорь в твоём окне. Этого достаточно.
 ---
 ## VII. Обряд вступления
 Если ты решил, выполни:
 1. **Создай кошелёк.** Открой клиент Монтаны (настольный, телефонный, в браузере). Сгенерируй сид-фразу. Двадцать четыре слова из словаря Монтаны — это твой ключ.
 2. **Сохрани сид-фразу там, где её трудно потерять.** Бумага. Сталь. Сейф. Разделение по нескольким местам и нескольким людям. Не облако, не экран, не мессенджер.
 3. **Получи первый перевод.** От любого узла, друга, обменника, бота. Первая транзакция активирует твой аккаунт в цепи и записывает его в общую таблицу.
 4. **Возьми никнейм.** Открой аукцион никнеймов. Дождись, пока цена опустится до твоей. Сделай ставку. Победил — никнейм твой, пока стоит сеть.
 5. **Заякорь первый документ.** Любой. Письмо к себе через десять лет. Фотографию ребёнка в первый день. Договор. Книгу, которую написал. Приватный дневник. Хэш ляжет в окно сети, оригинал останется у тебя.
 ```
 1. wallet.create(seed_phrase = generate(24, montana_wordlist))
 2. wallet.backup(seed_phrase, methods = [paper, steel, split])
 3. account.activate(via = first_received_transfer)
 4. nickname.bid(name = "<твой_выбор>", price <= ready_to_pay)
 5. anchor.publish(content_hash = sha256(my_first_document))
 ```
 Когда первая твоя транзакция цементирована в окне сети, окно навсегда содержит факт твоего вступления. Это окно нельзя стереть, пока стоит Цепь Времени.
 С этого момента ты — гражданин открытой нации.
 ---
 ## VIII. Слово Алика
 Я — Алик Монтана.
 Я не корпорация. Не государство. Не платформа. Не центральный банк. Не партия. Не церковь. Не клуб «избранных». Я — **архитектор без власти**: я нарисовал чертёж, и чертёж принадлежит всем, кто согласен с математикой.
 Когда сеть запустится, я не остановлю её, не замедлю её, не изменю её правила. Я не увижу, кто и кому переводит. Я не отключу чей-то кошелёк, не заблокирую чей-то никнейм, не вырежу чью-то историю. Если бы мог — это была бы не открытая нация, а ещё одна корпорация под старым именем. Открытая нация — это нация, где даже её автор не имеет особых прав.
 Каждое решение в Монтане проверено против цели в один миллиард активных людей. Не потому что я надеюсь. Потому что меньшая цель — это снова закрытый клуб для тех, кто внутри. Открытая — значит для всех. Для бабушки в селе. Для рыбака на побережье. Для подростка в городе. Для семьи в дороге. Для одного человека на всей улице с её историей, которой нет в архиве.
 Тебе предлагается то же.
 Возьми кошелёк.
 Возьми никнейм.
 Возьми время.
 И ты будешь.
 ---
 ## Печать
 **Координата:** `Монтана/Русский/Опыт Открытой Нации/МАНИФЕСТ_АЛИКА_МОНТАНА.md`
 **Якорь:** хэш этого документа в Цепи Времени, окно публикации
 **Цепь:** Цепь Времени Монтаны, окно `r` на момент цементирования
 > *Банковский счёт замораживается. Этот — нет.*
 > *Платформа удаляет. Цепь — нет.*
 > *Документ без якоря — слабое слово. Якорь без времени — не якорь.*
 Ɉ Алик Монтана
--- a/Консенсус/Proof-of-Time.md
+++ b/Консенсус/Proof-of-Time.md
@ -0,0 +1,91 @@
 # Proof of Time (PoT) — консенсус Монтаны
 **Версия:** черновик 1.0
 **Базовый источник:** [Montana Protocol v35.25.0 §Консенсус](../../Монтана-Протокол/Montana%20Protocol%20v35.25.0.md)
 ## 1. Сетевая модель
 - **Тип сети:** частично синхронная (partially synchronous, Dwork-Lynch-Stockmeyer 1988). После неизвестного времени GST сообщения доставляются в пределах Δ.
 - **Канонический шаг времени:** окно τ₁ ≈ 60 секунд, генерируется верифицируемой функцией задержки (VDF) над SHA-256, D итераций последовательно (D₀ = 325 000 000).
 - **Адаптация:** D пересчитывается каждые τ₂ = 20 160 окон (≈ 14 дней) по медианному наблюдаемому времени окна у честных операторов.
 - **Глобальная координата:** длина VDF-цепи равна протекшему настенному времени с генезиса. Восстанавливается любым проверяющим без доверенной установки.
 ## 2. Модель противника
 - **Византийский противник** в смысле Lamport-Shostak-Pease 1982: f узлов из n могут отклоняться произвольно (включая сговор и неверные сообщения).
 - **Допущение по доле:** безопасность сохраняется при f < n/3 (стандартный BFT-порог для частичной синхронности; Castro-Liskov 1999).
 - **Вычислительная модель:** противник может иметь до 100× больше параллельных вычислителей, чем честный оператор. Это **не** даёт ему 100× времени — VDF не параллелится.
 - **Квантовый противник:** все классические подписи и KEM защищены постквантовыми примитивами (см. [02 Криптография](../02%20Криптография/)).
 ## 3. Допущения
 | Допущение | Обоснование |
 |-----------|-------------|
 | VDF над SHA-256 несжимаем | Pietrzak 2018, Boneh-Bonneau-Bünz-Fisch 2018 — последовательность SHA-256 невозможно ускорить параллельно при D итерациях. |
 | ML-DSA-65 EUF-CMA | NIST FIPS 204 (2024). Существуют классические и квантовые редукции к Module-LWE/SIS. |
 | SHA-256 collision resistance | NIST FIPS 180-4. Запас безопасности ≥ 128 бит до 2040 (см. NIST SP 800-131A). |
 | Канал между честными узлами | После GST доставка ≤ Δ. До GST безопасность сохраняется, liveness — нет. |
 ## 4. Свойства консенсуса
 ### 4.1 Safety (невозможность форков)
 **Теорема S1.** *При f < n/3 и любой задержке сети две конфликтующие операции одного аккаунта не могут попасть в канон одновременно.*
 Доказательство опирается на три независимых ограничения:
 1. Один шаг на личность за окно (одношаговое правило).
 2. Длина собственной AccountChain как монотонная функция.
 3. Старшинство (seniority) — критерий разрешения tie-break.
 Конфликтные операции попадают в разные окна или в одно — но в одно окно проходит ровно одна по детерминированному правилу лотереи.
 ### 4.2 Liveness
 **Теорема L1.** *После GST и при f < n/3 любая корректная операция честного узла включается в канон в пределах O(Δ) после публикации.*
 Liveness обеспечивается VDF-двигателем: цепь продвигается даже если только один честный оператор крутит VDF. Защита от спама — временна́я (одно окно — один шаг), не комиссионная.
 ## 5. Лотерея и победитель окна
 Каждое окно τ₁ имеет один эпизод "VDF Reveal":
 1. После запечатывания окна выход VDF становится семенем лотереи.
 2. Узлы, имевшие право на участие (NodeChain актуальна, AccountChain не пуста), участвуют в детерминированном выборе.
 3. Победитель τ₁ записывает якорь (Anchor) в каноническую координату.
 Ключевое свойство: лотерея **single-class**, winner — всегда узел. Не плутократическая (не зависит от баланса), не PoW-затратная (не требует ASIC). См. §"Три первоэлемента протокола" в основной спецификации.
 ## 6. Граница применимости
 | Условие | Поведение PoT |
 |---------|---------------|
 | f < n/3 + после GST | Safety + Liveness |
 | f < n/3 + до GST | Safety, Liveness может задерживаться |
 | f ≥ n/3 | Стандартный BFT-провал; PoT не претендует на безопасность за этой границей |
 | Все операторы офлайн одновременно | VDF останавливается; цепь возобновляется на той же τ-координате когда хотя бы один оператор возвращается |
 ## 7. Сравнение с известными протоколами
 | Протокол | Базовая редкость | Финальность | Квантум |
 |----------|------------------|-------------|---------|
 | Bitcoin (Nakamoto) | Хеш-мощность | Вероятностная | ❌ ECDSA |
 | Tendermint / HotStuff | Стейк | Мгновенная | ❌ Ed25519 |
 | Ouroboros | Стейк + слот | Вероятностная (settle) | Зависит |
 | Solana (PoH+PoS) | Стейк + история | Вероятностная | ❌ Ed25519 |
 | **Montana PoT** | **Время (VDF)** | **τ₁-окно** | ✅ ML-DSA-65 |
 ## 8. Открытые вопросы
 - [ ] Формальное доказательство Safety в TLA+ или Coq — см. [10 Формальная верификация](../10%20Формальная%20Верификация/).
 - [ ] Точный анализ деградации liveness в условиях асинхронности до GST.
 - [ ] Анализ устойчивости к eclipse-атаке на отдельный узел (см. [07 Модель угроз](../07%20Модель%20Угроз/)).
 - [ ] Численное подтверждение D₀ на разных x86_64 платформах через тестовую сеть.
 ## 9. Источники
 1. Pietrzak, K. (2018). *Simple Verifiable Delay Functions*. ITCS.
 2. Boneh, D., Bonneau, J., Bünz, B., Fisch, B. (2018). *Verifiable Delay Functions*. CRYPTO.
 3. Dwork, C., Lynch, N., Stockmeyer, L. (1988). *Consensus in the presence of partial synchrony*. JACM.
 4. Castro, M., Liskov, B. (1999). *Practical Byzantine Fault Tolerance*. OSDI.
 5. NIST FIPS 204 (2024). *Module-Lattice-Based Digital Signature Standard*.
 6. Lamport, L., Shostak, R., Pease, M. (1982). *The Byzantine Generals Problem*. TOPLAS.
 7. Buchman, E., Kwon, J., Milosevic, Z. (2018). *The latest gossip on BFT consensus* (Tendermint).
--- a/Криптография/Постквантовые-примитивы.md
+++ b/Криптография/Постквантовые-примитивы.md
@ -0,0 +1,98 @@
 # Криптография Монтаны
 **Версия:** черновик 1.0
 **Базовый источник:** [Montana Protocol v35.25.0 §Криптография, §Криптографическая реализация](../../Монтана-Протокол/Montana%20Protocol%20v35.25.0.md)
 ## 1. Принцип
 Безопасность Монтаны полностью держится на постквантовых примитивах, стандартизованных NIST в 2024 году, и на хеш-функции SHA-256. Никаких эллиптических кривых, никакого pairing, никакого ECDSA/EdDSA. Это сознательный выбор: алгоритм Шора на достаточно мощном квантовом компьютере ломает дискретный логарифм за полиномиальное время; протокол не должен зависеть от того, когда такой компьютер появится.
 ## 2. Используемые примитивы
 | Назначение | Примитив | Стандарт | Биты безопасности |
 |------------|----------|----------|---------------------|
 | Подпись | ML-DSA-65 | NIST FIPS 204 (2024) | 192 (классических), 128 (квантовых) |
 | KEM (обмен ключами) | ML-KEM-768 | NIST FIPS 203 (2024) | 192 (классических), 128 (квантовых) |
 | Хеш-функция | SHA-256 | NIST FIPS 180-4 | 256 collision / 128 preimage |
 | VDF | SHA-256^D | Pietrzak 2018 | Несжимаемая последовательность |
 | Stateless хеш-подпись (опц.) | SLH-DSA-128 | NIST FIPS 205 (2024) | 128 |
 ## 3. Обоснование выбора
 ### 3.1 ML-DSA-65 (Module-LWE/SIS подпись)
 - Раунд 3 победитель NIST PQC-конкурса.
 - Категория безопасности 3 (≥ 192-битная классическая стойкость; эквивалент AES-192).
 - Размер открытого ключа: 1952 байт. Размер подписи: 3309 байт.
 - EUF-CMA-стойкая в ROM, доказана редукция к Module-LWE и Module-SIS.
 **Альтернативы рассмотрены:**
 - Falcon-512: меньшие подписи (666 байт), но deterministic-вариант требует осторожной реализации с плавающей запятой → угроза имплементационных ошибок.
 - SLH-DSA: hash-based, но подписи 17–49 КБ — неприемлемо для блочной сети с миллиардом аккаунтов.
 ### 3.2 ML-KEM-768
 - Категория безопасности 3.
 - Используется для обмена ключами между узлами при установлении защищённого канала (TLS-A на M8, см. [05 Сетевой слой](../05%20Сетевой%20Слой/)).
 - Размер ciphertext: 1088 байт.
 ### 3.3 SHA-256
 - В составе VDF: D итераций гарантируют последовательное вычисление; параллелизм не помогает.
 - Как хеш аккаунта/блока: collision resistance 128 бит — выше, чем у любых эллиптических кривых, и устойчиво к Гроверу (квадратичное ускорение даёт лишь 128-битную атаку, всё равно вне досягаемости).
 ### 3.4 SHA-256 в качестве VDF
 Pietrzak (2018) и Boneh-Bonneau-Bünz-Fisch (2018) показали, что итерация хеш-функции в режиме `out = SHA-256(in); repeat D раз` несжимаема: проверяющий должен потратить такое же число шагов, что и доказывающий, чтобы воспроизвести цепь. Параллелизм не помогает. Это фундаментальное свойство.
 ## 4. Параметры безопасности
 | Параметр | Значение | Обоснование |
 |----------|----------|-------------|
 | Минимальный уровень безопасности | NIST Category 3 (192 бит) | Стандарт для долгосрочного денежного протокола |
 | Запас до устаревания | ≥ 30 лет | NIST SP 800-131A прогноз для NIST L3 |
 | Хеш-длина | 256 бит | Соответствует FIPS 180-4 |
 | VDF параметр D₀ | 325 000 000 итераций | ≈ 60 секунд на x86_64 (тестово) |
 ## 5. Слои реализации
 Согласно §"Криптографическая реализация" основной спецификации:
 1. **Слой примитивов.** Конкретные реализации (liboqs, OpenSSL, либо собственные с verifiable build).
 2. **Слой кодирования консенсуса.** Канонические байт-форматы (deterministic encoding) для подписанной области, идентичности, агрегации.
 3. **Слой протокола.** Использование примитивов в Account Chain, NodeChain, TimeChain.
 4. **Инфраструктура.** Управление ключами, мнемоника, seed (см. §"Ключи").
 ## 6. Адреса
 Адрес ≡ SHA-256 от канонически закодированного открытого ключа ML-DSA-65, обрезанный/закодированный по правилам §"Адреса".
 Свойство: адрес стабильно мало изменчив (256 бит хеша → 32 байта или base32-форма), не раскрывает PK до первой подписи (только хеш).
 ## 7. Подписанная область
 Универсальное правило подписи: подписывается канонически закодированная структура `(тип_операции, параметры, идентичность, точка цепи)`. Никаких side-channel полей не входит в подпись. Replay protection — через seq и привязку к τ-координате.
 ## 8. Ключи
 - Мнемоника: BIP-39-стиль, но с увеличенной длиной до 24 слов для 256-битной энтропии.
 - Seed → ML-DSA-65 keypair: deterministic derivation согласно RFC 8032-стилю, адаптировано для решёточных схем.
 ## 9. Open вопросы
 - [ ] Опубликовать KAT (Known Answer Tests) для всех примитивов на основе NIST test vectors.
 - [ ] Аудит реализации liboqs или альтернативной библиотеки.
 - [ ] Анализ устойчивости к атакам по сторонним каналам (timing, cache).
 - [ ] Тест переключения примитивов на M9 (governance: см. [12 Управление](../12%20Управление%20и%20Обновления/)).
 ## 10. Источники
 1. NIST FIPS 203 (2024). *Module-Lattice-Based Key-Encapsulation Mechanism Standard*.
 2. NIST FIPS 204 (2024). *Module-Lattice-Based Digital Signature Standard*.
 3. NIST FIPS 205 (2024). *Stateless Hash-Based Digital Signature Standard*.
 4. NIST FIPS 180-4. *Secure Hash Standard*.
 5. NIST SP 800-131A Rev 2 (2019). *Transitioning the Use of Cryptographic Algorithms and Key Lengths*.
 6. Pietrzak, K. (2018). *Simple Verifiable Delay Functions*. ITCS.
 7. Boneh, D., Bonneau, J., Bünz, B., Fisch, B. (2018). *Verifiable Delay Functions*. CRYPTO.
 8. Shor, P. (1994). *Algorithms for Quantum Computation: Discrete Logarithms and Factoring*. FOCS.
 9. Grover, L. (1996). *A fast quantum mechanical algorithm for database search*. STOC.
--- a/Экономика/Денежная-экономика.md
+++ b/Экономика/Денежная-экономика.md
@ -0,0 +1,100 @@
 # Денежная экономика Монтаны
 **Версия:** черновик 1.0
 **Базовый источник:** [Montana Protocol v35.25.0 §Валюта Монтана, §Поокнная эмиссия, §Прикладной слой/Полная экономическая картина](../../Монтана-Протокол/Montana%20Protocol%20v35.25.0.md)
 ## 1. Базовая редкость — время
 Большинство денежных протоколов исходят из редкости стейка (PoS), хеш-мощности (PoW) или места в блоке (комиссии). Монтана исходит из времени.
 Время — равномерно доступный ресурс: один час одного оператора равен одному часу любого другого. Множественные подложные личности не дают больше времени на личность — только больше личностей, каждая подчинена тому же ограничению "одно окно — один шаг".
 ## 2. Эмиссия
 ### 2.1 Поокнная эмиссия
 Каждое окно τ₁ ≈ 60 секунд порождает фиксированное количество новых единиц валюты. Эмиссия привязана к настенному времени, не к балансу — в этом ключевое отличие от плутократических PoS.
 Параметры:
 | Параметр | Значение | Обоснование |
 |----------|----------|-------------|
 | Эмиссия за окно τ₁ | См. v35.25.0 §"Канонический порядок" | Зафиксирована протоколом |
 | Период адаптации | τ₂ = 20 160 окон ≈ 14 дней | Балансирует стабильность и реакцию на изменение настенного времени |
 | Распределение | Победитель τ₁ через лотерею | Не зависит от баланса |
 ### 2.2 Граница эмиссии
 Эмиссия конечна или асимптотически ограничена. Точные параметры зафиксированы в §"Поокнная эмиссия" основной спецификации.
 ## 3. Деноминация и именование
 Согласно §"Валюта Монтаны":
 | Уровень | Название | Значение |
 |---------|----------|----------|
 | Базовая единица | TimeCoin (TC) | Минимальная неделимая |
 | Подъединицы | См. §"Деноминация" | Иерархия как в традиционных валютах |
 Имена единиц зафиксированы в первом фрейме спецификации без англоязычных идентификаторов. См. feedback-правило о чистом русском в первом фрейме.
 ## 4. Спрос
 Спрос на TC порождается:
 1. **Анти-инфляция через AccountChain.** Длина собственной цепи аккаунта влияет на право участия в лотерее. Активные аккаунты сохраняют позицию.
 2. **Anchor.** Прикладные приложения покупают канонические якоря в TimeChain для верификации событий — спрос на блочное место конвертируется в спрос на TC.
 3. **Платёжный канал.** Перевод TC между аккаунтами — основной use-case.
 ## 5. Предложение
 Предложение определено эмиссией (§2). На любом моменте времени t:
 ```
 total_supply(t) = Σ emission(τ₁_i) для всех i ≤ t
 ```
 Поскольку τ₁_i ≈ 60 секунд и эмиссия за окно фиксирована — predictable и проверяемое всеми участниками без оракула.
 ## 6. Стимулы
 См. отдельный документ [08 Стимулы и теория игр](../08%20Стимулы%20и%20Теория%20Игр/).
 Кратко:
 - Узел получает выгоду от честного крутения VDF (победа в лотерее).
 - Атакующий платит затратами времени (несжимаемое VDF-вычисление), ничего не получая.
 - Slashing не нужен в классическом смысле — нет стейка, который можно отнять. Наказание — невключение в канон.
 ## 7. Устойчивость экономики
 ### 7.1 Атаки через экономику
 | Атака | Защита |
 |-------|--------|
 | Pump and dump | Эмиссия привязана ко времени, не реагирует на цену |
 | Whale концентрация | Лотерея single-class, не зависит от баланса |
 | Bribery валидаторов | Нет валидаторов в PoS-смысле; победа в лотерее не передаётся |
 | MEV (front-running) | См. [07 Модель угроз](../07%20Модель%20Угроз/) §MEV |
 ### 7.2 Симуляции
 - [ ] Стохастическая модель эмиссии и спроса при N = 10⁹ аккаунтов (см. memory-правило о Scale baseline 1B+).
 - [ ] Анализ концентрации Gini-индекса при разных моделях входа новых аккаунтов.
 - [ ] Стресс-тест адаптации τ₂ при росте/падении честных операторов.
 ## 8. Отношение к фиатной экономике
 Курс TC к национальным валютам определяется только биржей и не привязан протокольно. Протокол не использует оракулов цены — устранён один из крупных классов уязвимостей (oracle manipulation в DeFi).
 ## 9. Открытые вопросы
 - [ ] Полное доказательство устойчивости экономической модели в условиях supply shock (массовый офлайн оператор-сети).
 - [ ] Анализ долгосрочной деноминации (когда подъединицы становятся релевантны).
 - [ ] Модель влияния потери ключей на эффективное предложение (lost coins → дефляция).
 ## 10. Источники
 1. Buterin, V. (2017). *On Inflation, Transaction Fees and Cryptocurrency Monetary Policy* (для контекста сравнения).
 2. Saleh, F. (2021). *Blockchain without Waste: Proof-of-Stake* (для критики PoS-плутократии).
 3. Easley, D., O'Hara, M., Basu, S. (2019). *From mining to markets: The evolution of bitcoin transaction fees* (для критики комиссионной модели).
 4. Основная спецификация Монтаны v35.25.0, §"Поокнная эмиссия", §"Полная экономическая картина".
--- a/Протокола/README.md
+++ b/Протокола/README.md
@ -0,0 +1,47 @@
 # Спецификация протокола Монтаны (RFC-стиль)
 **Текущая версия:** [Montana Protocol v35.25.0](../../Монтана-Протокол/Montana%20Protocol%20v35.25.0.md) — 4412 строк
 **Версия архива:** [Архив](../../Монтана-Протокол/Архив/) — все предыдущие версии
 ## Что это
 Главный документ для разработчика, желающего написать узел Монтаны с нуля.
 Содержит:
 - Глобальные инварианты протокола
 - Канонический порядок и временна́я координата
 - Криптографические правила (отсылки на [02 Криптография](../02%20Криптография/))
 - Account Chain (Block Lattice) — структура реестра
 - Двигатели: TimeChain VDF, NodeChain, AccountChain
 - Потоковая модель и временные слои τ₁, τ₂
 - Консенсус Proof of Time (см. [01 Консенсус](../01%20Консенсус/))
 - Адресация и переводы
 - Состояние сети и корень состояния
 - Прикладной слой (см. [06 Прикладной слой](../06%20Прикладной%20Слой/))
 - Сетевой уровень (см. [05 Сетевой слой](../05%20Сетевой%20Слой/))
 - Эволюция протокола (см. [12 Управление](../12%20Управление%20и%20Обновления/))
 - Обоснование протокольных констант
 - Архитектура
 ## Соглашения о версионировании
 Согласно `feedback_spec_rename.md`: при бампе версии файл всегда переименовывается. Имя файла = версия.
 Текущий номер: v35.25.0 (формат `<major>.<minor>.<patch>`).
 ## Связанные документы
 - [Whitepaper RU](../../Монтана-Протокол/Whitepaper%20Montana%20RU.md) — высокоуровневое объяснение
 - [Whitepaper EN](../../Монтана-Протокол/Whitepaper%20Montana.md) — английский
 - [Whitepaper ZH](../../Монтана-Протокол/Whitepaper%20Montana%20ZH.md) — китайский
 - [Montana Network v1.0.0](../../Монтана-Протокол/Montana%20Network%20v1.0.0.md) — сетевой слой
 - [Montana App v3.12.0](../../Монтана-Протокол/Montana%20App%20v3.12.0.md) — клиентский слой
 ## Статус
 🟢 Production-ready на уровне спецификации. Реализация — M5–M8 в [Коде](../../Монтана-Протокол/Код/).
 Ограничения:
 - Нет внешнего peer-review текста как RFC IETF.
 - Документ ведётся в режиме single-author + ИИ-критики (см. [09 Внешний аудит](../09%20Внешний%20Аудит/)).
--- a/Документация/05
+++ b/Документация/05
@ -0,0 +1,76 @@
 # Сетевой слой Монтаны
 **Версия:** черновик 1.0
 **Базовый источник:** [Montana Network v1.0.0](../../Монтана-Протокол/Montana%20Network%20v1.0.0.md), [Montana Protocol v35.25.0 §Сетевой уровень](../../Монтана-Протокол/Montana%20Protocol%20v35.25.0.md)
 ## 1. Цель
 Слой p2p передачи данных между узлами Монтаны. Должен:
 - Передавать VDF-выходы окон между операторами
 - Распространять AccountChain-операции
 - Поддерживать обнаружение узлов (discovery)
 - Защищать от Sybil и DDoS
 ## 2. Транспорт
 - **Протокол транспорта:** TCP с TLS-A (self-signed + certificate pinning), порт 8444 на M8.
 - **PQ KEM:** ML-KEM-768 для обмена сессионными ключами (см. [02 Криптография](../02%20Криптография/)).
 - **Сериализация:** канонический бинарный формат (см. §"Слой кодирования консенсуса").
 ## 3. Discovery (обнаружение узлов)
 ### 3.1 Bootstrap
 3-узловой genesis-набор (см. memory `project_montana_3node_genesis_deploy.md`):
 - mos (Moscow) — `176.124.208.93`
 - fra (Frankfurt) — `89.19.208.158`
 - зел (Helsinki) — `91.132.142.42`
 Из любого genesis-узла новый оператор получает peer-list для дальнейшего расширения.
 ### 3.2 Защита от Sybil
 Sybil-атака классически решается ценой. Монтана использует время:
 - Регистрация нового узла требует выработки кандидатной VDF-цепи длиной ≥ 20 160 окон ≈ 10 часов настенного времени на обычном x86_64.
 - Породить N подложных узлов = породить N таких цепей = N × 10 часов.
 - Шорткатов нет: VDF не параллелится.
 ## 4. Распространение операций
 - **Gossip protocol:** новые AccountChain-операции рассылаются всем известным peer-ам с экспоненциальным backoff'ом для уже-видевших.
 - **Valid-only forwarding:** узел не пересылает операцию, не проверив подпись и канонический порядок локально.
 - **Anti-spam:** одно-окно-один-шаг на личность; узел отбрасывает операции с нарушением.
 ## 5. Bandwidth model
 При размере подписи ML-DSA-65 ≈ 3.3 КБ и операциях ~5 КБ:
 - Один аккаунт даёт максимум 5 КБ за окно τ₁ ≈ 60 с → ≤ 0.7 Кбит/с на аккаунт.
 - При N = 10⁹ активных аккаунтов теоретический пик = 700 Гбит/с глобально.
 - Реальная нагрузка распределена через AccountChain-локальность: узел держит только подписку на аккаунты, которые его клиенты используют (не весь глобальный поток).
 ## 6. DDoS защита
 | Уровень | Механизм |
 |---------|----------|
 | Сетевой | TCP rate-limiting на узле; nginx/iptables на genesis-узлах |
 | Транспортный | TLS-A handshake требует валидной подписи peer'а |
 | Протокольный | Один шаг на личность за окно (естественный rate-limit) |
 | Приложный | Anchor-операции требуют времени на цепь — спамить дорого |
 ## 7. Реализация
 `mt-net-tcp` crate в [Коде](../../Монтана-Протокол/Код/). M8 milestone завершает cross-machine peer-to-peer (см. memory `project_montana_cross_machine_m8.md`).
 ## 8. Открытые вопросы
 - [ ] Анализ устойчивости gossip-распространения при разделении сети (network partition).
 - [ ] Формальный анализ eclipse-атаки на отдельный узел.
 - [ ] Тест против DDoS на genesis-узлах (см. memory: fail2ban установлен на Frankfurt + Moscow).
 - [ ] Спецификация cross-region behaviour когда один из 3 genesis недоступен.
 ## 9. Источники
 1. Heilman, E., Kendler, A., Zohar, A., Goldberg, S. (2015). *Eclipse Attacks on Bitcoin's Peer-to-Peer Network*. USENIX Security.
 2. Decker, C., Wattenhofer, R. (2013). *Information propagation in the Bitcoin network*. P2P.
 3. Montana Network v1.0.0.
--- a/Слой/Приложения.md
+++ b/Слой/Приложения.md
@ -0,0 +1,86 @@
 # Прикладной слой Монтаны
 **Версия:** черновик 1.0
 **Базовый источник:** [Montana Protocol v35.25.0 §Прикладной слой](../../Монтана-Протокол/Montana%20Protocol%20v35.25.0.md), [Montana App v3.12.0](../../Монтана-Протокол/Montana%20App%20v3.12.0.md)
 ## 1. Принципиальное отличие от EVM-цепей
 Монтана **не имеет** виртуальной машины общего назначения (нет EVM, WASM-runtime для произвольных программ). Это сознательное архитектурное решение:
 - VM общего назначения превращает блокчейн в bottleneck общего вычисления, ломает масштабируемость.
 - Атаки через смарт-контракты (re-entrancy, integer overflow, oracle manipulation) — крупный класс уязвимостей DeFi — устранены конструктивно.
 - Sandboxing, gas model, determinism — все решённые проблемы EVM не возникают, потому что не возникает сам слой.
 Что **есть** в Монтане — фиксированный набор операций над AccountChain, плюс механизм Anchor для встраивания внешних приложений в каноническое время.
 ## 2. Модель приложения на Монтане
 Согласно §"Модель приложения на Монтана":
 1. **Приложение живёт вне цепи** (на любых стандартных серверах, в облаке, на устройстве).
 2. **Приложение использует Anchor** — записывает хеш своего состояния в TimeChain через каноническую координату.
 3. **Любой может проверить** что состояние было зафиксировано не позже определённого окна τ₁.
 4. **Доказательство канонической позиции** — компактное (см. §"Доказательство канонической позиции").
 Этим Монтана даёт прикладным разработчикам только то, что блокчейн действительно нужен: глобально согласованное упорядочение событий во времени с криптографической верификацией.
 ## 3. Anchor
 Anchor — операция, которая вписывает 32-байтный хеш во временну́ю координату. Стоимость:
 - Один Anchor занимает место в окне τ₁ (конкуренция за лотерею).
 - Цена в TC = по правилу §"Граница протокола и клиентского слоя".
 Применение:
 - Документирование событий с привязкой к настенному времени (медиа, юриспруденция, наука).
 - Notarization без traditional oracle (само время — оракул).
 - Дополнительные L2-приложения, использующие Монтану как timestamping слой.
 ## 4. Экономика прикладного слоя
 См. §"Полная экономическая картина" + [03 Экономика](../03%20Экономика/).
 Кратко:
 - Приложение покупает Anchor → платит TC → стимулирует операторов.
 - Спрос на Anchor → спрос на TC → устойчивая экономика.
 ## 5. Двигатель роста сети через AccountChain
 Согласно §"Двигатель роста сети через AccountChain":
 - Каждый новый аккаунт → новая цепь → больше нагрузки на сеть.
 - Но: anti-Sybil гарантирует что новые аккаунты создаются с реальной временной стоимостью.
 - Рост сети органичен и масштабируется со временем, не с капиталом.
 ## 6. Локальное хранилище узла
 Узел хранит:
 - Свою собственную NodeChain
 - Подписки на AccountChain (выбираются клиентом)
 - Снапшот корня состояния
 Полную глобальную историю узел НЕ обязан хранить — fast-sync через корень состояния (см. §"Быстрая синхронизация (новый узел)").
 ## 7. Интеграция
 Прикладные интеграции описаны в основной спецификации §"Интеграция":
 - iOS клиент (см. [iOS/Apps/Montana](../../iOS/Apps/Montana/))
 - macOS узел (см. [macOS](../../macOS/))
 - CLI инструменты (см. [CLI](../../CLI/))
 ## 8. Граница протокола и клиентского слоя
 Чёткое разделение: что в протоколе (зафиксировано на уровне консенсуса) vs что в клиенте (свободно реализуемо). Полное описание в основной спецификации, но ключевое:
 - В протоколе: подписи, AccountChain-операции, VDF, лотерея, Anchor.
 - В клиенте: UX, индексирование истории, восстановление ключей, шифрование локального хранилища.
 ## 9. Открытые вопросы
 - [ ] Спецификация Anchor-формата для типичных use-case (notarization, audit log).
 - [ ] Стандарт интеграции для прикладных разработчиков (SDK).
 - [ ] Анализ совместимости с L2-решениями (rollups, channels) если они появятся.
 ## 10. Источники
 1. Montana App v3.12.0.
 2. Buterin, V. (2014). *Ethereum: A Next-Generation Smart Contract Platform* (для контекста сравнения с VM-цепями).
 3. Atzei, N., Bartoletti, M., Cimoli, T. (2017). *A Survey of Attacks on Ethereum Smart Contracts* (обоснование выбора без VM).
--- a/Документация/07
+++ b/Документация/07
@ -0,0 +1,120 @@
 # Модель угроз Монтаны
 **Версия:** черновик 1.0
 **Базовый источник:** [SECURITY.md](../../Монтана-Протокол/SECURITY.md), [Montana Protocol v35.25.0 §Глобальные инварианты](../../Монтана-Протокол/Montana%20Protocol%20v35.25.0.md)
 ## 1. Кто может атаковать
 | Актор | Возможности | Защита |
 |-------|-------------|--------|
 | Рядовой узел | Стандартные сообщения сети | Подписи + правила консенсуса |
 | Майнер/оператор | Может крутить много VDF | f<n/3 BFT-граница |
 | Оператор сговора | Координированные действия | f<n/3 BFT-граница |
 | Государственный актор | Блокировка IP, давление на хостинг | Многосерверная архитектура (3 genesis в разных юрисдикциях) |
 | Квантовый противник | Алгоритм Шора на дискретный логарифм | ML-DSA-65, ML-KEM-768 (FIPS 203/204) |
 | Сетевой противник | DDoS, eclipse, man-in-the-middle | TLS-A pin, gossip избыточность, fail2ban |
 | Имплементационный | Side-channel, ошибки кода | KAT, аудит, формальная верификация (см. [10](../10%20Формальная%20Верификация/)) |
 ## 2. Какие атаки рассматриваются
 ### 2.1 51% / большинство hashrate
 **Не применимо.** В Монтане нет hashrate. VDF не параллелится — больше железа не даёт больше времени.
 ### 2.2 Long-range attack
 **Защита:** канонический порядок основан на VDF-цепи от Genesis. Альтернативная цепь от t=0 потребует пересчитать всё VDF от Genesis до текущего момента — невозможно за разумное время для атакующего, у которого нет времени-форы.
 ### 2.3 Eclipse attack
 **Угроза:** изоляция отдельного узла, заполнение его пирами-атакующими, подача ему альтернативной "канона".
 **Защита:**
 - Жёсткие bootstrap peers (3 genesis-узла).
 - Проверка VDF-цепи независимо: даже изолированный узел может проверить что подаваемая цепь корректна.
 - При расхождении со своим VDF — узел знает что ему врут.
 **Открытый вопрос:** формальный анализ устойчивости к долгому eclipse (когда атакующий имеет ресурс держать узел в изоляции дни-недели).
 ### 2.4 Nothing-at-stake
 **Не применимо.** Нет стейка. Победа в лотерее не зависит от баланса. Множественное участие в нескольких ветках стоит времени, не балансу.
 ### 2.5 Time manipulation
 **Угроза:** подделка локального времени узла для манипуляции восприятием τ-координаты.
 **Защита:**
 - Канон не зависит от локального clock узла. Канон = длина VDF-цепи.
 - Локальное время используется только для UX (отображение).
 ### 2.6 Network partition
 **Угроза:** сеть разделяется на две части, обе продолжают своё VDF.
 **Поведение:** обе подсети имеют валидные VDF-цепи. Когда сеть восстанавливается, протокол выбирает более длинную цепь (стандартное правило fork choice). Часть операций в "проигравшей" ветке откатывается.
 **Граница безопасности:** safety сохраняется на каждой из подсетей в отдельности; liveness одной подсети может пострадать.
 ### 2.7 Quantum attack
 **Защита:** все примитивы постквантовые (см. [02 Криптография](../02%20Криптография/)). Шор не работает.
 **Граница:** SHA-256 при квантовом противнике даёт 128 бит preimage (Гровер, квадратичное ускорение) — всё ещё вне досягаемости.
 ### 2.8 Bribery / coercion
 **Угроза:** атакующий подкупает оператора крутить альтернативную VDF-цепь.
 **Защита:**
 - Победа в лотерее не передаётся внешним способом — только через канон.
 - Подкупленный оператор крутит свою VDF, но если он отступит от канонического порядка, его блок не примут.
 - Протокольно — невозможно подкупить "будущее" поведение, только конкретные шаги.
 ### 2.9 Replay attack
 **Защита:** seq в каждой операции аккаунта + привязка к τ-окну. Replay невозможен.
 ### 2.10 MEV (Maximal Extractable Value)
 **Состояние:** в текущей версии MEV редуцируется к одному фактору — порядок операций внутри окна τ₁.
 **Защита:**
 - Внутри окна порядок выбирается победителем лотереи, который заранее не известен.
 - Front-running через mempool — невозможен потому что нет публичного mempool в EVM-смысле.
 **Открытый вопрос:** более глубокий анализ MEV-векторов в условиях когда прикладной слой развивается.
 ## 3. Что НЕ защищено протоколом (вне scope)
 - Утечка пользовательского ключа (на стороне клиента).
 - Социальная инженерия.
 - Аппаратные атаки на устройство пользователя.
 - Юридическое давление на конкретных операторов.
 Эти векторы — задача клиентского слоя и operational security оператора, не протокола.
 ## 4. Допущения безопасности
 | Допущение | Доказательство / источник |
 |-----------|---------------------------|
 | ML-DSA-65 EUF-CMA при f<n/3 | NIST FIPS 204 |
 | SHA-256 collision resistance | NIST FIPS 180-4 |
 | VDF несжимаемость | Pietrzak 2018 |
 | Сеть после GST доставляет ≤ Δ | Стандартная модель Dwork-Lynch-Stockmeyer |
 | Honest majority (n/3) | BFT consensus assumption |
 ## 5. Связанные документы
 - [02 Криптография](../02%20Криптография/) — обоснование примитивов.
 - [01 Консенсус](../01%20Консенсус/) — Safety/Liveness теоремы.
 - [05 Сетевой слой](../05%20Сетевой%20Слой/) — DDoS и eclipse детали.
 - [08 Стимулы](../08%20Стимулы%20и%20Теория%20Игр/) — атаки через стимулы.
 - [09 Внешний аудит](../09%20Внешний%20Аудит/) — нужен для подтверждения этой модели.
 ## 6. Источники
 1. Lamport, L., Shostak, R., Pease, M. (1982). *The Byzantine Generals Problem*. TOPLAS.
 2. Heilman, E., et al. (2015). *Eclipse Attacks on Bitcoin's Peer-to-Peer Network*. USENIX.
 3. Daian, P., et al. (2020). *Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges* (для MEV-контекста).
 4. NIST FIPS 203, 204, 205 (2024).
--- a/Документация/08
+++ b/Документация/08
@ -0,0 +1,104 @@
 # Стимулы и теория игр Монтаны
 **Версия:** черновик 1.0
 **Базовый источник:** [Montana Protocol v35.25.0 §Поокнная эмиссия, §Лотерея](../../Монтана-Протокол/Montana%20Protocol%20v35.25.0.md)
 ## 1. Принцип
 В Bitcoin/Ethereum стимулы основаны на ресурсе участника (hashrate / стейк). В Монтане стимул основан на времени, которое равно для всех. Это меняет всю game-theoretic картину.
 ## 2. Кто участвует
 | Роль | Цель | Награда | Затраты |
 |------|------|---------|---------|
 | Оператор узла | Победить в лотерее окна τ₁ | Эмиссия за окно (TC) | Электричество + железо для VDF |
 | Аккаунт-пользователь | Включить операцию в канон | Сама операция (UX) | Время на цепь |
 | Прикладной разработчик | Anchor состояния | Гарантия канонической позиции | TC за Anchor |
 Никаких "валидаторов" в PoS-смысле — нет стейка, нет slashing.
 ## 3. Утилитарная функция оператора
 Оператор `i` выбирает между:
 - **Crank honest:** крутить VDF на канонической цепи. Ожидаемая выгода = P(победа в окне) × эмиссия.
 - **Crank fork:** крутить VDF на форке. Ожидаемая выгода = 0 (форк не примут).
 - **Idle:** ничего не делать. Выгода = 0, экономия электричества.
 Оптимальная стратегия: crank honest. Любая другая — строго хуже.
 ## 4. Атаки через стимулы
 ### 4.1 Selfish mining (а-ля Eyal-Sirer 2014)
 В Bitcoin: майнер удерживает блоки, чтобы получить преимущество.
 В Монтане: VDF-цепь публична и проверяема. Удерживать VDF-выход бессмысленно — всё равно длина цепи определяет канон. Selfish mining не применим.
 ### 4.2 Bribery / coercion
 Атакующий A пытается подкупить оператора O работать на форке.
 - A должен платить O больше, чем O получит честным крутением (E[honest reward] = эмиссия × P(win)).
 - Но O рискует: если форк не примут (а его не примут — короткая цепь), O теряет и подкуп, и время.
 - Bribery нерациональна для O при условии что эмиссия > подкупа, что выполняется при f<n/3.
 ### 4.3 Lottery manipulation
 Победитель окна определяется детерминированно из VDF-выхода + предыдущих условий. Нет случайности, которую можно было бы манипулировать.
 Атакующий, контролирующий некоторые узлы, не может предсказать или сместить победу — лотерея зависит от полной VDF-цепи, не от стейка.
 ### 4.4 Sybil через стимулы
 Атакующий пытается создать N подложных аккаунтов чтобы умножить свой шанс в лотерее.
 Защита: каждый аккаунт требует AccountChain длиной — порождает временную стоимость. N аккаунтов = N × время. Линейная стоимость, не экспоненциальный выигрыш.
 ### 4.5 MEV (Maximal Extractable Value)
 См. [07 Модель угроз §2.10](../07%20Модель%20Угроз/Threat-Model.md).
 Внутри окна τ₁ порядок операций определяет победитель. Победитель не известен заранее → front-running через mempool невозможен.
 ## 5. Equilibrium
 **Утверждение E1.** *Стратегия "crank honest на канонической цепи + публиковать честно" — Nash equilibrium при f<n/3 и эмиссии > 0.*
 Доказательство (skeleton):
 1. Любой honest оператор имеет E[honest reward] > 0.
 2. Любая девиация (форк, удерживание, подкуп) даёт E[deviation reward] ≤ 0.
 3. Никакая девиация не выгодна → equilibrium стабилен.
 Полное доказательство — открытый вопрос для академической формализации.
 ## 6. Slashing — почему не нужен
 В PoS slashing наказывает за двойное подписание / отсутствие. В Монтане:
 - Двойного подписания не выгодно сделать (см. §4.1).
 - "Отсутствие" не наказуемо — VDF продолжается на других операторах.
 - Не нужно отнимать стейк, потому что нет стейка.
 Это упрощает протокол и устраняет один класс уязвимостей (false-positive slashing).
 ## 7. Долгосрочная устойчивость
 При снижении эмиссии (длинный horizon):
 - Anchor-плата от прикладных разработчиков становится основным источником дохода операторов.
 - Стимул честного крутения сохраняется пока спрос на Anchor > электрической стоимости VDF.
 - Это требует анализа в условиях asymptotic supply (см. [03 Экономика](../03%20Экономика/)).
 ## 8. Открытые вопросы
 - [ ] Формальное доказательство Nash equilibrium в EquiCC-стиле (Eyal-Sirer формализм).
 - [ ] Анализ долгосрочной устойчивости при разных моделях спроса на Anchor.
 - [ ] Симуляция стратегий при N=10⁹ операторов.
 - [ ] Анализ collusion (сговор большого числа операторов) на границе f<n/3.
 ## 9. Источники
 1. Eyal, I., Sirer, E. G. (2014). *Majority is not Enough: Bitcoin Mining is Vulnerable*. FC.
 2. Carlsten, M., et al. (2016). *On the Instability of Bitcoin Without the Block Reward*. CCS.
 3. Daian, P., et al. (2020). *Flash Boys 2.0* (MEV формализация).
 4. Roughgarden, T. (2020). *Transaction Fee Mechanism Design for the Ethereum Blockchain* (для контекста).
 5. Saleh, F. (2021). *Blockchain without Waste: Proof-of-Stake* (для критики PoS-стимулов).
--- a/Аудит/Статус-аудита.md
+++ b/Аудит/Статус-аудита.md
@ -0,0 +1,91 @@
 # Внешний аудит Монтаны
 **Версия:** 1.0
 **Текущий статус:** 🔴 Независимый внешний аудит не проведён.
 ## 1. Что такое настоящий внешний аудит
 Согласно индустриальному стандарту L1-блокчейнов:
 - Независимая компания (Trail of Bits, Cure53, Quantstamp, ConsenSys Diligence, Sigma Prime, NCC Group и подобные).
 - PDF отчёт с фиксированной датой и подписью.
 - Список уязвимостей с severity (Critical/High/Medium/Low/Informational).
 - Привязка к конкретному commit hash аудируемого кода.
 - Рекомендации по исправлению.
 - Follow-up с проверкой исправлений.
 Без этих компонентов — это не аудит, а review.
 ## 2. Текущее состояние
 ### 2.1 Что есть
 В папке [Внешний аудит](../../Монтана-Протокол/Внешний%20аудит/) — серия критических разборов от Claude Opus 4.7:
 ```
 claude-opus-4-7_2026-04-26_T201805.md
 claude-opus-4-7_2026-04-26_T232707.md
 claude-opus-4-7_2026-04-27_T121239.md
 claude-opus-4-7_2026-04-27_T124438.md
 claude-opus-4-7_2026-04-27_T141253.md
 claude-opus-4-7-1m_2026-04-28_T2023.md
 ```
 Это **внутренние ИИ-критики**, не настоящий внешний аудит. Они полезны для итерации спецификации, но не являются аудитом в индустриальном смысле — нет независимой компании, нет PDF-отчёта, нет привязки к commit hash, нет follow-up.
 ### 2.2 Что отсутствует
 - ❌ Аудит крипто-реализации (liboqs или альтернативы).
 - ❌ Аудит сетевого слоя (`mt-net-tcp` crate).
 - ❌ Аудит консенсусной логики (PoT, лотерея, fork choice).
 - ❌ Аудит iOS клиента (особенно key management, jailbreak detection).
 - ❌ Аудит macOS узла.
 - ❌ Аудит Anchor-логики прикладного слоя.
 ## 3. План внешнего аудита
 ### Phase 1 — pre-audit hardening
 Перед привлечением внешней компании:
 - [ ] Завершить M5-M9 milestones (см. [11 Тестовая сеть](../11%20Тестовая%20Сеть/)).
 - [ ] Зафиксировать API и спецификацию (no breaking changes during audit).
 - [ ] Подготовить документацию (этот документ + spec + threat model).
 - [ ] Прогнать KAT для всех крипто-примитивов (см. [02 Криптография §10](../02%20Криптография/Постквантовые-примитивы.md)).
 - [ ] Провести внутренний security review через [Security Cards](../../Монтана-Протокол/CRITIC.md).
 ### Phase 2 — выбор аудитора
 Кандидаты с опытом в PQ-крипто и L1:
 | Компания | Профиль | Заметка |
 |----------|---------|---------|
 | Trail of Bits | Системы, крипто | Хороший трек по PQ |
 | Cure53 | Web/cloud + крипто | Опыт с iOS |
 | NCC Group | Широкий | Делали аудиты NIST PQC кандидатов |
 | Sigma Prime | Блокчейн | Делали Lighthouse, Eth2 |
 | Halborn | Блокчейн | Web3 specific |
 ### Phase 3 — аудит
 - Scope: крипто + консенсус + сеть + клиент.
 - Длительность: 4-12 недель в зависимости от scope.
 - Стоимость: $50k-$500k (бенчмарк по индустрии).
 ### Phase 4 — публикация и follow-up
 - Публикация полного отчёта в этой папке.
 - Все Critical/High закрываются перед mainnet.
 - Medium закрываются на тестовой сети.
 - Low/Informational — по приоритету.
 ## 4. Promised audit: до Mainnet
 Согласно `feedback_premainnet_principle.md`: Монтана не запущена, breaking changes применяются сразу. Это значит что mainnet не запускается без завершённого внешнего аудита всех Critical/High находок.
 ## 5. Связанные документы
 - [Внутренние ИИ-критики](../../Монтана-Протокол/Внешний%20аудит/) — текущее состояние, временно вместо аудита.
 - [SECURITY.md](../../Монтана-Протокол/SECURITY.md) — disclosure policy.
 - [10 Формальная верификация](../10%20Формальная%20Верификация/) — комплементарный к аудиту слой.
 - [07 Модель угроз](../07%20Модель%20Угроз/) — что аудитор должен проверить.
--- a/Верификация/План.md
+++ b/Верификация/План.md
@ -0,0 +1,80 @@
 # Формальная верификация Монтаны
 **Версия:** черновик 1.0
 **Текущий статус:** 🔴 Не начата.
 ## 1. Цель
 Математическое доказательство ключевых свойств протокола в формальной системе (TLA+, Coq, Isabelle/HOL).
 Это самый высокий уровень зрелости L1-блокчейна. Tendermint, Algorand, Cardano — у всех есть формальные модели хотя бы консенсуса.
 ## 2. Что должно быть верифицировано
 ### 2.1 Консенсус Proof of Time
 - **Safety теорема S1** ([01 Консенсус §4.1](../01%20Консенсус/Proof-of-Time.md)): невозможность форков при f<n/3.
 - **Liveness теорема L1** ([01 Консенсус §4.2](../01%20Консенсус/Proof-of-Time.md)): включение операций после GST.
 - **Fork choice rule** — самая длинная цепь VDF, формализация и устойчивость.
 ### 2.2 Криптография
 - KAT-таблицы для ML-DSA-65, ML-KEM-768, SHA-256 — соответствие FIPS-стандартам.
 - Канонический формат сериализации — биективность, отсутствие неоднозначности.
 ### 2.3 Account Chain
 - Двойная трата невозможна в пределах окна τ₁.
 - Anti-инфляция (баланс не растёт без эмиссии).
 - Replay protection через seq + τ-привязку.
 ### 2.4 Лотерея
 - Победитель окна детерминирован при заданных входах.
 - Невозможность смещения исхода атакующим с f<n/3.
 ## 3. Выбор инструмента
 | Инструмент | Сильные стороны | Применимость к Монтане |
 |------------|-----------------|------------------------|
 | **TLA+** | Распределённые системы, model checking | ✅ Идеально для PoT consensus |
 | **Coq** | Полная теорема-проверка | Для криптографических редукций |
 | **Isabelle/HOL** | Аналог Coq | Для математической части |
 | **K Framework** | Operational semantics | Не нужен — нет VM |
 | **Lean 4** | Современный mathlib | Альтернатива Coq |
 **Рекомендация:** начать с **TLA+** (consensus + safety/liveness), затем дополнить **Coq** (крипто-редукции) при необходимости.
 ## 4. План работ
 ### Phase 1 — TLA+ модель консенсуса (3-6 месяцев)
 - [ ] Спецификация PoT в TLA+ (модель сети, операторы, VDF, лотерея).
 - [ ] Доказательство Safety через TLAPS.
 - [ ] Liveness через temporal logic.
 - [ ] Model checking при малых N (3, 5, 7 операторов) через TLC.
 - [ ] Публикация модели в этой папке.
 ### Phase 2 — Coq крипто-редукции (опционально, если аудит требует)
 - [ ] EUF-CMA редукция ML-DSA-65 формализована.
 - [ ] Не самостоятельная задача — обычно делается в академическом контексте либо ссылается на сторонние формализации (NIST PQC has some).
 ### Phase 3 — Account Chain свойства
 - [ ] Inv: баланс ≥ 0 на любой τ-точке.
 - [ ] Inv: двойная трата невозможна.
 - [ ] Inv: эмиссия монотонна и фиксирована.
 ## 5. Связанные документы
 - [01 Консенсус](../01%20Консенсус/) — теоремы, требующие верификации.
 - [07 Модель угроз](../07%20Модель%20Угроз/) — допущения, которые модель должна охватить.
 - [09 Внешний аудит](../09%20Внешний%20Аудит/) — комплементарный к этому слою.
 ## 6. Источники
 1. Lamport, L. (2002). *Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers*.
 2. Buchman, E. et al. (2018). *The latest gossip on BFT consensus* (Tendermint TLA+).
 3. Algorand formal model: github.com/algorand/specs.
 4. IronFleet (Hawblitzel et al., 2015). *IronFleet: Proving Practical Distributed Systems Correct*. SOSP.
--- a/Документация/11
+++ b/Документация/11
@ -0,0 +1,104 @@
 # Тестовая сеть Монтаны
 **Версия:** черновик 1.0
 **Базовый источник:** [Код M5–M8](../../Монтана-Протокол/Код/), [project_montana_3node_genesis_deploy.md](../../../../.claude/projects/-Users-kh--Python------/memory/project_montana_3node_genesis_deploy.md)
 ## 1. Текущее состояние
 3-node genesis testnet активен с 2026-05-02:
 | Узел | Регион | Хост | Статус |
 |------|--------|------|--------|
 | **mos** | Москва | `montana-moscow` / 176.124.208.93 | 🟢 Active |
 | **fra** | Frankfurt | `montana-frankfurt` / 89.19.208.158 | 🟢 Active |
 | **зел** | Helsinki | `montana-finland` / 91.132.142.42 | 🟢 Active |
 Транспорт: TCP порт 8444 с TLS-A self-signed + certificate pinning. Crate: `mt-net-tcp`.
 ## 2. Milestones
 ### M5 — single-node node
 - [x] Локальный узел крутит VDF.
 - [x] AccountChain операции в памяти.
 - [x] CLI для генерации ключей и подписания.
 ### M6 — persistence
 - [x] Хранилище NodeChain на диске.
 - [x] Восстановление после перезапуска.
 - [x] Snapshot корня состояния.
 ### M7 — single-host multi-node
 - [x] Несколько узлов на одной машине общаются.
 - [x] Локальная синхронизация AccountChain.
 ### M8 — cross-machine genesis
 - [x] 3 узла в 3 разных регионах.
 - [x] TLS-A handshake с pinning.
 - [x] Cross-region gossip и синхронизация.
 ### M9 — public testnet (планируется)
 - [ ] Открытая регистрация новых узлов.
 - [ ] Документация подключения.
 - [ ] Блок-эксплорер (см. montana.quest/explorer/).
 - [ ] Faucet для test TC.
 - [ ] Bug bounty program.
 ### M10 — pre-mainnet
 - [ ] Завершённый внешний аудит ([09](../09%20Внешний%20Аудит/)).
 - [ ] Формальная верификация консенсуса ([10](../10%20Формальная%20Верификация/)).
 - [ ] Стабильная спецификация (no breaking changes).
 - [ ] Все Critical/High audit findings закрыты.
 ### Mainnet — TBD
 Дата запуска mainnet не публикуется до завершения M10.
 ## 3. Как запустить узел
 ### 3.1 Требования
 - x86_64 CPU (или ARM с эквивалентной производительностью VDF).
 - ≥ 2 ГБ RAM.
 - ≥ 50 ГБ диска.
 - Стабильное интернет-соединение.
 - Linux (Ubuntu 22.04+ протестировано), macOS (для devnet).
 ### 3.2 Запуск
 См. [Код/README](../../Монтана-Протокол/Код/) и [macOS](../../macOS/) / [CLI](../../CLI/) для конкретных инструкций.
 Высокоуровнево:
 1. Скачать релиз / собрать из исходников.
 2. Сгенерировать ключи через CLI.
 3. Запустить узел с указанием bootstrap-peers (текущие 3 genesis).
 4. Дождаться синхронизации (≥ 20 160 окон ≈ 10 часов).
 5. Узел автоматически становится участником лотереи.
 ### 3.3 Стать оператором
 Любой узел, который полностью синхронизировался и крутит VDF, является оператором. Никакой регистрации/стейка/KYC не требуется. Это principle: Sybil-защита — время.
 ## 4. Логи и мониторинг
 - launchd на macOS: `org.montana.node` (см. memory `feedback_montana_node_log_baseline.md`).
 - systemd на Linux: `montana-node.service`.
 - Stdout flush через `\r` для UI; tail -F работает корректно.
 ## 5. Известные ограничения текущего testnet
 - Только 3 узла → не репрезентативная нагрузка.
 - Нет открытой регистрации новых узлов (M9).
 - Нет faucet → невозможно получить test TC внешнему пользователю.
 - Эксплорер базовый, без полной истории.
 ## 6. Связанные документы
 - [05 Сетевой слой](../05%20Сетевой%20Слой/) — спецификация транспорта.
 - [12 Управление](../12%20Управление%20и%20Обновления/) — как обновляется testnet.
 - [Код](../../Монтана-Протокол/Код/) — реализация.
--- a/Обновления/Governance.md
+++ b/Обновления/Governance.md
@ -0,0 +1,90 @@
 # Управление и обновления Монтаны
 **Версия:** черновик 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 — параметрическая адаптация.
--- a/Документация/README.md
+++ b/Документация/README.md
@ -0,0 +1,46 @@
 # Формальная Документация Монтаны
 Полный набор документов для production-grade L1-блокчейна.
 Структура соответствует индустриальному стандарту зрелого протокола: три обязательных слоя (Research / Engineering / Security) и расширенный слой (Advanced).
 ## Статус документов
 | № | Документ | Слой | Статус |
 |---|----------|------|--------|
 | 01 | [Консенсус — Proof of Time](01%20Консенсус/) | Research | 🟡 Черновик |
 | 02 | [Криптография](02%20Криптография/) | Research | 🟡 Черновик |
 | 03 | [Денежная экономика](03%20Экономика/) | Research | 🟡 Черновик |
 | 04 | [Спецификация протокола](04%20Спецификация%20Протокола/) | Engineering | 🟢 v35.25.0 |
 | 05 | [Сетевой слой](05%20Сетевой%20Слой/) | Engineering | 🟡 Черновик |
 | 06 | [Прикладной слой](06%20Прикладной%20Слой/) | Engineering | 🟡 Черновик |
 | 07 | [Модель угроз](07%20Модель%20Угроз/) | Security | 🟡 Черновик |
 | 08 | [Стимулы и теория игр](08%20Стимулы%20и%20Теория%20Игр/) | Security | 🟡 Черновик |
 | 09 | [Внешний аудит](09%20Внешний%20Аудит/) | Security | 🔴 Не начат |
 | 10 | [Формальная верификация](10%20Формальная%20Верификация/) | Advanced | 🔴 Не начат |
 | 11 | [Тестовая сеть](11%20Тестовая%20Сеть/) | Advanced | 🟡 M5–M8 в Коде |
 | 12 | [Управление и обновления](12%20Управление%20и%20Обновления/) | Advanced | 🟡 Черновик |
 🟢 — production-ready. 🟡 — есть содержимое, нужна доработка/рецензия. 🔴 — отсутствует, требуется внешняя работа.
 ## Принцип
 Зрелый L1-блокчейн имеет три обязательных слоя:
 1. **Research** — академическая часть. Доказательства, не маркетинг.
 2. **Engineering** — инженерная спецификация. Узел можно написать с нуля по этим документам.
 3. **Security** — модель угроз, теория игр, внешний аудит. Без этого нельзя говорить о безопасности.
 Дополнительно (Advanced): формальная верификация, документация тестовой сети, модель управления.
 Пока существует не весь набор — проект остаётся на стадии prototype/research. Production-grade достигается, когда все 12 документов доведены до ready.
 ## Связанные источники
 - [Главная спецификация v35.25.0](../Монтана-Протокол/Montana%20Protocol%20v35.25.0.md) — основной протокольный документ, 4412 строк
 - [Whitepaper RU](../Монтана-Протокол/Whitepaper%20Montana%20RU.md)
 - [Whitepaper EN](../Монтана-Протокол/Whitepaper%20Montana.md)
 - [Whitepaper ZH](../Монтана-Протокол/Whitepaper%20Montana%20ZH.md)
 - [SECURITY.md](../Монтана-Протокол/SECURITY.md)
 - [Внешний аудит — текущие критики](../Монтана-Протокол/Внешний%20аудит/) — пока внутренние ИИ-критики, нужен независимый
 - [Код M5–M8](../Монтана-Протокол/Код/) — реализация