BitVM 桥与 OP-DLC：新一代比特币 Layer2 跨链桥的设计思路

作者：Faust & Nickqiao，极客 web3

摘要：

• ZK 桥在 A 链上部署智能合约，直接接收验证 B 链区块头及相应零知识证明，确认跨链消息的有效性，属于安全级别最高的桥接方案；乐观 /OP 桥通过欺诈证明对无效的跨链消息进行链上挑战，只需存在 1 个可靠的挑战者，即可保证跨链桥资金池的安全；

• 比特币主网因为存在技术上的限制，无法直接部署 ZK 桥，但可以通过 BitVM 和欺诈证明实现乐观桥。Bitlayer 和 Citrea 等团队采用了 BitVM 桥的方案，引入预签名，结合了通道的思想，让用户在正式存款前，对存款执行后的处理流程进行限定，不给跨链桥官方挪用用户存款的机会。

• BitVM 桥本质基于「垫付 - 报销」模式，有专门的 Operator 节点为提款用户打钱，Operator 可以定期向公共存款地址申请报销。如果 Operator 存在不实的报销申请，可以被任何人挑战并 Slash；

• BitVM 桥在理论上不存在安全问题，但存在活性 / 可用性问题，而且不能满足特定用户对资金独立性和反洗钱的需求（本质还是资金池的模式）。Bitlayer 对此增设了名为 OP-DLC 的桥接方案，该方案类似于 DLC.link，在通道和 DLC 的基础上引入欺诈证明，防止 DLC 桥的预言机作恶。

• 由于 BitVM 和欺诈证明的落地难度大，DLC 桥会率先落地并成暂时的替代物，只要解决预言机的信任风险，集成更为可靠成熟的第三方预言机，DLC 桥可以在现阶段成为比多签桥更安全的提款验证方案。

导语

自去年的铭文热潮以来，比特币生态便以井喷之势步入高速增长期，短短半年时间，打着 BTC Layer2 旗号的项目便已达到近 100 家，简直成了一片乱象迭出、机会与骗局共存的新大陆。毫不夸张的说，现在的比特币生态已经是以太坊、Cosmos 与 Celestia、CKB 和比特币 native 生态的「多民族大熔炉」，加之缺乏权威的声音，比特币生态体系简直就像 19 世纪的美国一样，成为了吸纳各路势力的新天地。这在为整个 Web3 叙事带来繁荣与活力的同时，也引入了巨大的风险。

许多项目在连技术方案都没发布的情况下，就开始肆意炒作，打着 native layer2 的名号，声称能完整继承比特币主网的安全性；更有甚者玩起了造概念的宣传手法，发明一堆光怪陆离的名词术语，作为宣扬自身优越性的台词。虽然自吹自擂已然是比特币生态的现状，但还是有不少顶级 KOL 发出了客观的呼声。

前不久，区块链浏览器 Mempool 创始人 Monanaut 公开批判了当下比特币生态的问题，他犀利的指出，如果一个比特币 Layer2 单纯采用多签形式的提款桥，无法以一种去信任的形式让用户把资产随时撤出，这样的项目就不是一个真正的 Layer2。有趣的是，此前 Vitalik 也曾指出，Layer2 在安全保障上至少应比单纯依赖于多签的系统更安全。

可以说，Monanaut 和 Vitalik 直言不讳的指出了比特币 Layer2 在技术上的问题：很多 L2 的提款桥本质都是多签桥，要么是几个知名机构各执一道密钥，要么采用基于 POS 的去中心化签名，但无论如何，其安全模型都基于多数诚实假设，即默认大多数多签参与者不串谋作恶。

这种严重依赖于信用背书的提款桥方案绝非长久之计，历史已经告诉我们，多签桥迟早会出各种各样的问题，只有信任最小化或是趋于完全去信任的资产托管方式，才能经受住时间和黑客的考验。但比特币生态的现状是，很多项目方连提款桥技术路线图都没有发布，对于桥该如何去信任或是信任最小化，压根没有成型的设计思路。

但这并非比特币生态的全部。目前仍然有一些项目方针对提款桥优化思路发表了意见。在本文中，我们将对 Bitlayer 以及 Citrea 的 BitVM 桥进行简要解析，并介绍 Bitlayer 针对 BitVM 桥的不足而提出的 OP-DLC 桥，让更多人理解跨链桥的风险与设计思路，这对于广大比特币生态参与者而言，至关重要。

