作者：ScaleBit

比特币 Layer2 生态正在迎来一波爆发，而跨链桥则被认为是该生态中至关重要的组成部分。对于 Layer2 来说，跨链桥的安全性显得尤为重要，随着 Taproot 升级，跨链桥实现又出现了更多方案。在 ScaleBit 的研究中，我们审视了多个 BTC Layer2 跨链桥的设计方案，结合 ScaleBit 的 BTC Layer2 审计案例，总结出了四种常见的比特币多签方案，用于构建 BTC Layer2 跨链桥。本文旨在深入探讨这些方案的原理及其各自的优缺点，以期为读者提供更清晰的认识。

方案一：传统多签

概述

传统多签指的是比特币原生多签或支付到脚本哈希（P2SH）多重签名方式。比特币用户需要跨链时，先将 BTC 转到一个多签地址进行托管，并在交易中添加备注信息（如跨链的目标地址）。多签账户由 L2 链的节点共同管理，一般每个节点持有一个多签私钥。当节点确认多签账户收到 BTC 时，会在 L2 链上用户跨链的目标地址铸造对应数量的 BTC 。当用户跨链提现回 Bitcoin 网络时，L2 节点确认提现请求有效后，触发一笔 Bitcoin 网络上跨链桥多签账户向用户转账的交易，并分别用各自私钥对该交易进行签名并提交。

优点

最传统的跨链方案，其特点在于稳定，开发快速，成本较低，同时经过了大量的实践检验。在此基础上，也还能够增加额外的安全措施，例如可以将签名服务独立部署，形成签名机，隔绝网络，只让签名机和必要的其他服务链接起来。

缺点

多重签名技术的隐私性并无法得到保障，在解锁多签脚本时将暴露多签的公钥，且交易手续费偏高。

案例解析

ChainX

ChainX 的1.0版本的 BTC 跨链方案已经成功运行了一段时间，并且一度走在市场前列，上线之初在极短的时间内跨链 BTC 价值就已突破千万美金。ChainX 的 1.0 版本就是多重签名托管方案。

资产进入

ChainX 运行比特币轻节点，Relay 实时传输 Header 以保持最长链更新。当用户向托管人的多签地址发送转账，并将用户的 ChainX 地址以十六进制格式添加到 OP_RETURN 作为交易中的 Note 时，只有带有 OP_RETURN Note 的转账交易才会被跨链桥识别接受。监控比特币网络，在交易的区块被 Bitcoin 确认后，向跨链桥提交 Tx、Proof、OP_RETURN 及相关信息，跨链桥对 Tx 和 OP_RETURN 进行验证。如果两者都有效，X-BTC 将发行至 OP_RETURN Note 所附的 ChainX 地址。

资产退出

用户在 ChainX 网络中发起 BTC 提现，会促使 ChainX 跨链桥/网关中的记录模块动作，锁定相应数量的 X-BTC，并记录与用户 ID 关联的用户申请信息。同时托管人定期获取正在进行的提现信息，据此形成 BTC 提现交易并提交至 ChainX 比特币跨链桥，然后锁定相应的提款记录，最后由其他托管人共同签署这笔交易。签名完成后将交易提交至 BTC 网络，如果交易得到确认，将交易和证明路径提交给传输跨链桥以验证 Tx。如果有效，相应的提现记录将被关闭，锁定的 X-BTC 将被销毁。

方案二：Schnorr 多签

概述

Schnorr 多签是在 Taproot 升级当中引入的一种聚合签名形式。相较于传统的多签（例如P2SH），尽管能够实现 m-n 的门限签名，但是需要将每一个使用的公钥都输入到解锁脚本中，这样一来就会占据大量的交易体积。但是对于一个采用了 Schnorr 多签的锁定脚本来说，仅仅需要一个签名就能够进行解锁了。

具体来说，Schnorr 相较于传统的签名方案而言，其最大的优点在于能够进行聚合，即多个签名可以简单地合并。具体来说，对于给定的消息 m1、m2、...、mn，其对应的多个签名s1、s2、...、sn可以直接相加，得到一个聚合的签名s = s1 + s2 + ... + sn。

由于多个 Schnorr 签名能够用相加的方式进行聚合，因此单个 Schnorr 签名与聚合 Schnorr 签名的表现是一致的。它们具有相同的地址格式，同时和传统的单个签名几乎占用相同的空间。这个优点使得它非常适合用于压缩签名的体积。比特币在 Taproot 升级之后支持了对 Schnorr 签名的原生验证。

优点

通过聚合，可以大大减少签名的大小和验证的开销，特别是在多方签名或批量签名的情况下，能够提高效率并降低资源消耗。基于 Schnorr 多签的解锁通常只需要一个签名，而传统的 m-n 多签则至少需要提供m个签名。

与此同时，由于 Schnorr 多签地址和普通的公钥地址是完全相同的，Schnorr 签名还能够有效的进行隐私保护。传统的多签地址则需要一个截然不同的锁定脚本。

