8764f7ac74
Кандидат получает всю эмиссию окна admission (13 Ɉ); Active в это окно эмиссии не получает; 1 кандидат/окно строго; closed-form supply сохраняется. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
242 lines
24 KiB
Markdown
242 lines
24 KiB
Markdown
# 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": "<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**: 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`). Все три — содержательно идентичны; в случае расхождения каноническая версия — русская.*
|