乐观桥：基于欺诈证明的桥接验证方案

其实，跨链桥的本质很简单，就是向 B 链证明 A 链上的确发生了某事件。比如说，你从 ETH 往 Polygon 上跨资产，要让跨链桥帮你证明，你确实向 ETH 链上的特定地址转入了资产，然后你可以在 Polygon 链上接收等量资金。

传统的跨链桥一般采用见证人多签，他们会在链下指定几个见证人，见证人要运行各条公链的节点，监测是否有人向跨链桥收款地址充入了资金。

这类跨链桥的安全模型和多签钱包基本一致，要按照多签设置方式比如 M/N 来判定其信任模型，但最终基本都遵循诚实多数假设，就是默认多数公证人都是无恶意的，容错率比较有限。此前发生过的多起大数额的跨链桥被盗案，基本都发生在这类多签桥身上，要么是监守自盗，要么是被黑客攻击。

相比之下，基于欺诈证明协议的「乐观桥」，和基于 ZK 的「ZK 桥」，要安全的多。以 ZK 桥为例，它会在目标链上设置专用的验证器合约，直接在链上验证提款证明，免去对链下见证人的依赖。

比如说，一个横跨 ETH 和 Polygon 的 ZK 桥，会在 Polygon 上部署一个验证者合约，暂且记作 Verifier。ZK 桥的 Relayer 节点会将最新的以太坊区块头，及证明有效性的 ZK Proof 转发给 Verifier，由后者验证。这相当于让 Verifier 合约在 Polygon 链上同步并验证最新的以太坊区块头。区块头上记录的 merkle root 与区块内包含的交易集合有关联性，可以用于验证区块中是否包含某笔交易。

如果在区块高度为 101 的以太坊区块内，包含 10 笔从 ETH 到 Polygon 的跨链转账声明，Relayer 会生成与这 10 笔交易相关的 Merkle Proof，向 Polygon 链上的 Verifier 合约提交证明：

101 号以太坊区块内包含 10 笔 ETH 到 Polygon 的跨链交易。当然，ZK 桥可以把 Merkle Proof 进行 ZK 化，直接向 Verifier 合约提交 ZK Proof。这整个流程中，用户只需要信任跨链桥的智能合约没有漏洞，以及零知识证明技术本身安全可靠，不需要像传统多签桥那样引入过多的信任假设。

而「乐观桥 /Optimistic Bridge」要略为不同，一些乐观桥保留了类似于见证人的设定，但是会引入欺诈证明和挑战窗口期，见证人对跨链消息生成多签后，虽然会提交至目标链上，但其有效性不会被立刻认可，要度过一个窗口期且无人提出质疑，才能被判定为有效。这其实和 Optimistic Rollup（乐观 Rollup）的思路有些类似。当然，乐观桥还有其他的产品模式，但归根结底，安全性是靠欺诈证明协议来保障的。

M/N 多签桥的信任假设是 N-(M-1)/N，你要假设网络中的恶意者数量最多只有 M-1 个，则诚实者数量至少为 N-(M-1)。ZK 桥的信任假设可以忽略不计，而基于欺诈证明的乐观桥，信任假设为 1/N，N 个见证人中只需要有一个诚实，愿意对提交至目标链的无效跨链消息进行挑战，便可保证桥的安全。

目前，由于技术上的限制，只能实现比特币向 Layer2 存款方向的 ZK 桥，而如果方向相反，从 Layer2 向比特币链上提款，只支持多签桥或乐观桥，或是类似于通道的模式（下文要讲述的 OP-DLC 桥更像是通道）。要在比特币链上实现乐观桥，就要引入欺诈证明，bitVM 为这一技术的实现创造了良好条件。

在此前的文章《极简解读 BitVM：如何在 BTC 链上验证欺诈证明》，我们曾简单介绍过，BitVM 的欺诈证明，本质是把链下进行的复杂计算任务，拆解为大量的简单步骤，再挑出某一步放在比特币链上直接验证。这种思路和 Arbitrum、Optimism 等以太坊乐观 Rollup 比较类似。

