Whitepaper Montana Mesh RU/EN/ZH — суверенная mesh-сеть городов

Объединённый whitepaper TimeChain + Mesh VPN; концепция «Montana = карта городов = сеть ВПН = интернет»; live snapshot 2026-05-10. Три языка идентичны; canonical — RU. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-10 04:22:28 +03:00 · 2026-05-10 04:22:28 +03:00 · 2a00cb5ac6
commit 2a00cb5ac6
parent bb8ce27075
3 changed files with 726 additions and 0 deletions
--- a/Montana-Protocol/Whitepaper
+++ b/Montana-Protocol/Whitepaper
@ -0,0 +1,242 @@
+# Montana: суверенная mesh-сеть городов
+
+**Алехандро Монтана**
+[github.com/efir369999/Montana](https://github.com/efir369999/Montana) · [montana.quest](https://montana.quest)
+
+---
+
+## Аннотация
+
+Сеть, в которой ценность передаётся между сторонами без доверенных посредников и без зависимости от классической криптографии, должна одновременно решать три задачи: глобальный consensus о порядке событий, защита передаваемых пакетов от наблюдателя и цензора, и устойчивость инфраструктуры при отказе или захвате отдельных узлов. Существующие системы решают одну из трёх. Bitcoin даёт consensus, но не приватность транспорта. Tor даёт приватность транспорта, но не consensus. Tailscale и WireGuard дают peer-to-peer connectivity, но не суверенность инфраструктуры. Montana — попытка объединить три свойства в одной системе. Состоит из двух связанных слоёв: **TimeChain**, постквантовая блокчейн-цепь, в которой scarcity — это время (а не место в блоке и не комиссия), и **Mesh VPN**, federation узлов-городов, каждый из которых открывает свой регион интернета и страхует соседей при их отказе. Метафора-инвариант: каждый узел — это город на карте; сеть VPN-городов и есть интернет.
+
+---
+
+## 1. Введение
+
+Bitcoin [1] продемонстрировал, что децентрализованный денежный consensus достижим без посредников. Tor [11] продемонстрировал, что анонимная маршрутизация трафика достижима в публичной сети. WireGuard [12] и его наследники показали, что простой и быстрый peer-to-peer VPN возможен на базе современной криптографии. Ни одна из этих систем не объединяет три свойства, необходимые для целевой аудитории Montana — суверенный интернет на масштабе ≥10⁹ пользователей: глобальная упорядоченность, приватность транспорта и self-sovereign инфраструктура.
+
+Кроме того, у Bitcoin и его наследников остаются две неустранённые в их рамках уязвимости. Первая — все production-блокчейны строят защиту подписей на гипотезах сложности дискретного логарифма на эллиптической кривой. Алгоритм Шора [8] на достаточно большом квантовом компьютере ломает эти гипотезы за полиномиальное время. NIST в 2024 году стандартизировал постквантовые подписи и механизмы инкапсуляции (FIPS 203 [2], 204 [3], 205); крупные сети не мигрировали. Вторая — антиспам через комиссии плохо масштабируется при росте: при перегрузке мелкие операции вытесняются ценой, при недогрузке — спам возвращается на маржинальной стоимости. Layer-2 (state channels, rollups) переносит экономику, не устраняет дефицита.
+
+Montana предлагает: цепь, защита подписей которой целиком на постквантовых примитивах, и в которой антиспам работает на времени (а не на деньгах) [13]. Цепь продвигается VDF (Verifiable Delay Function) [5,6,7] над SHA-256, выдавая глобально упорядоченные окна по ≈60 секунд каждое. Операции в окне ограничены тремя независимыми ресурсами времени: per-identity per-window, длиной цепи аккаунта и старшинством. Поверх этого слоя протокол развёртывает второй слой — mesh VPN, использующий Reality (xray) [14] для маскировки трафика под штатный TLS-handshake к легитимной публичной мишени.
+
+---
+
+## 2. Архитектура: два слоя, одна сеть
+
+Montana состоит из двух слоёв, физически реализованных одними и теми же узлами:
+
+**Слой 1 — TimeChain.** Глобальный clock + identity registry + state. Отвечает за: упорядоченность событий, регистрацию операторов узлов, начисление эмиссии, сохранность state. Подробное изложение приведено в [«Whitepaper Montana RU»](Whitepaper%20Montana%20RU.md), здесь даём резюме (раздел 4).
+
+**Слой 2 — Mesh VPN.** Маршрутизация пользовательского трафика через узлы-города. Отвечает за: приватность транспорта, обход цензуры, failover между узлами. Раскрывается в разделах 5–7.
+
+Эти слои не независимы: оператор узла, желающий быть полноправным участником сети, обязан запустить и TimeChain-узел (`montana-node`), и VPN-сервер (`xray`) с конфигурацией Reality. TimeChain даёт self-sovereign identity и доказательство того, что узел работает; VPN даёт пропускную способность для пользователей. Без TimeChain VPN-узел — обычный VPS; без VPN TimeChain-узел — наблюдатель без полезной нагрузки. Только вместе они образуют suvereign-узел сети.
+
+---
+
+## 3. Метафора городов
+
+Узел Montana = город на карте. На сегодня (2026-05-10) сеть состоит из трёх городов:
+
+- **Москва** (55.7558° N, 37.6173° E) — TimeChain Active валидатор, эмитент окон;
+- **Frankfurt** (50.1109° N, 8.6821° E) — TimeChain candidate, VPN origin;
+- **Helsinki** (60.1699° N, 24.9384° E) — TimeChain candidate, VPN front для Frankfurt.
+
+Метафора не декоративна. Она задаёт три инварианта реализации:
+
+(а) **Каждый город открывает свой регион**. Пользователь, выбирающий «Helsinki», подключается к публичному интернету так, как его видит Helsinki: с её ASN, с её DNS-разрешением, с её доступностью к ресурсам, заблокированным в других регионах.
+
+(б) **Города страхуют друг друга**. Если узел падает или захватывается, оставшиеся города принимают его клиентов через federation-механизм, описанный в разделе 6.4. Никакой центральной точки failover нет.
+
+(в) **Сеть городов и есть интернет**. Конечный пользователь не различает «использую интернет» и «использую Montana» — Montana становится интернетом для тех, кто к ней присоединяется. Это идеальная цель; на текущей стадии она реализована частично (раздел 9).
+
+---
+
+## 4. Слой 1 — TimeChain (резюме)
+
+Полное описание — в спецификации `Montana Protocol v35.25.0` и в whitepaper TimeChain. Здесь только то, что необходимо для понимания связи со слоем 2.
+
+**Окно.** Пусть `T_r` — выход VDF на окне `r`. Цепь продвигается по правилу `T_r = SHA-256^D (T_{r-1})`, где `T_0` — genesis seed, `D` — параметр итераций per-окно. На текущей эпохе `D = 325 000 000`, что калибрует окно на ≈60 секунд commodity x86_64. `D` пересчитывается каждые `τ₂ = 20160` окон (≈14 дней) по канонической формуле.
+
+**Эмиссия.** На каждом окне начисляется ровно `13 Ɉ = 13·10⁹ nɈ`. Supply закрытой формулой: `supply(W) = 13·(W+1) Ɉ`. На момент написания `W = 34922`, supply ≈ 454 000 Ɉ.
+
+**Регистрация узла.** Новый оператор обязан построить candidate VDF цепь длиной `τ₂` окон (≈10 часов wall-clock на M-class Mac). Это Sybil-защита: N идентичностей требуют N candidate-цепей. После завершения candidate-VDF узел подаёт `NodeRegistration` и при ближайшем `selection event` (каждые 336 окон) попадает в `NodeTable` как Active.
+
+**Текущее состояние сети** (live-snapshot 2026-05-10):
+
+| Город | Phase | window | NodeTable | balance |
+|---|---|---|---|---|
+| Москва | Active | 34922 | 1 | 453 388 Ɉ |
+| Frankfurt | CandidateVdf 42% | 34920 | 1 | 0 |
+| Helsinki | CandidateVdf 4% | 34901 | 1 | 0 |
+| Mac (кандидат) | CandidateVdf 0.5% | 100 | 0 | 0 |
+
+Активный валидатор один — Москва. Frankfurt и Helsinki проходят candidate-VDF и в течение нескольких часов wall-clock выйдут на регистрацию; после этого NodeTable вырастет до трёх.
+
+---
+
+## 5. Слой 2 — Mesh VPN
+
+### 5.1. Транспорт: xray Reality
+
+Каждый VPN-узел запускает [xray](https://github.com/XTLS/Xray-core) с inbound-протоколом VLESS поверх Reality [14]. Reality — модификация TLS 1.3, в которой клиент инициирует handshake с настоящим публичным сайтом-мишенью (например `www.googletagmanager.com`), но получает первый ответ от прокси-сервера; для DPI-наблюдателя весь handshake неотличим от обычного TLS к этому публичному сайту. Дополнительный поток `xtls-rprx-vision` уменьшает сигнатуры в content-stream.
+
+Базовая конфигурация одного inbound на узле:
+
+```json
+{
+  "port": 443,
+  "protocol": "vless",
+  "streamSettings": {
+    "network": "tcp",
+    "security": "reality",
+    "realitySettings": {
+      "dest": "www.googletagmanager.com:443",
+      "serverNames": ["www.googletagmanager.com"],
+      "shortIds": ["<8 hex bytes per node>"],
+      "privateKey": "<X25519 private — per node>"
+    }
+  },
+  "settings": {
+    "clients": [{ "id": "<UUID>", "flow": "xtls-rprx-vision" }],
+    "decryption": "none"
+  }
+}
+```
+
+Каждый узел держит **свою** keypair и **свой** список UUID-клиентов. Координация между узлами — только на уровне federation (раздел 6.3), не на уровне keymaterial.
+
+### 5.2. Клиент
+
+Конечный пользователь устанавливает совместимый клиент (Happ для iOS, v2rayNG-derived `Монтана.apk` для Android, Hiddify/v2box для desktop) и подписывается на единый sub-URL `https://montana.quest/vpn/sub`. Sub отдаёт base64-encoded конкатенацию всех `vless://` ссылок узлов сети, обновляется каждые 5 минут (раздел 6.3). Клиент автоматически переключается между узлами при отказе одного из них.
+
+### 5.3. Per-city sub
+
+В дополнение к федеративному pool-у у каждого активного VPN-города есть собственный endpoint:
+
+- `GET /vpn/city/fra` — vless URL Frankfurt;
+- `GET /vpn/city/fin` — vless URL Helsinki;
+- `GET /vpn/city/msk` — пока 404 (Москва на текущий момент в режиме `node only`, см. раздел 9).
+
+Per-city sub — точка входа для интерфейсов, в которых пользователь явно выбирает город (например, карта городов на `montana.quest/net`).
+
+---
+
+## 6. Federation между городами
+
+### 6.1. Принцип: locally true, globally aggregated
+
+Каждый узел знает истину только о себе. Запрос «какой VPN-конфиг у города X?» имеет ответом то, что **сам узел X публикует**. Никакой централизованной базы нет; aggregator только собирает истины от узлов.
+
+### 6.2. Источник истины узла: `my-vpn.json`
+
+Каждый узел публикует на себе `/var/lib/montana-net/my-vpn.json`:
+
+```json
+{
+  "node": "frankfurt",
+  "primary": false,
+  "vless": "vless://...@<host>:443?...#Montana%20FRA"
+}
+```
+
+Файл доступен только по SSH из доверенного aggregator-узла (Москва) с предъявлением выделенного публичного ключа `vpn_stats2`, разрешённого forced-command `cat /var/lib/montana-net/my-vpn.json`. Никакой нагрузки на публичный HTTP не создаётся.
+
+### 6.3. Aggregator: `montana-sub.timer`
+
+На Москве крутится systemd-таймер `montana-sub.timer` (каждые 5 минут), вызывающий `/opt/montana-net/sub-aggregator.sh`. Скрипт:
+
+1. Pull-ит `my-vpn.json` с каждого известного peer-узла через SSH (forced-command).
+2. Собирает list `vless://`-ссылок, сортирует (primary первым).
+3. Конкатенирует через `\n`, кодирует base64.
+4. Записывает в `/var/www/montana_quest/vpn/sub`.
+
+Дополнительный коллектор `/opt/montana-net/aggregator.sh` собирает `peers.json` с тех же узлов и публикует `/var/www/montana_quest/vpn/network.json` — здоровье federation.
+
+### 6.4. Failover-граф
+
+Текущая топология fronting:
+
+- **Helsinki фронтит Frankfurt.** vless-ссылка Helsinki в federation pool указывает на `cdn.montana.quest:443`, который проксируется на Helsinki как первичную точку входа. Если Helsinki падает, клиенты на Frankfurt напрямую через `89.19.208.158:443` (вторичная ссылка в том же sub). Это spelled out в `cities.json` через поля `vpn.fronts` и `vpn.fronted_by`.
+- **Москва пока не VPN.** При запуске VPN на Москве (Roadmap, раздел 9) она войдёт в pool как третья точка, peer-связь — Москва ↔ Frankfurt, Москва ↔ Helsinki.
+
+### 6.5. Health probe
+
+`peer-health.py` (Москва, тот же таймер) проверяет TLS-handshake к каждому VPN-endpoint в pool с целевой SNI. Записывает результат в `/var/www/montana_quest/vpn/health.json`. Aggregator не выкидывает узел из sub при временном отказе — клиент сам переключится. Health-данные — для отображения в эксплорере (`montana.quest/net`).
+
+---
+
+## 7. Privacy by Default
+
+### 7.1. На уровне TimeChain
+
+Account ID — это `SHA-256(public_key)`. По цепи никакая `know-your-customer`-метаинформация не обязательна. Балансы публичны (как в Bitcoin), но никнеймы и связи между аккаунтами явно не раскрываются — пользователь сам выбирает, что приоткрыть. См. отдельный документ «Privacy by default».
+
+### 7.2. На уровне VPN
+
+Reality маскирует handshake под публичный TLS к легитимному сайту-мишени. DPI, видящий handshake, не отличает Montana-VPN от посещения `www.googletagmanager.com`. SNI и сертификат соответствуют публичной мишени. Шифрование payload — TLS 1.3 (поверх Reality), плюс инкапсуляция VLESS-протокола; ключ согласовывается per-session.
+
+### 7.3. На уровне эксплорера
+
+Публичные дашборды (`montana.quest/net`) **не отдают IP-адреса узлов** ни в JSON, ни в HTML. Координаты узлов — приближение до уровня города (Москва, Frankfurt, Helsinki), не до точного дата-центра. Имена хостинг-провайдеров не публикуются. Это снижает поверхность для прицельных DDoS- и социальных атак.
+
+---
+
+## 8. Масштаб
+
+Базовая цель — поддержка ≥10⁹ активных пользователей. Каждое архитектурное решение Montana проверяется на этот baseline; механизмы, не масштабирующиеся, отбрасываются без обсуждения. См. отдельный документ «Scale baseline 1B+».
+
+Прикидка слоёв:
+
+**TimeChain.** AccountTable растёт с каждой новой регистрацией. При 10⁹ аккаунтов и среднем размере записи ≈2 KB AccountTable — порядка 2 TB. Это не помещается в RAM, но влезает в SSD одного узла, при условии что узел держит только индекс активных. Эмиссия 13 Ɉ/окно × 525 600 окон/год ≈ 6.83 млн Ɉ/год — приемлемая инфляция при заявленном supply.
+
+**VPN mesh.** При типичной нагрузке 5 Mbps/пользователя, узел с 10 Gbps аплинком обслуживает ≈2000 одновременных активных. 10⁹ пользователей с предположением 1% одновременной активности — 10⁷ активных потоков, что требует ≈5000 узлов. Это и есть target для federation: достичь сети из тысяч городов. Текущие 3 — стартовая точка.
+
+---
+
+## 9. Текущее состояние и Roadmap
+
+### 9.1. На сегодня (2026-05-10)
+
+- **TimeChain**: 3 узла (Москва Active, Frankfurt+Helsinki в candidate-VDF), 1 кандидат (Mac). Genesis 2026-01-09. Window ≈ 35 000.
+- **VPN**: 2 активные точки (Frankfurt, Helsinki). Helsinki фронтит Frankfurt. Federated `/vpn/sub` агрегирует обе.
+- **Эксплорер**: `montana.quest/net` — live-дашборд 4 узлов, мобильно-адаптированный, без раскрытия IP.
+- **Карта городов**: backend `/net/cities.json` готов, `vpn/city/<id>` отдаёт per-city ссылки. Визуальная карта — следующий шаг.
+
+### 9.2. Ближайший шаг
+
+- Поднять xray Reality на Москве (отдельный порт, поскольку :443 занят nginx). Москва войдёт в federated pool как третий VPN-узел. После этого `cities.json` автоматически отметит Москву как `vpn origin`.
+- Frankfurt и Helsinki завершают candidate-VDF и регистрируются как Active валидаторы. Расхождение AccountTable / supply между узлами схлопывается до нуля.
+- Визуальная карта городов на `montana.quest/net` — отдельная итерация фронта.
+
+### 9.3. Среднесрочно
+
+- Расширение federation: новые города-узлы по запросу. Onboarding — поднять `montana-node` + xray Reality + публикация `my-vpn.json`. Aggregator подхватит автоматически.
+- Mobile distribution: уже собран `Монтана.apk` (rebrand v2rayNG, keystore = genesis-секрет). Аналог для iOS — Happ deeplink через `/vpn/sub`.
+
+### 9.4. Долгосрочно
+
+- Десятки и сотни городов. Sub-pool federated шардируется по регионам. Health-probe становится частью consensus (узел, не отвечающий >7 дней, исключается из NodeTable через специальную операцию).
+- Каждый город — отдельная identity ML-DSA-65, отдельный operator-аккаунт, отдельный VPN-keypair.
+
+---
+
+## 10. Ссылки
+
+[1] Nakamoto S. *Bitcoin: A Peer-to-Peer Electronic Cash System*. 2008.
+[2] NIST FIPS 203. *Module-Lattice-Based Key-Encapsulation Mechanism Standard*. 2024.
+[3] NIST FIPS 204. *Module-Lattice-Based Digital Signature Standard*. 2024.
+[4] NIST FIPS 180-4. *Secure Hash Standard*. 2015.
+[5] Boneh D., Bonneau J., Bünz B., Fisch B. *Verifiable Delay Functions*. CRYPTO 2018.
+[6] Wesolowski B. *Efficient Verifiable Delay Functions*. EUROCRYPT 2019.
+[7] Pietrzak K. *Simple Verifiable Delay Functions*. ITCS 2019.
+[8] Shor P. *Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer*. SIAM J. Comput., 1997.
+[9] Grover L. *A Fast Quantum Mechanical Algorithm for Database Search*. STOC 1996.
+[10] *Montana Protocol v35.25.0*. Montana spec, 2026.
+[11] Dingledine R., Mathewson N., Syverson P. *Tor: The Second-Generation Onion Router*. USENIX Security 2004.
+[12] Donenfeld J. *WireGuard: Next Generation Kernel Network Tunnel*. NDSS 2017.
+[13] *Whitepaper Montana RU* (TimeChain layer) — `Montana/Montana-Protocol/Whitepaper Montana RU.md`.
+[14] *XTLS Reality* — `github.com/XTLS/Xray-core/discussions/1295`.
+
+---
+
+*Документ публикуется на трёх языках: русском (этот файл), английском (`Whitepaper Montana Mesh.md`) и китайском (`Whitepaper Montana Mesh ZH.md`). Все три — содержательно идентичны; в случае расхождения каноническая версия — русская.*
--- a/Montana-Protocol/Whitepaper
+++ b/Montana-Protocol/Whitepaper
@ -0,0 +1,242 @@
+# Montana：城市自治网状网络
+
+**Alejandro Montana**
+[github.com/efir369999/Montana](https://github.com/efir369999/Montana) · [montana.quest](https://montana.quest)
+
+---
+
+## 摘要
+
+要在没有可信中介、不依赖经典密码学的前提下,在各方之间传递价值,网络必须同时解决三个问题:事件全局排序的一致性、对被动观察者和主动审查者的传输层保护、以及在个别节点失效或被夺取时的基础设施韧性。现有系统只解决其中一个。Bitcoin 提供共识,但不提供传输隐私。Tor 提供传输隐私,但不提供共识。Tailscale 与 WireGuard 提供 peer-to-peer 互联,但不提供基础设施自治。Montana 试图在一个系统中同时具备这三种属性。它由两个相互耦合的层组成:**TimeChain**——一条后量子区块链,其稀缺资源是时间(而非区块空间或手续费),以及 **Mesh VPN**——一个城市节点的联邦,每个节点开放其所在区域的互联网,并在邻近节点失效时承担其客户端。不变的隐喻:每个节点都是地图上的一座城市;由 VPN 城市组成的网络就是互联网。
+
+---
+
+## 1. 引言
+
+Bitcoin [1] 证明了去中心化的货币共识无须可信中介即可实现。Tor [11] 证明了在公共网络中匿名路由流量是可行的。WireGuard [12] 及其衍生方案表明,基于现代密码学构建简单且高速的 peer-to-peer VPN 是可能的。这些系统都不能同时具备 Montana 所追求的三项属性——面向 ≥10⁹ 用户规模的自治互联网所需的:全局排序、传输隐私、以及自治基础设施。
+
+此外,Bitcoin 及其后继者还存在两个未解决的脆弱性。第一,所有生产级区块链都将签名安全建立在椭圆曲线离散对数假设之上。Shor 算法 [8] 在足够大的量子计算机上以多项式时间打破这些假设。NIST 在 2024 年标准化了后量子签名与密钥封装机制(FIPS 203 [2]、204 [3]、205);主要链尚未迁移。第二,基于手续费的反垃圾机制在大规模采用下扩展不佳:拥堵时小额操作被价格挤出,空闲时垃圾以边际成本回归。Layer-2 系统(状态通道、rollup)只是转移经济成本,并未消除底层稀缺。
+
+Montana 提出:一条签名安全完全建立在后量子原语之上、反垃圾机制基于时间(而非金钱)的链 [13]。链通过 SHA-256 上的可验证延迟函数(VDF)[5,6,7] 推进,产生约 60 秒一格的全局有序窗口。窗口内的操作受三种独立的、由时间派生的稀缺资源限制:每身份每窗口、账户链长度、资历。在此层之上,协议部署第二层——网状 VPN,使用 Reality(xray)[14] 将流量伪装为对合法公开目标的常规 TLS 握手。
+
+---
+
+## 2. 架构:两层、一网
+
+Montana 由同一组节点物理实现的两个层组成:
+
+**第 1 层——TimeChain。** 全局时钟 + 身份注册 + 状态。负责:事件排序、节点运营商注册、发行核算、状态保存。详细论述参见 [Whitepaper Montana ZH](Whitepaper%20Montana%20ZH.md);本文第 4 节为摘要。
+
+**第 2 层——网状 VPN。** 通过城市节点路由用户流量。负责:传输隐私、规避审查、节点间故障转移。第 5–7 节展开。
+
+两层并非独立:愿意全程参与的运营商必须同时运行 TimeChain 节点(`montana-node`)和 Reality 配置的 VPN 服务器(`xray`)。TimeChain 提供自治身份和在线证明;VPN 为用户提供带宽。无 TimeChain,VPN 节点只是普通 VPS;无 VPN,TimeChain 节点只是没有有用负载的观察者。两者结合方为自治网络节点。
+
+---
+
+## 3. 城市隐喻
+
+Montana 节点 = 地图上的一座城市。截至 2026-05-10,网络由三座城市组成:
+
+- **莫斯科**(55.7558° N, 37.6173° E)—— TimeChain Active 验证者,窗口发行者;
+- **法兰克福**(50.1109° N, 8.6821° E)—— TimeChain candidate,VPN origin;
+- **赫尔辛基**(60.1699° N, 24.9384° E)—— TimeChain candidate,赫尔辛基为法兰克福做 VPN front。
+
+隐喻不是装饰性的。它强制三个实现不变量:
+
+(a)**每座城市开放其所在区域。** 选择"赫尔辛基"的用户以赫尔辛基的视角到达公共互联网:从赫尔辛基的 ASN、用赫尔辛基的 DNS 解析、具有赫尔辛基对其他地区被屏蔽资源的可达性。
+
+(b)**城市相互承担。** 当节点失效或被夺取时,余下的城市通过 6.4 节描述的联邦机制接收其客户端。不存在中央故障转移点。
+
+(c)**城市的网络就是互联网。** 终端用户不再区分"使用互联网"与"使用 Montana"——对于加入者,Montana 即互联网。这是终极目标;第 9 节描述当前的部分实现状态。
+
+---
+
+## 4. 第 1 层——TimeChain(摘要)
+
+完整描述见 `Montana Protocol v35.25.0` 与 TimeChain 白皮书 [13]。此处仅给出与第 2 层相关的部分。
+
+**窗口。** 设 `T_r` 为窗口 `r` 的 VDF 输出。链按 `T_r = SHA-256^D (T_{r-1})` 推进,其中 `T_0` 为创世种子,`D` 为每窗口迭代数。在当前 epoch,`D = 325 000 000`,将窗口校准至 commodity x86_64 上约 60 秒。`D` 每 `τ₂ = 20 160` 窗口(约 14 天)按典范公式重新校准。
+
+**发行。** 每个窗口准确铸造 `13 Ɉ = 13·10⁹ nɈ`。供应由闭式公式给出:`supply(W) = 13·(W+1) Ɉ`。撰文时 `W = 34 922`,supply ≈ 454 000 Ɉ。
+
+**节点注册。** 新运营商必须构建长度为 `τ₂` 窗口的 candidate VDF 链(M-class Mac 上约 10 小时实际墙钟)。这是 Sybil 防御:N 个身份需要 N 条 candidate 链。完成 candidate VDF 后,节点提交 `NodeRegistration`,在下一次 selection event(每 336 窗口一次)被纳入 `NodeTable` 为 Active。
+
+**当前网络状态**(2026-05-10 实时快照):
+
+| 城市 | Phase | window | NodeTable | 余额 |
+|---|---|---|---|---|
+| 莫斯科 | Active | 34922 | 1 | 453 388 Ɉ |
+| 法兰克福 | CandidateVdf 42% | 34920 | 1 | 0 |
+| 赫尔辛基 | CandidateVdf 4% | 34901 | 1 | 0 |
+| Mac(候选) | CandidateVdf 0.5% | 100 | 0 | 0 |
+
+当前仅有一个 Active 验证者——莫斯科。法兰克福和赫尔辛基在数小时墙钟内完成 candidate VDF 并注册;之后 NodeTable 增至三。
+
+---
+
+## 5. 第 2 层——网状 VPN
+
+### 5.1. 传输:xray Reality
+
+每个 VPN 节点运行 [xray](https://github.com/XTLS/Xray-core),inbound 协议为 VLESS 之上的 Reality [14]。Reality 是 TLS 1.3 的修改版,客户端向真实公开目标(如 `www.googletagmanager.com`)发起握手,但首响应来自代理服务器;对 DPI 观察者,整个握手与对该公开站点的常规 TLS 不可区分。`xtls-rprx-vision` 流进一步降低 content-stream 的特征。
+
+节点上单 inbound 的基线配置:
+
+```json
+{
+  "port": 443,
+  "protocol": "vless",
+  "streamSettings": {
+    "network": "tcp",
+    "security": "reality",
+    "realitySettings": {
+      "dest": "www.googletagmanager.com:443",
+      "serverNames": ["www.googletagmanager.com"],
+      "shortIds": ["<每节点 8 hex bytes>"],
+      "privateKey": "<X25519 私钥——每节点>"
+    }
+  },
+  "settings": {
+    "clients": [{ "id": "<UUID>", "flow": "xtls-rprx-vision" }],
+    "decryption": "none"
+  }
+}
+```
+
+每个节点持有**自己的** keypair 与**自己的** UUID 客户端列表。节点间协调仅在联邦层级(6.3 节),不在 keymaterial 层级。
+
+### 5.2. 客户端
+
+终端用户安装兼容客户端(iOS 用 Happ,Android 用基于 v2rayNG 的 `Монтана.apk`,桌面端用 Hiddify 或 v2box),并订阅单一 sub URL `https://montana.quest/vpn/sub`。sub 提供网络中所有节点 `vless://` URL 的 base64 串联,每 5 分钟刷新一次(6.3 节)。客户端在某节点失效时自动切换。
+
+### 5.3. 单城市 sub
+
+除联邦池外,每座活跃 VPN 城市还拥有自己的 endpoint:
+
+- `GET /vpn/city/fra`——法兰克福的 vless URL;
+- `GET /vpn/city/fin`——赫尔辛基的 vless URL;
+- `GET /vpn/city/msk`——目前 404(莫斯科当前为 `node only` 模式,见第 9 节)。
+
+单城市 sub 是用户显式选择城市的界面入口(例如 `montana.quest/net` 上的城市地图)。
+
+---
+
+## 6. 城市间联邦
+
+### 6.1. 原则:本地真实,全局聚合
+
+每个节点只知道关于自己的真相。"城市 X 的 VPN 配置是什么"这一查询的答案是**节点 X 自己发布的内容**。没有中心化数据库;聚合器仅从节点收集真相。
+
+### 6.2. 节点真相之源:`my-vpn.json`
+
+每个节点本地发布 `/var/lib/montana-net/my-vpn.json`:
+
+```json
+{
+  "node": "frankfurt",
+  "primary": false,
+  "vless": "vless://...@<host>:443?...#Montana%20FRA"
+}
+```
+
+该文件仅可由可信的聚合器节点(莫斯科)通过 SSH 访问,需提供专用公钥 `vpn_stats2`,被限制为 `forced-command cat /var/lib/montana-net/my-vpn.json`。不存在公开 HTTP 暴露。
+
+### 6.3. 聚合器:`montana-sub.timer`
+
+莫斯科运行 systemd 计时器 `montana-sub.timer`(每 5 分钟),调用 `/opt/montana-net/sub-aggregator.sh`。脚本:
+
+1. 通过 SSH(forced-command)从每个已知节点拉取 `my-vpn.json`。
+2. 收集 `vless://` 列表,排序(primary 优先)。
+3. 用 `\n` 串联,base64 编码。
+4. 写入 `/var/www/montana_quest/vpn/sub`。
+
+伴生收集器 `/opt/montana-net/aggregator.sh` 从相同节点收集 `peers.json`,发布 `/var/www/montana_quest/vpn/network.json`——联邦健康视图。
+
+### 6.4. 故障转移图
+
+当前 fronting 拓扑:
+
+- **赫尔辛基为法兰克福做 front。** 联邦池中赫尔辛基的 vless URL 指向 `cdn.montana.quest:443`,该地址被代理至赫尔辛基作为主入口。若赫尔辛基失效,客户端通过 `89.19.208.158:443`(同一 sub 中的次级 URL)直接连接法兰克福。这一关系在 `cities.json` 中通过 `vpn.fronts` 与 `vpn.fronted_by` 字段表达。
+- **莫斯科尚非 VPN。** 当莫斯科启动 VPN(路线图,第 9 节)时,作为第三入口加入池,与法兰克福和赫尔辛基对等。
+
+### 6.5. 健康探测
+
+`peer-health.py`(莫斯科,同一计时器)以目标 SNI 对每个 VPN endpoint 执行 TLS 握手,结果写入 `/var/www/montana_quest/vpn/health.json`。聚合器在临时失效时不将节点逐出 sub——客户端自行切换。健康数据用于 explorer 显示(`montana.quest/net`)。
+
+---
+
+## 7. 默认隐私
+
+### 7.1. TimeChain 层
+
+Account ID 为 `SHA-256(public_key)`。链本身不要求 KYC 元数据。余额是公开的(同 Bitcoin),但昵称及账户间联系默认不暴露——用户自主选择透露内容。详见单独文档"Privacy by default"。
+
+### 7.2. VPN 层
+
+Reality 将握手伪装为对合法公开目标的常规 TLS。观察握手的 DPI 无法区分 Montana-VPN 与对 `www.googletagmanager.com` 的访问。SNI 与证书均匹配公开目标。负载加密为 TLS 1.3(于 Reality 之上)叠加 VLESS 封装;密钥逐会话协商。
+
+### 7.3. Explorer 层
+
+公开仪表板(`montana.quest/net`)**不在 JSON 与 HTML 中暴露节点 IP**。节点坐标精度为城市级别(莫斯科、法兰克福、赫尔辛基),不到数据中心层级。不发布托管商名称。这降低了针对性 DDoS 与社会工程攻击的表面。
+
+---
+
+## 8. 规模
+
+基线目标是支撑 ≥10⁹ 活跃用户。Montana 的每一项架构决策都对照此基线检验;不可扩展的机制无须讨论即被舍弃。详见单独文档"Scale baseline 1B+"。
+
+各层估算:
+
+**TimeChain。** AccountTable 随每次新注册而增长。在 10⁹ 账户、平均记录 ≈2 KB 的情况下,表的量级约为 2 TB。无法置于 RAM,但适合单节点 SSD,前提是节点仅维护活跃集索引。13 Ɉ/窗口 × 525 600 窗口/年 ≈ 6.83M Ɉ/年——相对于宣称的 supply 是可接受的通胀。
+
+**网状 VPN。** 每用户典型 5 Mbps 负载下,具 10 Gbps 上行的节点服务约 2 000 并发活跃会话。10⁹ 用户在 1% 并发活跃假设下约为 10⁷ 活跃流,需要约 5 000 节点。这是联邦的目标:数千座城市的网络。当前的三座是起点。
+
+---
+
+## 9. 当前状态与路线图
+
+### 9.1. 截至 2026-05-10
+
+- **TimeChain**:3 个节点(莫斯科 Active,法兰克福+赫尔辛基处于 candidate-VDF 中),1 个候选(Mac)。Genesis 为 2026-01-09。Window ≈ 35 000。
+- **VPN**:2 个活跃点(法兰克福、赫尔辛基)。赫尔辛基为法兰克福做 front。联邦 `/vpn/sub` 同时聚合两者。
+- **Explorer**:`montana.quest/net`——4 节点的实时仪表板,移动端适配,不暴露 IP。
+- **城市地图**:后端 `/net/cities.json` 已就绪,`vpn/city/<id>` 提供单城市 URL。可视地图为下一步。
+
+### 9.2. 近期
+
+- 在莫斯科启动 xray Reality(独立端口,因 :443 由 nginx 占用)。莫斯科作为第三个 VPN 节点加入联邦池。之后 `cities.json` 自动将莫斯科标记为 `vpn origin`。
+- 法兰克福和赫尔辛基完成 candidate-VDF 并注册为 Active 验证者。节点间 AccountTable / supply 的偏差归零。
+- `montana.quest/net` 上的可视城市地图——独立的前端迭代。
+
+### 9.3. 中期
+
+- 联邦扩张:按需新增城市节点。Onboarding——启动 `montana-node` + xray Reality + 发布 `my-vpn.json`。聚合器自动接入。
+- 移动分发:`Монтана.apk` 已构建(基于 v2rayNG 重打包,keystore = genesis 秘密)。iOS 对应是通过 `/vpn/sub` 的 Happ deeplink。
+
+### 9.4. 远期
+
+- 数十至数百座城市。联邦 sub-pool 按区域分片。健康探测成为 consensus 的一部分(节点超过 7 天未响应将通过专用操作从 `NodeTable` 中剔除)。
+- 每座城市——自有的 ML-DSA-65 身份、自有的运营商账户、自有的 VPN keypair。
+
+---
+
+## 10. 参考文献
+
+[1] Nakamoto S. *Bitcoin: A Peer-to-Peer Electronic Cash System*. 2008.
+[2] NIST FIPS 203. *Module-Lattice-Based Key-Encapsulation Mechanism Standard*. 2024.
+[3] NIST FIPS 204. *Module-Lattice-Based Digital Signature Standard*. 2024.
+[4] NIST FIPS 180-4. *Secure Hash Standard*. 2015.
+[5] Boneh D., Bonneau J., Bünz B., Fisch B. *Verifiable Delay Functions*. CRYPTO 2018.
+[6] Wesolowski B. *Efficient Verifiable Delay Functions*. EUROCRYPT 2019.
+[7] Pietrzak K. *Simple Verifiable Delay Functions*. ITCS 2019.
+[8] Shor P. *Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer*. SIAM J. Comput., 1997.
+[9] Grover L. *A Fast Quantum Mechanical Algorithm for Database Search*. STOC 1996.
+[10] *Montana Protocol v35.25.0*. Montana spec, 2026.
+[11] Dingledine R., Mathewson N., Syverson P. *Tor: The Second-Generation Onion Router*. USENIX Security 2004.
+[12] Donenfeld J. *WireGuard: Next Generation Kernel Network Tunnel*. NDSS 2017.
+[13] *Whitepaper Montana ZH*(TimeChain layer)—— `Montana/Montana-Protocol/Whitepaper Montana ZH.md`。
+[14] *XTLS Reality*—— `github.com/XTLS/Xray-core/discussions/1295`。
+
+---
+
+*本文档以三种语言发布:俄语(`Whitepaper Montana Mesh RU.md`)、英语(`Whitepaper Montana Mesh.md`)、中文(本文)。三者内容相同;若有出入,典范版本为俄语版。*
--- a/Montana-Protocol/Whitepaper
+++ b/Montana-Protocol/Whitepaper
@ -0,0 +1,242 @@
+# Montana: A Sovereign Mesh of Cities
+
+**Alejandro Montana**
+[github.com/efir369999/Montana](https://github.com/efir369999/Montana) · [montana.quest](https://montana.quest)
+
+---
+
+## Abstract
+
+A network in which value moves between parties without trusted intermediaries and without dependence on classical cryptography must simultaneously solve three problems: global consensus on event ordering, transport-level protection against passive observers and active censors, and infrastructural resilience against the failure or capture of individual nodes. Existing systems solve one of the three. Bitcoin gives consensus but not transport privacy. Tor gives transport privacy but not consensus. Tailscale and WireGuard give peer-to-peer connectivity but not infrastructure sovereignty. Montana attempts to combine all three in a single system. It consists of two coupled layers: **TimeChain**, a post-quantum blockchain whose scarcity is time (not block space and not fees), and **Mesh VPN**, a federation of city-nodes, each of which exposes its region of the internet and underwrites its neighbors when they fail. The invariant metaphor: each node is a city on a map; the network of VPN-cities is the internet.
+
+---
+
+## 1. Introduction
+
+Bitcoin [1] demonstrated that decentralized monetary consensus is achievable without intermediaries. Tor [11] demonstrated that anonymous traffic routing is achievable on a public network. WireGuard [12] and its descendants showed that simple, fast peer-to-peer VPN is possible on top of modern cryptography. None of these systems combine the three properties Montana targets — a sovereign internet at the scale of ≥10⁹ users: global ordering, transport privacy, and self-sovereign infrastructure.
+
+Bitcoin and its descendants further leave two unresolved vulnerabilities. First, all production blockchains derive signature security from elliptic-curve discrete-logarithm assumptions. Shor's algorithm [8], on a sufficiently large quantum computer, breaks these assumptions in polynomial time. NIST standardized post-quantum signatures and key-encapsulation mechanisms in 2024 (FIPS 203 [2], 204 [3], 205); major chains have not migrated. Second, fee-based anti-spam scales poorly under adoption: under congestion small operations are priced out, under abundance spam returns at marginal cost. Layer-2 systems (state channels, rollups) shift the economics rather than remove the underlying scarcity.
+
+Montana proposes a chain whose signature security rests entirely on post-quantum primitives, and whose anti-spam mechanism operates on time rather than money [13]. The chain advances by a verifiable delay function (VDF) [5,6,7] over SHA-256, producing globally ordered windows of approximately 60 seconds. Operations within a window are rate-limited by three independent time-derived scarcities: per-identity, account chain length, and seniority. On top of this layer, the protocol deploys a second layer — mesh VPN — using Reality (xray) [14] to mask traffic as a regular TLS handshake to a legitimate public destination.
+
+---
+
+## 2. Architecture: Two Layers, One Network
+
+Montana consists of two layers physically realized by the same set of nodes:
+
+**Layer 1 — TimeChain.** Global clock + identity registry + state. Responsible for: event ordering, node-operator registration, emission accounting, state preservation. Detailed exposition is in [Whitepaper Montana](Whitepaper%20Montana.md); section 4 here is a summary.
+
+**Layer 2 — Mesh VPN.** Routing of user traffic through city-nodes. Responsible for: transport privacy, censorship circumvention, failover among nodes. Sections 5–7 elaborate.
+
+The layers are not independent: an operator who wishes to participate fully must run both a TimeChain node (`montana-node`) and a VPN server (`xray`) with Reality. TimeChain provides self-sovereign identity and proof-of-uptime; VPN provides bandwidth for users. Without TimeChain a VPN node is an ordinary VPS; without VPN a TimeChain node is an observer with no useful payload. Only together do they make a sovereign network node.
+
+---
+
+## 3. The City Metaphor
+
+A Montana node = a city on the map. As of 2026-05-10, the network consists of three cities:
+
+- **Moscow** (55.7558° N, 37.6173° E) — TimeChain Active validator, window emitter;
+- **Frankfurt** (50.1109° N, 8.6821° E) — TimeChain candidate, VPN origin;
+- **Helsinki** (60.1699° N, 24.9384° E) — TimeChain candidate, VPN front for Frankfurt.
+
+The metaphor is not decorative. It enforces three implementation invariants:
+
+(a) **Each city opens its region.** A user choosing "Helsinki" reaches the public internet as Helsinki sees it: from Helsinki's ASN, with Helsinki's DNS resolution, with Helsinki's reachability to resources blocked elsewhere.
+
+(b) **Cities underwrite each other.** When a node fails or is captured, the remaining cities accept its clients via the federation mechanism described in section 6.4. There is no central failover point.
+
+(c) **The network of cities is the internet.** The end user does not distinguish between "using the internet" and "using Montana" — Montana becomes the internet for those who join. This is the limit goal; section 9 describes the partial state of realization at present.
+
+---
+
+## 4. Layer 1 — TimeChain (summary)
+
+The full description is in `Montana Protocol v35.25.0` and in the TimeChain whitepaper [13]. Only the part relevant to Layer 2 is given here.
+
+**Window.** Let `T_r` denote the VDF output at window `r`. The chain advances by `T_r = SHA-256^D (T_{r-1})`, where `T_0` is the genesis seed and `D` the per-window iteration count. At the current epoch, `D = 325 000 000`, calibrating the window to ≈60 seconds on commodity x86_64. `D` is recalibrated every `τ₂ = 20 160` windows (≈14 days) by a canonical formula.
+
+**Emission.** Each window mints exactly `13 Ɉ = 13·10⁹ nɈ`. Supply is given by the closed form `supply(W) = 13·(W+1) Ɉ`. At the time of writing `W = 34 922`, supply ≈ 454 000 Ɉ.
+
+**Node registration.** A new operator must build a candidate VDF chain of length `τ₂` windows (≈10 hours wall-clock on M-class Mac). This is the Sybil defense: N identities require N candidate chains. After completing the candidate VDF, the node submits `NodeRegistration` and at the next selection event (every 336 windows) is admitted into the `NodeTable` as Active.
+
+**Current network state** (live snapshot 2026-05-10):
+
+| City | Phase | window | NodeTable | balance |
+|---|---|---|---|---|
+| Moscow | Active | 34922 | 1 | 453 388 Ɉ |
+| Frankfurt | CandidateVdf 42% | 34920 | 1 | 0 |
+| Helsinki | CandidateVdf 4% | 34901 | 1 | 0 |
+| Mac (candidate) | CandidateVdf 0.5% | 100 | 0 | 0 |
+
+A single Active validator at present — Moscow. Frankfurt and Helsinki finish candidate-VDF and register within hours of wall-clock; after that NodeTable grows to three.
+
+---
+
+## 5. Layer 2 — Mesh VPN
+
+### 5.1. Transport: xray Reality
+
+Each VPN node runs [xray](https://github.com/XTLS/Xray-core) with a VLESS inbound over Reality [14]. Reality is a modification of TLS 1.3 in which the client initiates a handshake to a real public destination (e.g. `www.googletagmanager.com`) but receives the first response from the proxy server; to a DPI observer the entire handshake is indistinguishable from ordinary TLS to that public site. The `xtls-rprx-vision` flow further reduces signatures in the content stream.
+
+Baseline single-inbound config on a node:
+
+```json
+{
+  "port": 443,
+  "protocol": "vless",
+  "streamSettings": {
+    "network": "tcp",
+    "security": "reality",
+    "realitySettings": {
+      "dest": "www.googletagmanager.com:443",
+      "serverNames": ["www.googletagmanager.com"],
+      "shortIds": ["<8 hex bytes per node>"],
+      "privateKey": "<X25519 private — per node>"
+    }
+  },
+  "settings": {
+    "clients": [{ "id": "<UUID>", "flow": "xtls-rprx-vision" }],
+    "decryption": "none"
+  }
+}
+```
+
+Each node holds **its own** keypair and **its own** UUID client list. Inter-node coordination is at the federation level only (section 6.3), not at the keymaterial level.
+
+### 5.2. Client
+
+The end user installs a compatible client (Happ for iOS, the v2rayNG-derived `Монтана.apk` for Android, Hiddify or v2box for desktop) and subscribes to the single sub URL `https://montana.quest/vpn/sub`. The sub serves a base64-encoded concatenation of every node's `vless://` URL, refreshed every five minutes (section 6.3). The client switches automatically between nodes on failure.
+
+### 5.3. Per-city sub
+
+In addition to the federated pool, each active VPN-city has its own endpoint:
+
+- `GET /vpn/city/fra` — vless URL of Frankfurt;
+- `GET /vpn/city/fin` — vless URL of Helsinki;
+- `GET /vpn/city/msk` — currently 404 (Moscow is in `node only` mode at present, see section 9).
+
+The per-city sub is the entry point for interfaces in which the user selects a city explicitly (e.g. the city map on `montana.quest/net`).
+
+---
+
+## 6. Federation Among Cities
+
+### 6.1. Principle: Locally True, Globally Aggregated
+
+Each node knows the truth only about itself. The query "what is the VPN config for city X?" is answered by what **node X publishes**. There is no centralized database; the aggregator only collects truths from nodes.
+
+### 6.2. Node Source of Truth: `my-vpn.json`
+
+Each node publishes locally `/var/lib/montana-net/my-vpn.json`:
+
+```json
+{
+  "node": "frankfurt",
+  "primary": false,
+  "vless": "vless://...@<host>:443?...#Montana%20FRA"
+}
+```
+
+The file is accessible only via SSH from the trusted aggregator node (Moscow) presenting the dedicated public key `vpn_stats2`, restricted to `forced-command cat /var/lib/montana-net/my-vpn.json`. No public HTTP exposure.
+
+### 6.3. Aggregator: `montana-sub.timer`
+
+Moscow runs the systemd timer `montana-sub.timer` (every 5 minutes) invoking `/opt/montana-net/sub-aggregator.sh`. The script:
+
+1. Pulls `my-vpn.json` from each known peer via SSH (forced-command).
+2. Collects the `vless://` list, sorts it (primary first).
+3. Concatenates with `\n`, base64-encodes.
+4. Writes to `/var/www/montana_quest/vpn/sub`.
+
+A companion collector `/opt/montana-net/aggregator.sh` collects `peers.json` from the same nodes and publishes `/var/www/montana_quest/vpn/network.json` — the federation health view.
+
+### 6.4. Failover Graph
+
+Current fronting topology:
+
+- **Helsinki fronts Frankfurt.** The Helsinki vless URL in the federation pool points to `cdn.montana.quest:443`, which is proxied to Helsinki as the primary entry point. If Helsinki fails, clients reach Frankfurt directly via `89.19.208.158:443` (the secondary URL in the same sub). This is spelled out in `cities.json` via the `vpn.fronts` and `vpn.fronted_by` fields.
+- **Moscow is not yet a VPN.** When VPN is brought up on Moscow (Roadmap, section 9), it joins the pool as a third entry point, peering with Frankfurt and Helsinki.
+
+### 6.5. Health Probe
+
+`peer-health.py` (Moscow, same timer) performs a TLS handshake to each VPN endpoint with the target SNI. The result is written to `/var/www/montana_quest/vpn/health.json`. The aggregator does not evict a node from sub on transient failure — the client switches itself. Health data is for explorer display (`montana.quest/net`).
+
+---
+
+## 7. Privacy by Default
+
+### 7.1. At the TimeChain Layer
+
+Account ID is `SHA-256(public_key)`. The chain itself does not require KYC metadata. Balances are public (as in Bitcoin), but nicknames and inter-account links are not exposed by default — the user chooses what to reveal. See the dedicated document "Privacy by default".
+
+### 7.2. At the VPN Layer
+
+Reality masks the handshake as ordinary TLS to a legitimate public destination. A DPI observer of the handshake cannot distinguish Montana-VPN from a visit to `www.googletagmanager.com`. SNI and certificate match the public destination. Payload encryption is TLS 1.3 (over Reality) plus VLESS encapsulation; the key is negotiated per session.
+
+### 7.3. At the Explorer Layer
+
+The public dashboard (`montana.quest/net`) **does not expose node IPs** in JSON or HTML. Node coordinates are at city granularity (Moscow, Frankfurt, Helsinki), not at the data-center level. Hosting-provider names are not published. This reduces the surface for targeted DDoS and social attacks.
+
+---
+
+## 8. Scale
+
+The baseline target is supporting ≥10⁹ active users. Every architectural decision in Montana is checked against this baseline; mechanisms that do not scale are dropped without discussion. See the dedicated document "Scale baseline 1B+".
+
+Layer estimates:
+
+**TimeChain.** AccountTable grows with each new registration. At 10⁹ accounts and an average record size of ≈2 KB, the table is on the order of 2 TB. This does not fit in RAM but does fit on a single node's SSD, provided the node maintains only an active-set index. Emission of 13 Ɉ/window × 525 600 windows/year ≈ 6.83M Ɉ/year — acceptable inflation against the announced supply.
+
+**VPN mesh.** At a typical load of 5 Mbps per user, a node with 10 Gbps uplink serves ≈2 000 concurrent active sessions. 10⁹ users at 1% concurrent activity assumption ≈ 10⁷ active streams, requiring ≈5 000 nodes. This is the federation target: a network of thousands of cities. The current three are the starting point.
+
+---
+
+## 9. Current State and Roadmap
+
+### 9.1. As of 2026-05-10
+
+- **TimeChain**: 3 nodes (Moscow Active, Frankfurt+Helsinki in candidate-VDF), 1 candidate (Mac). Genesis 2026-01-09. Window ≈ 35 000.
+- **VPN**: 2 active points (Frankfurt, Helsinki). Helsinki fronts Frankfurt. Federated `/vpn/sub` aggregates both.
+- **Explorer**: `montana.quest/net` — live dashboard for 4 nodes, mobile-adapted, no IP exposure.
+- **City map**: backend `/net/cities.json` ready, `vpn/city/<id>` serves per-city URLs. Visual map is the next step.
+
+### 9.2. Near-term
+
+- Bring up xray Reality on Moscow (separate port, since :443 is held by nginx). Moscow joins the federated pool as the third VPN node. After that `cities.json` automatically marks Moscow as `vpn origin`.
+- Frankfurt and Helsinki finish candidate-VDF and register as Active validators. AccountTable / supply divergence between nodes collapses to zero.
+- Visual city map on `montana.quest/net` — a separate frontend iteration.
+
+### 9.3. Mid-term
+
+- Federation expansion: new city-nodes on demand. Onboarding — bring up `montana-node` + xray Reality + publish `my-vpn.json`. The aggregator picks them up automatically.
+- Mobile distribution: `Монтана.apk` is already built (rebrand of v2rayNG, keystore = genesis secret). The iOS analog is the Happ deeplink via `/vpn/sub`.
+
+### 9.4. Long-term
+
+- Tens to hundreds of cities. The federated sub-pool shards by region. Health probe becomes part of consensus (a node not responding for >7 days is ejected from `NodeTable` via a dedicated operation).
+- Each city — its own ML-DSA-65 identity, its own operator account, its own VPN keypair.
+
+---
+
+## 10. References
+
+[1] Nakamoto S. *Bitcoin: A Peer-to-Peer Electronic Cash System*. 2008.
+[2] NIST FIPS 203. *Module-Lattice-Based Key-Encapsulation Mechanism Standard*. 2024.
+[3] NIST FIPS 204. *Module-Lattice-Based Digital Signature Standard*. 2024.
+[4] NIST FIPS 180-4. *Secure Hash Standard*. 2015.
+[5] Boneh D., Bonneau J., Bünz B., Fisch B. *Verifiable Delay Functions*. CRYPTO 2018.
+[6] Wesolowski B. *Efficient Verifiable Delay Functions*. EUROCRYPT 2019.
+[7] Pietrzak K. *Simple Verifiable Delay Functions*. ITCS 2019.
+[8] Shor P. *Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer*. SIAM J. Comput., 1997.
+[9] Grover L. *A Fast Quantum Mechanical Algorithm for Database Search*. STOC 1996.
+[10] *Montana Protocol v35.25.0*. Montana spec, 2026.
+[11] Dingledine R., Mathewson N., Syverson P. *Tor: The Second-Generation Onion Router*. USENIX Security 2004.
+[12] Donenfeld J. *WireGuard: Next Generation Kernel Network Tunnel*. NDSS 2017.
+[13] *Whitepaper Montana* (TimeChain layer) — `Montana/Montana-Protocol/Whitepaper Montana.md`.
+[14] *XTLS Reality* — `github.com/XTLS/Xray-core/discussions/1295`.
+
+---
+
+*This document is published in three languages: Russian (`Whitepaper Montana Mesh RU.md`), English (this file), and Chinese (`Whitepaper Montana Mesh ZH.md`). All three are content-identical; in case of discrepancy, the canonical version is the Russian one.*