1191 lines
54 KiB
Markdown
1191 lines
54 KiB
Markdown
# 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 τ₃ заголовков)
|
||
```
|
||
|
||
**Преимущества:**
|
||
1. Быстрая верификация: лёгкий клиент скачивает только заголовки верхнего слоя
|
||
2. Компактность: один τ₄ слайс = proof всех 4 лет (вся матрёшка внутри)
|
||
3. Параллелизм: слои можно верифицировать параллельно
|
||
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 → Ключи → Адреса → Сканирование таймчейна → Баланс
|
||
```
|
||
|
||
Кошелёк делает:
|
||
1. Генерирует или восстанавливает ключи из мнемоники (крипто-слой)
|
||
2. Вычисляет адрес (крипто-слой)
|
||
3. Сканирует таймчейн на UTXO принадлежащие этому адресу (таймчейн)
|
||
4. Суммирует UTXO → показывает «баланс»
|
||
5. При отправке: собирает 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 — три независимых слоя, связанных только математикой:
|
||
|
||
1. **Криптография** генерирует ключи и подписи. Офлайн. Чистая математика.
|
||
2. **Таймчейн** хранит транзакции и проверяет подписи. Не знает владельцев.
|
||
3. **Кошелёк** соединяет первое и второе. Показывает баланс, отправляет транзакции.
|
||
|
||
Консенсус 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_无_金元Ɉ
|
||
```
|