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

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

Bitcoin — найбільш ліквідний та безпечний блокчейн у світі, але його базовий рівень навмисне обмежений: немає Turing-повних смарт-контрактів, пропускна спроможність ~7 TPS, finality ~60 хвилин. Sidechain — це окремий блокчейн, прив'язаний до Bitcoin через механізм two-way peg, який дозволяє використовувати BTC як нативний актив у середовищі з розширеними можливостями.

Проблема, з якою стикається більшість команд: реалізувати trustless two-way peg між Bitcoin L1 та sidechain технічно крайне складно. Більшість існуючих рішень (RSK, Liquid, Stacks) йдуть на компроміси у бік довіри. Розбираємо ці компроміси та архітектурні варіанти.

Two-way peg: від federated до trustless

Federated peg (Liquid, поточний RSK)

Найбільш розповсюджений підхід. N-of-M мультисиг федерація функціонерів контролює BTC на mainchain. Користувач депозитирует BTC на mainchain → федерація mintit wrapped BTC на sidechain. Withdraw: спалює на sidechain → федерація виводить з mainchain мультисига.

Ключові параметри Liquid: 11-of-15 federated multisig. Функціонери — крупні біржи та кастодіани. L-BTC (Liquid Bitcoin) забезпечений 1:1 BTC, що зберігаються у федерації. Emergency keys дозволяють вивести середства через 4-тижневий timelock якщо федерація недоступна.

Ризики: сговір >M функціонерів, юридичне тиск на функціонерів в одній юрисдикції, operational failure. Для корпоративного застосування (торгові операції, settlement) — прийнятно. Для permissionless DeFi — спірно.

# Liquid Elements sidechain: створення конфіденційної транзакції
elements-cli sendtoaddress \
  "CTExxxxRecipientConfidentialAddress" \
  1.0 "" "" false true 1 UNSET false 1
# Confidential Transactions приховують суму, Confidential Assets приховують тип активу

Drive-chains (BIP-300/BIP-301)

Пропонує інший підхід: sidechain керується як soft fork Bitcoin, miners голосують за withdrawal через blind merged mining. BTC заблокований у sidechain контролюється не федерацією, а консенсусом Bitcoin miners. Теоретично більш trustless ніж federated peg.

BIP-300 не активований на mainnet Bitcoin (по стану на 2026 рік). Для тестування: Bitcoin Testnet fork з патчем BIP-300 або спеціальні тестнети (signet).

Критика: miners можуть саботувати withdrawals. Відповідь авторів: для цього потрібно 51%+ mining power утримувати veto 6 місяців — економічно невигідно. Дискусія у Bitcoin Core спільноті продовжується.

BitVM: trustless computation verification

BitVM (2023, Robin Linus) — проривний підхід, що використовує Bitcoin Script для верифікації довільних обчислень через fraud proofs. Не вимагає soft fork.

Механізм: prover стверджує результат обчислення та публікує commitment. Verifier може оспорити будь-який крок через challenge-response протокол. У разі мошенництва prover втрачає залог. Чесний prover ніколи не буде оспорен — оптимістична верифікація.

BitVM execution flow:
1. Prover: commit(program_hash, input_hash, output_hash) → Bitcoin UTXO
2. Off-chain: prover виконує програму, публікує trace
3. Happy path: verifier приймає trace → BTC розблокований
4. Dispute: verifier вибирає крок X → prover доказує крок X → ...
5. Бісекція ділить спір пополам логарифмічно → O(log N) on-chain кроків

BitVM2 (2024) спрощує протокол: єдиний on-chain крок при успішному challenge. Практичні реалізації: BitVM Bridge для trustless BTC-bridge до EVM chains.

Stacks: смарт-контракти з Bitcoin finality

Stacks використовує унікальний механізм Proof of Transfer (PoX): miners Stacks витрачають BTC для отримання права створити блок Stacks. Кожен блок Stacks прив'язаний до Bitcoin блоку через hash → успадковує Bitcoin finality без змін Bitcoin протоколу.

Clarity — мова смарт-контрактів

Stacks використовує Clarity замість Solidity — навмисне non-Turing-complete, interpreted (не compiled), decidable мова. Можна статично проаналізувати всі можливі execution paths.

;; Clarity: простий DEX контракт на Stacks
(define-map liquidity-pools
  { token-x: principal, token-y: principal }
  { reserve-x: uint, reserve-y: uint, total-shares: uint }
)

(define-public (add-liquidity (token-x principal) (token-y principal) 
                               (amount-x uint) (amount-y uint))
  (let ((pool (map-get? liquidity-pools { token-x: token-x, token-y: token-y })))
    (match pool
      existing-pool
        (begin
          ;; Transfer tokens to contract
          (try! (contract-call? token-x transfer amount-x tx-sender (as-contract tx-sender) none))
          (try! (contract-call? token-y transfer amount-y tx-sender (as-contract tx-sender) none))
          ;; Mint LP shares
          (ok (calculate-shares existing-pool amount-x amount-y)))
      ;; Pool doesn't exist - create it
      (begin
        (map-set liquidity-pools { token-x: token-x, token-y: token-y }
          { reserve-x: amount-x, reserve-y: amount-y, total-shares: amount-x })
        (ok amount-x))
    )
  )
)

