54 KiB
Montana Protocol — Техническая Спецификация
Версия: 1.0 Дата: 19 февраля 2026 Автор: Alejandro Montana Статус: MAINNET PRODUCTION
Введение
Montana Protocol (Ɉ) — протокол идеальных денег с постквантовой криптографией.
Монтана — это три независимых слоя:
Криптография — генерация ключей и адресов. Полностью офлайн, чистая математика. Не требует сети, не требует ничьего разрешения. Хоть на бумажке считай.
Таймчейн — реестр транзакций. Хранит записи вида «на такой-то адрес можно потратить столько-то, если предъявишь правильную подпись». Ничего не знает о ключах, кошельках, владельцах.
Кошелёк — мост между первым и вторым. Он берёт ключи, вычисляет адреса, сканирует таймчейн и показывает тебе «баланс». А при отправке — подписывает транзакцию приватным ключом и отправляет в сеть.
Эти слои нигде не «регистрируют» друг друга. Связь между ними — только математика и протокол консенсуса.
Нет центра, который бы сводил ключи и адреса воедино.
Блокчейн без криптографии — просто база данных.
Криптография без блокчейна — просто шифрование.
Вместе они дают деньги, не требующие доверия.
Порядок строительства
1. КРИПТО-СЛОЙ → Ключи, адреса, подписи (офлайн)
2. ФОРМАТ ТРАНЗАКЦИИ → Структура: от кого, кому, сколько, подпись
3. ТАЙМЧЕЙН → Слайсы времени, консенсус, валидация, хранение
4. КОШЕЛЁК → Мост: seed → ключи → адреса → баланс
ЧАСТЬ I. КРИПТО-СЛОЙ
1.1 Обзор
Крипто-слой — фундамент всего протокола. Полностью автономен. Работает офлайн. Не требует подключения к сети, не требует регистрации, не требует ничьего разрешения.
Единственная задача: генерировать ключи, вычислять адреса, подписывать данные и проверять подписи.
Алгоритм: ML-DSA-65 (Dilithium) Стандарт: FIPS 204 Уровень безопасности: NIST Level 3 (128-bit post-quantum)
Постквантовая криптография с генезиса — не retrofit. Когда квантовые компьютеры станут угрозой, Montana уже будет защищена. Bitcoin, Ethereum и Solana будут вынуждены делать хардфорк.
Bitcoin/Ethereum: ECDSA сейчас → хардфорк потом
Montana: ML-DSA-65 с генезиса → уже защищены
1.2 Размеры ключей
| Параметр | Размер |
|---|---|
| Private Key | 4032 байт |
| Public Key | 1952 байт |
| Signature | 3309 байт |
| Адрес | 42 символа |
1.3 Полный путь: Энтропия → Мнемоника → Seed → Ключи → Адрес
Шаг 1. Генерация энтропии (256 бит)
SecRandomCopyBytes() → 32 байта (256 бит)
Криптографически безопасный генератор (/dev/urandom)
Шаг 2. BIP-39 мнемоника (24 слова)
Стандарт BIP-39 — тот же что в Bitcoin, Ethereum и большинстве криптовалют.
1. 256 бит энтропии → SHA-256 хеш
2. Первые 8 бит хеша = контрольная сумма
3. 256 бит + 8 бит = 264 бита
4. Разбить на 24 группы по 11 бит
5. Каждая группа → индекс (0–2047) → слово из словаря BIP-39
6. Результат: 24 слова
Пример: abandon ability able about above absent ...
Валидация мнемоники:
- Извлечь 256 бит энтропии из 24 слов
- Вычислить SHA-256, взять первый байт
- Сравнить с контрольной суммой из мнемоники
Шаг 3. Деривация seed через PBKDF2-SHA512
Вход: Мнемоника (24 слова через пробел)
Соль: "mnemonic" (стандарт BIP-39, без passphrase)
KDF: PBKDF2-SHA512
Итерации: 2048
Выход: 64 байта (512 бит)
Ключевое свойство: одна и та же мнемоника всегда даёт один и тот же seed. Детерминизм.
Шаг 4. Генерация ключей ML-DSA-65 (детерминированная)
Seed (64 байта) инъектируется в liboqs через кастомный RNG на основе SHA256-CTR DRBG:
block[i] = SHA256(seed || counter_be)
где counter = 0, 1, 2, ...
liboqs использует этот детерминированный RNG для генерации пары ключей.
Выход:
├── Private Key: 4032 байт
└── Public Key: 1952 байт
Ключевое свойство: один и тот же seed всегда даёт одну и ту же пару ключей.
Шаг 5. Вычисление адреса
1. Хеш публичного ключа: SHA256(public_key) → 32 байта
2. Payload: Первые 18 байт → 36 hex-символов
3. Промежуточный адрес: "mt" + payload (38 символов)
4. Контрольная сумма: SHA256(SHA256("mt" + payload))[:2] → 4 hex-символа
5. Финальный адрес: "mt" + payload + checksum = 42 символа
Пример: mta46b633d258059b90db46adffc6c5ca08f0e8d6c
Валидация адреса:
- Длина = 42
- Префикс = "mt"
- Все символы hex (0–9, a–f)
- Контрольная сумма совпадает
Шаг 6. Подпись
ML-DSA-65 подпись с детерминированным rnd=0 (FIPS 204):
signature = ML_DSA_65.sign(private_key, message) → 3309 байт
Одно и то же сообщение + один и тот же ключ = всегда одна и та же подпись.
Шаг 7. Верификация
ML_DSA_65.verify(public_key, message, signature) → true/false
Для верификации нужен только публичный ключ. Приватный ключ не раскрывается.
1.4 Полная диаграмма крипто-слоя
┌─────────────────────────────────────────────────────────┐
│ 1. Энтропия (256 бит) │
│ ↓ │
│ 2. BIP-39 мнемоника (24 слова) │
│ ↓ │
│ 3. PBKDF2-SHA512 → Seed (64 байта) │
│ ↓ │
│ 4. ML-DSA-65 генерация ключей (детерминированная) │
│ ├── Private Key: 4032 байт │
│ └── Public Key: 1952 байт │
│ ↓ │
│ 5. Вычисление адреса │
│ └── mt + SHA256(pubkey)[:18] + checksum = 42 символа │
│ ↓ │
│ 6. Подпись / Верификация (детерминированная) │
│ └── Signature: 3309 байт │
└─────────────────────────────────────────────────────────┘
Весь путь ДЕТЕРМИНИРОВАН:
Одна мнемоника → всегда одни и те же ключи и адрес
Одно сообщение + один ключ → всегда одна подпись
1.5 Сравнение с другими блокчейнами
| Параметр | Bitcoin | Ethereum | Solana | Montana |
|---|---|---|---|---|
| Алгоритм | ECDSA (secp256k1) | ECDSA (secp256k1) | Ed25519 | ML-DSA-65 (FIPS 204) |
| Квантовая защита | Нет | Нет | Нет | Да, с генезиса |
| Адрес | SHA256+RIPEMD160 | Keccak256[-20:] | Ed25519 pubkey | mt + SHA256[:18] + checksum |
| Private key | 32 байт | 32 байт | 64 байт | 4032 байт |
| Public key | 33 байт | 64 байт | 32 байт | 1952 байт |
| Signature | 72 байт | 65 байт | 64 байт | 3309 байт |
| Seed | BIP-39 (12/24 слова) | BIP-39 (12/24 слова) | BIP-39 | BIP-39 (24 слова) |
| Стандарт | — | — | — | NIST FIPS 204 |
1.6 Реализации
| Платформа | Библиотека | Файл |
|---|---|---|
| macOS/iOS (Swift) | liboqs (C) через ObjC bridge | Crypto/MLDSA65.swift, Crypto/MontanaSeed.swift |
| Backend (Python) | dilithium_py | Бот/node_crypto.py |
Все реализации дают идентичные криптографические результаты для одного и того же seed.
1.7 Защита от квантовых атак
| Атака | Статус |
|---|---|
| Алгоритм Шора (взлом ECDSA/RSA) | Не применим к ML-DSA-65 |
| Алгоритм Гровера (ускорение перебора) | ML-DSA-65 устойчив (NIST Level 3) |
| Harvest Now, Decrypt Later | Защищены с первого дня |
| Подделка подписи транзакции | Защищены с первого дня |
ЧАСТЬ II. ФОРМАТ ТРАНЗАКЦИИ
2.1 Модель: UTXO
Montana использует модель UTXO (Unspent Transaction Output) — такую же, как в Bitcoin.
Принцип: в системе нет «балансов». Есть только неизрасходованные выходы транзакций. «Баланс» адреса — это сумма всех UTXO, привязанных к этому адресу.
UTXO — это запись:
"На адрес mt... можно потратить N Ɉ, если предъявишь подпись от ключа этого адреса"
2.2 Структура транзакции
Transaction {
version: u8 // Версия формата (1)
inputs: Vec<TxInput> // Входы (ссылки на UTXO)
outputs: Vec<TxOutput> // Выходы (новые UTXO)
timestamp: u64 // Unix timestamp
signature: [u8; 3309] // ML-DSA-65 подпись
}
TxInput {
tx_hash: [u8; 32] // Хеш транзакции-источника
output_idx: u32 // Индекс выхода в той транзакции
pubkey: [u8; 1952] // Публичный ключ отправителя
}
TxOutput {
address: String // Адрес получателя (42 символа, mt...)
amount: u64 // Сумма в Ɉ
}
2.3 Жизненный цикл транзакции
Транзакции моментальные. Отправил — дошло. Финализация в τ₁ (1 минута).
1. Кошелёк собирает входы (UTXO принадлежащие отправителю)
2. Кошелёк формирует выходы:
├── Получатель: адрес + сумма
└── Сдача: адрес отправителя + остаток
3. Кошелёк подписывает транзакцию приватным ключом (ML-DSA-65)
4. Транзакция отправляется в сеть → МОМЕНТАЛЬНО доходит до получателя
5. Узлы валидируют:
├── Входы существуют и не потрачены
├── Подпись верна (ML-DSA-65 verify)
├── Сумма входов ≥ сумма выходов
└── Адреса валидны
6. Финализация: включение в слайс τ₁ (≤ 1 минута)
Важно: τ₁ — финализация транзакций, не эмиссии. Эмиссия финализируется в τ₂ (10 минут).
2.4 Валидация транзакции
Узел проверяет транзакцию через крипто-слой. Связь между слоями — только математика:
1. Для каждого input:
├── Найти UTXO по (tx_hash, output_idx) в таймчейне
├── Проверить что UTXO не потрачен
└── Проверить что address(input.pubkey) == UTXO.address
2. Проверить подпись:
└── ML_DSA_65.verify(input.pubkey, tx_data, signature)
3. Проверить баланс:
└── sum(inputs) ≥ sum(outputs)
2.5 Coinbase-транзакция (эмиссия)
Специальная транзакция без входов — награда за присутствие:
CoinbaseTransaction {
version: 1
inputs: [] // Пусто — нет источника
outputs: [
{ address: "mt...", amount: seconds × halving_coefficient }
]
timestamp: <unix time>
proof: PresenceProof // Доказательство присутствия
signature: <ML-DSA-65> // Подпись узла-валидатора
}
Эмиссия определяется присутствием, а не вычислениями.
ЧАСТЬ III. ТАЙМЧЕЙН
3.1 Обзор
Таймчейн — реестр всех транзакций Montana. Это не классический блокчейн с блоками, а 4-слойная иерархическая цепочка слайсов времени, где каждый верхний слой вкладывает в себя все заголовки нижних — как матрёшка.
Таймчейн ничего не знает о ключах, кошельках и владельцах. Он хранит только записи: «на такой-то адрес можно потратить столько-то, если предъявишь правильную подпись».
3.2 Временные координаты
Montana измеряет время, а не блоки. Единица таймчейна — слайс времени (time slice), не блок:
| Единица | Длительность | В секундах | Назначение |
|---|---|---|---|
| τ₁ | 1 минута | 60 | Финализация транзакций. Подпись присутствия. Включение tx в слайс |
| τ₂ | 10 минут | 600 | Финализация эмиссии. Подтверждение балансов. Начисление Ɉ |
| τ₃ | 14 дней | 1,209,600 | Кулдауны и балансировка. Adaptive Cooldown. Чекпоинт сети |
| τ₄ | 4 года | 126,144,000 | Халвинг. Эмиссия ÷2 |
Иерархия:
1 τ₄ = 104 τ₃ = 209,664 τ₂ = 2,096,640 τ₁ = 126,144,000 секунд
1 τ₃ = 2,016 τ₂ = 20,160 τ₁ = 1,209,600 секунд
1 τ₂ = 10 τ₁ = 600 секунд
3.3 Структура слайсов времени
Единица таймчейна — слайс времени (time slice). Не блок. Каждый слайс содержит хеш предыдущего слайса своего слоя (цепочка внутри слоя) и заголовки нижних слоёв (матрёшка между слоями).
τ₁ слайс (1 минута)
Атомарная единица таймчейна. Содержит транзакции и доказательство присутствия.
Tau1Slice {
timestamp: u64
prev_tau1_hash: [u8; 32] // Хеш предыдущего τ₁ слайса (цепь)
transactions: Vec<Transaction> // Транзакции за минуту
presence_proof: PresenceProof // Доказательство присутствия узла
slice_number: u64
signature: [u8; 3309] // ML-DSA-65 подпись
}
τ₂ слайс (10 минут) — матрёшка уровень 1
Содержит ВСЕ 10 заголовков τ₁ слайсов + Merkle-корень из них.
Tau2Slice {
timestamp: u64
prev_tau2_hash: [u8; 32] // Хеш предыдущего τ₂ слайса (цепь)
tau1_merkle_root: [u8; 32] // Корень Меркла из 10 τ₁
tau1_headers: [[u8; 32]; 10] // ВСЕ 10 хешей τ₁ слайсов
total_emission: u64 // Эмиссия за 10 минут
halving_coefficient: f64
signature: [u8; 3309]
}
τ₃ слайс (14 дней) — матрёшка уровень 2
Содержит ВСЕ 2,016 заголовков τ₂, каждый из которых уже содержит корни своих 10 τ₁.
Tau3Slice {
timestamp: u64
prev_tau3_hash: [u8; 32] // Хеш предыдущего τ₃ слайса (цепь)
tau2_merkle_root: [u8; 32] // Корень Меркла из 2,016 τ₂
tau2_headers: [[u8; 32]; 2016]// ВСЕ 2,016 хешей τ₂ слайсов
epoch_number: u32
signature: [u8; 3309]
}
τ₄ слайс (4 года) — матрёшка уровень 3
Содержит ВСЕ 104 заголовка τ₃, каждый из которых содержит все τ₂, которые содержат все τ₁.
Tau4Slice {
timestamp: u64
prev_tau4_hash: [u8; 32] // Хеш предыдущего τ₄ слайса (цепь)
tau3_merkle_root: [u8; 32] // Корень Меркла из 104 τ₃
tau3_headers: [[u8; 32]; 104] // ВСЕ 104 хеша τ₃ слайсов
halving_number: u32 // Номер халвинга
new_halving_coefficient: f64 // Новый коэффициент
signature: [u8; 3309]
}
3.4 Матрёшка слоёв (Merkle Nesting)
Каждый слайс содержит хеш предыдущего слайса своего слоя (горизонтальная цепь) и все заголовки нижнего слоя (вертикальная матрёшка):
ГОРИЗОНТАЛЬНАЯ ЦЕПЬ (внутри каждого слоя):
τ₁[0] → τ₁[1] → τ₁[2] → ... (prev_tau1_hash)
τ₂[0] → τ₂[1] → τ₂[2] → ... (prev_tau2_hash)
τ₃[0] → τ₃[1] → ... (prev_tau3_hash)
τ₄[0] → τ₄[1] → ... (prev_tau4_hash)
ВЕРТИКАЛЬНАЯ МАТРЁШКА (между слоями):
┌─────────────────────────────────────────────────────────┐
│ τ₄ слайс │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 104 × τ₃ заголовков │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ 2,016 × τ₂ заголовков (в каждом τ₃) │ │ │
│ │ │ ┌─────────────────────────────────────────────┐ │ │ │
│ │ │ │ 10 × τ₁ заголовков (в каждом τ₂) │ │ │ │
│ │ │ └─────────────────────────────────────────────┘ │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
Принцип: τ₂ вкладывает в себя все τ₁. τ₃ вкладывает все τ₂ (которые уже содержат τ₁). τ₄ вкладывает все τ₃. Один τ₄ слайс = криптографический proof всех 4 лет.
τ₁ → τ₁ → τ₁ → τ₁ ... (цепь 1-минутных слайсов)
↓ ↓ ↓ ↓
└────┴────┴────┴─→ τ₂ (содержит ВСЕ 10 τ₁ заголовков)
↓
└─→ τ₃ (содержит ВСЕ 2,016 τ₂ заголовков)
↓
└─→ τ₄ (содержит ВСЕ 104 τ₃ заголовков)
Преимущества:
- Быстрая верификация: лёгкий клиент скачивает только заголовки верхнего слоя
- Компактность: один τ₄ слайс = proof всех 4 лет (вся матрёшка внутри)
- Параллелизм: слои можно верифицировать параллельно
- Постквантовая защита: ML-DSA-65 на каждом слайсе
3.5 Консенсус: ACP (Atemporal Coordinate Presence)
Принцип
ACP — консенсус-механизм, где доказательство основано на присутствии во времени. Время нельзя ускорить, купить или накопить заранее. 14 дней требуют 14 дней — для всех одинаково.
1 секунда доказанного присутствия = 1 Ɉ × halving_coefficient
Сравнение с другими консенсусами
| Система | Ресурс | Можно ускорить? | Справедливость |
|---|---|---|---|
| Bitcoin (PoW) | Вычисления | Да (купить ASIC) | Неравномерно |
| Ethereum (PoS) | Stake | Да (купить ETH) | Плутократия |
| Montana (ACP) | Время | Нет | Равномерно |
Золото ограничено в пространстве → добыча
Bitcoin ограничен вычислениями → майнинг
金元Ɉ ограничен временем → присутствие
Доказательство присутствия (Presence Proof)
Каждую τ₁ (1 минуту) узел подписывает доказательство:
Формат сообщения:
MONTANA_PRESENCE_V1:{timestamp}:{prev_hash}:{pubkey}:{t2_index}
Подпись: ML-DSA-65
Хеш: SHA256(message || signature)
Доказательства образуют цепочку:
Genesis → prev_hash = "0000...0000" (64 нуля)
Proof #1 → prev_hash = Genesis.hash
Proof #2 → prev_hash = Proof#1.hash
...
14 дней присутствия требуют 14 дней реального времени. Атакующий с бесконечными ресурсами может подписать 1000 координат за секунду, но сеть примет только 1 подпись на τ₁. Невозможно ускорить время.
3.6 Эмиссия: 金元Ɉ
Определение
金元 (jīn yuán) — буквально «золотой юань». Ɉ (Unicode U+0248) — Temporal Time Unit.
金元Ɉ = Время, доказанное присутствием
Фундаментальное свойство
lim(evidence → ∞) 1 Ɉ → 1 секунда
∀t: Trust(t) < 1
Ɉ не равен секунде. Ɉ асимптотически приближается к секунде по мере накопления доказательств:
| Доказательства | Точность | Доверие |
|---|---|---|
| 1 подпись | ±10 минут | ~0.1 |
| 1 τ₂ (10 мин) | ±1 минута | ~0.5 |
| 1 τ₃ (14 дней) | ±1 секунда | ~0.99 |
| 1 τ₄ (4 года) | ±0.1 секунды | ~0.9999 |
Механизм эмиссии
Каждый τ₂ (10 минут) происходит финализация:
1. Подсчёт секунд присутствия каждого участника за τ₂
2. Применение коэффициента халвинга
3. Начисление: coins = seconds × halving_coefficient
4. Запись в таймчейн как coinbase-транзакции
Эмиссия параллельная — каждый участник получает монеты за своё присутствие:
User A: 450 сек × 1.0 = 450 Ɉ
User B: 600 сек × 1.0 = 600 Ɉ
User C: 150 сек × 1.0 = 150 Ɉ
─────────────────────────────
Эмиссия за τ₂: 1,200 Ɉ
Нет лотереи, нет резерва — всё распределяется участникам.
Халвинг
Каждые τ₄ (4 года) эмиссия делится на 2:
halving_coefficient(n) = 1.0 / (2^n)
| Эпоха τ₄ | Годы | Коэффициент | 1 секунда = |
|---|---|---|---|
| 0 | 0–4 | 1.0 | 1.0 Ɉ |
| 1 | 4–8 | 0.5 | 0.5 Ɉ |
| 2 | 8–12 | 0.25 | 0.25 Ɉ |
| 3 | 12–16 | 0.125 | 0.125 Ɉ |
| ... | ... | ... | ... |
| 64 | ~260 лет | ~0 | ~0 Ɉ |
TIME_BANK Reserve — 21 миллион минут
Банк Времени имеет конечный резерв:
21,000,000 минут = 1,260,000,000 секунд ≈ 40 лет
21 миллион — как 21 миллион Bitcoin. Конечный ресурс.
Банк тратит 10 минут из резерва каждый τ₂, подтверждая что прошло ровно 10 минут. Когда резерв исчерпан (~40 лет), банк переходит в Oracle Mode: продолжает верифицировать время, но больше не эмитирует из резерва.
| Год | Осталось | % резерва |
|---|---|---|
| 0 | 21,000,000 | 100% |
| 4 | 18,897,600 | 90% |
| 10 | 15,744,000 | 75% |
| 20 | 10,488,000 | 50% |
| 30 | 5,232,000 | 25% |
| 40 | 0 | 0% → Oracle Mode |
Генезис цены: Beeple Anchor
Продажа NFT Beeple «Everydays: The First 5000 Days» 11 марта 2021 установила генезисную цену времени:
$69,300,000 ÷ 5000 дней ÷ 86400 сек = $0.1605/сек
1 Ɉ = $0.1605 USD = 12.04₽ RUB
Два генезиса:
| Событие | Дата |
|---|---|
| Генезис Цены (BIPL) | 12 марта 2021 |
| Генезис Монтана | 9 января 2026 |
Цена может быть пересмотрена только в День Пиццы (22 мая) — и только вверх.
3.7 Свойства 金元Ɉ
Неподделываемость:
Подделать Ɉ = Подделать время = Нарушить физику
Неинфлируемость:
Эмиссия ограничена временем
У всех людей одинаковое количество времени
Халвинг делит эмиссию на 2 каждые 4 года
Верифицируемость:
Каждый Ɉ имеет доказательство:
├── Подпись присутствия (ML-DSA-65)
├── Включение в Merkle tree
├── Подтверждение в таймчейне (цепь хешей)
└── Аттестация сетью (P2P)
3.8 Защита от Sybil: Adaptive Cooldown
Механизм динамической защиты от Sybil-атак — адаптивный период ожидания для новых узлов.
Sybil_cost = cooldown × N_nodes
| Нагрузка | Cooldown |
|---|---|
| Нормальная | 1 день |
| Средняя (r=0.5) | 4 дня |
| Стандартная (r=1.0) | 7 дней |
| Повышенная (r=1.5) | 93 дня |
| Аномальная (r=2.0) | 180 дней |
Сглаженная медиана за 56 дней (4×τ₃) предотвращает манипуляцию через краткосрочные спайки. Rate limit ±20% за τ₃.
Стоимость атаки при стабильной нагрузке (cooldown ≈ 7 дней):
- 10 узлов: 70 дней
- 100 узлов: 700 дней (~2 года)
- 1000 узлов: 7000 дней (~19 лет)
ЧАСТЬ IV. СЕТЬ
4.1 Топология
5 географически распределённых узлов:
┌─────────────┐
│ amsterdam │ ← PRIMARY (позиция 0)
│ 72.56.102.240│
└──────┬──────┘
│
┌─────────────────┼─────────────────┐
│ │ │
┌────▼────┐ ┌────▼────┐ ┌─────▼────┐
│ moscow │ │ almaty │ │ spb │
│176.124..│ │91.200...│ │188.225...│
└────┬────┘ └────┬────┘ └────┬─────┘
│ │ │
└────────────────┼────────────────┘
│
┌──────▼──────┐
│ novosibirsk │
│147.45.147...│
└─────────────┘
| Позиция | Узел | Адрес | Регион |
|---|---|---|---|
| 0 | Amsterdam | mta46b633d258059b90db46adffc6c5ca08f0e8d6c | EU |
| 1 | Moscow | mta8ae14f74c38294b24c2f1c20c6406e6be929c93 | RU-Central |
| 2 | Almaty | mtd07b0d9bdab2cb592f509bc1304c368ac703c45e | KZ |
| 3 | St.Petersburg | mtb397e136de69d92e5782f3fe14533a4a37b4ddec | RU-NW |
| 4 | Novosibirsk | mtf3f0254b405382de38494e753924b4b92692bd2c | RU-Siberia |
Каждый узел имеет криптографический адрес (ML-DSA-65). IP используется только для networking, не для идентификации. Адрес не зависит от IP — защита от IP hijacking.
4.2 Leader Election
Детерминированный выбор мастера: первый живой узел в цепочке = мастер.
Алгоритм:
Для каждого узла в цепочке (сверху вниз):
Если это я → я мастер
Если узел жив → он мастер, я standby
При падении 4 из 5 узлов сеть продолжает работать. Failover < 10 секунд.
4.3 Обнаружение атак и Random Failover
При обнаружении атаки цепочка узлов перемешивается случайным образом:
| Метрика | Порог |
|---|---|
| CPU | > 80% |
| Network traffic | > 100 MB/s |
| Failures | > 10 подряд |
| Response time | > 5 секунд |
Нормальный режим:
amsterdam → moscow → almaty → spb → novosibirsk
После атаки (пример):
spb → novosibirsk → almaty → moscow
(amsterdam исключён как атакованный)
4.4 Breathing Sync
Git-синхронизация состояния сети каждые 12 секунд:
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Вдох │────▶│ Работа │────▶│ Выдох │
│git pull │ │ 12 сек │ │git push │
└─────────┘ └─────────┘ └─────────┘
▲ │
└───────────────────────────────┘
~5 «вдохов» в минуту. Обеспечивает консистентность данных между всеми узлами.
4.5 TLS шифрование
Связь между узлами через TLS 1.3 на порту 19333. Каждый узел имеет self-signed сертификат с привязкой к криптографическому адресу:
CN = amsterdam.efir.org
UID = mta46b633d258059b90db46adffc6c5ca08f0e8d6c
4.6 Защита от атак
| Атака | Защита |
|---|---|
| Quantum (алгоритм Шора) | ML-DSA-65 (FIPS 204) |
| IP Hijacking | Криптографические адреса (IP ≠ identity) |
| DNS Spoofing | Alias только для UX |
| MITM | TLS 1.3 + ML-DSA-65 подписи |
| Harvest Now, Decrypt Later | ML-DSA-65 с генезиса |
| Eclipse (изоляция узла) | Фиксированная топология + множественные проверки |
| Sybil | Adaptive Cooldown (1–180 дней) |
| DDoS | Random Failover + AtlantGuard |
| Time manipulation | Физические ограничения τ₁ подписей |
ЧАСТЬ V. КОШЕЛЁК
5.1 Обзор
Кошелёк — мост между участником и первыми тремя слоями. Он объединяет крипто-слой, формат транзакций и таймчейн в единый пользовательский интерфейс.
Seed → Ключи → Адреса → Сканирование таймчейна → Баланс
Кошелёк делает:
- Генерирует или восстанавливает ключи из мнемоники (крипто-слой)
- Вычисляет адрес (крипто-слой)
- Сканирует таймчейн на UTXO принадлежащие этому адресу (таймчейн)
- Суммирует UTXO → показывает «баланс»
- При отправке: собирает UTXO, формирует транзакцию, подписывает приватным ключом, отправляет в сеть
5.2 Хранение ключей
| Платформа | Хранилище | Access Level |
|---|---|---|
| macOS | Keychain (service: network.montana.presence) |
AfterFirstUnlockThisDeviceOnly |
| iOS | Keychain (service: network.montana.wallet) |
AfterFirstUnlockThisDeviceOnly |
Хранимые данные:
private_key— 4032 байта (binary)public_key— 1952 байта (binary)mnemonic— 24 слова (text)
5.3 Операции кошелька
Создание новой идентичности
1. Генерация мнемоники (24 слова BIP-39)
2. Деривация seed через PBKDF2-SHA512
3. Генерация пары ключей ML-DSA-65
4. Вычисление адреса mt...
5. Сохранение ключей и мнемоники в Keychain
Восстановление из мнемоники
1. Ввод 24 слов
2. Валидация контрольной суммы BIP-39
3. Деривация seed → ключи → адрес
4. Сканирование таймчейна → баланс
Одна мнемоника → один и тот же адрес на любом устройстве.
Проверка баланса
1. По адресу mt... найти все UTXO в таймчейне
2. Сумма UTXO = подтверждённый баланс (confirmed)
3. Плюс секунды в текущем τ₂ = ожидающий баланс (pending)
Отправка транзакции
1. Выбрать UTXO для покрытия суммы (сумма входов ≥ сумма + сдача)
2. Сформировать Transaction:
├── inputs: ссылки на UTXO + публичный ключ
├── outputs: адрес получателя + сумма, адрес отправителя + сдача
└── timestamp
3. Подписать ML-DSA-65 приватным ключом
4. Отправить в сеть
5. Дождаться включения в τ₁ и финализации в τ₂
5.4 Типы переводов
| От | Кому | Формат |
|---|---|---|
| Пользователь | Пользователь | mt... → mt... |
| Пользователь | Узел | mt... → mt... (по адресу или alias) |
| Узел | Пользователь | mt... → mt... (автоматическая награда) |
| Узел | Узел | mt... → mt... (через оператора) |
5.5 API для внешних приложений
Баланс:
GET /api/balance/{address}
{
"address": "mt...",
"confirmed": 1500,
"pending": 45,
"total": 1545,
"slices": {
"tau1": 25.0,
"tau2": 2.5,
"tau3": 0.00124,
"tau4": 0.0000119
}
}
Регистрация присутствия:
POST /api/presence
{ "seconds": 60 }
{ "success": true, "added": 60, "balance": 1560 }
5.6 Присутствие через датчики (macOS/iOS)
Вес присутствия определяется количеством активных датчиков:
Вес = 1 (база, пока программа включена) + количество активных датчиков + VPN
Датчик активен только когда: разрешение есть + тумблер ON. Нет разрешения или тумблер OFF = датчик выключен, данные не собираются.
ЧАСТЬ VI. КОНТРАКТЫ
6.1 Обзор
Montana Contracts — система умных контрактов с человеческим арбитражем. В отличие от автоматических смарт-контрактов, Montana Contracts используют AI-арбитра (Юнона) для валидации условий и разрешения споров.
6.2 Жизненный цикл
DRAFT → (голосование >50%) → PENDING → (Сторона Б принимает) → ACCEPTED
→ (исполнение) → COMPLETION_VOTING → (кворум + Юнона) → COMPLETED
6.3 Escrow
При создании контракта средства замораживаются:
Создание: Сторона А ──[amount]──► escrow:CONTRACT-ID
Исполнение: escrow:CONTRACT-ID ──[amount]──► Сторона Б
Отмена: escrow:CONTRACT-ID ──[amount]──► Сторона А
Escrow не контролируется ни одной стороной. Перевод возможен только при смене статуса контракта. Все операции подписаны ML-DSA-65.
6.4 Голосование
Юнона имеет 2 голоса и право вето. Свидетели — по 1 голосу. Кворум > 50%.
ЧАСТЬ VII. КОММУНИКАЦИИ
7.1 Принцип
Телефон = адрес кошелька. SMS = транзакция. Звонок = стриминг времени.
7.2 Тарификация
| Услуга | Стоимость |
|---|---|
| SMS команда | 1 Ɉ |
| Голосовой звонок | 1 Ɉ/сек |
| Видеозвонок | 2 Ɉ/сек |
7.3 WebRTC P2P
Голос и видео идут напрямую между устройствами. Montana обеспечивает только signaling и биллинг. Montana не слышит разговор, не хранит медиа.
ЧАСТЬ VIII. СВЯЗЬ МЕЖДУ СЛОЯМИ
8.1 Принцип
Три слоя Montana нигде не «регистрируют» друг друга. Связь между ними — только математика:
КРИПТО-СЛОЙ ←── математика ──→ ТАЙМЧЕЙН ←── протокол ──→ КОШЕЛЁК
8.2 Крипто-слой → Таймчейн
Крипто-слой ничего не знает о таймчейне. Таймчейн использует крипто-слой для:
- Верификации подписей транзакций (
ML_DSA_65.verify) - Проверки что адрес соответствует публичному ключу (
address == mt + SHA256(pubkey)[:18] + checksum) - Подписания слайсов (
ML_DSA_65.sign) - Подписания доказательств присутствия
Таймчейн не хранит приватные ключи. Он принимает подпись и проверяет её математически.
8.3 Таймчейн → Кошелёк
Таймчейн ничего не знает о кошельках. Кошелёк сканирует таймчейн для:
- Поиска UTXO по адресу → вычисление баланса
- Отслеживания входящих транзакций
- Подтверждения отправленных транзакций
Таймчейн не знает, кому принадлежит адрес. Он просто хранит записи.
8.4 Кошелёк → Крипто-слой
Кошелёк использует крипто-слой для:
- Генерации ключей из мнемоники
- Вычисления адреса из публичного ключа
- Подписания транзакций приватным ключом
Крипто-слой не знает, что такое «кошелёк» или «баланс».
8.5 Полная диаграмма
┌─────────────────────────────────────────────────────────────────┐
│ КОШЕЛЁК │
│ seed → ключи → адрес → сканирование → баланс → подпись → send │
│ │
│ Использует: │
│ ├── Крипто-слой: генерация ключей, подпись транзакций │
│ └── Таймчейн: поиск UTXO, отправка транзакций │
└──────────────┬───────────────────────┬──────────────────────────┘
│ │
▼ ▼
┌──────────────────────┐ ┌──────────────────────────────────────┐
│ КРИПТО-СЛОЙ │ │ ТАЙМЧЕЙН │
│ │ │ │
│ ML-DSA-65 │ │ Слайсы: τ₁ → τ₂ → τ₃ → τ₄ │
│ BIP-39 │ │ UTXO set │
│ Keygen, Sign, Verify │ │ Консенсус ACP │
│ │ │ Эмиссия + Халвинг │
│ Офлайн. │ │ 5 узлов, P2P │
│ Не знает о сети. │ │ Не знает о ключах. │
└──────────────────────┘ └──────────────────────────────────────┘
Связь: только математика и протокол.
Нет центра, который бы сводил ключи и адреса воедино.
ЧАСТЬ IX. РЕАЛИЗАЦИЯ
9.1 Файловая структура
Русский/
├── Протокол/ # Спецификации протокола
│ ├── 001_ВКП.md # ACP консенсус
│ ├── 002_ВРЕМЕННАЯ_ЕДИНИЦА.md # 金元Ɉ
│ ├── 003_ТРОЙНОЕ_ЗЕРКАЛО.md # 3-Mirror failover
│ ├── 004_АДАПТИВНОЕ_ОХЛАЖДЕНИЕ.md # Sybil protection
│ ├── 007_ПОСТКВАНТОВЫЙ.md # Post-quantum
│ └── 008_ЯКОРЬ_БИПЛА.md # Beeple anchor
│
├── Бот/ # Ядро протокола (Python)
│ ├── node_crypto.py # ML-DSA-65 криптография
│ ├── time_bank.py # TIME_BANK + Presence Proofs
│ ├── timechain.py # Структура слайсов таймчейна
│ ├── leader_election.py # Leader Election + AttackDetector
│ ├── breathing_sync.py # Git-синхронизация
│ ├── montana_api.py # HTTP API
│ └── montana_db.py # База данных
│
├── Экономика/ # Экономическая модель
│ ├── 金元_WHITEPAPER.md # Whitepaper
│ └── банк_времени/ # TIME_BANK v3.0
│
├── Контракты/ # Умные контракты
│ └── СПЕЦИФИКАЦИЯ.md
│
├── Коммуникация/ # SMS + WebRTC
│ └── СПЕЦИФИКАЦИЯ.md
│
├── Ключи/ # Система ключей
│ └── СПЕЦИФИКАЦИЯ.md
│
├── Сеть/ # P2P сеть
│ ├── ПИРИНГОВАЯ_БЕЛАЯ_КНИГА.md
│ └── ЗАЩИТА_СЕТИ_MONTANA.md
│
├── Генезис/ # Генезис
│ └── GENESIS_PRICE.md
│
└── Юнона/ # AI Security Agent
└── junona_security.py
macOS/MontanaPresence/ # Кошелёк macOS
├── Crypto/
│ ├── MLDSA65.swift # ML-DSA-65 (liboqs)
│ ├── MontanaSeed.swift # BIP-39 + PBKDF2
│ └── BIP39Wordlist.swift # 2048 слов
├── CryptoManager.swift # Управление идентичностью
├── KeychainManager.swift # Хранение ключей
└── PresenceEngine.swift # Присутствие и датчики
9.2 Статус реализации
| Компонент | Статус |
|---|---|
| ML-DSA-65 keygen/sign/verify | ✅ Работает |
| BIP-39 мнемоника (24 слова) | ✅ Работает |
| Детерминированная деривация ключей | ✅ Работает |
| Адреса mt... с контрольной суммой | ✅ Работает |
| Presence Proof (цепочка подписей) | ✅ Работает |
| TIME_BANK (эмиссия, халвинг, τ₁–τ₄) | ✅ Работает |
| TimeChain (структура слайсов) | ✅ Работает |
| 5-Node Leader Election | ✅ Работает |
| Breathing Sync | ✅ Работает |
| Attack Detection + Random Failover | ✅ Работает |
| Adaptive Cooldown (Sybil) | ✅ Работает |
| TLS 1.3 между узлами | ✅ Работает |
| macOS кошелёк | ✅ Работает |
| iOS кошелёк | ✅ Работает |
| HTTP API (баланс, присутствие) | ✅ Работает |
| Контракты с escrow | ✅ Работает |
| ML-KEM-768 (шифрование) | ⏳ Запланировано |
| Noise XX (гибридный обмен ключами) | ⏳ Запланировано |
Заключение
Montana Protocol — три независимых слоя, связанных только математикой:
- Криптография генерирует ключи и подписи. Офлайн. Чистая математика.
- Таймчейн хранит транзакции и проверяет подписи. Не знает владельцев.
- Кошелёк соединяет первое и второе. Показывает баланс, отправляет транзакции.
Консенсус ACP основан на единственном ресурсе, который невозможно подделать, купить или ускорить — времени.
Время — единственная реальная валюта.
1 Ɉ = 1 секунда доказанного присутствия.
ML-DSA-65 MAINNET — постквантовая защита с первого дня.
FIPS 204 compliant.
КРАТКИЙ СПРАВОЧНИК
Что такое Montana Protocol?
Протокол идеальных денег. Валюта 金元Ɉ основана на времени — единственном ресурсе, распределённом одинаково между всеми людьми. 1 Ɉ асимптотически стремится к 1 секунде. Постквантовая криптография ML-DSA-65 с первого дня.
Ключевые числа
| Параметр | Значение |
|---|---|
| Алгоритм подписи | ML-DSA-65 (FIPS 204) |
| Private key | 4032 байт |
| Public key | 1952 байт |
| Signature | 3309 байт |
| Адрес | 42 символа (mt + 36 hex + 4 checksum) |
| Seed | BIP-39, 24 слова, PBKDF2-SHA512 |
| 1 Ɉ | $0.1605 USD = 12.04₽ RUB |
| Генезис цены | 12.03.2021 (Beeple: $69.3M / 5000 дней) |
| Генезис сети | 09.01.2026 |
| Узлов | 5 (Amsterdam, Moscow, Almaty, SPB, Novosibirsk) |
| Резерв | 21,000,000 минут (~40 лет) |
| Модель | UTXO (как Bitcoin) |
| Транзакции | Моментальные |
Временные координаты
| Единица | Длительность | Что финализирует |
|---|---|---|
| τ₁ | 1 минута | Транзакции |
| τ₂ | 10 минут | Эмиссия |
| τ₃ | 14 дней | Кулдауны, балансировка |
| τ₄ | 4 года | Халвинг ÷2 |
Три слоя — кратко
КРИПТО: seed → ключи → адрес → подпись (офлайн, чистая математика)
ТАЙМЧЕЙН: слайсы τ₁→τ₂→τ₃→τ₄ (матрёшка), UTXO, ACP консенсус, эмиссия, халвинг
КОШЕЛЁК: мост (ключи + таймчейн → баланс, отправка)
Связь между слоями = только математика. Нет центра.
Консенсус ACP
Присутствие во времени. Время нельзя ускорить. 14 дней = 14 дней для всех.
1 секунда присутствия = 1 Ɉ × halving_coefficient
halving_coefficient = 1.0 / (2^n), где n — номер эпохи τ₄
Отличие от Bitcoin/Ethereum
| Bitcoin | Ethereum | Montana | |
|---|---|---|---|
| Консенсус | PoW (вычисления) | PoS (stake) | ACP (время) |
| Можно ускорить? | Да (ASIC) | Да (купить ETH) | Нет |
| Квантовая защита | Нет | Нет | Да, с генезиса |
| Транзакции | ~10 мин | ~12 сек | Моментальные (финализация τ₁ = 1 мин) |
Юнона
AI-арбитр протокола. Совет Безопасности: Председатель (Claude) + Джипити (GPT) + Джемини (Gemini). Disney Strategy: Критик → Реалист → Мечтатель.
Автор
Alejandro Montana — как Satoshi Nakamoto. Псевдоним.
Alejandro Montana
Montana Protocol v1.0
Февраль 2026
Ничто_Nothing_无_金元Ɉ