Разработка решений на BitVM
Проблема звучит так: у вас есть Bitcoin с его security и liquidity, но вы не можете выполнить произвольную логику на его базе без доверенных посредников. Multisig решает часть задач, но как только логика усложняется — HTLC, условные выплаты, верификация ZK-proof — приходится либо уходить в сайдчейн с иной моделью безопасности, либо оборачивать BTC в ERC-20 и работать в EVM-среде с кастодиальными рисками. BitVM меняет это уравнение: он даёт возможность выполнять произвольные вычисления с верификацией на Bitcoin L1, не меняя консенсус сети.
Как работает BitVM: не просто "смарт-контракты на Bitcoin"
Термин "смарт-контракты" применительно к BitVM технически некорректен — в Bitcoin нет EVM. BitVM (предложен Робином Лэнусом в октябре 2023, развит в BitVM2 в 2024) реализует optimistic execution с fraud proof верификацией.
Базовый принцип:
- Prover утверждает результат вычисления и публикует commitment — Merkle-дерево состояний программы
- Verifier может бездействовать (по умолчанию считает результат корректным) или инициировать challenge
- В случае challenge начинается bisection protocol: оппоненты итеративно сужают спор до единственной NAND-операции, которую можно верифицировать через Bitcoin Script
- Нечестный prover теряет залог
BitVM2 упрощает модель: любой наблюдатель может быть verifier (не только designated), и challenge period сжимается с нескольких раундов до двух транзакций. Это критично для практического применения.
Что реально исполняется on-chain vs off-chain
Распространённое заблуждение: BitVM не "запускает программы" на Bitcoin. Исполнение всегда off-chain — программа выполняется prover'ом локально. Bitcoin L1 задействуется только в случае спора, и только для верификации одной битовой операции. Это фундаментальное отличие от Ethereum, где execution происходит on-chain каждый раз.
Практическое следствие: BitVM-решения оптимальны для low-frequency, high-value операций — кросс-чейн бриджи, верификация ZK-proof, условные выплаты с complex logic. Они не подходят для high-throughput приложений типа DEX или игр, где каждый пользователь генерирует транзакции.
Архитектура BitVM-моста: самый востребованный use case
BitVM-мост между Bitcoin и другими сетями — сейчас наиболее зрелый production use case. Проектов несколько: BitVM Bridge (Robin Linus), BitlayerLabs, Citrea.
Схема trustless withdrawal
Bitcoin L1:
- Locked BTC в multisig (Federation N-of-M)
- Pre-signed transactions с taproot scriptpath
L2/Sidechain:
- Пользователь сжигает wrapped BTC
- Генерируется withdrawal proof (ZK или optimistic)
Verifier Network:
- Проверяет proof
- Если валиден → подписывает release transaction на L1
- Если невалиден → публикует fraud proof, активирует challenge
Ключевой компонент — pre-signed transaction graph. Перед деплоем моста все участники (Federation) подписывают Taproot транзакции для всех возможных путей исполнения. Это требует одноразовой интерактивной сессии между участниками, после чего мост работает автоматически.
Taproot и его роль в BitVM
Без Taproot (BIP-341/342, активирован в ноябре 2021) BitVM был бы невозможен. Taproot позволяет:
- Script trees: один адрес скрывает до 2^128 возможных скриптов, revealing только исполненный путь
- Schnorr signatures: линейно комбинируются (MuSig2), что критично для эффективных multisig
- Script size: каждый leaf скрипт может быть до 520 байт, что достаточно для NAND-верификации
В BitVM-мосте типичная структура taproot дерева выглядит так:
Internal Key: MuSig2(federation_keys)
├── Script Leaf 1: normal_withdrawal (federation_threshold_sig + timelock)
├── Script Leaf 2: challenge_response (verifier_sig + proof_data)
├── Script Leaf 3: fraud_proof (challenger_sig + bisection_result)
└── Script Leaf N: timeout_refund (prover_sig + CSV_timelock)
Реализация: стек инструментов
Написание BitVM программ
BitVM программы компилируются в circuit — набор NAND/OR gate'ов, представляемых как Bitcoin Script. Основные инструменты:
bitcoin-script (Rust crate) — низкоуровневая работа со скриптами. Большинство BitVM реализаций используют его.
BitVM Rust SDK (BitVM Alliance) — высокоуровневые абстракции для написания circuits. На момент 2024-2025 активно разрабатывается, API нестабилен — важно пиннить версию.
Groth16/PLONK verifier circuits — для BitVM-моста нужна верификация ZK-proof в Bitcoin Script. Это самая сложная часть: native Bitcoin Script крайне ограничен по операциям, поэтому ZK верификатор разбивается на тысячи NAND gate'ов.
Инфраструктура для разработки
# Локальная Bitcoin regtest сеть
bitcoind -regtest -txindex=1 -rpcuser=user -rpcpass=pass
# или через docker
docker run -d --name bitcoin-regtest \
-p 18443:18443 \
ruimarinho/bitcoin-core \
-regtest -txindex -rpcallowip=0.0.0.0/0
# Esplora для индексирования
docker run -d electrs --network regtest
Тестирование BitVM требует transaction simulation — нужно проверить что pre-signed transaction graph консистентен, все скрипты удовлетворяются, timelock'и корректны. Мы используем кастомный harness на Python поверх bitcoinlib + python-bitcointx.
Обработка transaction pinning
Критическая проблема для BitVM: если challenger транслирует fraud proof транзакцию, злоумышленник может pin её с минимальным fee, блокируя подтверждение. Защита:
- CPFP (Child Pays For Parent) якоря во всех транзакциях спора
- Package relay (Bitcoin Core 26.0+) — позволяет транслировать связанные транзакции как пакет
- Размер anchor output: 240 sats (dust threshold в 2024)
Экономика и ограничения
Реальные transaction costs
Типичный BitVM bridge withdrawal (без спора):
- 1–2 on-chain транзакции
- Размер: ~500-1500 байт с Taproot witness
- При feerate 50 sat/vB: $5–15 на withdrawal
С challenge (fraud proof):
- До 10–20 транзакций в bisection протоколе
- Общий размер: 10-50KB
- Стоимость: $100–500 при высоком feerate
- Challenger теряет все транзакционные costs, prover теряет залог — экономическая безопасность держится на асимметрии
Актуальные ограничения
Нет Script introspection — Bitcoin Script не может читать поля собственной транзакции (TXID, inputs, outputs). Обходится через pre-commitment, но усложняет архитектуру. OP_CAT (если активируется) решит часть этих проблем.
Размер witness data — сложные circuits генерируют witness транзакции по нескольку МБ. Майнеры принимают, но propagation через сеть медленнее.
Latency — challenge period для безопасности должен быть достаточным (7–14 дней для trustless withdrawal, аналогично Optimistic Rollup). Для UX это проблема — большинство использует ликвидность liquidity providers с fast withdrawal за комиссию.
Federation assumptions — большинство текущих реализаций требуют N-of-M federation. Истинно trustless (1-of-N) пока в разработке.
Процесс разработки и сроки
| Компонент | Сложность | Срок |
|---|---|---|
| Архитектура и circuit дизайн | Высокая | 3–4 нед |
| Bitcoin Script / Taproot transactions | Высокая | 4–6 нед |
| Off-chain prover/verifier | Средняя | 3–4 нед |
| L2-сторона (smart contract) | Средняя | 2–3 нед |
| Интеграционное тестирование (regtest) | Высокая | 2–3 нед |
| Security review | Критическая | 3–5 нед |
Реалистичный минимум для production-grade BitVM bridge: 4–6 месяцев. Проекты, обещающие меньше, как правило, имеют federation с высоким trust assumption или не-production качество кода. Текущий landscape BitVM — всё ещё frontier инженерия: документации мало, большинство знаний живёт в исходниках и Discord (BitVM Alliance, стек BitVM2 от Robin Linus).