montana/Монтана-Протокол/Архив/TimeChain v10.0.0.md

# TimeChain — Спецификация протокола Montana

**Версия:** 10.0.0 (2026-03-30)

## Определение

Децентрализованная сеть. Время — единственная реальная валюта. 1 секунда присутствия узла в сети = 1 Ɉ.

Консенсус: **Proof of Time (PoT)** — последовательное SHA-256 хэширование (VDF) как доказательство прошедшего времени. Один криптографический примитив — SHA-256. Временные окна возникают из вычислений.

Генезис: 09.01.2026 00:00:00 MSK.

---

## Криптография

Единственный примитив — SHA-256. Подписи, адреса, консенсус, Merkle-деревья построены на SHA-256.

Квантовая устойчивость обеспечивается природой хэш-функции: алгоритм Гровера сокращает безопасность с 256 до 128 бит.

### Подписи — WOTS+ (Winternitz One-Time Signature)

Хэш-подпись на SHA-256. Каждый ключ используется однократно — одна подпись на один UTXO. Приватный ключ представляет собой начальные значения хэш-цепочек. Подпись содержит промежуточные точки цепочек, позиция которых кодирует подписываемое сообщение. Подпись математически привязана к конкретной транзакции.

Параметр w=256:

| Компонент | Размер |
|-----------|--------|
| Приватный ключ (seed) | 32B |
| Публичный ключ (сжатый) | 32B |
| Подпись | 1 120B |

Деривация ключей: `secret_n = SHA-256("montana-tx" || seed || n)`. Один seed (32B) порождает цепочку одноразовых ключей через инкрементальный counter.

### Адреса

Формат: `mt` + Base58(SHA-256(pubkey) + checksum). Деривация ключей и адресов описана в разделе «Ключи».

---

## Транзакции — UTXO модель

Модель неизрасходованных выходов. Каждая транзакция потребляет существующие UTXO и создаёт новые.

### Формат транзакции

| Компонент | Размер |
|-----------|--------|
| WOTS+ подпись | 1 120B |
| UTXO reference (tx_hash + index) | 36B |
| Выходы (2 × (address 49B + amount 8B)) | 114B |
| Slot index | 4B |
| **Итого** | **~1.3 KB** |

Вход: WOTS+ подпись (привязана к данным транзакции) + ссылка на UTXO.
Выход: адрес получателя + сумма.

### Верификация баланса

sum(входы) = sum(выходы) + fee. Каждый узел проверяет баланс арифметическим сложением.

Dust limit: каждый выход ≥ 1 Ɉ (MINIMUM_UTXO).

### Комиссия

Комиссия = разница между суммой входов и суммой выходов. Минимум 1 mɈ (миллисекунда). Размер адаптивный — рассчитывается по формуле на основе заполненности окон τ₁. Пользователь знает комиссию до отправки.

Победитель окна τ₂ получает сумму всех комиссий транзакций в окне.

### UTXO

Формат: `{address, amount, tx_hash, output_index}`.

UTXO существует до момента траты. Трата фиксируется использованием WOTS+ подписи. Повторная трата исключена конструкцией данных.

### Coinbase

Победитель τ₂ создаёт coinbase-транзакцию. Входов нет. Выходы содержат эмиссию за τ₂ + сумму комиссий всех транзакций окна.

Supply audit при финализации τ₂: суммарная эмиссия coinbase от генезиса сверяется с расчётной по формуле халвинга.

---

## Таймчейн

Три логических двигателя с односторонним потоком зависимостей: Beacon → Service → Execution.

### Beacon — глобальные часы протокола

Непрерывная последовательная SHA-256 цепочка. Общий источник случайности и ритм сети:

```
B_r = SHA-256^D(B_{r-1})
```

D — количество последовательных хэшей за один слот τ₁. Beacon продвигается по расписанию финализированных слотов. Для фиксированного индекса r значение B_r совпадает у всех честных узлов. Каждый узел вычисляет Beacon независимо — результат детерминирован.

Beacon не зависит от состояния, транзакций и поведения отдельных узлов.

### Service — персональный VDF узла

Доказательство непрерывного присутствия конкретного node_id. Якорится в Beacon каждый слот:

```
S_{i,s,0}   = SHA-256(S_{i,s-1,m} || B_s || node_id_i)
S_{i,s,j+1} = SHA-256(S_{i,s,j})    для j = 0..m-1
```

Три компонента seed: предыдущий endpoint (непрерывность службы), значение Beacon (протокольное время), node_id (идентичность). m последовательных хэшей за слот — доказательство работы.