（BitVM2 文档中提到将通过 Lamport 签名把一个计算任务拆分为大量的中间步骤，然后任何人可以对某个中间步骤进行挑战）

当然，上述说法还是比较晦涩，但相信大多数人早就对欺诈证明的含义有所了解。在今天的这篇文章中，受限于整体篇幅，我们不打算对 BitVM 和欺诈证明协议的技术实现细节进行解读，因为这涉及到一系列复杂的交互流程。

我们将从产品与机制设计的角度简要介绍 BitLayer 和 Citrea、BOB 乃至于 BitVM 官方设计的原生 BitVM 桥，以及 Bitlayer 如何通过 OP-DLC 桥来缓解 BitVM 桥的瓶颈，向大家展示如何在比特币链上设计出更优越的提款桥方案。

（Bitlayer 的桥接方案示意图）

Bitlayer 和 Citrea 的 BitVM 桥原理简析

下文中，我们以 Bitlayer 和 Citrea、Bob 已公布的 BitVM 桥方案作为素材，来阐明 BitVM 桥的大体运作流程。

在其官方文档和技术博客中，上述项目方比较清晰的解释了 BitVM 提款桥的产品设计思路（目前处于理论阶段）。首先，当用户通过 BitVM 桥提款时，需要借助 Layer2 上的 Bridge 合约生成提款声明，提款声明中会指定以下关键参数：

• 提款人需在 L2 销毁的映射版 BTC 数量（如 1 个 BTC）；

• 提款人打算支付的跨链手续费（假设为 0.01 个 BTC）；

• 提款人在 L1 的收款地址：L1_receipt；

• 提款人的收款金额（即 1 — 0.01 = 0.99BTC）

之后，上述提款声明会被包含进 Layer2 的区块中。BitVM 桥的Relayer 节点会同步 Layer2 区块，监听其中包含的提款声明，并将其转发给 Operator 节点，由后者为提款用户打款。

这里需要注意的是，Operator 是先自掏腰包在比特币链上为用户打款，也就是替 BitVM 桥「垫付」资金，之后再向 BitVM 桥的资金池申请补偿。

Operator 在申请报销时，需要提供自己在 Bitcoin 链上的垫付证明（就是证明自己在 L1 上向提款用户指定的地址打款了，要把包含在比特币区块中的特定转账记录抽出来）。同时，Operator 还要出具提款人在 L2 生成的提款声明（通过 Merkle Proof，证明出具的提款声明来自于 L2 区块中，而不是自己凭空捏造的）。之后，Operator 需要证明如下事项：

• Operator 替 BitVM 桥垫付给提款人的资金，等于提款人在声明中要求的收款金额；

• Operator 申请报销时，报销金额不多于提款人在 Layer2 销毁的映射版 BTC 金额；

• Operator 的确把一段时间内的 L2-L1 提款声明全部处理了，每一笔提款声明都能匹配到比特币链上的提款转账记录；

这本质是对 Operator 谎报垫付金额，或是拒绝处理提款声明的惩罚（可以解决提款桥的抗审查问题）。Operator 需要在链下对垫付证明和提款声明的关键字段进行对比验证，证明两者涉及的 BTC 数额相等。

而如果提款桥 Operator 谎报垫付金额，就是指 Operator 声称在 L1 上的 payment proof，和 L2 提款人发出的 Withdrawal Statement 相匹配，但实际情况却是两者并不匹配。

这样一来，证明 Payment Proof = Withdrawal Statement 的 ZKP 一定是有错误的。只要这个 ZKP 被发布出去，Challanger 就可以指出其中哪一步有错，并通过 BitVM2 的欺诈证明协议进行挑战。

需要强调的是，Bitlayer 和 Citrea、BOB、ZKBase 等都采用了最新的 BitVM2 路线，也就是新版的 BitVM 方案，这种方案会把链下的计算任务 ZK 化，也就是说，为链下进行的计算过程生成 ZK Proof，然后对 Proof 进行验证，之后把验证 ZKP 的过程转化为适配于 BitVM 的形式，便于后续的挑战。

同时，通过采用 Lamport 和预签名，可以把原始 BitVM 的多轮交互式挑战，优化为单轮非交互式挑战，极大程度降低了挑战的难度。

