# Прикладной слой Монтаны

**Версия:** черновик 1.0
**Базовый источник:** [Montana Protocol v35.25.0 §Прикладной слой](../../Монтана-Протокол/Montana%20Protocol%20v35.25.0.md), [Montana App v3.12.0](../../Монтана-Протокол/Montana%20App%20v3.12.0.md)

## 1. Принципиальное отличие от EVM-цепей

Монтана **не имеет** виртуальной машины общего назначения (нет EVM, WASM-runtime для произвольных программ). Это сознательное архитектурное решение:

- VM общего назначения превращает блокчейн в bottleneck общего вычисления, ломает масштабируемость.
- Атаки через смарт-контракты (re-entrancy, integer overflow, oracle manipulation) — крупный класс уязвимостей DeFi — устранены конструктивно.
- Sandboxing, gas model, determinism — все решённые проблемы EVM не возникают, потому что не возникает сам слой.

Что **есть** в Монтане — фиксированный набор операций над AccountChain, плюс механизм Anchor для встраивания внешних приложений в каноническое время.

## 2. Модель приложения на Монтане

Согласно §"Модель приложения на Монтана":

1. **Приложение живёт вне цепи** (на любых стандартных серверах, в облаке, на устройстве).
2. **Приложение использует Anchor** — записывает хеш своего состояния в TimeChain через каноническую координату.
3. **Любой может проверить** что состояние было зафиксировано не позже определённого окна τ₁.
4. **Доказательство канонической позиции** — компактное (см. §"Доказательство канонической позиции").

Этим Монтана даёт прикладным разработчикам только то, что блокчейн действительно нужен: глобально согласованное упорядочение событий во времени с криптографической верификацией.

## 3. Anchor

Anchor — операция, которая вписывает 32-байтный хеш во временну́ю координату. Стоимость:
- Один Anchor занимает место в окне τ₁ (конкуренция за лотерею).
- Цена в TC = по правилу §"Граница протокола и клиентского слоя".

Применение:
- Документирование событий с привязкой к настенному времени (медиа, юриспруденция, наука).
- Notarization без traditional oracle (само время — оракул).
- Дополнительные L2-приложения, использующие Монтану как timestamping слой.

## 4. Экономика прикладного слоя

См. §"Полная экономическая картина" + [03 Экономика](../03%20Экономика/).

Кратко:
- Приложение покупает Anchor → платит TC → стимулирует операторов.
- Спрос на Anchor → спрос на TC → устойчивая экономика.

## 5. Двигатель роста сети через AccountChain

Согласно §"Двигатель роста сети через AccountChain":

- Каждый новый аккаунт → новая цепь → больше нагрузки на сеть.
- Но: anti-Sybil гарантирует что новые аккаунты создаются с реальной временной стоимостью.
- Рост сети органичен и масштабируется со временем, не с капиталом.

## 6. Локальное хранилище узла

Узел хранит:
- Свою собственную NodeChain
- Подписки на AccountChain (выбираются клиентом)
- Снапшот корня состояния

Полную глобальную историю узел НЕ обязан хранить — fast-sync через корень состояния (см. §"Быстрая синхронизация (новый узел)").

## 7. Интеграция

Прикладные интеграции описаны в основной спецификации §"Интеграция":
- iOS клиент (см. [iOS/Apps/Montana](../../iOS/Apps/Montana/))
- macOS узел (см. [macOS](../../macOS/))
- CLI инструменты (см. [CLI](../../CLI/))

## 8. Граница протокола и клиентского слоя

Чёткое разделение: что в протоколе (зафиксировано на уровне консенсуса) vs что в клиенте (свободно реализуемо). Полное описание в основной спецификации, но ключевое:
- В протоколе: подписи, AccountChain-операции, VDF, лотерея, Anchor.
- В клиенте: UX, индексирование истории, восстановление ключей, шифрование локального хранилища.

## 9. Открытые вопросы

- [ ] Спецификация Anchor-формата для типичных use-case (notarization, audit log).
- [ ] Стандарт интеграции для прикладных разработчиков (SDK).
- [ ] Анализ совместимости с L2-решениями (rollups, channels) если они появятся.

## 10. Источники

1. Montana App v3.12.0.
2. Buterin, V. (2014). *Ethereum: A Next-Generation Smart Contract Platform* (для контекста сравнения с VM-цепями).
3. Atzei, N., Bartoletti, M., Cimoli, T. (2017). *A Survey of Attacks on Ethereum Smart Contracts* (обоснование выбора без VM).