Service зависит от Beacon. Beacon не зависит от Service.

### Execution — содержимое блока

Приём, верификация транзакций (WOTS+ подписи, баланс) и формирование канонического набора.

Транзакция получает Inclusion Certificate (IC) когда её наличие подтверждено подписанными чекпоинтами суммарного веса >2/3 active set. Канонический набор τ₂ состоит из всех транзакций с валидным IC, полученным до cutoff последнего слота окна. Канонический порядок: (earliest_certified_slot, txid). Конфликты UTXO разрешаются правилом first valid in canonical order wins.

Победитель лотереи собирает блок механически по этим правилам, добавляя coinbase. Отклонение от правил — невалидный блок, переход ко второму месту. Любой узел независимо вычисляет тот же набор и тот же порядок.

Execution зависит от Beacon и Service. Обратных зависимостей нет.

С ростом TPS сети дополнительные ядра подключаются для верификации транзакций. Минимум для валидатора: 3 логических ядра (Beacon + Service + Execution).

### Чекпоинт

Каждый валидатор в каждом слоте τ₁ публикует подписанный чекпоинт:

```
CP_{i,s} = Sig_i(epoch, slot, B_s, S_{i,s,m}, tx_root_{i,s})
```

Чекпоинт связывает протокольное время (B_s), доказательство службы (S_{i,s,m}) и локальную картину транзакций (tx_root) в одну подписанную аттестацию.

### Входной барьер — Adaptive Cooldown

Допуск к консенсусу определяется Adaptive Cooldown — динамическим входным периодом, чувствительным к темпу роста сети.

#### Формула

Скользящее окно из 3 последних τ₃ (42 дня). Темп роста — процент новых регистраций от количества активных узлов. Медиана трёх последних значений определяет норму:

```
growth_rate = new_registrations_in_τ₃ / active_nodes_at_start × 100%
median = median(growth_rate за 3 предыдущих τ₃)
excess = ((current_growth - median) / median) × 100%

excess ≤ 0%:          cooldown = 7 дней
0% < excess ≤ 100%:   cooldown = 7 + excess × 35 / 100
excess > 100%:        cooldown = 42 дня
```

Минимум 7 дней. Максимум 42 дня (3 × τ₃).

Bootstrap: `effective_median = max(median, 1%)`, `effective_active = max(active_nodes, 10)`.

#### Асимметрия

Повышение cooldown — немедленное, без ограничений. Снижение — не быстрее 20% за τ₃. Атака поднимает барьер мгновенно. Возврат к норме занимает месяцы.

#### Реакция внутри τ₃

Cooldown пересчитывается в реальном времени по проекции темпа на конец окна:

```
projected_growth = current_registrations / elapsed_fraction
elapsed_fraction = elapsed_slots / total_slots_in_τ₃
```

Счётчик регистраций детерминирован: считаются только сертифицированные регистрации (с IC) в каноническом порядке (slot, txid).

#### Фиксация

Cooldown закрепляется за узлом в момент регистрации. Пересчёт не меняет cooldown уже зарегистрированным узлам.

#### Во время cooldown

Узел запускает Beacon + Service VDF сразу при регистрации. Валидирует транзакции, ретранслирует данные, публикует чекпоинты. Узел усиливает сетевой слой и несёт стоимость допуска к консенсусу. Стоимость каждого Sybil-узла: 1 service-core непрерывно на весь период cooldown.

#### После cooldown

Вес начинается с 0 и растёт линейно с каждым подписанным τ₂. Работа во время cooldown полезна сети, но не конвертируется в консенсусный вес.

---

## Потоковая модель транзакций

Транзакции текут непрерывно. Узел получает транзакцию → проверяет подпись и баланс → передаёт в P2P gossip. Время подтверждения определяется скоростью интернета отправителя и P2P-распространением (~2-5 секунд).

Транзакция включается в канонический набор τ₂ при получении Inclusion Certificate (>2/3 активного веса подтвердили через чекпоинты). Транзакции не ожидают появления τ₁ или τ₂ — окна являются чекпоинтами, а не условиями приёма.

---

## Временные слои (τ)

```
τ₁ (≈60с) → τ₂ (10 × τ₁) → τ₃ (2016 × τ₂) → τ₄ (~104 × τ₃)
```

### τ₁ — Слот (≈60 секунд)

