87 lines
6.4 KiB
Markdown
87 lines
6.4 KiB
Markdown
|
# Прикладной слой Монтаны
|
|||
|
|
|
|||
|
|
**Версия:** черновик 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).
|