BitVM 的挑战流程需要用到一种称为「承诺」的东西，即 Commitment。我们解释下什么是「承诺」。一般而言，在比特币链上发布「承诺」的人会声称，某些存放在链下的数据 / 发生在链下的计算任务是准确无误的，而发布到链上的相关声明就是「承诺」。

我们可以近似的把 Commitment 理解为一大批链下数据的 hash。承诺 Commitment 本身的尺寸往往被压缩的很小，但其可以通过 Merkle Tree 等方式，与大量的链下数据相绑定，而这些被关联的链下数据无需上链。

在 BitVM2 和 Citrea、BitLayer 的 BitVM 桥方案中，如果有人认为提款桥 Operator 在链上发布的承诺有问题，该承诺关联了无效的 ZKP 验证流程，就可以发起挑战，而且挑战权限是 Permissionless 的。（里面的交互流程比较复杂，在此不展开解释）

由于 Operator 是替 BitVM 资金池垫付资金来给提款人打款，之后再向资金池申请报销，在申请时，Operator 要发布一个 Commitment，证明自己在 L1 上给提款人转的钱，等于提款人在 L2 上声明要收到的钱。如果这个 Commitment 经过了欺诈证明窗口期仍然没有被挑战，Operator 就可以取走自己需要的报销金额。

这里我们要解释下 BitVM 桥的公共资金池是如何维护的，而这恰恰是跨链桥最关键的部分。大家都知道，跨链桥能兑付给提款人的资金，来源于存款人或是其他 LP 贡献的资产，而 Operator 垫付出去的钱，最终都要从公共资金池抽走，所以单纯看资金的转移结果，BitVM 桥吸收的存款人 Deposit 金额，应等于提款人 Withdraw 的金额。那么如何保管 Deposit 的资金，就是一个很重要的问题。

在大多数比特币 Layer2 的桥接方案中，往往通过多签来管理公共资产，用户的存款被汇总到一个多签账户中，当需要给提款人打款时，就由这个多签账户负责打款，这种方案显然是存在巨大的信任风险的。

而 Bitlayer 和 Citrea 的 BitVM 桥，采用了类似于闪电网络和通道的思想，用户在存款前，会先和 BitVM 联盟进行通讯，让后者进行预签名，以达成以下效果：

用户向充值地址转入存款后，这些钱会直接锁定在一个 Taproot 地址上，只能由桥的 Operator 来领取。而且，Operator 只有向用户垫付了提款资金后，通过申请报销的方式，向上述存款的 Taproot 地址申领资金。挑战期结束后，Operator 才能把一定额度的用户存款取走。

在 BitVM 桥方案中，存在由 N 个成员组建的 BitVM 联盟（BitVM Federation），由他们对用户的存款进行调度。但这 N 个成员无法私自挪用用户的存款，因为用户在向指定地址打款前，会要求 BitVM 联盟先进行预签名，确保这些存款只能被 Operator 合法申领。

（BitVM2 对其乐观桥方案的示意图）

高度概括，BitVM 桥采用了类似于通道和闪电网络的思想，让用户「verify by yourself」，通过预签名的方式让 BitVM 联盟无法擅自操纵存款池，存款池的钱只能用于为 Operator 报销资金。如果 Operator 谎报垫付金额，任何人都可以发布欺诈证明并进行挑战。

如果上述方案可以落地，届时 BitVM 桥将成为最安全的比特币提款桥之一：这种桥不存在安全问题，仅存在可用性 / 活性问题。用户在尝试向 BitVM 存入资金时，可能遭到 BitVM 联盟的审查或拒绝配合，导致无法顺利存入资金，但这与安全无关而属于活性 / 可用性问题。

但 BitVM 桥的落地难度比较大，而且也无法满足一些对资金透明度要求比较高的大户的需求：这些人可能涉及到反洗钱问题，不太希望把自己的资金与别人的资金混到一起，但 BitVM 桥会统一收纳存款者的钱，某种程度上是一个混杂很多钱的池子。

为了解决上述 BitVM 桥的活性问题，以及为有特定需求的人提供独立干净的资金出入通道，BitLayer 团队额外增设了名为 OP-DLC 的跨链桥方案，在 BitVM2 的乐观桥之外，采用了类似于 DLC.link 的 DLC 桥，为用户提供 BitVM 桥和 OP-DLC 桥两个出入口，以此降低对 BitVM 桥乃至于 BitVM 联盟的依赖。