- Beacon продвигается на D хэшей
- Service VDF продвигается на m хэшей с якорем в текущем B_s
- Валидаторы публикуют подписанные чекпоинты CP_{i,s}
- Узлы обмениваются чекпоинтами и транзакциями по P2P
- Транзакции набирают Inclusion Certificates

### τ₂ — Финализация и эмиссия (10 × τ₁ ≈ 10 минут)

- Active set (состав и веса участников) фиксируется в начале τ₂
- Канонический набор: все транзакции с валидным IC до cutoff последнего слота
- Лотерея: `ticket_i = S_{i,final,m} / weight_i`, победитель = min(ticket_i) среди допущенных
- Победитель публикует proposal блока (канонический набор TX + coinbase)
- Финальность: Quorum Certificate (QC) на заголовок блока от >2/3 активного веса
- Seed следующей эпохи: `seed_i = SHA-256(B_r || active_set_root_r || node_id_i)`
- Coinbase: вся эмиссия + все комиссии → победителю
- Supply audit: суммарная эмиссия coinbase от генезиса сверяется с расчётной
- Разрешение форков: приоритет ветки с наибольшим суммарным Beacon-доказательством

Beacon safety: компрометация значения Beacon требует нарушения свойства последовательности SHA-256 VDF или подделки finality certificate порогом >2/3 активного веса.

Beacon liveness: задержка продвижения Beacon требует блокировки finality порогом >1/3 активного веса.

### τ₃ — Адаптация (2016 × τ₂ ≈ 14 дней)

- Калибровка D и m: медиана слотовых интервалов сверяется с целевыми, цель τ₁ ≈ 60 секунд
- UTXO Merkle Root: включается в заголовок последнего τ₂, ратифицируется QC
- Криптографическая амнезия: тела транзакций и WOTS+ подписи старше 8 × τ₃ удаляются. Цепочка заголовков τ₂ (Beacon, QC hash, UTXO root, tx root) сохраняется навсегда
- Вызов архивных узлов: retention audit по случайному историческому блоку, архивный узел предоставляет данные + Merkle proof
- Пересчёт параметров окна τ₁

### τ₄ — Халвинг (~104 × τ₃ ≈ 4 года)

- Коэффициент эмиссии делится на 2

---

## Консенсус — Proof of Time (PoT)

### Три двигателя

**Beacon** — глобальные часы. Чистая VDF-цепочка `B_r = SHA-256^D(B_{r-1})`. Источник случайности для лотереи. Продвигается по расписанию финализированных слотов.

**Service** — персональный VDF. Якорится в Beacon каждый слот. Доказывает непрерывное присутствие node_id. Определяет вес и лотерейный билет.

**Execution** — содержимое блока. Канонический набор TX определяется Inclusion Certificate (>2/3 активного веса). Порядок детерминирован. Победитель собирает блок механически.

Зависимости односторонние: Beacon → Service → Execution. Отказ в Execution не заражает случайность. Отказ конкретного узла в Service не заражает общий ритм.

### Стаж и вес

#### Определение

Вес узла — длина его непрерывной Service цепочки, измеренная в подписанных τ₂:

```
weight_i = min(chain_length_i, MAX_WEIGHT)
MAX_WEIGHT = количество τ₂ в одном τ₄ (~105 000)
```

Вес — единственная мера влияния узла в протоколе. Определяется только временем непрерывной службы.

#### Как растёт

Цепочка растёт на 1 за каждый τ₂ с засчитанным участием. Участие в τ₂ засчитывается при публикации не менее k валидных чекпоинтов из n слотов окна (k=8, n=10). Чекпоинт валиден при выполнении условий: подписан ключом node_id, содержит корректные epoch и slot, якорится в соответствующий Beacon slot, получен сетью до конца следующего слота.

#### Обрыв

Если узел за период τ₃ отработал менее 1613 из 2016 окон τ₂ — цепочка обрывается, weight = 0. Узел начинает копить длину заново. Adaptive Cooldown повторно не проходится (node_id уже зарегистрирован).

#### Три зоны

- **Cooldown (7-42 дня):** допуск закрыт, weight = 0, узел работает как валидатор и ретранслятор
- **После cooldown — 4 года:** weight растёт линейно с каждым подписанным τ₂
- **4+ года (≥ τ₄):** weight = MAX_WEIGHT, потолок

Потолок τ₄ предотвращает бесконечный рост преимущества ранних участников. Все цепочки старше 4 лет равны между собой.

#### На что влияет вес

Вес определяет три вещи:

**1. Лотерея.** Вероятность победы в τ₂ пропорциональна весу:

