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

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