Перевага Clarity для DeFi: read-only функції дійсно read-only (перевіряється на рівні типів), немає reentrancy attacks класу DAO hack, передбачуваний gas cost (обчислюється статично).

sBTC: новий two-way peg Stacks

sBTC (2024) — децентралізований peg на базі threshold signatures. 70% Stacks validators керують ключем через FROST threshold signature scheme (Schnorr-based). Для вивода потрібно 70% підписів. Більш децентралізований ніж federated peg, але не повністю trustless — все ще залежить від честності більшості validators.

Депозит sBTC: ~15 хвилин (1 Bitcoin block confirmation). Withdraw: ~24 години (challenge window для fraud detection).

RSK: EVM-сумісний Bitcoin sidechain

RSK (RootStock) надає EVM-сумісне середовище з BTC як native gas token (RBTC). Federated peg через PowPeg — посилена версія мультисига з hardware security modules (HSM) у кожного функціонера, що знижує ризик сговору.

Merged mining: RSK видобувається одночасно з Bitcoin без додаткових витрат енергії для miners. ~60% Bitcoin hashrate участвує у merged mining RSK → висока безпека для EVM chain.

// RSK: той же Solidity, але gas token — RBTC
// Приклад: DeFi протокол що використовує RBTC як collateral
contract RBTCLending {
    mapping(address => uint256) public collateral; // in wei (RBTC)
    mapping(address => uint256) public debt;       // in RUSD
    
    uint256 constant COLLATERAL_RATIO = 150; // 150% overcollateralization
    
    function depositCollateral() external payable {
        collateral[msg.sender] += msg.value;
    }
    
    function borrow(uint256 rusdAmount) external {
        uint256 rbtcPrice = oracle.getPrice(); // RBTC/USD
        uint256 maxBorrow = (collateral[msg.sender] * rbtcPrice * 100) / COLLATERAL_RATIO;
        require(debt[msg.sender] + rusdAmount <= maxBorrow, "Undercollateralized");
        debt[msg.sender] += rusdAmount;
        RUSD.mint(msg.sender, rusdAmount);
    }
}

Архітектурний вибір для вашого проекту

Специфічні технічні складності

Cross-chain finality mismatch. Bitcoin finality ~60 хв (6 confirmations). Sidechain finality може бути 10 секунд. Операція на sidechain не вважається finalized поки не finalized відповідний Bitcoin блок з peg транзакцією.

Reorg handling. Bitcoin reorg глибиною 1-2 блока — рідко, але можливо. Peg система повинна коректно обробляти reorg: rollback sidechain якщо Bitcoin reorg аннулює lock-up транзакцію.

UTXO vs account model. Bitcoin L1 — UTXO модель, більшість sidechains — account модель. Peg повинен конвертувати між ними. Для розробника: Bitcoin UTXO management вимагає окремого tooling (bitcoinjs-lib, rust-bitcoin).

Стек розробки

Bitcoin L1 взаємодія: rust-bitcoin + bitcoinjs-lib + bitcoin-rpc. RSK/EVM side: Foundry + Hardhat + ethers.js. Stacks: Clarity (Clarinet для тестування + Stacks.js). Liquid/Elements: elements-cli + elementsd node. BitVM (експериментально): BitVM Rust implementation (robin-linus/bitvm на GitHub).

Процес роботи

Аналітика (1 тиждень). Визначаємо вимоги: потрібна ли trustless модель або federated достатньо, EVM-сумісність необхідна чи ні, обсяг BTC ліквідності, вимоги до finality time.

Архітектурний дизайн (1 тиждень). Вибір sidechain платформи, проектування peg механізму, схема управління ключами функціонерів (якщо federated).

Розробка (2-4 місяці). Смарт-контракти sidechain сторони → Bitcoin L1 скрипти для peg → мониторинг та relay сервіс → frontend. Складність варіюється від 4 тижнів (RSK deployment + стандартні DeFi контракти) до 4+ місяців (кастомний peg з BitVM).

Security. Peg контракт керує реальними BTC. Обов'язковий external аудит, multi-sig management процедури, incident response план для peg failures.

Ориентири по срокам

Деплой існуючого протоколу на RSK з BTC ліквідністю — 4-8 тижнів. Stacks приложення з Clarity + sBTC інтеграцією — 8-12 тижнів. Кастомний federated peg з нуля — 4-6 місяців. BitVM-based trustless bridge — дослідницький проект, 6+ місяців.