```
ticket_i = S_{i,final,m} / weight_i
winner = min(ticket_i)
P(node_i) = weight_i / Σ weight(all_nodes)
```

Больше вес → меньше ticket → выше шанс. Узел с weight = 0 не участвует в лотерее.

**2. Голосовая сила в консенсусе.** Inclusion Certificate и Quorum Certificate считаются по весу, а не по количеству узлов:

```
IC валиден:  Σ weight(подтвердивших) > 2/3 × Σ weight(active_set)
QC валиден:  Σ weight(подписавших)   > 2/3 × Σ weight(active_set)
```

Голос узла в IC и QC пропорционален его weight. Sybil-атака через 1000 свежих узлов (weight ≈ 0 каждый) не даёт голосовой силы. Для контроля консенсуса атакующий должен накопить >1/3 суммарного веса сети — это годы непрерывной службы.

**3. Допуск.** weight = 0 означает: узел участвует в сети (валидация, ретрансляция), но не участвует в лотерее и не имеет голосовой силы в IC/QC.

### Победитель τ₂

Победитель определяется после закрытия окна τ₂. Каждый узел раскрывает свой Service VDF endpoint. Минимальный ticket среди допущенных — победитель (формула в разделе «На что влияет вес»).

Победитель публикует proposal блока: канонический набор TX (определён IC) + coinbase. Содержимое блока детерминировано правилами IC и каноническим порядком. Свобода победителя в формировании блока: ноль.

Финальность блока возникает после QC на заголовок от >2/3 активного веса.

### Верификация

Победитель публикует: `{node_id, Service checkpoints[], proposal}`.

Верификация Service VDF: пересчёт K сегментов параллельно. K ≈ 960. На C ядрах: ~(K/C) × t_segment секунд. 8 ядер → ~7.5 сек. 64 ядра → ~1 сек.

Верификация proposal: независимый расчёт канонического набора по IC и сравнение с proposal.

### Устойчивость

- **Proposer grinding** исключён: победитель не выбирает состав блока, канонический набор определяется IC (>2/3 активного веса)
- **Committee grinding** исключён: Beacon не зависит от состояния и транзакций, seed лотереи строится из Beacon
- **Node_id гриндинг** исключён: Adaptive Cooldown (7-42 дня), Beacon неизвестен при регистрации
- **Предвычисление** исключено: seed содержит текущее значение Beacon
- **Replay** исключён: Beacon уникален для каждого τ₂
- **Аппаратное преимущество** ограничено: последовательное хэширование масштабируется тактовой частотой и IPC, а не количеством ядер или бюджетом
- **Sybil-барьер**: Adaptive Cooldown (7-42 дня, асимметричный) + Service VDF (физическое ядро) + линейный рост веса от нуля
- **Аристократия** ограничена: потолок веса τ₄, после 4 лет все равны

---

## Адреса и переводы

### Полный флоу перевода

```
1. Боб: кошелёк генерирует keypair_7 → address_7
2. Боб → Алисе: "отправь на mt4ZGfe..." (address_7)
3. Алиса формирует транзакцию:
   Вход:  UTXO на 80 Ɉ (address_3)
   Выход: 50 Ɉ → address_7 (Бобу)
   Выход: 30 Ɉ → address_12 (сдача, новый адрес)
4. Алиса подписывает WOTS+ (привязано к выходам)
5. Алиса рассылает транзакцию узлам сети
6. Каждый узел проверяет:
   WOTS+ подпись валидна для pubkey address_3 ✓
   80 = 50 + 30 ✓
7. Транзакция распространяется через P2P gossip
8. Транзакция получает IC (>2/3 валидаторов подтвердили в чекпоинтах)
9. При финализации τ₂: UTXO address_3 потрачен
10. Созданы UTXO: 50 Ɉ @ address_7, 30 Ɉ @ address_12
```

### Баланс

Кошелёк деривирует все адреса из seed, сканирует UTXO set. Сумма непотраченных UTXO = баланс.

Бэкап = seed (32 байта).

---

## Эмиссия

### Единица

1 секунда Montana = 1 $MONT = 1 Ɉ = 1 000 mɈ = 1 000 000 μɈ = 1 000 000 000 nɈ

Точность: 9 знаков после запятой (наносекунда).

`lim(t → ∞) 1 Ɉ → 1 секунда`. Халвинг делает Ɉ дефицитнее, секунды идут с постоянной скоростью. Чем дальше от генезиса, тем ценнее каждый Ɉ, тем ближе он к реальной секунде.

