BitVM and Bridges-侧链桥

原文：https://github.com/BitVM/BitVM/blob/main/docs/sidechain_bridges.md

信任最小化的双向挂钩机制。

正在撰写中。

比特币桥和跨链互操作性的总体背景：

• 比特币桥梁：治愈还是诅咒？

• SoK：分布式账本之间的通信

概要：乐观、信任最小化、BTC 与 BitVM 的桥梁

BitVM BTC 桥背后的主要思想是为比特币全节点创建仅使用比特币脚本来操作侧链桥程序的方式，包括侧链轻客户端。虽然众所周知不可能创建像链上比特币合约这样的程序，但我们利用 BitVM 的防欺诈机制乐观地在链下执行侧链轻客户端（以及桥接程序的其余部分），使用链上交易仅用于执行挑战-响应游戏，允许诚实的参与者防止离线或恶意参与者的不诚实行为。侧链以智能合约的形式实现了等效的桥接程序和比特币轻客户端。（注意：我们需要假设有足够的功能可用。或者，侧链也可以通过类似 BitVM 的机制来实现桥接程序。）

为了将 BTC 从比特币转移到侧链，“存款人”将 BTC 发送到由 N 个成员组成的委员会（一个 Prover=“Operator”，N-1 个 Verifiers=“Watchtowers”）控制的多重签名，该委员会承诺作为桥接计划的一部分BitVM 设置。只要这些参与者之一是诚实的，存款就仍然安全，因为恶意的委员会成员将受到质疑，并且他们对 BTC 存款的访问权限将被删除。每当存款人请求将打包的 xBTC 兑换为 BTC 时，当前活跃的运营商都会验证链下侧链的状态，如果一切正确，则从她自己的余额中将 BTC 发送给用户，即将 BTC 付款给用户。然后，运营商要求从多重签名存款中退还已赎回的 BTC 金额。了望塔观察这个过程并验证正确性。一旦运营商请求报销，如果链下程序执行产生不同的结果，例如运营商发送了错误的 BTC 金额或支付到错误的地址，那么 Watchtowers 可以在预定义的质询期内发出链上质询。如果运营商未在预定义的超时期限内支付 BTC，Watchtowers 将质疑不活动状态。在这两种情况下，瞭望塔都会通过 BitVM 触发链上质询-响应协议。在最坏的情况下，这个过程需要进行多次链上比特币交易，并导致运营商被从委员会中除名，并无法访问存入桥的比特币。然后，其中一个了望塔被选为操作员并恢复桥梁的操作。为了确保瞭望塔有足够的动力来执行挑战（并支付最终的链上比特币交易费用），运营商以比特币作为抵押。同样，为了抑制虚假挑战，瞭望塔还必须存入抵押品。