缺点

由于 Schnorr 签名的特性，其只能用于构造 n-n 的门限签名，它要求提供所有参与到聚合过程中的签名才能够解锁。如果有任意一个私钥遗失，则会导致资产锁死。与此同时，Schnorr 签名本身需要在链下进行聚合，其需要通过一个额外的链下协议，完成对签名的聚合（例如 MuSig ），这个步骤可能会引入额外的隐私和安全风险。

案例解析

具体实践当中，暂时没有直接使用 Schnorr 签名地址作为跨链桥的案例，但是从理论上是可行的。

方案三：Schnorr 多签 + Taproot

概述

在比特币主网进行 Taproot 升级之后，通过 Schnorr 签名技术来构造 m-n 的多签 Taproot 账户成为了可能。通过构造一个特殊的 Tapscript，就能够实现基于 Schnorr 的门限签名。

任何一个 Tapscript 脚本都可以被理解为存在多个条件，并且可以按照每个条件进行解锁的特殊脚本。其中，每个分支所对应的解锁脚本，事实上都是默克尔化抽象语法树（MAST）的叶子节点。显然，只要将 Schnorr 签名的不同可能的结果，都作为一个独立的叶子节点，就能够实现 m-n 的多签钱包了。

具体来说，生成这样一个 Tapscript 需要多方在链下完成脚本的构造。以2-3多签为例，首先在链下，参与者必须首先构造多组可能的 Schnorr 多签。例如通过 MuSig2，三个参与者A，B，C 分别生成 Sig1(A,B)，Sig2(B,C) 以及 Sig3(A,C)。之后，需要将这三个生成的 Schnorr 签名Sig1，Sig2，Sig3 分别放在不同的叶子结点中并加入 OP_CHECKSIG。最后，通过叶子结点，生成最终的默克尔树根，即可完成一个 Taproot 的多签钱包，如下图所示。

优点

能够在 Schnorr 签名的基础上实现 m-n 的原生多签，并且具备原生 Schnorr 多签的其他优点，例如隐私保护，减少空间占用等。与此同时，其使得多签钱包能够拥有的碎片数量得到了极大的拓展，理论上完全能够使用数百个密钥构建更加去中心化的跨链桥，进一步增加多签方案的安全性。

缺点

由于其依然使用了 Schnorr 签名技术作为基础，因此依然需要链下协商过程来生成聚合签名。同时，随着签名方的增加，Tapscript 需要处理的叶子节点也会随之增加，使得效率降低。并且，在参与签名方增加的同时，链下聚合过程中由于协议缺陷，导致信息泄漏的风险也更高了。

案例解析

BEVM

BEVM 是一条 Bitcoin 二层网络，尽可能的利用了 Bitcoin Core 0.21 之后的一些特性。比特币中的用户A通过将比特币发送到 BEVM 指定的，包含了 Tapscript 的，一个使用了聚合公钥的账户之中以进行跨链；并通过在 BEVM 中销毁掉对应的代币进行退出。

BEVM 上的每个 POS 共识节点都自带一把 BTC 门限签名私钥：是通过Taproot（Schnorr + Mast 合约）技术产生的 N 个门限合约私钥，负责托管交互 BTC 网络上的资产和数据。BTC 门限签名私钥是通过 POS Staking 逻辑选出 n 个共识节点产生的，n 最大可以支持到 1000，如下图所示。

资产进入

用户将 BTC 发送到了跨链桥 Taproot 地址当中，Bitcoin 矿工接受到了这笔交易。在 BEVM 当中，每个矿工都需要同时运行一个比特币网络的轻节点，以便于快速的识别比特币中打过来的交易。在确定用户将 BTC 打入 Taproot 地址之后，矿工们将根据协议，在另外一个和用户商议好（或者在生成之后发送给他）的地址中，加入相同数量的 BEVM BTC。

资产退出

用户如果希望退出 BEVM，首先，用户在 BEVM 的 EVM 平台提交跨回 BTC网络的交易请求，然后 BEVM 的 n 个 POS 共识节点会用 BTC 门限托管合约进行大于2/3的 BFT 投票，投票通过后会产生 BTC Taproot 交易。随后，BTC Taproot 交易会被提交到 BTC 网络，完成 BTC 链上资产的交互。在这笔交易得到了足够多的确认之后，用户将收到 BTC，其拥有的 BEVM BTC 被销毁，整个跨链生命周期结束。

构造 Taproot 账户以及 Tapscript

从以上的流程中可以看到，BEVM 从工程实践的角度看，最关键的部分显然就是如何构造这个 Taproot 账户，以及这个账户对应的 Tapscript 应该如何构造。但是 Tapscript 支持对 Schnorr 签名进行验证，通过 OP_CHECKSIGADD 指令，能够累进式的判断最终签名是否成功。

方案四：DLC (Discreet Log Contracts)

概述

