Fiber Cross-Chain Protocol Design

# Fiber Cross-Chain Protocol Design ## Metadata **Status**:: #x **Zettel**:: #zettel/fleeting **Created**:: [[2024-03-14]] **Notion**:: [notion.so](https://www.notion.so/cryptape/The-HTLC-Cross-Chain-Protocol-Design-60fe8edef9864bf19bd891fdfc92eed2?pvs=4) ## Objective - CKB 闪电钱包用户 Charlie 可以出示 BTC 收款码，BTC 闪电钱包用户 Bob 向该收款码支付 BTC，Charlie 能收到扣除手续费后的等价 wBTC\*. - BTC 闪电钱包用户 Bob 出示的 BTC 收款码，CKB 闪电钱包用户 Charlie 向该收款码支付 wBTC，Bob 能收到扣除手续费后的等价 BTC。 \*: wBTC 是通过在 BTC 上锁定等量资产在 CKB 上铸造出来的 xUDT 代币 ## Alternatives ### 伪装成 BTC 通道把 CKB 上的 wBTC 通道伪装成 BTC 通道，这样可以直接接入 BOLT P2P 网络将 wBTC 通道广播成 BTC 通道。这个方案最大的优点是不用再自己做 P2P，寻路和支付路由了。缺点是受限于 BOLT 协议的发展。不过最大的问题在于这条路可能会走不通，因为在 (BOLT, 2016[^bolt2016BOLTP2P]) 里提到节点收到 `channel_announcement` 消息必须验证 funding transaction 在链上，且 output 未被花费。虽然 BOLT 的各种实现不一定都实现了这个验证要求，但是在兼容性上肯定会有很大的障碍。有两种可能绕开的方案，不过复杂度都很高。 1. 一种可能的方案是按照 (BOLT, 2017[^bolt2017BOLT11]) 中提到的，在 Invoice 的 `r` 字段加入私有的通道供路由挑选。这个方案有两个明显的缺点。第一，不确定节点是否会像 `channel_announcement` 一样验证 funding transaction；第三，对于同时有 BTC 和 CKB 通道的节点有不小的负担，他们需要负责 CKB 侧的寻路，并将对应的通道放到 Invoice 中。 2. 第二种是让 wBTC 跨链桥来支持在 BTC 通过创建一个 BTC 通道来锁定资产。这样发行出来的 wBTC 会用于在 CKB 侧创建一条 wBTC 通道。wBTC 通道可以借用对应的 BTC 上通道的信息进行广播，但是实际的资产流转发生在 CKB 的 wBTC 通道里。 ### 支持跨资产跨链的 BOLT 网络如果 BOLT 能支持不同币种，不同网络的通道混合组网，那我们只需要按照 BOLT 的 P2P 协议参与到网络的寻路和支付路由即可。这是一个理想的道路，但是时间不可控。我们可以尝试推进，但是不能依赖于这条路。 ### 使用一种新的协议比如使用 (Malavolta et al., 2019[^malavolta2019AnonymousMultiHop]) 绕过 BOLT 支持直接进行三方的跨链支付。这个方案的问题在于需要 BTC 闪电钱包支持，目标不可控。早期可能只用那些同时支持 BTC，CKB 的钱包会考虑支持，影响范围有限。 ## Specification 如果不想改动 BTC 侧的 BOLT 协议，也不想依赖任何还会大规模使用的 BOLT 扩展，同时又不能把 CKB 上的通道伪装成 BTC 上的通道，那剩下的方案就是把一条路径切成两段，分别在 BTC 和 CKB 上进行支付然后通过协议设计保证两条路径上支付的原子性了。为了方便描述，我们先定义一些角色： - Bob 是 BTC 的闪电节点。 - Charlie 是 CKB 的闪电节点。 - Ingrid 是跨链提供商，同时运行 BTC 和 CKB 的闪电节点 Bob 和 Ingrid 之间存在一条 BTC 闪电网络的支付路径；Charlie 和 Ingrid 之间存在一条 CKB 闪电网络的支付路径。Charlie 必须知道 Ingrid 的存在，或者是能通过某种目录服务找到 Ingrid 这样的跨链提供商。而 Bob 不需要知道也不需要去主动查找 Ingrid，因为在本协议中，跨链对于 BTC 的闪电节点来说是透明的，他们完成的只是普通的 BTC 闪电支付。 ### BTC 向 CKB 支持 ```mermaid sequenceDiagram participant Bob participant Ingrid participant Charlie Charlie->>Ingrid: wBTC Invoice Ingrid->>Charlie: BTC Invoice Charlie->>Bob: BTC Invoice Bob->>Ingrid: BTC Payment Ingrid->>Charlie: wBTC Payment Charlie->>Ingrid: Hash Preimage Ingrid->>Bob: Hash Preimage ``` 按照 BOLT 协议，Charlie 想要向 BTC 闪电钱包用户收款，要先出示 BTC 闪电网络的 Invoice。Charlie 需要找到 Ingrid 来协助。 - Charlie 按照收款额度生成 CKB 闪电网络上的 wBTC 资产的 Invoice，将其发给 Ingrid - Ingrid 使用自己的 BTC 闪电节点信息生成对应的 BTC Invoice 返回给 Charlie - Charlie 将收到的 BTC Invoice 发给付款人。 Charlie: - 提交 CKB Invoice 给 Ingrid 时可以协商手续费和兑换比例。比如发 950 Sat 的 CKB Invoice 给 Ingrid，而 Ingrid 生成 1000 Sat 的 BTC Invoice，相关的 50 Sat 作为 Ingrid 的额外手续费。 - 收到 BTC Invoice 之后必须检查是否合法并且和提供的 CKB Invoice 匹配。 - BTC Invoice 金额是否在扣除手续费后和进行兑换比例换算之后和 CKB Invoice 金额一致。 - `p`, SHA256 payment hash 必须使用 CKB Invoice 中提供的 payment hash。 - `f`, Fallback on-chain address 不能设置。 Ingrid: - `c`, `min_final_cltv_expiry_delta` 设置为一个比默认值 18 大小些的值，因为 Ingrid 还需要完成 CKB 侧的交易才能拿到 payment hash 的 preimage。 - `m`, payment metadata. Ingrid 可以使用 metadata 方便区分这笔支付是否需要跨链。关于 BTC Invoice 字段的说明参考 (BOLT, 2017[^bolt2017BOLT11]) Bob 收到 Charlie Invoice 后开始正常的 BTC 闪电支付流程。最终这笔支付会发到 Ingrid。Ingrid 在收到支付也就是创建出 receiving htlc 后，按照对应的 CKB Invoice 向 Charlie 支付 wBTC。 Charlie 收到 wBTC 后原路回传 preimage 给 Ingrid，然后 Ingrid 再将 preimage 通过 BTC 闪电网络回传给 Bob，从而完成整个交易。 ### CKB 向 BTC 支持 ```mermaid sequenceDiagram participant Bob participant Ingrid participant Charlie Bob->>Charlie: BTC Invoice Charlie->>Ingrid: BTC Invoice Ingrid->>Charlie: wBTC Invoice Charlie->>Ingrid: wBTC Payment Ingrid->>Bob: BTC Payment Bob->>Ingrid: Hash Preimage Ingrid->>Charlie: Hash Preimage ``` Charlie 想向 Bob 支付，需要 Bob 提供 BTC Invoice。Charlie 需要找到 Ingrid 来协助。 - Charlie 将 BTC Invoice 发送给 Ingrid。 - Ingrid 使用自己的 CKB 闪电节点信息生成对应的 CKB Invoice 返回给 Charlie Charlie: - 提交 BTC Invoice 给 Ingrid 时同样可以协商手续费和兑换比例。 - 收到 CKB Invoice 之后必须检查是否合法并且和提供的 BTC Invoice 匹配。 - CKB Invoice 金额是否在扣除手续费后和进行兑换比例换算之后和 BTC Invoice 金额一致。 - Payment hash 必须使用 BTC Invoice 中提供的 payment hash。 - 如果 CKB 支持 Fallback on-chain address，该字段不能设置。 Ingrid: - 在 CKB Invoice 中设置一个比较大的过期时间，因为 Ingrid 还需要完成 BTC 侧的交易才能拿到 payment hash 的 preimage。 Charlie 查找完 CKB Invoice 后就可以向 Ingrid 支付 wBTC。Ingrid 收到 wBTC 后找到对应的 BTC Invoice 向 Bob 支付 BTC。 Bob 收到 BTC 后原路回传 preimage 给 Ingrid，然后 Ingrid 再将 preimage 通过 CKB 闪电网络回传给 Charlie，从而完成整个交易。 ## Problems and Future ### 隐私性 Charlie 的隐私完全暴露给了 Ingrid。目前没有太好的方案来避免。不过相反的，既然无法保证隐私性，在性能和用户体验上能做得更好一些。比如 Charlie 和 Ingrid 之间支持建立通道。另外在 Charlie 收款时还可以使用 JIT 通道 (Kohler, 2023[^kohler2023WhatJustInTime]) 等技术由 Ingrid 注资解决 Charlie 收款额度的问题。 ### HTLC or PTLC 即然 Charlie 和 Ingrid 之间有通道支持连接，使用 PTLC (Kohler, 2022[^kohler2022WhatPoint]) 或者其它基于 Adapter Signatures (Erwig et al., 2021[^erwig2021TwoPartyAdaptor]) 的方案就没有什么优势了，所以本协议按照 CKB 也使用 HTLC (Lighting Engineering, 2021[^lightingengineering2021HashedTimelock]) 做了设计。如果 BTC 开始广泛采用 PTLC，或者 CKB 选择使用 PTLC 或者 AMHL (Malavolta et al., 2019[^malavolta2019AnonymousMultiHop]) 等方案，Ingrid 如何保证两条支付链路的原子性需要重新设计。 - [[Fiber Cross-Chain HTLC and PTLC]] - [[Fiber Cross-Chain PTLC and PTLC]] ### wBTC 流动性 wBTC 的流动性对跨链用户体验影响很大，Ingrid 需要储备一定量的 wBTC 保证流动性。这个问题最好在源头解决，比如 wBTC 的提供商支持通过 BTC 和 CKB 上的闪电网络进行资产跨链。在 BTC 上可以通过闪电网络向 wBTC 提供商支付 BTC，从而在指定的 CKB 闪电网络中获得增发的 wBTC，反过来流程类似。当然 wBTC 的提供商也可以自己扮演 Ingrid 的角色。 ### 其它资产的跨链目前该协议到 BTC 只能支持其原生 BTC 资产。在 CKB 这一侧容易扩展到任意代币，只要 Charlie 和 Ingrid 协商好和 BTC 的兑换比例即可。要在 BTC 上支持其它资产，需要 RGB++ (Wang, 2024[^wang2024RGBProtocol]) 这样的协议支持，这样可以通过将 CKB 上资产的所有权代理给 BTC UTXO 来实现资产的跨链流转。 ## References [^bolt2016BOLTP2P]: BOLT. (2016). BOLT #7: P2P Node and Channel Discovery. <https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#the-channel_announcement-message> [^bolt2017BOLT11]: BOLT. (2017). BOLT #11: Invoice Protocol for Lightning Payments. <https://github.com/lightning/bolts/blob/master/11-payment-encoding.md> [^erwig2021TwoPartyAdaptor]: Erwig, A., Faust, S., Hostáková, K., Maitra, M., & Riahi, S. (2021). Two-Party Adaptor Signatures from Identification Schemes. In J. A. Garay (Ed.), Public-Key Cryptography – PKC 2021 (Vol. 12710, pp. 451–480). Springer International Publishing. <https://doi.org/10.1007/978-3-030-75245-3_17> [^kohler2022WhatPoint]: Kohler, C. (2022). What Is A Point Time Lock Contract? <https://thebitcoinmanual.com/articles/point-time-lock-contract/> [^kohler2023WhatJustInTime]: Kohler, C. (2023). What Is A Just-In-Time (JIT) channel? <https://thebitcoinmanual.com/articles/jit-channel/> [^lightingengineering2021HashedTimelock]: Lighting Engineering. (2021). Hashed Timelock Contract (HTLC). <https://docs.lightning.engineering/the-lightning-network/multihop-payments/hash-time-lock-contract-htlc> [^malavolta2019AnonymousMultiHop]: Malavolta, G., Moreno-Sanchez, P., Schneidewind, C., Kate, A., & Maffei, M. (2019). Anonymous Multi-Hop Locks for Blockchain Scalability and Interoperability. Proceedings 2019 Network and Distributed System Security Symposium. Network and Distributed System Security Symposium, San Diego, CA. <https://doi.org/10.14722/ndss.2019.23330> [^wang2024RGBProtocol]: Wang, C. (2024). RGB++ Protocol Light Paper. <https://talk.nervos.org/t/rgb-protocol-light-paper/7733/3>