Коротко: Arch Network строит среду для программируемых приложений, которые взаимодействуют с Bitcoin-активами и используют Bitcoin для расчётов. Программы выполняются в ArchVM на базе eBPF, а dPoS-валидаторы применяют threshold-подписи семейства FROST/ROAST для операций с UTXO. Это отдельный исполнительный слой, а не запуск произвольных смарт-контрактов внутри каждого узла Bitcoin. Между вычислением, подписью и окончательным подтверждением в Bitcoin есть отдельные компоненты и риски.
Какую проблему решает Arch
Bitcoin поддерживает проверяемую передачу UTXO, но его скриптовая модель намеренно ограничивает сложные приложения. DeFi-протоколам, рынкам и программируемым кошелькам нужны логика, состояние и взаимодействие между контрактами. Обычно для этого BTC оборачивают или переносят в другую сеть, где работают смарт-контракты. При этом доверие к мосту становится частью риска пользователя.
Arch предлагает иной подход: отдельную среду исполнения и сеть валидаторов, которая может выполнять программы и создавать Bitcoin-транзакции, расходующие реальные UTXO. По описанию проекта, изменения состояния приводятся к транзакциям Bitcoin, подписанным пороговой схемой участников, и отправляются в базовую сеть. Это позволяет строить приложения с расчётом в Bitcoin, не превращая BTC в обычный ERC-20-токен.
«Использует Bitcoin» всё же не означает «работает без дополнительной инфраструктуры». Программа исполняется участниками Arch, а её результат должен пройти предусмотренный протоколом процесс проверки, подписи и публикации. Для сравнения полезно посмотреть, чем отличаются виды rollup-сетей, и отдельно выяснить, где именно выполняется логика конкретного продукта.
ArchVM и модель исполнения
ArchVM основана на eBPF – виртуальной машине, применяемой в системном программном обеспечении для безопасного запуска ограниченного кода. В Arch она служит средой исполнения программ. Такой выбор отличается от EVM и влияет на язык, инструменты компиляции, модель ресурсов и возможности отладки. Разработчику недостаточно знать Solidity: нужно проверять совместимость конкретного приложения и инструментария с ArchVM.
У приложения есть состояние, которое обслуживается инфраструктурой Arch, а результат операций должен отражаться в Bitcoin-транзакциях или связанных с UTXO действиях. Разница между внутренним состоянием среды и тем, что уже подтверждено Bitcoin, важна для пользователя. Пока транзакция не включена в блок, экономический результат может зависеть от валидаторов, текущей очереди и правил протокола.
Для сложных программ важны ограничения на вычисления, доступные системные вызовы, политика обновления и управление состоянием. Любая из этих частей может стать источником ошибок. Не делайте вывод о безопасности приложения только из названия виртуальной машины; проверяйте аудит программы и то, какие полномочия есть у её администраторов.
Валидаторы, FROST и ROAST
Arch описывает модель делегированного Proof of Stake: участники валидируют сеть и могут участвовать в создании пороговой подписи. Threshold-подпись позволяет нескольким участникам совместно сформировать подпись, соответствующую общему ключу, при этом индивидуальные доли ключа не должны раскрываться полностью. FROST – протокол пороговых подписей, а ROAST предназначен для повышения устойчивости коалиционного подписания при участниках, которые могут вести себя некорректно или отвечать с задержкой.
Такая схема помогает избегать хранения полного приватного ключа в одном месте и может связывать подпись транзакции с правилами сети. Но она не устраняет необходимость доверять корректности реализации, достаточному числу честных участников и доступности порога подписантов. Если участники недоступны, операция может задержаться; если порог контролируется сговором или уязвимостью, последствия зависят от ограничений UTXO и способов восстановления.
Пороговая криптография не является автоматической гарантией отсутствия кастодиального риска. Пользователю важно понять, кто выбирает валидаторов, как меняется набор, какие стимулы и санкции применяются, кто может обновлять код и что происходит при потере кворума. Эти вопросы особенно важны для активов, блокировка или расходование которых зависит от группового ключа.
Settlement в Bitcoin и взаимодействие с UTXO
Документация Arch описывает Bitcoin как слой расчётов: изменения состояния могут оформляться транзакциями, которые валидаторы подписывают и передают в Bitcoin. Активы при этом связаны с реальными UTXO, а не только с записью о токене в иной сети. Это может сократить некоторые виды обёртывания, однако добавляет зависимость от доступности Bitcoin, комиссий, структуры транзакций и правил расходования выходов.
Settlement требует времени и комиссии базовой сети. Если Bitcoin перегружен или выбранная транзакция имеет недостаточную ставку, подтверждение может задержаться. При этом состояние приложения Arch и уже подтверждённое состояние Bitcoin могут расходиться по времени. Поэтому приложения должны аккуратно обрабатывать ожидание, повторную отправку и конфликтные операции.
Обычный UTXO можно потратить только при выполнении заложенных условий. В связанной с Arch конструкции пользователь должен знать, кто инициирует транзакцию, кто подписывает её, какие ограничения применяются и как вывести актив при проблемах валидаторской сети. Инструкция о том, как проверять UTXO и комиссию Bitcoin, полезна для оценки базового слоя перед взаимодействием с приложением.
Приложения и риски сети
Arch может быть интересна разработчикам финансовых приложений, которым нужен программируемый доступ к Bitcoin-активам без простой модели обёрнутого токена. Возможные сценарии включают кредитование, торговлю, условные выплаты и кошельки с дополнительными правилами. Реальная доступность зависит от текущих приложений, ликвидности, поддержки кошельков и статуса mainnet-функций.
Перед внесением средств проверяйте адрес контракта, фактический маршрут BTC, форму пользовательского подтверждения и возможность выхода при остановке приложения. Если актив передаётся в управление программе, изучите ограничения UTXO и администраторские ключи. Для кредитного протокола отдельно оцените оракул, процедуру ликвидации и доступность резервной ликвидности.
В публичных материалах нельзя автоматически считать наличие токена обязательным или приписывать ему конкретную функцию, если это не подтверждено актуальными документами. Не покупайте актив по обещаниям будущего запуска или неофициальному тикеру. Даже официальный токен не заменяет понимание, какие участники обеспечивают работу сети и как их поведение связано с безопасностью средств.
Основные компромиссы Arch – дополнительная гибкость исполнения при зависимости от отдельного набора валидаторов и подписантов, а также привязка расчётов к реальным Bitcoin-транзакциям с их комиссиями и временем подтверждения. Модель может подойти приложениям, которым важны UTXO и settlement в Bitcoin, но её следует оценивать по полному пути транзакции. Проверьте, где исполняется код, как формируется подпись, что именно записывается в Bitcoin и как пользователь восстановит доступ при отказе одного из компонентов.
