1. 引言
前序博客：
基于BitVM的乐观 BTC bridge：
- Trust-minimized two-way peg 机制
BitVM BTC bridge背后的主要思想是：
- 为比特币全节点创建仅使用比特币脚本来操作sidechain bridge program的方式，包括sidechain light client。虽然众所周知不可能创建像链上比特币合约这样的程序，但利用 BitVM 的防欺诈机制乐观地在链下执行侧链轻客户端（以及桥接程序的其余部分），仅用链上交易于执行挑战-响应游戏，允许诚实的参与者防止离线或恶意参与者的不诚实行为。
- 侧链以智能合约的形式实现了等效的bridge program和比特币轻客户端。
*（注意：需假设有足够的功能可用。或者，侧链也可通过类似 BitVM 的机制来实现bridge program。）
为了将 BTC 从比特币转移到侧链，"Depositor"将 BTC 发送到由 N 个成员组成的委员会（一个 Prover="Operator"，N-1 个Verifiers="Watchtowers"）控制的multisig多重签名，作为BitVM setup的一部分，该委员会对bridge program进行commit。只要这些参与者中有一个是诚实的，存款就仍然安全，因为恶意的委员会成员将受到挑战，且其对 BTC 存款的访问权限将被删除。
每当Depositor请求将Wrapped xBTC 兑换为 BTC 时：
- 1）当前活跃的Operator都会在链下 验证侧链的状态，如果一切正确，则从她自己的余额中将 BTC 发送给用户，即将 BTC 付款给用户。
- 然后，Operator要求从multisig多重签名存款中报销已赎回的 BTC 金额。Watchtowers观察该过程并验证正确性。
- 一旦Operator请求报销，若链下程序执行产生不同的结果，如Operator发送了错误的 BTC 金额或支付到错误的地址，则 Watchtowers 可在预定义的挑战期内发出链上挑战。
- 2）若Operator未在预定义的超时期限内支付 BTC，Watchtowers 将挑战不活动状态（inactivity）。
在这两种情况下，Watchtowers都会通过 BitVM 触发链上挑战-响应协议。
- 在最坏的情况下，这个过程需要进行多次链上比特币交易，并导致Operator被从委员会中除名，并无法访问存入bridge中的BTC。
- 然后，其中一个Watchtower被选为Operator并恢复bridge的运营。
为确保Watchtowers有足够的动力来执行挑战（并支付最终的链上比特币交易费用），Operator以比特币作为抵押。
同样，为了抑制虚假挑战，Watchtowers还必须存入抵押。
参考资料
[1] BitVM Sidechain Bridge