（DLC 原理图）

DLC：谨慎日志合约

DLC（Discreet Log Contracts）名为谨慎日志合约，由 MIT 的 Digital Currency Initiative 提出，该技术最早用于在比特币上实现一种轻量级的智能合约，不需要把合约的内容上链，就可以通过链下交互式通讯和预签名等方法，在比特币链上实现出保护隐私的智能合约功能。下面我们通过一个赌球案例来说明 DLC 的工作原理。

假设 Alice 与 Bob 要对 3 天后举行的皇马和巴萨的比赛结果打赌，两人各出 1 个 btc。如果皇马胜出，则 Alice 可以获得 1.5 BTC，Bob 只能收回 0.5 BTC，这就相当于 Alice 赚 0.5 个 BTC，Bob 亏损 0.5 BTC；如果巴萨胜出，Alice 只能收回 0.5 BTC，Bob 则可以拿走 1.5 BTC。如果平局，两人各自从拿回 1 个 BTC。

如果我们要让上述对赌过程变得去信任化，就要想办法防止任何一方耍赖，如果单纯用 2/2 多签或是 2/3 多签，显然还不够去信任。DLC 针对这一要点给出了自己的解决方案（要依赖于第三方预言机）。其整个工作流程大体可以分为四部分。

以前面的 Alice 和 Bob 为例，首先，双方在链下创建一笔 fund 交易，这可以把彼此的 1 枚 BTC 锁在 2/2 多签地址上，如果这笔 fund 交易生效，则该多签地址里的 2 枚 BTC 需要双方都授权，才能被花费。

当然，这笔 Fund 交易先不上链，只留存在链下的 Alice 和 Bob 客户端本地，他们都知道这笔交易生效后会有什么后果。目前双方只是在进行理论推演，然后根据推演的结果达成一系列协议。

在 DLC 创建的第一阶段，我们可以确定的是，双方将在未来把各自的 1 枚 BTC 锁入一个多签地址中。

第二步，双方继续推演未来可能发生的事件和结果：比如，当球赛结果公布后，可能是 Alice 赢 Bob 输、Alice 输 Bob 赢、平局等多种可能，这会导致前述 2/2 多签地址中的比特币出现不同的分配结果。

不同的结果需要由不同的交易指令来触发，这些「可能在未来上链的交易指令」被称为 CET，即合约执行交易（Contract Execution Transaction）。Alice 和 Bob 要事先推演出所有的 CET，生成包含全部 CET 的交易数据集。

例如，根据前述 Alice 和 Bob 对赌的几种可能结果，Alice 创建出以下几种 CET：

• CET1：Alice 可从多签地址获得 1.5 枚 BTC，Bob 可获得 0.5 枚 BTC；

• CET2：Alice 可从多签地址获得 0.5 枚 BTC，Bob 可获得 1.5 枚 BTC；

• CET3：双方各自可获得 1 枚 BTC。

我们以 CET1 为例（Alice 拿 1.5 BTC，Bob 拿 0.5 BTC）：

这笔交易的意思是，把多签地址中的 1.5 枚 BTC，转移到一个由 Alice 和预言机输出结果共同触发的 Taproot 地址，另外 0.5 枚 BTC 转移给 Bob 的地址。此时对应的事件是：皇马胜出，Alice 赢 0.5BTC，Bob 输 0.5BTC。

当然，要花费这 1.5 枚 BTC，Alice 必须拿到预言机发送的「皇马胜出」结果签名。换句话说，只有当预言机输出「皇马胜利」的消息后，Alice 才能够把这 1.5 枚 BTC 转走。至于 CET2 和 CET3 的内容，我们可以以此类推，在此不赘述。

需要注意的是，CET 本质是一笔待上链待生效的交易，如果 Alice 提前把 CET1 广播出去，或是在「巴萨胜出」的情况下，仍然把「皇马胜出」后才能顺利触发的 CET1 上链，会发生什么？