| Параметр | Значение |
|----------|----------|
| Генезис | 09.01.2026 00:00:00 MSK |
| Эмиссия за τ₂ | 50 минут (3 000 Ɉ) |
| Халвинг | ÷2 каждые τ₄ |
| TIME_BANK | 21 000 000 минут (~40 лет) |
| После истощения | Oracle Mode (верификация) |

| Эпоха | Годы | Эмиссия за τ₂ |
|-------|------|--------------|
| τ₄ #0 | 0-4 | 50 мин (3 000 Ɉ) |
| τ₄ #1 | 4-8 | 25 мин (1 500 Ɉ) |
| τ₄ #2 | 8-12 | 12.5 мин (750 Ɉ) |
| τ₄ #3 | 12-16 | 6.25 мин (375 Ɉ) |

### Распределение

Победитель τ₂ получает всю эмиссию + все комиссии окна. Один выход в coinbase.

### Якорь цены — Bitcoin

```
1 BTC = block_interval ÷ block_reward
1 BTC = 600 ÷ 3.125 = 192 Ɉ (эпоха 2024-2028)
```

| Эпоха | Награда за блок | 1 BTC = Ɉ |
|-------|----------------|-----------|
| 2024-2028 | 3.125 BTC | 192 |
| 2028-2032 | 1.5625 BTC | 384 |
| 2032-2036 | 0.78125 BTC | 768 |

Константа между халвингами. Справочная привязка, протокол функционирует автономно.

---

## Пропускная способность

Размер транзакции: ~1.3 KB.

| Канал узла | TPS |
|-----------|-----|
| 10 Mbps | ~960 |
| 100 Mbps | ~9 600 |
| 1 Gbps | ~96 000 |

### Адаптивный размер окна

Пересчёт в τ₃:

- Заполненность > 80% → увеличение размера окна
- Заполненность < 20% → уменьшение размера окна
- Шаг: ±20% за τ₃
- Диапазон: 1 MB — 100 MB

---

## Хранение

| TPS | Архивный (20 лет) | Полный (112 дней) | Pruned | SPV |
|-----|-------------------|-------------------|--------|-----|
| 7 | ~6 TB | ~80 GB | ~15 GB | ~1 GB |
| 100 | ~88 TB | ~1.1 TB | ~15 GB | ~1 GB |
| 960 | ~850 TB | ~10.5 TB | ~15 GB | ~1 GB |

| Тип узла | Содержимое | Лотерея |
|----------|-----------|---------|
| Полный | Скользящее окно 8 × τ₃ + UTXO set + заголовки | weight × 1 |
| Архивный | Полная история от генезиса | weight × 1 + archive reward |
| Pruned | UTXO set + заголовки + UTXO snapshots τ₃ | Наблюдатель |
| SPV | Заголовки + собственные транзакции | Наблюдатель |

Узел самостоятельно выбирает тип. Участие в лотерее: полный или архивный узел. Архивные узлы получают отдельную archive reward за прохождение retention audit.

### Fast Sync (новый узел)

1. Цепочка заголовков τ₂ от генезиса — проверка Beacon-цепочки и QC (мегабайты)
2. UTXO Merkle Root из последнего τ₃
3. UTXO snapshot — проверка SHA-256(snapshot) == UTXO Merkle Root (гигабайты)
4. Транзакции с подписями за последние 112 дней (скользящее окно)
5. Узел синхронизирован и готов к участию

---

## Ключи

```
seed (32B)
├── Транзакции: SHA-256("montana-tx" || seed || counter)
└── Идентификатор узла: SHA-256("montana-node" || seed)
```

Все деривации — SHA-256.

---

## Зависимости

| Библиотека | Назначение |
|------------|------------|
| `hashlib` (stdlib) | SHA-256 |
| `sqlite3` (stdlib) | Хранение |
| `socket` (stdlib) | P2P сеть |

Base58, Merkle-деревья, WOTS+, VDF — собственная реализация. Production: C/Rust.

---

## Архитектура

```
┌─────────────────────────────────┐
│  Wallet                         │
│  Кошелёк, баланс, переводы     │
└──────────────┬──────────────────┘
               │
┌──────────────┴──────────────────┐
│  TimeChain                      │
│                                 │
│  Beacon ──→ Service ──→ Execution
│  (часы)    (служба)   (состояние)
│                                 │
│  τ₁/τ₂/τ₃/τ₄, UTXO, IC, QC   │
│  WOTS+, SHA-256, Base58        │
└─────────────────────────────────┘
```