# 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 Ɉ. **Регистрация узла, очередь и welcome-bonus.** Новый оператор обязан построить candidate VDF цепь длиной `τ₂` окон (≈10 часов wall-clock на M-class Mac). Это Sybil-защита: N идентичностей требуют N candidate-цепей. После завершения candidate-VDF узел подаёт `NodeRegistration` и встаёт в очередь `CandidatePool`. Приём — **строго один кандидат за окно**: в окне admission принятый получает всю эмиссию этого окна (13 Ɉ) как welcome-bonus («одно окно времени = первый шаг в Montana»), Active валидатор в это окно эмиссии не получает. Closed-form supply `13·(W+1) Ɉ` сохраняется без изменений. Если очередь содержит N готовых кандидатов, admission всех занимает N окон (≈ N минут). **Текущее состояние сети** (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": "" } }, "settings": { "clients": [{ "id": "", "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://...@: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**: 3 активные точки (Москва :2053, Frankfurt :443, Helsinki :443). Helsinki фронтит Frankfurt; Москва — самостоятельный третий origin. Federated `/vpn/sub` агрегирует все три. - **Эксплорер**: `montana.quest/net` — live-дашборд 4 узлов, мобильно-адаптированный, без раскрытия IP. - **Карта городов**: backend `/net/cities.json` готов, `/vpn/city/{msk,fra,fin}` отдаёт per-city ссылки. Все три города помечены как VPN-узлы. Визуальная карта — следующий шаг. ### 9.2. Ближайший шаг - 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`). Все три — содержательно идентичны; в случае расхождения каноническая версия — русская.*