前面的示意图中，我们提到，CET1 上链后，会把原始多签地址中锁定的 2 枚 BTC 转走，0.5 枚 BTC 转给 Bob，1.5 枚 BTC 转到一个 Taproot 地址中，预言机输出「皇马胜出」后，Alice 方能解锁 Taproot 地址锁定的 BTC。效果如下图所示。

同时，这个 Taproot 地址受到时间锁限制，如果在时间锁规定的窗口期内，Alice 无法成功提走 1.5 枚 BTC，则 Bob 有权把这些钱直接拿走。

所以，只要预言机是诚实的，Alice 就无法拿走这 1.5 枚 BTC，等时间锁期限耗尽，Bob 可以把这 1.5 枚 BTC 拿走。再算上 CET1 上链时直接转给 Bob 的那 0.5 枚 BTC，最后所有的钱都会归 Bob 所有。

对于 Alice 而言，无论自己最终是赢还是输，最有利的做法都是把正确的 CET 上链，把无效的 CET 上链会让自己输更多钱。

其实上述 CET 在构建时，对 Taproot 的 schnorr 签名做了改进，可以理解为利用预言机的公钥 + 事件结果，针对不同结果构造出彼此独立的地址。之后，等预言机公布某个结果对应的签名，才能花费该结果对应的地址上锁定的 BTC。

当然，这里面存在一种额外的可能。假如 Alice 知道自己输了，干脆不把自己构建的 CET1 上链，这个时候怎么办？这个很好解决，因为Bob 可以针对「alice 输，Bob 赢」一事构建出自定义的 CET，这个 CET 达成的效果和 Alice 构建的 CET 基本一致，只是具体细节不一样，但结果是一样的。

上面讲述的就是最关键的 CET 构建流程。而 DLC 的第三步，是 Alice 和 Bob 双方进行通讯，检查对方构建的 CET 交易，带上自己对该 CET 的签名，检查无误后，可以信任彼此，便各自出资 1 枚 BTC，锁入最开始提到的那个 Alice 和 Bob 的 2/2 多签地址，然后等待某个 CET 被上链，触发后续的流程。

最后，等预言机公布结果，拿到预言机对结果的签名后，任意一方可以把正确的 CET 上链，让多签地址中锁定的 2 枚 BTC 被再分配，如果输家抢先把错误的 CET 上链，会让自己损失所有的钱，如果把正确的 CET 上链，输家还可以收回 0.5BTC。

可能有人会问，DLC 与普通的 2/3 多签有何不同？首先，2/3 多签下，任意两方串谋即可盗走全部资产，而 DLC 通过提前构建 CET 集合的方式，让对手方之间把全部的场景都限制住了，就算预言机参与串谋，造成的损失往往也有限。

其次，多签需要各方针对具体的待上链交易进行签名，而在 DLC 的设定下，预言机只需要对特定事件的结果进行签名，不需要知道 CET/ 待上链交易的内容，甚至完全不需要知道有 Alice 和 Bob 这两个人，只需要像普通的预言机那样和用户进行正常的交互即可。

我们可以认为，DLC 本质是把对多签参与方的信任转变成了对预言机的信任，只要预言机不参与作恶，就可以保证 DLC 的协议设计足够去信任。理论上来说，DLC 可以采用比较成熟完善的第三方预言机，来避免作恶。而 DLC.link 和 BitLayer 利用了 DLC 的这种特性，把桥的信任问题转嫁给了第三方预言机。

此外，Bitlayer 的 DLC 桥还支持自建的预言机节点，在此之上加上了一层欺诈证明，当自建的预言机把无效的 CET 上链时，允许任何人对其进行挑战。关于其 OP-DLC 桥的原理，我们将在下面展开简述。

OP-DLC 桥：DLC 通道 + 欺诈证明

我们从存取款的全流程来解释 OP-DLC 桥的运转原理。假设现在 Alice 通过 OP-DLC 桥向 L2 存款 1 枚 BTC，根据两步交易机制，ALice 先生成一个 pre-fund 交易，如下图：

这其实是先把 1 枚 BTC 转移到 Alice 和 BitVM 联盟成员共同控制的 Taproot 地址中，然后开启创建 CET 的一系列流程。如果 BitVM 桥联盟成员拒绝配合 Alice 的存款请求，Alice 可以等时间锁结束后，把钱立刻抽回去。

