Розробка рішень на BitVM

Розробка рішень на BitVM

Проблема звучить так: у вас є Bitcoin із його безпекою та ліквідністю, але ви не можете виконувати довільну логіку на його основі без довіреного посередника. Multisig вирішує частину завдань, але як тільки логіка ускладнюється — HTLC, умовні платежі, верифікація ZK-proof — доводиться або переходити на sidechain з іншою моделлю безпеки, або обертати BTC в ERC-20 і працювати в EVM-середовищі з кастодіальними ризиками. BitVM змінює це рівняння: він дає можливість виконувати довільні обчислення з верифікацією на Bitcoin L1, не змінюючи консенсус мережі.

Як працює BitVM: не просто "смарт-контракти на Bitcoin"

Термін "смарт-контракти" стосовно BitVM технічно некоректний — у Bitcoin немає EVM. BitVM (запропонований Робіном Ленусом у жовтні 2023, розвинений у BitVM2 у 2024) реалізує оптимістичне виконання з верифікацією fraud proof.

Базовий принцип:

1. Prover стверджує результат обчислення та публікує commitment — дерево Меркла станів програми
2. Verifier може бездіяльнувати (за замовчуванням вважає результат коректним) або ініціювати виклик
3. Якщо виклик — починається bisection protocol: опоненти ітеративно звужують спір до однієї NAND-операції, яку можна верифікувати через Bitcoin Script
4. Нечесний prover втрачає свій залог

BitVM2 спрощує модель: будь-який спостерігач може бути verifier (не лише визначений), і період challenge стискується з кількох раундів до двох транзакцій. Це критично для практичного застосування.

Що дійсно виконується on-chain vs off-chain

Поширене неправильне уявлення: BitVM не "запускає програми" на Bitcoin. Виконання завжди off-chain — програма виконується локально prover'ом. Bitcoin L1 залучається лише у разі спору, і лише для верифікації однієї бітової операції. Це фундаментальна відмінність від Ethereum, де виконання відбувається on-chain кожного разу.

Практичне наслідання: BitVM-рішення оптимальні для низькочастотних, високовартісних операцій — кросс-чейн мости, верифікація ZK-proof, умовні платежі зі складною логікою. Вони не підходять для high-throughput приложень типу DEX або ігор, де кожен користувач генерує транзакції.

Архітектура BitVM-моста: найбільш затребуваний use case

BitVM-мість між Bitcoin та іншими мережами — наразі найбільш зрілий production use case. Проектів кілька: BitVM Bridge (Robin Linus), BitlayerLabs, Citrea.

Схема trustless withdrawal

Bitcoin L1:
  - Заблокований BTC у multisig (Federation N-of-M)
  - Pre-signed транзакції з taproot scriptpath
  
L2/Sidechain:
  - Користувач спалює wrapped BTC
  - Генерується withdrawal proof (ZK або оптимістичний)
  
Verifier Network:
  - Перевіряє proof
  - Якщо валідний → підписує release транзакцію на L1
  - Якщо невалідний → публікує fraud proof, активує challenge

Ключовий компонент — pre-signed transaction graph. Перед розгортанням моста всі учасники (Federation) підписують Taproot транзакції для всіх можливих шляхів виконання. Це вимагає одноразової інтерактивної сесії між учасниками, після чого мість працює автоматично.

Taproot та його роль у BitVM

Без Taproot (BIP-341/342, активований у листопаді 2021) BitVM був би неможливим. Taproot дозволяє:

• Script trees: одна адреса приховує до 2^128 можливих скриптів, розкриваючи лише виконаний шлях
• 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 втрачає всі transaction costs, prover втрачає залог — економічна безпека тримається на асиметрії

Актуальні обмеження

Немає Script introspection — Bitcoin Script не може читати поля власної транзакції (TXID, inputs, outputs). Обходиться через pre-commitment, але ускладнює архітектуру. OP_CAT (якщо активується) вирішить частину цих проблем.

Розмір witness data — складні circuits генерують witness транзакції по кілька МБ. Майнери приймають, але поширення через мережу повільніше.

Latency — challenge period для безпеки повинен бути достатнім (7–14 днів для trustless withdrawal, аналогічно Optimistic Rollup). Для UX це проблема — більшість використовує ліквідність від провайдерів з fast withdrawal за комісію.

Federation assumptions — більшість поточних реалізацій вимагають N-of-M federation. Істинно trustless (1-of-N) поки в розробці.

Процес розробки та сроки

Реалістичний мінімум для production-grade BitVM bridge: 4–6 місяців. Проекти, що обіцяють менше, як правило, мають federation з високим trust assumption або не-production якістю кода. Поточний ландшафт BitVM — все ще frontier інженерія: документації мало, більшість знань живе у вихідних кодах та Discord (BitVM Alliance, стек BitVM2 від Robin Linus).