montana/Montana-Protocol/Whitepaper Montana Mesh RU.md

Montana: суверенная mesh-сеть городов

Алехандро Монтана github.com/efir369999/Montana · 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», здесь даём резюме (раздел 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 с inbound-протоколом VLESS поверх Reality [14]. Reality — модификация TLS 1.3, в которой клиент инициирует handshake с настоящим публичным сайтом-мишенью (например www.googletagmanager.com), но получает первый ответ от прокси-сервера; для DPI-наблюдателя весь handshake неотличим от обычного TLS к этому публичному сайту. Дополнительный поток xtls-rprx-vision уменьшает сигнатуры в content-stream.

Базовая конфигурация одного inbound на узле:

{
  "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:

{
  "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: 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). Все три — содержательно идентичны; в случае расхождения каноническая версия — русская.