谨慎日志合约（DLC）的方案同样基于传统多签方案。用户将资金存储在一个与项目方共同参与的 2-2 多签钱包中，并且构造多笔交易，按照预言机发出的信息，来决定最终资金的去向。

具体来说，首先，DLC 的参与双方 A 和 B 共同创建一个 2-2 的多签地址，并且将资金发送到当中。接下来，A和B将会和预言机一起，按照可能出现的结果，用多签地址中的代币，再构建多笔交易。这些交易被称为 Contract Execution Transactions (CET)，于链下保存。最后，预言机可以根据结果，对某一个特定的 CET 进行签名，并提交上链，完成整个 DLC 的生命周期。预言机与项目方的差别，相比于直接掌握跨链桥私钥的项目方，预言机作为第三方作恶或者窜谋过程会更复杂且不可控。

如下图所示，与其他跨链桥显著不同的一点是，DLC 需要为每一个用户单独构造一个地址（或者让用户自行构建 DLC 地址）。

优点

通过 DLC 跨链方案，用户对跨链桥账户拥有更多的自主权，不需要第三方托管资金；同时 DLC 还能够通过 HTLC 构造逃生舱，使得资金相对安全。相较于多签跨链桥，用户可以用自己构建的账户完成跨链，而无需依赖项目方提供的特定地址。于此同时，相较于项目方，预言机网络由于不能查看 DLC 的链下部分，因此更加安全可信。

缺点

尽管预言机与项目方进行了区分，但是依然存在着恶意的预言机与 DLC 参与方进行窜谋的可能性。在预言机被操纵的情况下，用户的资金将可能被意外的划转。

案例解析一

DLC.link

在 DLC.link 当中，强调这样一个概念，即 DLC.link 官方不会参与到任何 L1 的事务当中，如 DLC 的创建，资金的接收等，而是全部在对手盘之间完成。下图是 DLC.link 简化后的铸造流程。

资产进入

与传统跨链桥不同，用户可以被允许自发的生成一个 DLC 脚本，其中，参与的双方分别为 DLC 指定的做市商以及用户，它们需要通过链下协议，构建一个 2-2 的多签钱包。之后，它们还需要按照一定的清算标准，在链下设置好所有可能发生的未来交易（CET），以及触发这些交易所需要的预言机签名。

用户在创建完成 DLC 脚本之后，需要等待 4-6 个比特币区块的确认，之后，DLC 网络中的节点将会使用它们的轻节点抓取所有有效的 DLC 信息，并根据他们进行 dlcBTC 的铸造。

资产退出

当用户试图退出 DLC.link 网络的时候，存在以下几种可能的方式，正常提现和逃生舱（Escape Hatch）。在正常的情形下，如果预言机接收到来自 L2 消息，表明用户有提现意图，资金将返还给用户，同时对应的 dlcBTC 被销毁。而如果 DLC 账户长时间未收到消息（例如，一年）的情况下，资金能够通过 CET 当中的一笔包含了 HTLC 的特殊交易自动返回给用户。

案例解析二

Bison

Bison 提供了一个专注于解决比特币 Layer2 生态中的安全性、速度和用户体验的跨链桥技术。通过结合多签钱包和 DLC，Bison 能够提供一个高效且安全的跨链转移解决方案。

资产进入

当任意一笔资产试图进入 Bison 网络时，用户需要将资产发送至一层网络的 DLC 当中。该 DLC 是一个链上的多签地址，由 Bison 和用户共同拥有。因此 Bison 无法在未经用户授权的前提下对比特币进行转移。在用户试图在 Bison 网络使用这些质押的比特币之前，他需要首先提供一个 DLC 的签名，才可以使得未来的交易能够进行。

资产退出

如果用户希望将他的比特币移回自己的钱包，Bison 会签署一条消息，以便用户对资金进行转移。当 Bison 网络在指定时间范围内没有进行相应，DLC 通过 HTLC 自动解锁，将剩余的比特币退回给用户。这种机制确保用户在决定在 Bison 网络上使用它们之前，保留对资金的自我保管。

总结

以上四种方案，各有优缺点，除第三种外，其他的都有应用案例。

针对 BTC L2 的跨链桥方案，最终的目标都是能够建立一个去信任的资产托管方案。能够在尽量保障用户资金安全的同时，确保最终 L1 结算的正确性。现阶段来看，基于 Tapscript 的 Schnorr 多签与 DLC 方案能够较大程度上降低作恶与合谋的风险，增加跨链桥的安全性。除此之外，跨链桥也需要健壮且去信任的验证者网络进行维护，我们未来也将会对如何建立它进行讨论。

感谢 BEVM CEO Gavin ，Bison Labs CEO Jay、Rooch Network 联合创始人 JoleStar 对本文的贡献。

继续阅读：

此文由 比特币官网 编辑，未经允许不得转载！：首页 > 比特币新闻 » 比特币Layer2跨链桥多签资产托管案例解析