1. 引言
主要参考：
2. 为何需关注Bitcoin bridge？
当前的Bitcoin bridge，其所谓bridge，实际是deposit：
在其它链上的BTC情况为：
尽管当前约有43.7万枚BTC在其它链上，但其去中心化程度不足0.3%。
3. Bitcoin bridge 101
Bitcoin bridge的目标是：
- 将BTC存入某appchain（"application chain"）内
- 在appchain内，将BTC用作某原生资产
- 将BTC赎回到Bitcoin
- 用户体验（UX，User Experience）：与在中心化交易所内使用BTC一样
- 安全性（Security）：总是能拿回你的BTC
但是需注意：
- 在Bitcoin和appchain上，二者的信任模型是有差异的
| Bitcoin链上的BTC | 其它appchain上的BTC | |
|---|---|---|
| 所需资源？ | Bitcoin钱包 | Bitcoin钱包、appchain钱包、bridge BTC的方式 |
| 所需信任？ | Bitcoin网络是安全的、钱包未损坏 | Bitcoin网络是安全的、appchain网络是安全的、钱包未损坏、（可能是中心化的）bridge未损坏 |
| 如何检查？ | 开源代码 | 开源代码、中心化bridge的声誉 |
3.1 Wrapping
BTC仅存在于Bitcoin链上。
所谓Wrapping，是指：
- 在另一条链上，创建1:1的BTC原生token表示。
在计算机科学属于中：
- 获取某UTXO state的write lock ，并确保在该write lock 释放之前，在其它链上完成（applied） 该 updates。
3.2 为何bridge如此难？
这是一个好的、老的公平交易问题：
- Alice有BTC，Bob有苹果，如何确保二者交易总是公平的？
在数字世界中，总是有某人先做动作，为确保所有情况下的100%公平性：
- 需引入可信第三方
这与bridge的关系为：
- Wrapping：将BTC，替换为，wrapped BTC
- Unwrapping：将wrapped BTC，替换为，BTC
即，需有人在Bitcoin链上做BTC的锁定和解锁。
bridge的难点在于：
- 如何确保在锁定的同时，同步，在appchain上mint wrapped BTC？即保证整个bridge操作的原子性。
bridge的挑战在于：
- 选择合适的custodian（监护人）
- 中心化实体
- 委员会/联盟
- 第三方网络的共识
- 所关联链的共识
3.3 bridge最好情况：链共识
bridge最好情况：链共识，即继承目标链的安全性/去中心化。
如：
- 以太坊，验证，Bitcoin SPV proof
- Bitcoin，验证，以太坊SPV proof
- 需有一个在线方负责relay proofs
但这需要引入新的Bitcoin opcode，来验证其它网络/系统的lock/unlock。
3.4 当今的BTC bridge：hard模式
希望能实现的目标为：
- 根据其它链上的事件，来lock/unlock Bitcoin链上的BTC
问题在于：
- Bitcoin链并不知道其它链上的事件。
因此，需要有人来处理BTC的lock/unlock。
当前大多数（中心化）BTC bridge的mint和redeem操作流程为：
但是，这样的中心化bridge，没有防盗/扣押/审查/丢失保护。
3.5 如何在不改变Bitcoin的情况下，实现去中心化bridge？
如何在不改变Bitcoin的情况下，实现去中心化bridge？
可采用如下措施：
- 1）支持任何人成为operator/custodian。
- 2）意识到情况更糟......则将BTC发送给网络上的随机用户。
- 3）使用与Bitcoin相同的工具来解决：
- 激励措施：operator锁定抵押
- 惩罚：若operator行为不端，则slash抵押（且 补偿受害者）
如interBTC：
- 1）任何人都可在interlay网络注册运行vaults，并存入抵押
- 2）若用户锁定BTC，其锁定值应小于抵押值（即要求过度抵押）
- 3）则interlay网络为用户mint iBTC。
- 4）若用户想要赎回BTC，Good Vault情况下，则：
- 用户先返还iBTC，
- 然后Vault将BTC返还给用户，
- Vault的抵押解锁
- 5）若用户想要赎回BTC，Bad Vault情况下，则：
- 用户先返还iBTC，
- 然后Vault fails，
- 用户被偿付（或，尝试不同的Vault）
其中，可采用如下方式来验证Bitcoin payment：【用于验证BTC锁定，以及BTC赎回完成】
- 将Bitcoin light client (SPV) 作为智能合约部署
- 可跟踪所有Bitcoin区块头
- 可验证Bitcoin交易
- 其安全模型为：若在Bitcoin主链上存在，则必须有效（与任何手机钱包一样）
- 需有人负责持续更新该light client为最新
总之，interBTC bridge中： - issuer为智能合约
- 任何人可参与的，由Vaults组成的无需许可的网络
- 作为安全保证，Vaults需过度抵押
- 验证：SPV light client
- 安全假设：总是能拿回BTC，或者被偿付。
在此，忽略了： - 抵押管理和流动性
- Vault抵押市值可能会下降
- 与lending协议一样，会top up或被清算
- 如何获得BTC报价？
- 需要oracle
- 可混合中心化交易所和去中心化交易所报价
还存在其它扩展：
- Vault模式
- Single key
- Vault = multisig (plain, musig, MPC threshold sig,...)
- Free for all vs pre-defined group vs one big Vault
- 抵押类型及金额
- Full / partial
- Diversified (USDC, ETH,...) vs native token (risky)
- 安全假设
- Pessimistic / optimistic
- 验证类型
- Light client / 3rd party oracle / coinvote（共同投票）
4. 现有Bitcoin bridge方案对比
现有Bitcoin bridge方案对比为：
| BTC保管/安全模型 | 是否抵押？ | |
|---|---|---|
| RSK | 由第三方群体组成的多签 | 否 |
| Stacks xBTC | 中心化第三方保管 | 否 |
| Stacks sBTC | 由STX质押者组成的多签，会轮换 | 是，但仅抵押STX token |
| tBTC v2 | 由大量（50/100）第三方组成的多签，会轮换 | 否 |
| Liquid | 由侧链（联盟系统）operators组成的多签。 | 否 |
| Fedmint | 由mint（联盟系统）operators组成的多签。 | 否 |
| Cashu | Single Key，为mint（保管系统）operator。 | 否 |
| Interlay iBTC | 由抵押过的第三方保管人组成的去中心化网络 | 是（多种抵押物） |
5. 其它bridge模式
5.1 miners强化的bridge
所谓miners强化的bridge，是指：
- 由Bitcoin miners验证bridge，确保locking/unlocking处理正确。
如：
- BIP300：基于很长一段时间，miners对peg-in和peg-out交易进行投票。
- 缺点是：需要硬分叉
更多细节，可参看：
5.2 基于zkRollup实现的bridge
所谓基于zkRollup实现的bridge，是指：
- Bitcoin通过检查cryptographic proof，来验证appchain上的lock/unlock是否正确。
如：
- 将appchain上状态的验证编码为一个opcode。验证ZK proofs是非常高效的（创建ZK proofs是昂贵的）。
- 缺点是：需要分叉
- 需要ZK技术的成熟
更多细节，可参看：
6. 总结
Bridge问题，等价为，安全保管问题。
Cure（治愈）：
- 更多应用场景和BTC使用，不对Bitcoin造成安全风险。
- 若使用安全bridge，客观上比中心化交易所更安全。
Curse（诅咒）：
- 99%的BTC bridge是中心化的，且错误营销的
- 去中心化很难，而且是有代价的（资本效率）
- 其他链上增加手续费，而不是Bitcoin
6.1 走向非保管bridge
完全的non-custodial bridge是不可能的。
可能的是：为专有应用设置的non-custodial bridge。
如：
- Lending：
- 用户BTC与第三方多签管理
- 仅当用户贷款时，第三方才能获得其BTC
具体实现方式为：
- DLC（discrete log contracts）：基于交易汇率，编码不同的outcomes。
- 另一 第三方：oracle基于outcome签署交易（理想情况下，应使用"blind"盲签名）。
但是：
- 这需要信任oracle。"但是"大多数去中心化的金融应用程序都是这样。
参考资料
[1] Interlay合伙人Alexei Zamyatin Bitcoin Bridges: Cure or Curse?