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

Версия: черновик 1.0 Базовый источник: Montana Protocol v35.25.0 §Прикладной слой, Montana App v3.12.0

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

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

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

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

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

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

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

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

3. Anchor

Anchor — операция, которая вписывает 32-байтный хеш во временну́ю координату. Стоимость:

Один Anchor занимает место в окне τ₁ (конкуренция за лотерею).
Цена в TC = по правилу §"Граница протокола и клиентского слоя".

Применение:

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

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

См. §"Полная экономическая картина" + 03 Экономика.

Кратко:

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

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

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

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

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

Узел хранит:

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

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

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

Прикладные интеграции описаны в основной спецификации §"Интеграция":

iOS клиент (см. iOS/Apps/Montana)
macOS узел (см. macOS)
CLI инструменты (см. CLI)

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

Чёткое разделение: что в протоколе (зафиксировано на уровне консенсуса) vs что в клиенте (свободно реализуемо). Полное описание в основной спецификации, но ключевое:

В протоколе: подписи, AccountChain-операции, VDF, лотерея, Anchor.
В клиенте: UX, индексирование истории, восстановление ключей, шифрование локального хранилища.

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

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

10. Источники

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

6.4 KiB Raw Permalink Blame History Unescape Escape