如果 BitVM 联盟成员愿意配合 Alice，双方便通过链下通讯的方式，先生成正式的 Fund 存款交易（先不上链），以及提款场景下全部的 CET，待 CET 生成和检验结束后，双方才把 Fund 交易提交上链。

在 Fund 交易的 Witness/ 签名数据里，Alice 会指定自己在 Layer2 的收款地址；Fund 交易上链后，Alice 可以向 Layer2 上的桥合约提交上述 fund 交易数据，证明自己在比特币链上完成了存款动作，有资格让 L2 桥合约向指定的收款地址释放 Token。

Fund 交易触发后，存款实际上还是被锁定于 Alice 和 BitVM 联盟成员共同控制的 Taproot 多签地址中。但要注意，该多签只能通过 CET 来解锁该地址锁定的 BTC，BitVM 联盟不能平白无故把钱转走。

接下来我们来解析 Alice 和 BitVM 联盟事先构建好的 CET。这些 CET 用来满足未来提款时的潜在场景，比如 Alice 可能存入了 1 枚 BTC，但她初次提款时只提走 0.3 枚 BTC，剩下的 0.7 枚 BTC 交由 BitVM 联盟的公共资金池来支配，但要再提款就只能通过前文讲过的 BitVM 桥；

或者干脆用这 0.7 枚 BTC 发起一次新的 pre-fund 存款，当做是一笔新充入 DLC 桥的资产，可以重复前面提过的 fund 交易和 CET 构建流程。

上述流程不难理解，其实就是让存款人 Alice 和 bitVM 联盟互相充当对手方，为不同金额的提款事件创建 CET，然后让预言机读取 Alice 在 Layer2 发起的提款声明，判断 Alice 想触发哪一个 CET（想提多少钱）。

这里面的风险在于，预言机可能和 BitVM 联盟串谋，比如 Alice 声明要提款 0.5 枚 BTC，预言机却伪造了提款声明，最终使得「Alice 收回 0.1BTC，BitVM 联盟收到 0.9BTC」的错误 CET 上链。

对此的解决方法有好几种，首先就是可以采用在设计上比较完善的第三方预言机，防止此类串谋行为（此时 BitVM 联盟要和预言机串谋的拉拢难度极高），或者让预言机进行质押，预言机需要定期在比特币链上发布 Commitment，声明自己诚实的处理了提款人的提款请求。任何人都可以通过 BitVM 的欺诈证明协议对 Commitment 进行挑战，如果挑战成功，就 Slash 作恶的预言机。

在 OP-DLC 桥的设计下，用户可以始终对自己的资产「参一手」，防止资产被 BitVM 联盟挪用，而且这种类似于通道的设计方案，为用户带来了更多的自主权，也不需要让自己的资金和其他人的资金混到一起，更像一种 P2P 点对点的存取款方案。

此外，考虑到 BitVM 方案要过一段时间才能落地，在其落地前，相比于单纯的多签方案，DLC 桥都是更可靠的桥接处理模型。这种方案也可以作为与 BitVM 桥并行使用的两大存取款出入口，其中一个出了故障后，用户可以走另一个出入口，也不失为一种好的容错方法。

总结

BitLayer 和 Citrea 的 BitVM 桥方案，本质是「垫付 - 报销」模式，有专门的 Operator 节点为提款用户打钱，Operator 可以定期向公共存款地址申请报销。如果 Operator 存在不实的报销申请，可以被任何人挑战并 Slash。

BitVM2 的方案引入预签名，结合了通道的思想，让用户在正式存款前，对存款执行后的处理流程进行限定，不给跨链桥官方挪用用户存款的机会。

这种桥在理论上不存在安全问题，但存在活性 / 可用性问题，而且不能满足特定用户对资金独立性和反洗钱的需求（本质还是资金池的模式），落地难度也很大。

为此，Bitlayer 增设了名为 OP-DLC 的桥接方案，该方案类似于 DLC.link，在通道和 DLC 的基础上引入欺诈证明，防止 DLC 桥的预言机作恶。

但由于 BitVM 的落地难度太大，DLC 桥会率先落地并成暂时的替代物，只要解决预言机的信任风险，集成更为可靠成熟的第三方预言机，DLC 桥可以在现阶段成为比多签桥更安全的提款验证方案。

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。